Лагідна монетизація: від ідеї до +21% зростання ARPU менш ніж за дев’ять місяців
Усім хелоу! На зв’язку Роман Калинчук, Senior Product Manager Taimi в українській продуктовій ІТ-компанії appflame, і це мій продуктовий щоденник.
На його сторінках ви прочитаєте історію про те, як я вже близько року покращую монетизацію на одному із продуктів компанії. Мова про Taimi — це мобільний застосунок для знайомств, розроблений спеціально для LGBTQIA+ спільноти.
Для мене робота в дейтингу — це експерименти на межі психології та розробки (або на межі друзі пишаються, а бабуся не розуміє). Це коли треба мати неабиякий досвід та дуже гарно розуміти аудиторію, адже мікс та основа для твоїх гіпотез — сухі дані та поведінкові моделі користувачів.
Минулого року мені запропонували очолити монетизаційний напрям у продуктовому сабдепартаменті. Особисто для себе я розцінював це як виклик, оскільки мій досвід роботи з монетизацією був доволі базовий.
Інформація, яку ви прочитаєте далі, буде переважно рефлексією на всі виклики та best practices, які траплялися на шляху. Я намагатимусь бути «своїм у дошку», аби ця інформація була корисною для Product-менеджерів, які або вже працюють із монетизацією, або тільки планують свій світчинг у професію, а також для Product-дизайнерів, які шукають натхнення.
Думаю, що й розробники, команди сапорту, і будь-хто дотичний до user experience зможуть знайти щось цікаве для себе в цьому матеріалі.
Як ми віднайшли фокус та почали роботу
В основі монетизації нашого застосунку лежить freemium-модель, яка складається з підписок (subscription) та фічових покупок (one-time purchases). Основною метою команди монетизації було підвищення average revenue per user (ARPU), а неофіційним мото — Make subscription great again.
Почати було не просто: за будь-якою метрикою стоять люди, отже, потрібно було зібрати команду, яка була б не просто сильною, але і вмотивованою. Та найголовніше — бачила себе в цій зоні відповідальності. Іншими словами — work with flame, not in flame.
Зрештою наша команда сформувалась із мене («It’s me, hi, I’m the problem, it’s me...»), трьох Product Analyst та одного Product Designer. І тут почалося найцікавіше, адже перед нами стояла задача не просто підняти цільову метрику, а ще й не погіршити інші продуктові метрики (думаю, це не новина для багатьох продуктових компаній).
Тому я ініціював наступний етап — зрозуміти фокус, що окреслюватиме основну зону відповідальності нашої команди та не дозволить відхилятися від кінцевої цілі. Фокус — це основа шляху, він має бути чітким, прозорим для всіх членів команди та говорити про те, якою ми бачимо свою роботу в результаті.
Наявність командного фокуса лімітує зайві мітинги, витрачені години на суперечки (куди ж без них) та виступає своєрідним валідатором тих чи інших продуктових гіпотез.
Нашим головним фокусом і валідатором надалі стало чітке бачення монетизації всередині продукту, ми хотіли, щоби вона була бажаною (не плутати зі співачкою, яка співає про «...логіка, статика й математика...»).
Створити нову фічу простіше, ніж донести її цінність, а ще складніше тримати її retention, тобто закохати користувача в неї. Ось це і стало нашою Fata Morgana.
Ідейно визначились, що ж далі? А далі — практичне втілення. Кожного кварталу продуктові команди готують роадмапи з продуктовими імплементаціями, що допомагають нам рухатися кожним релізом. У нашому випадку ці роадмапи з акцентом на монетизацію.
Оскільки ми маємо двотижневі релізні цикли, то повинні рухатися швидко, бо, як каже мій лід, час — наш найбільший ворог (Press F to pay respects). Над продуктовими імплементаціями на нашому продукті працює величезна команда — понад тридцяти спеціалістів, серед яких продакти, аналітики, розробники та дизайнери), а від ідеї до реалізації задача проходить об’ємний цикл. Опишу, як ми зазвичай працюємо над нововведеннями:
- Initial Research — дивимось на дані, що стосуються нашої зони відповідальності, формуємо гіпотезу;
- Competitor Research — дивимось, що там за поребриком в Tier-1 та спираємось на конкурентів усіх дотичних ніш (бо в сусіда трава завжди зеленіша);
- Release Planning — презентуємо гіпотезу команді. Тут головна небезпека — перетин з іншими задачами релізу, тому важливо орієнтуватись на company-wide цілі та зрозуміти, що важливе для компанії;
- Experiment Design — описуємо, уточнюємо гіпотезу, проводимо комунікацію чи то брейншторми з командою дизайну;
- Development — реалізовуємо задачу, саме тут важливо підтримувати комунікацію з командою розробки;
- Build Launch — випускаємо задачу у світ, де наші користувачі стануть найкращими суддями;
- Analysis — аналізуємо, що в сухому залишку нам дала задача й чи ми джастифікували гіпотезу.
На кожному етапі циклу ми розуміли, що штучні пейволи на старті застосунку, неорганічні воронки всередині продукту або роздавання знижок точно не підвищать репутацію підписки, а тим паче не зроблять її важливим атрибутом для користувача.
Отже ми усвідомили, що варто працювати над її цінністю. З кожною задачею, імплементацією, рісьорчем ми завжди керувалися цим простим прикметником (хто забув — бажана). Зрештою ми досягли +21 % до ARPU менше ніж за дев’ять місяців і примножили x8 feature revenue за останні шість місяців. Далі ділюсь головними принципами та best practices, завдяки яким ми досягли таких результатів.
Question the basics
Однією з best practices для нашої команди став челендж уже наявних воронок всередині продукту. Розкласти по поличках, проаналізувати поточні конверсії, зрозуміти, що із сегментами — це першочергові кроки, які ми зробили. Таким чином ми мали картину й розуміли, що на продукті є воронки, що вже є неактуальними в силу свого надокучання користувачам, зміни аудиторії продукту чи низьким використанням фічі після покупки.
Хорошим прикладом будуть промокартки, які з’являються при перегляді профілів користувачів і продають різного типу сервіс. Основною проблемою була висока конверсія в показ, але низька конверсія в покупку. Ми зрозуміли, що в користувачів випрацювалась «банерна сліпота» (aka «рекламна сліпота»).
Наступним кроком було прибирання цих карток і звільнення коду від непростих умов показу. Чи втратили ми в грошах? Ні. Чи виграли в активності? Так!
«І чому це успіх для команди монетизації», — спитаєте ви? Тому що користувачі почали робити більшу кількість дій. Прибирання промокарток вивільнило місце для показу більшої кількості профілей, а більше вихідних дій — це завжди добре для продукту з network effect (якщо це словосполучення викликає у вас цікавість, то ласкаво прошу зазирнути сюди).
«People ignore design that ignores people»
Наступною best practice нашої команди стала цитата вище відомого американського Product-дизайнера Франка Чімеро. Маючи в команді власного Product-дизайнера, ми з легкістю могли брейнштормити ідеї для покращення UI/UX застосунку.
У канву таких брейнштормів лягали реальні фідбеки наших користувачів, які ми збираємо з понад шести різних ресурсів: in-app, Google Play Store, App Store, support тощо.
Після кодингу фідбеків (виокремлення основних запитів за ключовими словами та групування їх у потенційні точки росту), ми побачили, що одним з рекурентних запитів наших користувачів була навігація вхідної активності.
Простими словами: змога фільтрувати та керувати тим, що отримують користувачі під час взаємодії з іншими користувачами. Тому ми зрозуміли, що імплементація фільтрів, які полегшують перебування користувача в Notification center (наприклад, показати лише лайки від онлайн користувачів) чи вкладці Messages (наприклад, показати лише верифіковані чати) можуть дати цінність користувачам — підсилять комунікацію з потрібним користувачу партнером і підсвітять нотифікації від цих же користувачів.
Важливим кроком було втримати баланс між наданням цінності, сервісу та монетизацію, тому сформувавши world cloud фідбеків ми розділили фільтри на безплатні та платні, аби всі мали змогу використовувати базові фільтри (найпоширеніші концепти, що траплялися в word cloud), а вже для глибшого менеджменту своєї вхідної активності можна було використати додаткові платні фільтри (доволі нішові концепти з world cloud).
Таким чином ми не тільки отримали приріст у грошах, бо зробили ці платні фільтри частиною підписки, але й підбустили інші продуктові метрики: converions to dialog та first message sent, адже тепер користувачі могли взаємодіяти зі справді важливою для них активністю.
Less is More
Кожного кварталу під час формування роадмапу наша команда використовує різні інструменти для підготовки продуктових гіпотез — від аналізу власних даних до проведення зовнішніх консультацій з Growth Managers, Product Analytics тощо.
Під час однієї з таких консультацій, які нам організовує команда Busness Development, ми отримали наступний інсайт — дефолтним вважається, що якщо користувач має підписку на ваш продукт, то потрібно звідусіль кричати йому про це, а ще краще показати це іншим користувачам.
Ця логіка існувала й у нас, але коли ми перевірили глибше, то з’ясували, що цей параметр впливає на кількість метчів. Преміум-користувач зі «значком» отримував менше лайків у відповідь, ніж користувач без неї. Провівши customer development, ми отримали наступне підтвердження — користувачі були менш схильні лайкати користувачів, які мають підписку, оскільки вони вважали, що «їх купують, а кохання купити не можливо».
Далі ми помітили, що часто в застосунку ми повторюємо інформацію про вік користувачів, це особливо стосувалося нотифікацій в Notification center та Message tab, що створювало візуальний безлад.
А таймстемпи нотифікацій (час, коли було відправлено або отримане певне повідомлення) в Notification center та Message tab (вкладка із повідомленнями) додавали тільки більшого смислового навантаження, оскільки в застосунку вже існувало візуальне розділення нотифікацій new vs. old.
Логічним наступним кроком було позбутися цього «візуального шуму» (важливо, що інформація про вік однаково залишалась у профілі користувача).
Прибравши «значок» про наявність підписки в користувачів та їх вік, а також таймстемпи меседжів та нотифікацій у застосунку ми звільнили місце для іншої корисної інформації та почали підсвічувати, що користувач, який тебе вподобав додатково ще й написав тобі меседж, а це завжди сильний тригер для користувачів, і їх конверсія в купівлю підписки для розкриття цього користувача та меседжу скайрокетиться, що дало нам +27 % до conversion to purchase саме з воронки вхідних лайків.
In the right place at the right time
Одним з найбільших челенджів, які проходила наша команда, було розкачування вже наявних воронок покупки. Деякі воронки існують на продукті із самого часу заснування і мають стабільні (flat) конверсії, але це не означає, що не варто намагатись їх розворушити.
Одна з гіпотез полягає в тому, що конверсія в покупку із цих воронок низька через низьке покриття — adoption friction (чудова стаття на цю тему для ознайомлення).
Влучним порівнянням може бути, наприклад, коли ваш улюблений сукулент припиняє ріст, оскільки йому не вистачає сонця, яке взимку вже не так огортає його, і ви змінюєте місце його розташування. Це і сталось із нашою фічою Boost, яка дозволяє користувачеві отримати пріоритетні покази у видачі іншим користувачам і отримати вхідну активність у вигляді лайків та переглядів профілю.
Ми зрозуміли, що в нас є точка входу на цю воронку, але вона нічого не говорить про потребу користувача придбати фічу. Вона просто є. Просто відмальована в застосунку. Просто отримує свій стабільно низький конверт у порівнянні з іншими воронками.
Але чи це максимум, який вона може отримати? Треба тестувати. Для цього варто запитати себе, чи поточний плейсмент резонує з бажанням користувача придбати фічу? Чи цей плейсмент тригерить його? Чи розв’язує його проблему?
Такий брейншторм допоміг нам зрозуміти, що користувач, який уже переглянув усі свої лайки, не знайшов когось, хто йому до вподоби та хотів би отримати додаткові шанси на потенційне побачення. І таке місце в нас є — екран з усіма вхідними лайками користувача. Додавання кнопки Boost Me на цей екран дало нам +5 % to conversion from view to buy, а також +20 % to Boost usage. Як кажуть «в потрібному місці, у потрібний час».
...not only money, money, money
Найважливіша порада, яку я хочу залишити собі та всім, хто читає цю статтю — не концентруйтесь лише на грошах як на результаті вашої діяльності. Одна із best practice полягає в тому, що за постійної роботи з монетизацією треба вміти перемикатися на інші задачі: кроскомандні колаборації чи операційну інфраструктуру. Такий підхід допоможе тримати око не замиленим, а ідеї — свіжими.
Для нас такими chillout zone стали перехід на нову систему серверних нотифікацій від Apple — івенти від AppStore, що приходять у реальному часі та містять інформацію про взаємодію користувача з покупками в продукті та розробка в застосунку Safety section про online та real-life dating.
Серверні нотифікації стали нашим першим досвідом тісної взаємодії з командою розробки не на рівні імплементації фічі, а на рівні infrustructure health, адже ризики були та (спойлер) підготуватися до всіх не вдалось, але вирішити їх за 24 години — дуже навіть вийшло!
Нотифікації — це основи для нашої внутрішньої системи івентів, на основі якої визначається платіжний статус користувача, нарахування йому належного сервісу та опрацювання відшкодувань (refund).
Розуміючи складність, ми вирішили декомпозувати процес, тому перехід відбувався в декілька етапів:
- підготовка всіх точок виклику App Store API;
- мапінг наявних нотифікацій із новими;
- внесення змін у логіки обробки серверних нотифікацій і їхні перетворення у внутрішньопродуктові івенти, що інформують про purchasing flow користувача;
- погодинний моніторинг внесених змін на основі оновлених нотифікацій;
- виправлення всіх неточностей;
- ретроспетивний перезапис даних.
Як зазначав вище — не без фейлів, але я в цьому вбачаю тільки ріст і 100 % занурення в контекст, чи ба навіть розуміння точок для покращення внутрішньо командних процесів.
Safety section стала моїм особистим челенджом. Як all inclusive dating app, ми розуміли важливість не просто надати платформу для пошуку потенційних партнерів, але і впевнитись, що наші користувачі мають усі інструменти, які допоможуть їм робити це мінімізувавши всі ризики, які може нести в собі сучасне глобалізоване суспільство.
Ми вирішили розмістити в застосунку цілу Вікіпедію з порадами по дейтингу, питаннями здоров’я, сексуальної ідентифікації та запобіганню суїциду. Усю інформацію ми збирали з різних джерел, які були затверджені нашими Partnership, Legal & Brand team.
Блок містив 11 розділів з корисними покликаннями на ресурси, телефонами гарячих ліній і корисними чеклістами. Було важливо зробити цей блок, докладаючи мінімальних ресурсів, і головне — закласти динамічність змін чи то ресурсів, чи то гарячих ліній, чи то локацій, на які може бути дистрибутований той, чи інший розділ.
Зрештою розробники створили окрему платформу, куди ми внесли всю інформацію і, що найцінніше, могли в будь-який момент внести зміни до контенту чи керувати відображенням того, чи іншого розділу. По суті, влада над Safety section була не в коді, а у Product-менеджерів, що полегшує роботу із цим блоком для всіх — від маркетологів до CEO.
Із цікавого побачили, що ми залучаємо в цю табу кожного 90 користувача. Конверсія по кліку на будь-яку діплінку, що веде на допоміжний ресурс становить приблизно 10 користувачів щодня. Найвідвідуванішою секціює стала (без сюрпризів) Dating Online про правила поведінки в застосунку, у яку заходять ~17 % від усіх, хто відвідав Safety Section.
The last but not the least
Наші наступні кроки вже окреслені новим роадмапом — розкачати наявні воронки, імплементувати нові, відрізати зайве. Цих кроків не було, якби не було фокусу. Якби ми не розуміли лейтмотив нашої команди.
Якби можна було розказати про все. Скільки фейлів та успішних фічей ми мали за останні дев’ять місяців, точно не перерахувати на пальцях однієї руки, але тільки наша монетизаційна команда проводить майже 50 тестів за один квартал. А попліткувати про network effects та впливи інших команд на нашу цільову метрику? Це все є, але то вже інший щоденник.
Щоденник, який я виклав тут, — це рефлексія, не сприймайте його за хизування. Моя головна мета — показати, що монетизація не страшна ні для команди, яка нею займається, ні для користувачів. Монетизація є і має бути лагідною. Я щиро вірю, що ціль тих, хто займається монетизацією продукту — закохати користувачів у підписку. І, сподіваюсь, цей лонгрід це доводить. Доводить, правда ж?
Єгор Домачук
Maksim Lepskiy
Anastasiia Shevchuk
5 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів