Монетизация: как мы вредили себе и пользователям

История о том, как мы сделали платным всё в приложении, потом аккуратно экспериментом это изменили и офигели от результатов.

Развитие продукта похоже на постройку дачи. Сперва ты делаешь фундамент для одноэтажного дома, всё продуманно и логично. Потом возникает шальная мысль: «Почему бы не сделать второй этаж?» Ничего плохого же, а площади станет только больше. После этого идёт пристройка c балконом, гараж, баня, сарай, веранда с навесом, и в итоге всё это выглядит очень плохо и нелогично — и иногда в процессе разваливается.

В продуктах та же история: всё начинается с MVP, потом с каждой итерацией на продукт нанизываются всё новые и новые функции, навигация загромождается, дизайн становится всё сложнее. Многие в этот момент понимают: дальше уже нельзя, пора что-то менять, вносить изменения становится с каждым днём всё сложнее. Самые смелые команды находят силы реагировать радикально: выкинуть всё и написать с нуля.

Но это касается не только дизайна. Если у вас freemium-приложение, велика вероятность, что ваш фичер-сет, закрытый покупками, — это та самая дача, легаси давно ушедших дней, которое надо полностью пересмотреть. Во всяком случае так было у нас.

Freemium — это модель монетизации и дистрибуции сервиса, при которой пользование возможно без оплаты, но с какими-то ограничениями. Как правило, это ограничения трёх типов:

• Функциональные. При покупке разблокируются новые возможности. Примеры: YouTube Premium (подписка даёт офлайн-просмотр, просмотр в фоне, отсутствие рекламы и прочее), Tinder (подписка даёт суперлайки, бусты, расширение зоны поиска и так далее).
• Ограничение квоты. Использовать продукт можно без ограничений до определённой квоты. Примеры: Dropbox (лимит на место), Slack (лимит на интеграции, количество сообщений), CleverPay (лимит на MAU).
• Ограничение поддержки. Формат, редко встречающийся в b2c-секторе, чаще в b2b-секторе enterprise-уровня, очень часто совмещённый с OSS-проектами (nginx, SphinX, MongoDB, RHEL, elasticsearch, и так далее). Само ПО распространяется бесплатно, а за деньги вы получаете расширенную поддержку от команды.

Дальше речь пойдёт про первые два типа ограничений, поскольку третий вид слишком специфичный.

Что характеризует большинство успешных b2c-проектов, выбравших freemium, так это то, что множество людей могут годами пользоваться сервисом, не заплатив ни цента. Я лично пользуюсь Dropbox с 2009 года и ни разу не платил. Notion, «Google Диск», Evernote — ни один из этих сервисов не получил от меня ни цента, хотя эти продукты я очень ценю и пользуюсь ими.

Ограничения часто поначалу кажутся недостижимыми. Только пользователь, плотно подсевший и использующий продукт годами, начнёт платить. Это игра вдолгую, но и шанс бесконтрольного роста аудитории значительно выше благодаря реферальному трафику: людям проще рекомендовать то, что они по-настоящему ценят.

Если рассматриваете freemium, тогда вот несколько условий, которым лучше соответствовать:

• У вас классный продукт. Ваш хлеб и соль — это рекомендации, а друзьям фигню не рекомендуют.
• Бесплатные пользователи вас не разорят. Если 95% пользователей будут сидеть на горбу 5% платящих, ваша компания должна находить в этом прибыль.
• Это большой рынок с огромным количеством пользователей. Иначе рекомендации не сработают.
• Ваш продукт про регулярное использование. Иначе пользователи не столкнутся с ограничениями, а вы… вы закроетесь.

В b2b ситуация сложнее и мотивов для выбора freemium-модели больше. Об этом мы поговорим в другой раз.

Это ключевой вопрос, который может сломать всё: вашу доходность, вашу реферальную программу и даже продукт. Ответ никто не знает, а кто говорит, что знает, тот врёт.

Это как вопрос с ценой продукта: ты всегда ставишь первую цену, основываясь на своём представлении о ценности продукта, а потом меняешь её в зависимости от реакции рынка.

Что следует учесть, если вы только разрабатываете продукт:

• Ваша задача — максимизировать удержание и использование сервиса. Если есть много аудитории и сессий, то монетизировать её — дело техники. Не задушите пользователя в попытке его ограничить.
• Сделать доступной ту возможность, которая была недоступна, проще, чем наоборот.
• Готовьтесь к тому, что вы будете экспериментировать — и много — с доступностью функций.

Мы сделали yet another трекер расходов для смартфона. По ряду причин мы решили, что проще ограничивать доступ к функциям. В самом начале приложение было только про расходы.

Со временем добавлялись новые функции: учёт доходов, учёт долгов, отчёты, ведение совместного кошелька и так далее. Все новые функции мы аккуратно прятали за премиум-подписку, полагая, что основы — учёта расходов — вполне хватит для счастливой жизни большинству пользователей.

