Развитие продукта похоже на постройку дачи. Сперва ты делаешь фундамент для одноэтажного дома, всё продуманно и логично. Потом возникает шальная мысль: «Почему бы не сделать второй этаж?» Ничего плохого же, а площади станет только больше. После этого идёт пристройка c балконом, гараж, баня, сарай, веранда с навесом, и в итоге всё это выглядит очень плохо и нелогично — и иногда в процессе разваливается.
В продуктах та же история: всё начинается с MVP, потом с каждой итерацией на продукт нанизываются всё новые и новые функции, навигация загромождается, дизайн становится всё сложнее. Многие в этот момент понимают: дальше уже нельзя, пора что-то менять, вносить изменения становится с каждым днём всё сложнее. Самые смелые команды находят силы реагировать радикально: выкинуть всё и написать с нуля.
Но это касается не только дизайна. Если у вас freemium-приложение, велика вероятность, что ваш фичер-сет, закрытый покупками, — это та самая дача, легаси давно ушедших дней, которое надо полностью пересмотреть. Во всяком случае так было у нас.
Freemium — это модель монетизации и дистрибуции сервиса, при которой пользование возможно без оплаты, но с какими-то ограничениями. Как правило, это ограничения трёх типов:
Дальше речь пойдёт про первые два типа ограничений, поскольку третий вид слишком специфичный.
Что характеризует большинство успешных b2c-проектов, выбравших freemium, так это то, что множество людей могут годами пользоваться сервисом, не заплатив ни цента. Я лично пользуюсь Dropbox с 2009 года и ни разу не платил. Notion, «Google Диск», Evernote — ни один из этих сервисов не получил от меня ни цента, хотя эти продукты я очень ценю и пользуюсь ими.
Ограничения часто поначалу кажутся недостижимыми. Только пользователь, плотно подсевший и использующий продукт годами, начнёт платить. Это игра вдолгую, но и шанс бесконтрольного роста аудитории значительно выше благодаря реферальному трафику: людям проще рекомендовать то, что они по-настоящему ценят.
Если рассматриваете freemium, тогда вот несколько условий, которым лучше соответствовать:
В b2b ситуация сложнее и мотивов для выбора freemium-модели больше. Об этом мы поговорим в другой раз.
Это ключевой вопрос, который может сломать всё: вашу доходность, вашу реферальную программу и даже продукт. Ответ никто не знает, а кто говорит, что знает, тот врёт.
Это как вопрос с ценой продукта: ты всегда ставишь первую цену, основываясь на своём представлении о ценности продукта, а потом меняешь её в зависимости от реакции рынка.
Что следует учесть, если вы только разрабатываете продукт:
Мы сделали yet another трекер расходов для смартфона. По ряду причин мы решили, что проще ограничивать доступ к функциям. В самом начале приложение было только про расходы.
Со временем добавлялись новые функции: учёт доходов, учёт долгов, отчёты, ведение совместного кошелька и так далее. Все новые функции мы аккуратно прятали за премиум-подписку, полагая, что основы — учёта расходов — вполне хватит для счастливой жизни большинству пользователей.
Мы ошибались. Новые функции для премиум-подписки наслаивались, а бесплатный план никак не менялся, и от этого сильно страдало удержание. Мы это понимали, сравнивая удержание платящих и неплатящих пользователей, но не знали, как с этим бороться.
Когда мы перепробовали всё, чтобы поднять удержание, мы решили сделать одну из платных функций бесплатной. Это был прыжок веры: мы взяли самую активно используемую функцию, которая больше всего коррелировала с высоким удержанием аудитории. Пользователи чаще всего просили сделать функцию бесплатной, и перенесли её в бесплатный план.
Доступность функций была гвоздями прибита к наличию подписки, поэтому этот эксперимент потребовал привлечения разработчиков и переписывания одной из старейших частей приложения. Потратив на весь цикл полторы недели (ТЗ, разработка, ревью, тестирование, сборка и так далее), мы выпустили новую версию.
Мы запустили функциональный эксперимент, направив две трети новых пользователей по старой версии продукта, где учёт доходов платный, а одну треть — на новую, где учёт доходов даётся бесплатно. Мы были готовы ко всяким плохим исходам с падением денежных метрик, но получили мы нечто совершенно неожиданное.
Вот так выглядел график удержания. Две контрольные группы — АА-тест — закрылись очень хорошо. В результате эксперимента тестовая группа вырвалась вперёд в первый же день, к концу недели уже стало всё более-менее понятно. Через неделю после запуска мы закрыли набор пользователей в эксперимент. С удержанием всё стало ясно: рост был около 20%, и тестовая группа бескомпромиссно победила в эксперименте.
С покупками всё было сложнее. Если у вас подписочная модель, смотреть на конверсию мало, надо всегда следить за продлениями. Продления — это лакмусовая палочка того, насколько ценный у вас платный продукт.
Мы ждали два месяца после закрытия набора пользователей в эксперимент, чтобы у пользователей в эксперименте был месяц на первую покупку и ещё месяц — на первое продление. В процессе мы поняли, что закрыв набор пользователей в эксперимент достаточно рано, мы сделали его менее достоверным. Но выводы сделать всё равно можно.
Мы вывели функцию из премиум-подписки, по идее сделав её менее ценной. Но каким-то образом мы умудрились вырасти в конверсии и не потерять в продлениях. Помимо этого у нас сильно выросло удержание, а это всегда имеет долгий хвост эффекта: когда-нибудь у нас будет распродажа, и те удержанные пользователи будут готовы купить что-нибудь по сниженной цене.
Тогда у нас была только MVP виральной программы, поэтому динамику приглашённых в сервис я показать не могу, но что-то мне подсказывает, что там тоже всё выросло.
В результате одного эксперимента мы вырастили конверсию на 15% и месячное удержание на 60%.
После эксперимента с доходами мы провели полный пересмотр нашей платной подписки и запустили 12 экспериментов. Чтобы проводить их быстрее и не подключать команду разработки каждый раз, мы вспомнили старый концепт, известный как feature toggling, и добавили в него немного модификаций. Подробнее о технической стороне вопроса можно прочитать в нашем блоге.
В приложении было около десяти серьёзных функций, доступность которых мы хотели проверить. Мы научили приложение не полагаться на наличие подписки, а вместо этого слушать сервер, который решал, имеет ли конкретный пользователь доступ к этой функции или за неё надо заплатить.
Такой подход открыл нам огромный простор для экспериментов. Среди самых интересных экспериментов мы проверили:
Самое ценное, что всё это было вне релизного цикла и без привлечения разработчиков. Мы садились, придумывали эксперимент и запускали его, а наши разработчики дальше работали над продуктом.
Не все мы станем, как Dropbox или Tinder, но мы можем к этому стремиться. Если вы не уверены на 100% в том, за что берёте деньги, то имеет смысл это проверять. Выдвигайте гипотезы, обоснованные хотя бы чем-нибудь (обращениями в саппорт, статистикой, «продуктовой чуйкой» — чем угодно) и проверяйте экспериментальным способом.
А вы экспериментируете над доступностью функций в приложении?