Монетизация: как мы вредили себе и пользователям
История о том, как мы сделали платным всё в приложении, потом аккуратно экспериментом это изменили и офигели от результатов.
Развитие продукта похоже на постройку дачи. Сперва ты делаешь фундамент для одноэтажного дома, всё продуманно и логично. Потом возникает шальная мысль: «Почему бы не сделать второй этаж?» Ничего плохого же, а площади станет только больше. После этого идёт пристройка c балконом, гараж, баня, сарай, веранда с навесом, и в итоге всё это выглядит очень плохо и нелогично — и иногда в процессе разваливается.
В продуктах та же история: всё начинается с MVP, потом с каждой итерацией на продукт нанизываются всё новые и новые функции, навигация загромождается, дизайн становится всё сложнее. Многие в этот момент понимают: дальше уже нельзя, пора что-то менять, вносить изменения становится с каждым днём всё сложнее. Самые смелые команды находят силы реагировать радикально: выкинуть всё и написать с нуля.
Но это касается не только дизайна. Если у вас freemium-приложение, велика вероятность, что ваш фичер-сет, закрытый покупками, — это та самая дача, легаси давно ушедших дней, которое надо полностью пересмотреть. Во всяком случае так было у нас.
Что такое freemium в двух словах
Freemium — это модель монетизации и дистрибуции сервиса, при которой пользование возможно без оплаты, но с какими-то ограничениями. Как правило, это ограничения трёх типов:
- Функциональные. При покупке разблокируются новые возможности. Примеры: YouTube Premium (подписка даёт офлайн-просмотр, просмотр в фоне, отсутствие рекламы и прочее), Tinder (подписка даёт суперлайки, бусты, расширение зоны поиска и так далее).
- Ограничение квоты. Использовать продукт можно без ограничений до определённой квоты. Примеры: Dropbox (лимит на место), Slack (лимит на интеграции, количество сообщений), CleverPay (лимит на MAU).
- Ограничение поддержки. Формат, редко встречающийся в b2c-секторе, чаще в b2b-секторе enterprise-уровня, очень часто совмещённый с OSS-проектами (nginx, SphinX, MongoDB, RHEL, elasticsearch, и так далее). Само ПО распространяется бесплатно, а за деньги вы получаете расширенную поддержку от команды.
Дальше речь пойдёт про первые два типа ограничений, поскольку третий вид слишком специфичный.
Когда стоит выбирать freemium
Что характеризует большинство успешных 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% в том, за что берёте деньги, то имеет смысл это проверять. Выдвигайте гипотезы, обоснованные хотя бы чем-нибудь (обращениями в саппорт, статистикой, «продуктовой чуйкой» — чем угодно) и проверяйте экспериментальным способом.
А вы экспериментируете над доступностью функций в приложении?
А каким образом вы выстроили в сторах разные модели монетизации? Публиковали несколько приложений со схожими названиями и разными покупками?
Мы заведомо интересуемся только моделями, связанными с встроенными покупками.
Приложение у нас одно, и мы в нём мы используем SDK CleverPay.io. Они (то есть мы, это наш сервис) как раз дают относительно просто проводить эксперименты с доступностью функций и с выбором модели монетизации.
Приложение одно, но поведение разное. Всё управляется удалённо. Про техническую часть можно почитать здесь: https://cleverpay.io/blog/feature-toggling
просто удалённым конфигом управляли набором доступных функций
Как мы вредили себе и пользователям
Монетизацией
Не сыпьте соль на рану, пжл.
Я читал наискосок (экономил время) и главный вывод статьи остался непонятым. Все свелось к сравнению "тестовых" и "контрольных" групп, а что стоит за этими терминами уже непонятно. Вы для таких как я гуманитариев с рассеяным вниманием, напишите в конце статьи вывод крупными буквами - мол, ввели платную функцию - конверсия повысилась/понизилась на столько-то. Не ввели - на столько-то.
TL;DR: сделали платную фичу бесплатной, вырастили конверсию на 15% и месячное удержание на 60%.
Я не Тони Роббинс, чтобы давать простые рецепты успеха :) Никаких простых выводов из истории сделать нельзя, мне кажется.