Чому A/B-тести без стратегії не працюють

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

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

Привіт, мене звати Софія Горбань, я — Senior Product Manager дейтинг-застосунку Taimi в українській продуктовій IT-компанії appflame. Зараз разом із колегами я працюю над retention-напрямом й покращую досвід користувачів у продукті, щоби їм було приємно з ним взаємодіяти й очі на лоба не лізли через кепський UI/UX.

Окрім цього, наша продуктова команда — адепти регулярних A/B-тестів. Лише за минулий рік ми протестували понад 400 гіпотез через A/B тестування, 167 з яких ми закрили в тест. Ми системно знаходимо інсайти в продуктово-поведінкових метриках і стараємося робити так, щоби максимум наших рішень спиралися на дані (хоча частину речей усе ж таки можемо довіряти інтуїції).

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

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

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

Переможця обираєш ТИ!

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

Певний час наша продуктова команда працювала за схемою класичних кроскоманд: маленькими групами із чіткими межами впливу й точковими цілями. До прикладу, були команди, які відповідали лише за push-повідомлення, або ж за онбординг користувачів. У командах зазвичай були backend і frontend-розробники, QA, продакт-аналітики, продакт-менеджери, а також продуктові дизайнери, якщо напрям передбачав роботу з UI/UX.

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

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

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

Ми вибудували стратегію і за квартал підняли цей показник на 24 %, але в якийсь момент стало зрозуміло, що ми вперлися в стелю, бо нові приватні картки з’являлися, але на retention і DAU це майже ніяк не впливало. Тобто ми досягли оптимуму, після якого приріст уже не давав цінності для продукту.

Обмеження 2. Невеликі кроскоманди добре працюють, коли треба швидко реалізувати невеликі зміни.

Але коли йдеться про великі епіки, як от додавання нового функціоналу, на це може піти весь спринт, бо в маленьких командах кількість ресурсів нерідко обмежена і є лише один розробник, котрому складно одночасно покрити кілька напрямів. У результаті команда буде чекати, поки завершиться розробка й (!) тестування функціоналу, і вони не зможуть розпочати розробку навіть незначних задач.

Обмеження 3. Коли команда працює точковими метриками, є дуже висока ймовірність перетинів тестів усередині самої команди. І саме через точковий вплив в одному місці застосунку усі A/B-тести накладаються на ті самі екрани.

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

Паралельно із цим ми працювали над редизайном заголовків для всього онбордингу, включно із цим етапом додавання фото. У результаті новий дизайн заголовків потрібно було застосувати як для базової (один екран зі старою логікою), так і для тестової групи (два нові екрани). І виходило так, що на одних і тих самих екранах ми одночасно тестували дві різні гіпотези.

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

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

Тож найкращий спосіб його прокачувати — це робити комплексно й працювати над покращенням ефективності пушів, UI/UX, воронки метчу і так далі.

Проаналізувавши ці виклики й зрозумівши, що локалізація цілей не дає нам ефективно підіймати наші верхньорівневі метрики, наприклад Retention і DAU, у Q3 ми вирішили потестувати новий підхід до командоутворення й перейти до роботи стрімами.

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

• стрім монетизації фокусується на gross revenue і працює над усім, що пов’язано із заробітком продукту — від підписок і юридичних моментів (наприклад, податкових особливостей у різних країнах) до того, наскільки зручним є процес покупки;
• а retention-стрім наразі відповідає за Day 1 та Next Day retention і має в розпорядженні всі інструменти, що впливають на повернення користувачів: push-комунікації, метчінг-алгоритм, UI/UX зміни.

В обох продуктових стрімах наразі близько 11 спеціалістів: два продакт-менеджери, три продакт-аналітики, один дизайнер, два frontend, один backend і два QA-інженери.

Як ми визначаємо цілі

Taimi — це абсолютно data-driven продукт. Як я згадувала раніше, лише за минулий рік наша retention-команда зробила понад 400 A/B тестів, а загальний success rate склав 39,9 %.

Досягти цього показника ми змогли завдяки ретельній підготовці на всіх етапах: від визначення цілей до впровадження епіка. Далі детальніше розповім про кожен із цих етапів планування.

Визначення company-wide цілей. Наше планування завжди проходить за системою OKR (Objectives & Key Results) і починається з визначення річних і квартальних company-wide цілей. На цьому етапі компанія задає напрям і загальні OKR-цілі з приросту DAU і Net Profit, до яких має рухатися увесь продукт.

Каскадування цілей на департаменти та стріми. Далі ці цілі ми каскадуємо вниз — продуктова команда формулює свої Objectives, а потім кожен департамент і стрім визначає конкретні Key Results, за які відповідає.

Наприклад, зараз ціль нашого продуктового департаменту: [O] Durable Product Growth (підтримувати стійке зростання продукту), а Key Results нашого ретеншен-стріма — це покращення retention day 1 та next day retention. Також усі наші Key Results повинні мати конкретне цільове значення, яке зараховується як виконання мети. Ми не лише визначаємо метрику, на яку плануємо впливати, а й обов’язково фіксуємо, на скільки саме вона має змінитися.

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

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

Як інсайт стає епіком: шість етапів у нашій системі прийняття рішень

Над прийняттям рішень щодо тестування гіпотез (і щоби вплинути на метрики й зекономити час команди й ресурси розробки) ми працюємо за такою схемою.

Етап 1 — пошук інсайтів. У нас є кілька джерел, у яких ми знаходимо ідеї для гіпотез.

У першу чергу ми аналізуємо дані всередині нашого застосунку. Сюди входить як пошук нових ідей при аналізі A/B-тестів, що ми вже робили (що спрацювало, що ні, і чому), так і цілеспрямовані аналітичні дослідження — наприклад, по воронках активності, онбордингу, взаємозв’язках між поведінкою і метриками. Або глибший аналіз якості push-повідомлень, їхньої дистрибуції та успіху. Половину гіпотез ми точно беремо звідси.

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

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

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

Етап 2 — формуємо гіпотези. Міркуємо, як ми можемо використати ці інсайти для покращення продукту.

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

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

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

• на який Key Results стріма ми хочемо вплинути;
• який adoption ми очікуємо (відсоток користувачів, котрі скористається фічею). Наприклад, якщо ми розуміємо, що фіча крутезна, але за нашими розрахунками нею скористаються лише 5 % користувачів, то ми опускаємо її по беклогу;
• який ефект на метрику ми очікуємо. Тут важливо, щоби в розробку бралися фічі, які допоможуть досягти мети, а не лише логічно вписуються у ваші OKR.

Етап 5 — перетворюємо ідею на епік і забираємо в A/B-тестування. Цей крок у нас ділиться на:

• cold release — продакт-менеджери та ліди з обох стрімів (монетизація і retention) обговорюють, які епіки беруть до етапу підготовки до розробки й перевіряють, що немає перетинів по тестах;
• hot release — фінальний чекпоінт, на якому продакт-менеджери та ліди з обох стрімів погоджують перелік готових, описаних і оцінених командою розробки епіків, які підуть у роботу в наступному спринті.

Етап 6 — проводимо спільні ретро продуктовою командою двох стрімів після тестування гіпотези та обговорюємо результати експериментів і рішення по них.

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

Окрім цього, під час планування й подальшої роботи ми проводимо щоденні сінки:

• продакти, frontend, backend і QA мають дейліки між собою;
• також у нас є окремий дейлік для кожного стріму, де збираються продакти, продуктові аналітики та продуктові дизайнери.

Наше головне правило, яке дається досить важко, але якого ми намагаємось дотримуватись — будь-які зміни чи розмови мають бути записані. Єдина точка правди — це епік у Jira і всі зміни ми стараємося завжди фіксувати в коментарях до епіка.

Дані наштовхнули на нову фічу, яку вдалося зафічерити в App Store

У нашому застосунку є блок like-messages — варіанти готових повідомлень, які користувач може відправити разом із лайком іншому користувачу.

Наявність будь-якого like-message давало нам кращу конверсію (точну цифру важко виміряти, бо на це впливали й інші фактори, але приблизно конверсія зростала до 50 %) в deep dialogue порівняно з метчами без повідомлень. Тому ми вирішили проаналізувати:

• які like-messages користувачі обирають найчастіше?
• який reply rate у різних типів like-messageʼів?
• як це впливає на конверсію в deep dialogue?

У результаті ми побачили, що повідомлення «Привіт!» працювало краще за більшість складних питань, як от «Яке в тебе хобі?» або навіть «Привіт, як справи?».

І в нас виникла гіпотеза: а що, як автоматизувати ці like-messages і зробити фічу «First Move» — заготовлене повідомлення, яке автоматично відправляється після метчу. Користувач може обрати з кількох варіантів або написати своє, але ми преселектимо просте «Привіт!».

Після того як ми додали цю фічу, conversion from mutual to deep dialogue стала +33 %. А фіча First Move була зафічерена в App Store завдяки своїй унікальності в дейтинг-ніші (і, звісно ж, нашій команді, котра пітчила фічу в App Store).

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

1. Визначте, яка структура команд найбільше підходить для роботи над вашим продуктом. Якщо помічаєте, що команди успішно покращують локальні метрики, але це не впливає на ключові показники продукту — варто переглянути структуру й зрозуміти, як ви можете впливати на метрики комплексно.
2. Формуйте та погоджуйте цілі на всіх рівнях — від company wide до конкретних епіків, щоби команди не тягнули продукт у різні сторони й могли впливати на високорівневі метрики.
3. Проводьте регулярні сінки між ролями й командами, щоби не створювати перетини в тестах і швидко реагувати на проблеми. Головне правило тут — плануйте сінки заздалегідь, формуйте чітку адженду, фіксуйте письмово всі домовленості, щоби команда рухалася в одному напрямку.

Навіщо це все? Щоб усі у команді розуміли, навіщо ми робимо те, що робимо, і як наша робота впливає на загальний результат. І найголовніше — щоби ми не втрачали фокус на покращенні досвіду користувачів.

Якщо маєте питання щодо наших підходів — пишіть у коментарях, поспілкуймося.

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