Як подолати виклики A/B-тестування монетизації у мобільних застосунках

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

Усім привіт! Мене звати Антон Шуляк, я — Product Analyst дейтинг-застосунку Hily в українській продуктовій IT-компанії appflame.

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

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

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

Виклики продуктових аналітиків у монетизації застосунків

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

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

Застосунок Hily

Щоб віднайти цей баланс і покращувати бізнес-показники, ми формулюємо продуктові гіпотези. Найчастіше працюємо із задачами в контексті конкретних бізнес-метрик (як-то конверсія в оплату, ARPU(Average Revenue Per User), LTV (LifeTime Value). А саме:

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

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

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

Челенджі при аналізі A/B-тестів

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

Ключовим в A/B-тестуванні є рандомізоване розподілення користувачів у різні групи, що дозволяє об’єктивно оцінити вплив змін на аудиторію. Якщо ви хочете перевірити, чи працює нова версія застосунку краще, і в групу «A» включите тільки чоловіків, а в групу «B» тільки жінок — це не дозволить точно оцінити вплив нової версії, оскільки сама аудиторія груп буде різною. З різними інтересами, поведінкою тощо.

Аналіз A/B-тесту може бути дуже складним і мати багато підводних каменів, які здатні погіршити якість та правдивість аналізу і привести вас до неправильного рішення. Тому далі ми поговоримо про челенджі, з якими можна зіштовхнутися під час аналізу A/B-тестів і як можна їх розвʼязувати.

Челендж #1. Вплив викидів у даних на монетизаційні метрики

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

Абстрактний приклад: один із ваших користувачів заплатив вам 1000000 доларів, коли середній чек у вашому застосунку 5 доларів.

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

Уявіть, що ви запустили A/B-тест, у якому збільшили дохід кожного користувача із 10 гривень до 15 гривень, і маєте по 100 користувачів у кожній із тестових груп. Середнє значення доходу в групі «A» буде 10 гривень, а в групі «B» — 15 гривень. Ріст 50%, усе чудово.

Але додамо ще по одному користувачу в кожну з груп — у групу «A» користувача із доходом 1000 гривень, а в групу «B» користувача із доходом 15 гривень. Середнє значення доходу в групі «B» не зміниться, але водночас у групі «A» воно складатиме майже 20 гривень. Група «B» уже не виглядає такою успішною. Тобто одне спостереження змінило ту групу експерименту, яку ви вважаєте кращою.

Як зʼявляються викиди? Причини їх появи можуть бути пов’язані не лише з поведінкою користувачів (наприклад, коли вони свідомо здійснили нетипові покупки в застосунку). Викиди можуть мати й технічний характер. Наприклад, через дублювання транзакцій у користувача або використання неправильного курсу валют.

У нашому продукті ми маємо два основних джерела викидів у даних:

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

Як працювати із викидами? У мережі можна знайти достатньо багато методів для роботи із викидами. За статтями How to Detect Outliers in Machine Learning і Outliers Detection ​​ви знайдете більше варіантів методів і зможете обрати найбільш зрозумілий і логічний для себе.

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

Область викидів на box plot візуалізації

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

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

Як зрозуміти, чи є у вас проблеми із викидами

Часто важко точно визначити, чи справді перед вами викид у даних. У таких випадках раджу слідувати цими кроками:

Уважно придивіться до своєї монетизації

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

Проаналізуйте історичні дані транзакцій

Чи були у вас колись аномалії, і як вони з’явилися? Такий аналіз дозволить зрозуміти ті патерни поведінки користувачів, які можуть спровокувати аномальні результати.

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

Проведіть A/A-тест

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

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

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

Челендж #2. Оцінка довгострокового впливу на монетизаційні метрики

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

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

Наприклад, одного разу ми запустили експеримент на основному платіжному екрані, де за замовчуванням змінили підписку із тижневої на місячну. Оскільки місячна підписка є дорожчою, на початку ми спостерігали короткострокове зростання доходу. Проте із часом, на 7, 14, 21 день і далі цей ефект поступово зникав, оскільки в базовій групі ми почали отримувати регулярні платежі за тижневі підписки.

Що можна використати для оцінки довготривалих ефектів

Ми використовуємо криву із кумулятивним значенням ARPU (Average Revenue Per User), яку рахуємо як середній дохід користувача за N днів життя в застосунку (lifetime). Але значення обраховуємо лише для тих користувачів, які прожили в застосунку мінімум N днів.

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

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

Кумулятивний ARPU

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

Як оцінити поведінку кумулятивного ARPU

Оцінювати кумулятивний ARPU складно, коли ми маємо пізні lifetime, оскільки зазвичай немає достатньо фактичних даних за ці періоди.

Для оцінки кумулятивного ARPU можна використовувати наявні дані, отримані під час експерименту. Зазвичай в нас це різні проксі-метрики, які сильно корелюють із наступними платежами. Тому що вони визначають величину ARPU для пізнього lifetime користувачів.

Найякісніші проксі-метрики, що впливають на пізні lifetime:

• Cancel Rate — рівень скасувань підписок;
• Subscribers/Payers Retention — утримання підписників/платників;
• Renewal Rate — фактичні дані по наступних платежах.

Наведу приклад гіпотези, яка принесла короткочасний позитивний ефект. Ми зробили зміну в місячній підписці, додавши до неї в подарунок одну з найбільш популярних платних функцій застосунку. Спочатку це дало гарний результат — користувачі почали частіше вибирати місячну підписку замість тижневої, що призвело до тимчасового збільшення доходів. Однак через те, що період між платежами зріс із 7 до 30 днів, наступні платежі значно знизились. Тому вже після семи днів тесту наша тестова група почала відставати від базової групи за показником кумулятивного ARPU.

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

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

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

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

Кумулятивний ARPU в експериментах із позитивним та негативним довгостроковим впливом

Челендж #3. Оцінка side-ефектів та канібалізацій воронок

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

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

Де можуть зʼявлятися side-ефекти

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

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

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

Канібалізації монетизаційних воронок

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

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

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

Як виміряти канібалізацію

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

Щоб оцінити рівень канібалізації, потрібно порівняти конверсії з наявних воронок у тестовій і базовій групах експерименту. Зазвичай ми це робимо в абсолютних числах, хоча можна також вирахувати відсотки. Наприклад, рівень конверсії у вашому застосунку 10% (базова логіка). Ви запускаєте нову воронку в тестовій логіці, з якої здійснюють покупку 4% користувачів, але водночас конверсія з інших воронок знижується і складає вже не 10%, а 8%. Тому сумарна конверсія в тестовій групі складає 12%, а не 14%, бо ви канібалізували 2% покупок із наявних воронок.

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

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

Челендж #4. Аналіз впливу на екосистему продукту

Як я писав раніше, ми працюємо за freemium-моделлю і надаємо користувачам безкоштовний доступ до застосунку з обмеженим функціоналом, який можна розширити за додаткову оплату, що дозволяє швидше знайти партнера або партнерку.

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

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

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

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

На що звертати увагу під час аналізу впливу на екосистему продукту

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

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

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

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

Челендж #5. Ефект новинки (novelty effect)

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

Як виглядає цей ефект і як помітити його в даних

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

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

Вигляд ефекту новинки в метриках

Як аналізувати ефект новинки

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

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

Спостерігаємо за динамікою метрик у тренді. Якщо експеримент триває місяць і приніс додаткові 1000 гривень, але 900 гривень були зароблені в перші три дні експерименту, то після його завершення ця функція може не мати суттєвого впливу на бізнес-показники.

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

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

Челендж #6. Аналіз відмінностей між різними сегментами

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

На які сегменти звертати увагу

Ми неодноразово стикалися із ситуаціями, коли після запуску A/B-тестів спостерігали значну різницю в поведінці різних сегментів користувачів. Найчастіше ці відмінності виникають між платформами: користувачі Android та iOS по-різному реагують на зміни, особливо в контексті монетизації. Бувало, що тест на iOS показував відмінні результати, тоді як на Android ті ж самі зміни не отримували позитивної реакції. Тому при аналізі ми зосереджуємося на цих сегментах.

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

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

Що робити, якщо сегменти користувачів по-різному реагують на експеримент

Якщо ми бачимо, що якісь сегменти мають різний вплив на метрики, ми:

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

Аналізуємо порядок змін у метриках на кожному із сегментів. Якщо ваша зміна працює на iOS із приростом в 10%, а на Android із падінням 3%, і розподіл користувачів між платформами приблизно 50 на 50, то в загальному ваш тест виглядає успішним.

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

Якщо ви маєте ситуацію, як у попередньому пункті, і не можете підтримувати різні логіки на платформах, то, запровадивши зміни для всіх, отримаєте приріст у загальній метриці, адже приріст на iOS компенсує спад на Android.

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

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

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

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

Ці дії дозволили нам зробити експеримент успішним для обох платформ у наступній ітерації експерименту.

Висновки

У даній статті я поділився списком задач, з якими найчастіше доводиться працювати аналітику в команді монетизації мобільного застосунку та списком проблем, які виникають при аналітиці A/B-тестів. Резюмуючи: якщо ви активно працюєте над монетизацією застосунку, варто памʼятати про таке.

1. Звертайте увагу на викиди в даних — зрозумійте їхню природу й розгляньте метрики без них.
2. Оцініть довготривалі ефекти — перевіряйте, чи отримаєте ви покращення метрик у тривалій перспективі тижня, місяця або навіть років.
3. Перевіряйте інші воронки та механіки на ефект канібалізації та непередбачуваних змін.
4. Оцініть вплив на ваш продукт як на екосистему. Враховуйте, чи не створять ваші зміни проблем іншим командам та майбутньому розвитку продукту.
5. Звертайте увагу на ефект новинки при роботі зі старими користувачами.
6. Аналізуйте зміну на різних сегментах, адже різні сегменти користувачів можуть сприймати її по-різному.

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

Якщо у вас залишилися запитання або ви хотіли б поділитися фідбеком та своїми думками щодо статті — залюбки поспілкуюся з вами в коментарях або у своєму LinkedIn.