Як ми досягли понад 30% success rate продуктових тестів і чому тепер хочемо його знизити

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

Привіт! Мене звати Катя Корнейчук і я Team Lead Product Manager дейтинг-застосунку Hily в українській продуктовій ІТ-компанії appflame.

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

В Hily я працюю вже майже пʼять років, раніше відповідала за напрямок монетизації, а зараз — за весь продуктовий департамент та кроскоманди всередині нього.

Ключовий фокус нашої команди — створювати якісний дейтинг-продукт, який приносить цінний досвід користувачам і мотивує їх користуватися застосунком. Щоб досягти цього, ми працюємо над покращенням юзер-флоу та оптимізацією алгоритмів, що допомагає користувачам швидше починати спілкування після метчу або домовлятися про зустріч. У результаті, коштом покращеного досвіду користувачів, ми також підвищуємо й середній дохід на користувача (ARPU) й завдяки цьому маємо можливість розвивати продукт.

У цій статті я б хотіла поділитися нашими підходами з генерації гіпотез, завдяки яким ми досягаємо success rate наших продуктових тестів понад 30 %. А також спойлер — чому ми хочемо його знижувати.

Ця стаття буде корисною всім, хто хоче покращити success rate своїх експериментів, адже підходи, про які буду говорити далі, цілком можна застосувати на будь-яких продуктах і в будь-яких нішах.

Чому ми почали прогнозувати success rate наших продуктових гіпотез

Памʼятаю, коли я тільки доєдналася до Hily, усі наші процеси та інструменти були спрямовані на те, щоб тестувати більше гіпотез і робити це якомога швидко. Наприклад, зі сторони коду ми часто робили зміни на бекенді, щоб мати змогу швидко запускати тести, не чекаючи релізу в App Store чи Google Play.

Це допомагало нам швидше рухатися й отримувати результати, але ретроспективно ми бачили, що такі швидкі експерименти мають або низький success rate, або дають незначний вплив на таргет-метрики. Бо коли фокус на кількості експериментів, немає часу на глибокий аналіз проблеми, якісні дослідження або продумування гіпотез із чітким обґрунтуванням, навіщо ми це робимо.

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

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

Саме тоді ми змістили фокус із «як рости швидко» на «як рости стабільно» й почали вводити у свої процеси методику постановки цілей за OKR (Objectives and Key Results). Завдяки цій методиці змогли визначити конкретні продуктові проблеми, цілі, метрики та критерії їхньої успішності.

Наприклад одним з Objectives (O), який ми ставили собі на продуктовий департамент, було підсилити залученість користувачів, зробивши безпеку ключовою компонентою їхнього досвіду. А Key Results (KR) — збільшити кількість активних днів входу в застосунок серед жінок, які шукають чоловіків, на 15 %.

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

Вже на той момент ми мали десятки мільйонів користувачів і користувачок із різних країн і з різними потребами. І щоби зрозуміти, як наші зміни на них впливають, запускали й досі запускаємо велику кількість сплітів (A/B тестів) на різні сегменти — тестуємо функції, інтерфейс, алгоритми тощо.

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

Зробили висновок, що систему експериментів потрібно впорядкувати: визначати пріоритетні напрямки, чітко обирати, які гіпотези варто тестувати, і планувати їх так, щоби тести не заважали один одному та могли позитивно впливати на ключові метрики.

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

Як ми адаптуємо під себе RICE, прогнозуємо success rate і пріоритизуємо гіпотези

Оскільки ми маємо багато джерел для генерації гіпотез (дослідження поведінки користувачів, аналітика результатів експериментів, дослідження конкурентів тощо), а ресурси розробки в нас обмежені, потрібен гарний інструмент для пріоритизації задач у беклозі.

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

• Reach (Охоплення) — скільки користувачів чи сегментів буде зачеплено зміною або новою фічею;
• Impact (Вплив) — наскільки зміна вплине на ключові метрики або на користувацький досвід;
• Confidence (Впевненість) — наскільки ми довіряємо власним оцінкам і чи справді зміна матиме очікуваний вплив на метрики. Ми визначаємо це на основі фактів, досліджень і з досвіду команди;
• та Effort (Зусилля) — скільки ресурсів (час, команда, гроші) потрібно для реалізації задачі чи експерименту.

