Як новий продуктовий підхід допоміг збільшити виторг застосунку на 45% за рік

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

Усім привіт! У Minecraft я використовую нікнейм Sneaker_Snake, а в реальному житті більше відомий як Єгор Домачук. Я Product Manager Taimi в українській продуктовій IT-компанії appflame, де працюю над створенням гіпотез і їхньою реалізацією. На сьогодні мій робочий досвід поділяється на два етапи: раніше я обіймав посаду Product Analyst, а зараз — Product Manager. Тому й підхід, про який ви прочитаєте в статті, має як суто продуктовий концепт, так і аналітичне обґрунтування.

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

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

За більше ніж рік роботи над монетизацією ми з командою провели 155 тестів наших гіпотез (а на момент публікації матеріалу це число може наближатися вже до 200). Маючи такий великий обсяг роботи, ми завжди ставили запитання: які гіпотези з більшою ймовірністю принесуть найкращі результати й виторг та як визначити їхні пріоритети? І ми розробили новий підхід до роботи з продуктом, який сьогодні допомагає нам генерувати ефективний роадмап із кварталу у квартал.

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

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

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

Суть підходу та як структуризація гіпотез для продуктових тестів забезпечує кращі результати

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

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

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

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

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

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

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

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

Коли ми починали впроваджувати новий продуктовий підхід, я зібрав усі наші завдання та дані з них за останній рік і розбив за пʼятьма концептами, які вже раніше виокремив у нашому продукті (їх можна побачити на скриншоті нижче). Гадаю, варто зробити ремарку, що ми працюємо над монетизацією застосунку для ЛГБТІК+ знайомств Taimi та використовуємо freemium-модель із багаторівневою системою підписок.

Розповім детальніше про кожен із них.

  1. Обмеження — це монетизаційний концепт, за якого ви обмежуєте споживачам доступну функціональність. Це може бути як закриття доступу до безплатних опцій, так і зменшення пропозиції на підписці. Тобто ви обмежуєте щось, що споживачі використовували. Наприклад, ми зменшили кількість дій у застосунку та запровадили платний доступ до раніше безплатних можливостей.
  2. Візуальні зміни — концепт, який актуальний у більшості випадків, але сюди зараховуємо не тільки UI/UX-зміни, але і зміни в комунікації до користувачів/ок. Цікавий факт: коли ми змінили CTA на монетизаційному екрані з «Continue» на «Get *Subscription_name* now», то просадили конверт у клік у чотири рази.
  3. Зміни умов — дії, які впливають на наші монетизаційні пропозиції користувач(к)ам: усе, що повʼязане з цінами, наповненням підписки, тривалостями бандлів (варіантів підписок) тощо. Загалом цей концепт накопичує ті гіпотези, які впливають на пропозиції на монетизаційному екрані.
  4. Зміна воронки — створення нових лійок продажів для наявних фіч або підписок, їхнє переміщення, переосмислення, зміна умов їхнього показу. Тобто все те, що відбувається до того, як користувачі/ки потрапляють на монетизаційний екран, і також стимулює їх перейти на нього.
  5. Нові фічі — щоразу, як ми додаємо абсолютно нову функціональність, ми зараховуємо це сюди. Введення нової фічі в діалогах, платні фільтри (яких раніше в застосунку не було, інакше це — обмеження) або кастомізований список рекомендацій тощо. Гіпотез може бути багато, але зазвичай вони найтяжчі в реалізації.

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

Які дані для аналізу продуктових концептів ми збираємо

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

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

Далі ми по концептах агрегуємо приріст виторгу від тесту та, наприклад, аналізуємо:

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

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

Інсайти з аналітики продуктових тестів, засвоєні завдяки нашому підходу

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

На графіку нижче можна побачити, що концепти «Зміни умов» і «Обмеження» дали суттєво більше результату за інші концепти. При цьому в Q4 2023 року концепт «Обмеження» не зростав. Отож можна зробити висновок, що ми або не реалізовували ніяких гіпотез, які могли б його стосуватися, або того кварталу всі ці завдання закривались у базу.

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

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

Якщо подивитись на метрику «Конверт закриття в тест» (Test Success Rate), але в розбивці поквартально, бачимо інші цікаві інсайти:

  • концепт «Зміни умов» з часом перестає працювати. Це легко пояснити тим, що через тести цін, тривалості підписок та інших варіантів пропозицій підписок довгостроково вигравати не вийде, адже рано чи пізно ми досягнемо оптимальної точки ефективності по цих тестах;
  • конверт «Зміни умов» за рік упав із 70% до 30%, але при цьому концепт «Зміна воронки» зріс із 50% до 75%. Загалом щойно ми починали використовувати новий підхід, то приходили до того, що концепт «Зміна воронки» найбільш неефективний і нам треба його мінімізувати. Робили ми це ще тоді, коли тільки вчилися використовувати цей концепт. Спочатку створювали дуже неорганічні воронки, та час навчив нас, як робити це правильно (приклад неорганічної воронки: на вкладці меседжів ми додали згори рекламу у вигляді повідомлення, де пропонували підписку зі знижкою). Саме цей інструмент змусив нас переосмислити підходи до створення / трансформації воронок у застосунку;

