Усі дивляться на монетизацію. Ми подивилися на активацію й отримали +40% ARPU

💡 Усі статті, обговорення, новини про продукти — в одному місці. Приєднуйтесь до Product спільноти!

Останні тижні український продуктовий ринок активно обговорює, які є growth практики при побудові та масштабуванні продуктів. Основна частина дискусії крутиться довкола монетизації: веб-фаннели, пейволи, конверсії в оплату та тонка межа між оптимізацією й маніпуляцією.

За моїми спостереженнями, ці обговорення найчастіше приводять до одного тейку: коли всередині продукту починають погіршуватись бізнес-метрики, першочерговий фокус уваги автоматично й майже рефлекторно зміщується в бік монетизації. У такі моменти в людини виникає цілком класичний, інтуїтивний набір запитів: «потрібно тестувати новий пейвол», «змінити прайсинг», «перебудувати воронку й збільшувати trial conversion».

Це лінійний і найбільш очевидний шлях. Проте за фокусом на екранах оплати значно рідше постає фундаментальне питання: «Чи доходить користувач до цінності продукту?»

Кілька місяців тому ми, в межах одного з продуктів, що скейлиться на платформі Kiss My Apps, отримали близько 40% росту ARPU — і це було результатом не роботи з пейволами чи експериментів із ціною, а цілеспрямованої роботи з активацією. Історія почалася з падіння rebill rate в продукті-автентифікаторі, але насправді це кейс про те, чому growth починається значно раніше за монетизацію.

Growth починається не з пейволу

За останні роки роботи із subscription-продуктами я помітила цікаву закономірність. Поки продукт шукає свою юніт-економіку, команда дійсно багато працює з монетизацією та позиціонуванням, шукаючи точку, де економіка починає працювати. Але після того, як юніт-економіка знайдена, починається зовсім інша гра, в яку мало хто починає грати, бо це складно. Починається growth. І growth — це не про пейволи. Growth починається з активації, з пошуку моменту, коли користувач вперше отримує цінність від продукту.

Саме тому, коли ми побачили падіння rebill rate, я настояла не на тому, щоб дивитися в бік монетизації, а на тому, щоб спочатку відповісти на більш фундаментальне питання: що в нашому продукті є активацією?

Пошук Setup Moment та Aha Moment

Звучить дивно, але в багатьох продуктах команда не може чітко відповісти на питання, що саме є активацією, і будьмо відвертими — ці питання навіть не підіймаються. Але мене така ситуація насторожує, як і будь-які припущення без перевірки, тому разом з аналітиками ми почали окреме дослідження.

Нашою задачею було знайти Setup Moment, Aha Moment та події, які формують Habit Moment. Ми будували когорти, порівнювали поведінку користувачів на D1, D7, D14 та D30, аналізували десятки продуктових подій і шукали причинно-наслідкові зв’язки між поведінкою користувачів і бізнес-метриками.

Серед усіх подій була одна, яка виділялася найбільше. Користувачі, які доходили до неї, поверталися в продукт у 4,5 раза частіше, мали значно кращий retention та rebill rate, значно частіше доходили до наступного платежу й приносили більше виручки бізнесу. Саме цю дію ми визначили як наш Aha Moment, а все, що було необхідно для того, щоб користувач до нього дійшов, стало нашим Setup. І тільки після цього ми почали досліджувати шлях між ними. Саме там і знаходилася проблема.

Найцікавіше почалося після аналізу

Після того як ми знайшли активацію, стало зрозуміло, що більшість користувачів так і не доходить до неї. Ми чудово бачили це в аналітиці: бачили точки зупинки, бачили місця, де рух припиняється, але причину все ще не розуміли.

І саме в цей момент я почала активно просувати ідею тестувань. Не тому, що я дизайнер і люблю дослідження, а тому, що за роки роботи я так і не знайшла інструменту, який краще пояснює поведінку користувача. Аналітика показує, що відбувається, а тестування показують, чому це відбувається. І поки ти не побачиш користувача в дії, ти майже ніколи не зрозумієш, що відбувається у нього в голові.

Чому я не хотіла починати з глибинних інтерв’ю

Багато хто в такій ситуації одразу запускає глибинні інтерв’ю, але мене вони не цікавили, принаймні на цьому етапі. Мені потрібно було не почути думку користувача, а побачити його поведінку.

Люди дуже часто раціоналізують свої дії заднім числом, забувають деталі, будують логічні пояснення там, де насправді діяли інтуїтивно. Тому інтерв’ю могли дати нам цікаві думки, але не обов’язково дали б реальні причини проблеми. Мені потрібно було побачити момент, у якому користувач губиться, сумнівається, момент, будує неправильні очікування. Такі речі майже неможливо дістати з розмови, їх потрібно спостерігати.

Чому ми обрали гібрид між юзер-тестуванням і коридорками

Повноцінне usability testing — то дорого і довго: рекрутинг, скринінг, організація слотів, і на це можуть піти тижні. Тому я побудувала гібридний формат.

За процесом це було повноцінне юзер-тестування з чіткою дослідницькою метою, сценаріями, завданнями, записами всіх сесій, аналізом інсайтів та синтезом результатів. Єдина різниця була в рекрутингу: ми шукали людей всередині Kiss My Apps, які максимально нагадували нашу цільову аудиторію, не мали глибокої технічної експертизи й ніколи не стикались з нашою апкою.

Тестування виявилися справжнім контрастним душем, і попереджаю: якщо ви ніколи не тестували — це буде боляче, але це відкриває інші грані тебе й того, як ти сприймаєш дизайн. Після кожної нової сесії руйнувалося чергове припущення команди, а інсайтів було настільки багато, що вже після кількох перших учасників стало зрозуміло: ми дивилися на проблему не з того боку — і це нормально, бо саме для цього й потрібні тестування.

Найцінніший інсайт у всій історії

Наш продукт був побудований на перевірених ринком UX-патернах: ми регулярно аналізували конкурентів, дивилися їхні флоу, сценарії активації та ключові точки взаємодії з користувачем. При цьому я ніколи не сприймаю конкурентів як істину в останній інстанції, для мене вони швидше джерело сигналів. Я завжди звертаю увагу як на повторювані патерни, які використовує більшість ринку, так і на рішення, де окремі продукти свідомо виходять за рамки ніші та намагаються переосмислити звичний досвід.

У нашому випадку ми бачили, що ключові сценарії побудовані дуже схожим чином у більшості гравців ринку. З одного боку, це підтверджувало, що ми не зробили якоїсь очевидної UX-помилки, з іншого — підштовхнуло мене до зовсім іншої думки: якщо користувачі губляться у нашому сценарії, висока ймовірність, що вони губляться і в конкурентів.

А отже, ми маємо справу не з проблемою конкретного продукту, а з системною проблемою ніші. Користувачі не розуміють, як працює двофакторна автентифікація, не бачать різниці між сервісом, де потрібно ввімкнути 2FA, і самим автентифікатором, який лише генерує коди. Багато хто очікує, що застосунок сам відкриє потрібний сервіс, увімкне захист і все налаштує без їхньої участі. Коли цього не відбувається, люди починають шукати кнопку, якої не існує, або взагалі думають, що застосунок працює неправильно. І це лише один із найменших інсайтів, які ми отримали під час тестувань.

Для мене це був не привід заспокоїтися фразою «у всіх так», навпаки, це був сигнал: якщо ми знайдемо причину цієї поведінки та навчимося вирішувати її краще, це стане перевагою, яку складно повторити просто зміною прайсингу чи редизайном пейволу.

Саме тому я так наполягала на тестуваннях. Мене цікавило не те, чи правильний у нас флоу за ринковими стандартами, а те, як цей флоу сприймає реальний користувач і де саме між нашим задумом та його очікуваннями виникає розрив.

Під час тестувань ми побачили десятки місць, де користувачі будували зовсім іншу картину продукту, ніж ми очікували: неправильні очікування, страх перед певними діями, невпевненість, сценарії, які інтерпретувалися зовсім не так, як задумувала команда. А ще більшість користувачів вважала задачу завершеною значно раніше, ніж вона була завершена насправді. Так складно може сприйматись те, що я говорю, але в цьому продукті ця задача відігравала ключову роль: саме в цей момент ми втрачали активацію, retention і майбутні ребіли. І схоже, що це системна проблема ніші, а не тільки нашого продукту.