Мета використання RICE — це отримати числову оцінку (RICE Score) для кожної гіпотези, щоби об’єктивно порівняти та обирати найважливіші задачі для планування роадмапу. RICE Score розраховується за формулою: Reach * Impact * Confidence / Effort.

Проте ми внесли деякі зміни до методології, адаптувавши її під наші потреби й наш продукт. І замість RICE ми зробили ICE зі шкалою оцінки ICE Score, де:

• до 32 балів — низький пріоритет тестування гіпотез;
• ~32—100 — середній пріоритет;
• 100–160 — високий;
• 160+ — дуже високий (high impact, low effort).

Що ми змінили в RICE:

а) Відмовилися від критерію «Reach» (Охоплення) бо побачили, що навіть невеликі сегменти користувачів можуть мати непропорційно великий вплив на ключові метрики та генерувати більшу частку доходу або активності в застосунку. Натомість вирішили фокусуватися на потенційному впливі (Impact) кожної гіпотези на ключові метрики.

b) «Impact» (Вплив) розділили на чотири рівні залежно від потенційного ефекту гіпотез на наші OKR, щоб точніше оцінювати вагомість кожної. Для зручності підрахунку кожен рівень отримав числовий коефіцієнт, який використовуємо у формулі ICE.

Щоб точніше оцінювати потенційний «Impact» наших гіпотез, ми разом із нашим Head of Analytics створили калькулятор у Google Spreadsheets, який допомагає спрогнозувати, як зміни в одному або кількох сегментах користувачів можуть вплинути на ключову метрику. На скриншоті нижче — приклад такої таблиці з інструкцією та описом її елементів.

Таблиця для оцінки впливу гіпотез

Отже, як працює калькулятор.

1) У блоці Scenario basic вводимо реальні показники з продуктової аналітики, тобто поточні значення метрик для кожного сегмента користувачів. У прикладі на скриншоті ми розраховували вплив однієї з гіпотез на Day 3 Retention серед жінок, де:

• Share — частка сегмента в загальній аудиторії (наприклад, 92 %);
• Metric (rt3) — поточне значення метрики (у цьому випадку 55 %);
• Other — користувачі, які не входять до таргетованого сегмента.

2) У блоці Scenario success розрахували, як можуть змінитися показники після реалізації гіпотези. У блоці можна:

• відредагувати частку сегмента (share), якщо очікуєте, що вона виросте або зменшиться;
• змінити значення метрики (metric), якщо гіпотеза має добре вплинути на поведінку користувачів.

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

3) У блоці Diff ми прораховуємо очікуваний приріст нашої метрики. Блок показує різницю між поточним і прогнозованим значенням:

• 20 % OKR і 33 % OKR — це наші умовні цілі приросту до ключової метрики.

У прикладі, щоб досягти приросту 20 % або 33 %, потрібно отримати +0.010 або +0.017 до метрики. Ми прогнозуємо +0.018, що перевищує таргет і відповідає категорії «very high».

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

• наскільки реалістично ви оцінили зміни в сегментах;
• наскільки точними є вихідні дані з аналітики;
• чи врахували можливі негативні сценарії.

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

с) наступний критерій з ICE-методології — це «Confidence» (Впевненість) — тобто наскільки ми довіряємо власним оцінкам і чи справді зміна матиме очікуваний вплив на метрику.

Раніше ми для простоти вимірювання Confidence використовували умовні оцінки рівня впевненості low, medium, high, ґрунтуючись на попередніх експериментах, даних конкурентів або користувацьких дослідженнях. Але швидко зрозуміли, що не всі джерела дають однаковий рівень впевненості. Закритий експеримент дає реальні цифри, на які можна спиратися, тоді як дані з інтерв’ю користувачів — це лише припущення. Люди насправді часто кажуть те, що, на їхню думку, сподобається інтерв’юеру, і не факт, що це відповідає дійсності.

Тому ми проаналізували наші спліти та замінили умовні оцінки на числові значення, співвідносні з джерелами даних і рівнем довіри до них (приклад на скріншоті нижче).

Confidence points

d) останній критерій з ICE — «Effort» (Зусилля) і його ми оцінюємо стандартними S, M, L, залежно від кількості сторіпоінтів.

Прорахунок Effort

Коли ми зібрали дані по всіх критеріях, ми повертаємося до оцінки гіпотези й визначаємо її ICE Score, щоби об’єктивно порівняти та обирати найважливіші задачі для довгострокового стратегічного планування. Для цього використовуємо формулу ICE = Impact * Confidence / Effort, підставляючи числові значення по кожному критерію.

У нас на продукті, наприклад, є свій поріг ICE score у 32 бали, нижче якого ми намагаємося не запускати гіпотези.

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

Кейси, коли ми отримували понад 30 % success rate

Далі я наведу два приклади тестів, які повʼязані між собою.

Кейс із підвищення метрики Active Login Days

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

Тож однією з цільових метрик ми визначили Active Login Days 1–7 — кількість логінів із вихідною активністю, які зробить жінка в застосунку протягом тижня. І пізніше помітили, що ця метрика сильно корелює з метрикою Retention: чим активніше користувачки взаємодіють із певними функціями одразу після входу в застосунок, тим частіше вони повертаються до нього протягом наступного дня чи тижня.

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

Тоді ми сформували гіпотезу: якщо показати користувачкам спільні інтереси з потенційним партнером прямо на профілі у Finder, це зменшить невпевненість під час свайпу й дасть більше приводів для початку діалогу. У результаті це має підвищити активність у застосунку, Retention та нашу цільову метрику Active Login Days 1–7.

Finder

Перед тестом ми порахували ICE Score гіпотези:

• Impact і Confidence ми дали високі оцінки, адже мали достатньо даних (аналітика, попередні тести) й очікували на гарний ефект;
• за Effort це була не складна задача, розміром S;
• загальний ICE score у нас вийшов ≈ 160, що за нашою шкалою означає дуже високий пріоритет для тестування цієї гіпотези.

В результаті гіпотеза принесла 40 % приросту до метрики Active Login Days 1—7LT (наша таргет метрика) для жінок.

Кейс зі збільшення кількості лайків у Finder

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

Команда зробила аналітичне дослідження по кореляції наявності спільних інтересів та їхньої кількості з відправленими лайками й сформувала гіпотезу: якщо показувати користувачкам профілі з найбільш схожими інтересами й бустити їх за допомогою алгоритмів, жінки частіше ставитимуть лайки чоловікам у Finder. Це підвищить активність у застосунку та покращить Retention.

*Це, до речі, одна з речей, які ми часто робимо в команді — будуємо ланцюжки гіпотез і завдяки цьому маємо більше задач із високим параметром Confidence, адже вони ґрунтуються вже на базі попередніх закритих тестів.

Після команда так само розрахувала Score гіпотези за ICE: Impact оцінили як Medium, хоча за результатами попереднього тесту можна було сміливо ставити High. Але команда зробила поправку на непередбачуваність поведінки користувачів, адже кожен новий параметр в алгоритмах може поводитися не так, як очікувалось.

Наприклад, якось команда помітила, що ймовірність отримати лайк залежить від вікового діапазону користувача. Умовно, якщо я шукаю чоловіків віком 18–36 років, то ймовірність, що я відправлю лайк чоловікові на нижчому віковому порозі — вища. Ми запустили тест, надаючи пріоритет профілям чоловіків молодшого віку, але результат показав, що кількість відправлених лайків зменшилась. Це означає, що існували інші фактори, які ми не врахували, тому тест ми закрили й повернули до стандартної логіки;

• по Confidence параметру гіпотеза була з оцінкою High, адже ми враховували аналітичне дослідження + закритий експеримент іншої команди + напрацювання по user research згідно із нашим калькулятором;

• по Effort це була задача рівня S, бо розробники оцінили її у 2 сторіпоінти.

За результатами тесту ми підтвердили, що блок зі спільними інтересами впливає на кількість лайків, які жінки відправляють у Finder. Команда алгоритмів змінила логіку показу карток залежно від кількості спільних інтересів, і це дало нам ~45 % приросту до таргет метрики.