Мы ошибались. Новые функции для премиум-подписки наслаивались, а бесплатный план никак не менялся, и от этого сильно страдало удержание. Мы это понимали, сравнивая удержание платящих и неплатящих пользователей, но не знали, как с этим бороться.

Когда мы перепробовали всё, чтобы поднять удержание, мы решили сделать одну из платных функций бесплатной. Это был прыжок веры: мы взяли самую активно используемую функцию, которая больше всего коррелировала с высоким удержанием аудитории. Пользователи чаще всего просили сделать функцию бесплатной, и перенесли её в бесплатный план.

Доступность функций была гвоздями прибита к наличию подписки, поэтому этот эксперимент потребовал привлечения разработчиков и переписывания одной из старейших частей приложения. Потратив на весь цикл полторы недели (ТЗ, разработка, ревью, тестирование, сборка и так далее), мы выпустили новую версию.

Мы запустили функциональный эксперимент, направив две трети новых пользователей по старой версии продукта, где учёт доходов платный, а одну треть — на новую, где учёт доходов даётся бесплатно. Мы были готовы ко всяким плохим исходам с падением денежных метрик, но получили мы нечто совершенно неожиданное.

Вот так выглядел график удержания. Две контрольные группы — АА-тест — закрылись очень хорошо. В результате эксперимента тестовая группа вырвалась вперёд в первый же день, к концу недели уже стало всё более-менее понятно. Через неделю после запуска мы закрыли набор пользователей в эксперимент. С удержанием всё стало ясно: рост был около 20%, и тестовая группа бескомпромиссно победила в эксперименте.

С покупками всё было сложнее. Если у вас подписочная модель, смотреть на конверсию мало, надо всегда следить за продлениями. Продления — это лакмусовая палочка того, насколько ценный у вас платный продукт.

Мы ждали два месяца после закрытия набора пользователей в эксперимент, чтобы у пользователей в эксперименте был месяц на первую покупку и ещё месяц — на первое продление. В процессе мы поняли, что закрыв набор пользователей в эксперимент достаточно рано, мы сделали его менее достоверным. Но выводы сделать всё равно можно.

Мы вывели функцию из премиум-подписки, по идее сделав её менее ценной. Но каким-то образом мы умудрились вырасти в конверсии и не потерять в продлениях. Помимо этого у нас сильно выросло удержание, а это всегда имеет долгий хвост эффекта: когда-нибудь у нас будет распродажа, и те удержанные пользователи будут готовы купить что-нибудь по сниженной цене.

Тогда у нас была только MVP виральной программы, поэтому динамику приглашённых в сервис я показать не могу, но что-то мне подсказывает, что там тоже всё выросло.

В результате одного эксперимента мы вырастили конверсию на 15% и месячное удержание на 60%.

После эксперимента с доходами мы провели полный пересмотр нашей платной подписки и запустили 12 экспериментов. Чтобы проводить их быстрее и не подключать команду разработки каждый раз, мы вспомнили старый концепт, известный как feature toggling, и добавили в него немного модификаций. Подробнее о технической стороне вопроса можно прочитать в нашем блоге.

В приложении было около десяти серьёзных функций, доступность которых мы хотели проверить. Мы научили приложение не полагаться на наличие подписки, а вместо этого слушать сервер, который решал, имеет ли конкретный пользователь доступ к этой функции или за неё надо заплатить.

Такой подход открыл нам огромный простор для экспериментов. Среди самых интересных экспериментов мы проверили:

• Подходит ли нам ограничение квоты. Мы открыли все функции, но ограничили количество создаваемых сущностей 100 штуками.
• Разделение подписки на несколько уровней. В добавок к обычному Premium по сниженной цене мы ввели SuperPremium по повышенной, куда отправили ряд нишевых функций.
• Влияние доступности функций на удержание и монетарные метрики. Тот же эксперимент, что с учётом доходов, только с прочими функциями приложения.
• Может, подписки — это не для нас? Мы попробовали предлагать пользователям разблокировать функции приложения по одноразовой покупке и навсегда.
• Разблокируем возможности на приглашения пользователей. Часть нашей виральной программы позволяла за приглашения активных пользователей получать определённые функции бесплатно.

Самое ценное, что всё это было вне релизного цикла и без привлечения разработчиков. Мы садились, придумывали эксперимент и запускали его, а наши разработчики дальше работали над продуктом.

Не все мы станем, как Dropbox или Tinder, но мы можем к этому стремиться. Если вы не уверены на 100% в том, за что берёте деньги, то имеет смысл это проверять. Выдвигайте гипотезы, обоснованные хотя бы чем-нибудь (обращениями в саппорт, статистикой, «продуктовой чуйкой» — чем угодно) и проверяйте экспериментальным способом.

А вы экспериментируете над доступностью функций в приложении?