Ох, я несколько недель вынашивал этот пост. У меня не было никогда единого списка тех практик, что у меня в голове, и вспомнить все в один момент оказалось нереальным. Обычно знания всплывают под контекст ситуации. Поэтмоу я просто в течении недель записывал, что всплывало, а вчера был диалог по монетизации и вечером я на фоне конеткста еще что-то добил. Это 100% не все, до круглого числа я не стал добивать, но в последствии в моем Telegram канале будут продолжения.
1. Тестируйте новые модели монетизации раз в 3–6 месяцев - регулярный пересмотр = рост.
2. При снижении конверсии более чем на 20% после изменения прайсинга - откатить, даже если ARPU вырос. В PLG важен рост, не только выручка.
3. Разница между соседними планами - оптимально x1.5–x4. Больше - только при переходе в sales-led. >x4+ допустимо только при радикально разной ценности (SLA, кастом, onboarding).
4. Минимальная разница между планами - 30–50%, иначе пользователь не видит смысла платить больше.
5. У тарифов должен быть один основной ростовой параметр (core value demention) — например, пользователи или задачи. Второй demention - вводится как модификатор.
6. Тестируйте разные ростовые единицы (dementions) - пользователи, проекты, API-запросы, минуты, карточки и т.п.
7. Лучший момент для апсейла - при использовании 80% лимита. Поздно = потеря денег, рано = раздражение.
8. Предлагайте апгрейд при попытке превышения лимита, но без жёсткой блокировки - conversion - растет, отток - нет.
9. Paywall должен быть полезным - показывайте, за что берёте деньги, а не просто “заплати”.
11. Показывайте ценность рядом с ценой - например: “$99 - экономит 12 часов / $1000”.
ARPU не всегда цель. CAC Payback Time < 3 месяца - цель. ARPU может расти при убыточной модели.
12. Не прячьте ключевые фичи в самый дорогой тариф, если они нужны для discovery ценности.
13. Точка перехода на платный тариф = момент стабильной пользы, не первой эмоции.
14. Идеальный триггер оплаты - повторяемая польза, а не вау-эффект.
15. Формулируйте фичи тарифов в терминах результата, не действия - “отчет за 2 клика”, а не “аналитика”.
16. Бесплатный план - с ограничением по power-использованию, но не по базовым действиям.
17. Performance-based pricing работает, только если результат под контролем продукта - например, карточки товаров (продукт для маркетплейс sallers), а не продажи клиента.
18. Добавьте возможность частичного апгрейда (докупать пакеты) - гибкость -> доход.
19. A/B тесты тарифов - сравнивать по LTV, а не по ARPU в моменте.
20. Сопряжение триала с конкретным действием (например, “чтобы экспортировать - оплатите”) лучше, чем таймер.
21. Оптимальная скидка за год - 20–25%. Больше = плохой retention или попытка выжить churn.
22. Enterprise pricing = кастомизация + поддержка. Не публикуйте цену - используйте CTA “Contact Sales”.
23. Пересматривайте тарифы не реже раза в год. Рынок и ценность меняются.
24. Новых клиентов можно переводить на новые цены, старым - сохранить старые (grandfathering).
25. При откате прайсинга - отключить метрику в BI, пересчитать ретроспективно.
26. Храните конфигурации всех тарифов, даже удалённых. Аналитика и поддержка скажут спасибо.
27. Если пользователю не хватает чуть-чуть - предложите “разблокировать на день” фичу.
28. Даже самый дешёвый план должен быть profit-positive, иначе это не продукт, а маркетинг.
29. Никаких бессрочных лицензий, только подписка.
30. Сделайте конфигуратор тарифов в UI, чтобы пользователь сам моделировал стоимость. Повышает конверсии.
31. Локализуйте цены по регионам. Без этого conversion проседает.
32. Используйте прогрев-уведомления: 70% -> 90% -> превышение лимита.
33. Не прячьте цены за формами, если это не enterprise-план.
34. Segment WTP (willingness to pay) определяется по поведению, а не по типу компании.
35. Переход от feature-based к usage-based — это нагрузка на поддержку. Планируйте.
36. Если API даёт ценность - монетизируйте его отдельно. Но обязательно ограничьте abuse.
37. В Enterprise ценность не равно фичи. Это: SLA, кастомизация, onboarding.
38. Внедрите auto-upgrade при росте usage, особенно в PLG.
39. Churn анализируйте по доходу, а не по числу юзеров. Потеря 5% может быть всего 2% выручки - или 50%.
40. Никогда не делайте unlimited core-ценности в базовом плане. Если ваш продукт про видео - нельзя давать unlimited видео. Если про юзеров - нельзя unlimited юзеров.
41. Делайте effectively unlimited, но с защитой. Например, "До 1 млн задач в месяц", что для 99.9% = unlimited, но для abuse есть потолок.
42. Привязывайте unlimited к фиксированной стоимости обслуживания. Например: unlimited storage только если это S3 с понятной ценой. А вот unlimited GPU-рендеринг - риск.
43. Unlimited - только на том, где нет высокой вариативности затрат. Не давайте unlimited API, если нет rate limiting. Не давайте unlimited пользователей, если у вас нагрузка на каждый аккаунт.
44. Unlimited = anchor для апсейла. Работает как верхний план для старших клиентов, не чтобы его покупали массово, а чтобы middle план казался выгодным.
45. Unlimited можно ограничить по fair use policy. Пример: “Unlimited при использовании: не более 10,000 задач/день”.
46. Тестируйте восприятие unlimited в A/B - часто 90% пользователей не замечают ограничений, но слово "unlimited" триггерит покупку.
47. Unlimited в enterprise - нормально. В PLG - рискованно. В self-serve лучше работать с масштабируемыми лимитами (tiered pricing), чем с hard unlimited.
48. Не бойтесь продавать фич, которых нет. Создайте план с лейблом [coming soon] и скидкой от завышеной цены, провалидируйте покупаемость и потом делайте фичи.
49. Подключайте всегда сразу нормальную платежку. Лучше потратиться на организацию инфраструктуры для подключения Stripe, чем потом заниматься кастомной разработкой под неразвитые системы.
50. "Гарантируем вернуть деньги в течении 60 дней" - отлично конвертирует в SaaS, где LT для роста все равно должен быть не менее 12 месяцев.
51. Нормальное соотношение годвых к месяыным планам - 60/40.
52. Триал до 14 дней - делает перекос в сторону месяыных планов, надо планировать механнику апдейтов на год.
53. На старте проукта делайте даунгрейды и отмены подписок только через customer success.
54. Лучшие продажи идут через саппорт. Не берить в штат только тех, кто может вести саппорт не продавай на старте продукта.
55. В PLG должен быть масштабируемый fremium план.
Больше уникального материала в Telegram канале - Supervision.PM | Подписаться