Чому ми хочемо знижувати наш success rate

Але, як кажуть, є нюанс: якщо ви бачите що ваш success rate сильно перевалює за ринковий (а це десь 20-25 %), то щось не так.

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

У такому випадку краще зробіть крок назад і подивіться, як перформлять ваші гіпотези на лонграні — чи ростуть топ-метрики, чи дійсно спліт-експерименти важливі для користувачів (а не лише для бізнесу).

Ми в команді зрозуміли, що наша точка росту зараз якраз полягає в тому, щоби ризикувати та тестувати інноваційні гіпотези. Для цього почали запускати Big Bets — великі й ризикові ініціативи, які можуть дати найбільший приріст у наших показниках. Додатково ми стараємося балансувати їх із Quick Wins й також робимо зміни в підходах до монетизації (але це вже окрема історія для майбутньої статті).

У яких випадках гіпотези можуть не спрацьовувати

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

Запускають гіпотези, базуючись на так званому «gut feelings» («я так відчуваю»). За нашим досвідом такі гіпотези мають найнижчий success rate й переважно працюють лише за умови, якщо ви добре знаєте вашу нішу, конкурентів і працюєте з «low hanging fruits» гіпотезами (легкодоступні задачі, очевидні гіпотези).

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

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

Як ми перейняли одну з механік в health&fitness застосунках і помилилися

Якось ми тестували додавання value-екрану на етапі онбордингу з відгуками користувачок, орієнтованого виключно на жінок, щоби підвищити їхню активність у застосунку.

До прикладу, у health&fitness апках це виглядає так:

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

Value-екран у health-застосунку

• на другому скриншоті — стара добра схема «social proof» або «соціальне підкріплення» (термін, запозичений із психології). Якщо коротко, то цей підхід ґрунтується на відчутті приналежності та бажанні людей бути як усі. Коли ми бачимо, що десять людей радять купити певний продукт, то, швидше за все, і самі його купимо. У певний момент багато застосунків почали активно використовувати цей психологічний гачок на своїх пейволах.

Ми у Hily також вирішили піти механікою social proof — через подібний екран донести наше USP (унікальну ціннісну пропозицію) і показати відгуки задоволених користувачок.

Value-екран у Hily

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

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

Ми втратили 2 % нових користувачок, які не завершували онбординг, не доходили до Finder і не починали активність у застосунку. І проблемою було те, що ми не врахували контекст онлайн-дейтингу.

У дейтингу для користувачів головне — це швидко потрапити в головну фічу (у нашому випадку це Finder) й одразу подивитися, хто є в застосунку, щоби прийняти рішення — залишатися в ньому чи ні. Цей інсайт нам якраз підсвітили якісні опитування користувачів. Багато з них казали, що хочуть швидко отримати доступ до профілів користувачів, щоби зрозуміти, чи відрізняються люди в Hily від тих, кого вони бачили в Tinder або Bumble.

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

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

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

Fun fact: цю гіпотезу з value-екраном тестував, напевно, кожен новий продакт-менеджер, який приходив у Hily, і ми щоразу закривали її в базу. Але після останнього тесту вирішили поставити ці спроби на довгу паузу.

Ми поверталися до неї через дві причини:

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

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

1. а що це дасть нашому користувачу?
2. як це вписується в наш користувацький флоу?

Ну і якщо гіпотеза не заводиться і раз, і другий, і третій — то, можливо, досить? :)

Висновки

Якщо резюмувати, то фокус на користувацькому та бізнес-імпакті, крос-командна робота, пріоритизація за ICE та калькулятор прорахунку «Impact» дають дуже добрий вплив на succes rate й разом із тим більше розуміння, які гіпотези варто брати в роботу, а які — ні.

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

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

Буду рада почитати ваші ідеї, як ще можна доповнити наш ICE, та обмінятися думками в коментарях. Або ж поділитися досвідом, лайфхаками та обговорити різні підходи для пріоритизації гіпотез — також у коментарях чи в Linkedin.

Сподобалась стаття? Підписуйтесь на автора, щоб отримувати сповіщення про нові публікації на пошту.