Наступні два графіки демонструють ефективність концептів у нашому продукті: перший вказує на середній виторг за один тест, другий — на середній виторг за один Story Point розробки.

За результатами бачимо, що «Обмеження» — це найефективніший концепт, який можна реалізовувати в застосунку; проте є і мінус: його не вийде використовувати постійно, він має дуже високу динаміку «вигорання». Тому треба використовувати його в перших кварталах роботи з монетизацією, потім створювати нову цінність за допомогою нових фіч і пізніше намагатися знову обмежувати. Але це завжди треба робити у вигідному обміні з метриками активності та ставити питання, чи готові ви, наприклад, отримати 1% до показника revenue (виторгу), натомість втративши 2% з показника retention (повернення користувачів/ок у застосунок).

Другий за ефективністю концепт, але тільки в коефіцієнті до витрачених Story Points — «Зміни умов» (графік нижче). Це не найважчі гіпотези в реалізації, але вони також мають властивість «вигорати».

Бачимо, що концепт «Нові фічі» дуже неефективний за витраченими Story Points, але для того, щоб наші найефективніші концепти й надалі підтримували позитивну динаміку, треба впроваджувати щось нове і збільшувати його обсяги використання серед споживачів.

Висновки за результатами нашого аналізу

Якщо підсумувати, наше основне джерело збільшення виторгу (концепти «Обмеження» + «Зміни умов») станом на зараз вигорає, і ми потроху можемо заходити в нейтральну динаміку. З часом зміни будуть мінімальні й впливатимуть тільки на те, щоб виторг не падав. Але ми вже давно користуємось цим продуктовим інструментом, й озвучені в статті інсайти ми знали ще перед початком попереднього кварталу (наприкінці 2023 року). Тому на графіку нижче ви можете побачити, наскільки суттєво ми почали працювати над впровадженням концепту «Нові фічі». При тому, що це тільки половина всіх випущених релізів у Q2 2024.

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

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

Ефективність нового продуктового підходу

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

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

Тому, підсумовуючи:

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

P.S.: Іноді, навпаки, треба визначати, які ідеї неефективні, та знімати пріоритети з кращих концептів (адже деякі з часом перестають приносити результат), як можна побачити на нашому прикладі нижче.

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

👍ПодобаєтьсяСподобалось20
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

дуже дякую за корисну інформацію та ваш досвід!

Чудова стаття!
Візьму на озброєння аналіз результатів тестів у розрізі концептів.

Дякую! Цікава стаття.
Не дуже зрозуміло як перевірялися гіпотези, це були A/B тести? Якщо так як ви перевіряли що один експеримент не впливає на інший? Як довго тривали експерименти щоб получити необхідний power?

Вельми вдячний!
Усі гіпотези ми перевіряємо за допомогою A/B тестування, вірно.
Пересічення експериментів ми не аналізуємо кожен раз, їх занадто багато і назбирати статистичну значимість на кожну варіацію пересічень дуже важко, якщо не неможливо. Але коли ми бачимо неочікувані результати і розуміємо, що це вплив іншого тесту, ми можемо вдатися до «аналізу тесту в розрізі іншого тесту»
Експерименти в нашій команді тривають в середньому від 13 до 17 днів. Цього часу достатньо, щоб назбирати статистично значимий результат, якого достатньо для прийняття рішення. Але також зустрічаються кейси, де adoption задачі маленький і тест треба тримати 1-2 місяці

Дуже крута аналогія з будинками! Головне щоб в результаті це все не рухнуло))

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

Щира дяка автору, додам в LinkedIn та Maincraft!
Проте, є питання

Тестуючи таку велику кількість нових фічей ми не заплутуємо користувачів?
Сьогодні фіча є — завтра замість неї інша

Дякую, кину порти хамачі в лінкд ін ;)
Насправді, ми доволі регулярно отримуємо фідбек від користувачів, щоб ми повернули старий функціонал, щоб повернули «старе» Taimi, оскільки юзерів дійсно заплутує новий функціонал. Але ми завжди приймаємо рішення виходячи з данних, якщо юзерів заплутує нова фіча і це видно — ми не закриємо це в тест.

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

Важка тема, але сподіваюсь, що зміг донести основну думку

Вау!! Неймовірна стаття, ви неймовірні

Цікава і змістовна стаття
Дякую автору

Дуже хороша рефлексія! Обовʼязково візьму на замітку 😎

Підписатись на коментарі