Від інсайтів до грошей

Після тестувань ми перебудували частину activation flow, пропрацювали критичні сценарії і запустили серію експериментів, які суттєво покращили проходження шляху до Aha Moment. Поступово ми почали бачити зміни: зростання активації, покращення retention, покращення rebill rate, зменшення cancellation після першого платежу. Почала змінюватися метрика, заради якої бізнес взагалі запускає всі ці експерименти, — ARPU.

У підсумку серія змін, яка почалася з пошуку активації та тестувань користувачів, дала близько 40% росту ARPU — без зміни цін, нових тарифів і пейволів.

Висновок

Після цієї історії я ще сильніше переконалася в одній думці. Перш ніж оптимізувати монетизацію, потрібно зрозуміти активацію. Перш ніж запускати новий пейвол, потрібно зрозуміти, де користувач отримує цінність. Перш ніж тестувати нову ціну, потрібно переконатися, що користувач взагалі доходить до Aha Moment.

У нашому кейсі найбільший вплив на ARPU дала не монетизація, а відповідь на одне просте питання: «Що повинно відбутися в продукті, щоб користувач дійсно відчув його цінність?»

І поки ринок сперечається про те, як ефективніше продавати продукт, мені здається важливим нагадати інше: між оплатою і наступним платежем завжди знаходиться продукт. І дуже часто саме там лежать найбільші можливості для росту.

Бонус для тих, хто дочитав до кінця

Розповім про процес, який дав нам не менше користі, ніж самі юзабіліті-тестування.

Ми вирішили, що працювати з інсайтами має не лише дизайнер чи PM, а вся продуктова команда. І під командою я маю на увазі PM, розробник,QA , маркетолог, аналітик і дизайнер. Нам було важливо, щоб кожен дивився на проблему зі своєї професійної перспективи.

Але класичний брейнштормінг, де всі збираються на годину, накидають десятки сирих ідей, а потім більшість із них так і не доходить до реалізації, нас не влаштовував.

Тому ми повністю змінили формат. Замість класичного брейнштормінгу, де команда вперше чує про проблему вже на дзвінку й одразу намагається придумати рішення, ми побудували процес так, як зазвичай працюємо з продуктовими ініціативами.

Перед початком кожен член команди отримав доступ до всіх матеріалів дослідження. Можна було переглянути записи інтерв’ю, прочитати транскрипти, попрацювати з Miro-дошкою, де ми структуровано зібрали цитати користувачів, їхні болі та блокери, а також ознайомитися з аналітичним ресерчем, щоб розуміти не лише що говорили користувачі, а й як це проявлялося в продуктових метриках та поведінці.

Сам брейнштормінг теж мав чіткі рамки. Ми винесли лише три найважливіші проблеми, які були зараз в продукті. Завдання було простим: для кожної проблеми запропонувати хоча б одну якісно сформульовану продуктову гіпотезу.

Не просто ідею на кшталт «давайте додамо підказку», а повноцінну гіпотезу:

Якщо ми зробимо X, то покращиться Y, тому що користувачі зараз поводяться Z.

Ми дали команді цілий тиждень. Щоб кожен без поспіху міг зануритися в дослідження, зрозуміти контекст і сформувати власні висновки.

Результат приємно здивував. На зустріч усі прийшли вже підготовленими, з аргументованими гіпотезами, а не випадковими ідеями. Ми разом їх прочеленджили, обговорили ризики, пріоритезували, і в підсумку близько 60% гіпотез одразу потрапили в продуктовий беклог.

Мені дуже сподобався цей підхід, тому що він змінив роль команди. Люди перестали вигадувати рішення у вакуумі. Вони працювали з однаковим набором даних, бачили ті самі інсайти, аналізували поведінку користувачів і вже на цій основі пропонували рішення. Завдяки цьому обговорення стали значно предметнішими, а якість гіпотез — помітно вищою.