AI-функціонал у бізнесі та «пастка рісьорчів»

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

Привіт, продакт-спільното! Знову на звʼязку Макс Галійов, Head of Product в EdTech-компанії Brighterly. Хотів би я пожартувати, що був на літніх канікулах і тому не повертався до вас із новими випусками Product Digest. Та насправді ми з командою працювали дуже плідно і завдяки цьому можу поділитися з вами кейсом із власного досвіду, як побудувати новий функціонал у продукті на базі AI, який розширює базову послугу та збільшує цінність для користувачів. А також, чому команда ретеншну може загрузнути в рісьорчах, якщо не обере одну пріоритетну метрику.

Learning Platform: 4 AI-фічі як новий функціонал

Для контексту: Brighterly — це онлайн-платформа для навчання школярів у США, яку ми за останні пів року трансформували від «школи математики з тьюторами» до цілісної Learning Platform з AI-фічами. До 2026 року дитина отримувала цінність від продукту саме під час 60-хвилинних уроків з тьютором 2-3 рази на тиждень. Та між заняттями не відбувалося нічого: батьки не бачили прогресу дитини, використання продукту не ставало щоденною звичкою так, як ми з командою прагнули цього.

Гіпотеза: якщо між уроками на платформі користувачам є чим зайнятися, то ретеншн зростає. Не через «більше контенту» в продукті, а тому що:

  • Батьки отримують рівномірну видимість прогресу своєї дитини.
  • Дитина може самостійно відстежувати успіх, не чекаючи на наступне заняття з тьютором.

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

Після їхньої імплементації зробили з командою непопулярний висновок — не всі AI-фічі однаково підвищують ретеншн:

  • AI Summaries — класна фіча, працює як сильний важіль, але саме на батьків.
  • Homework Help — також крута функція, але найменш популярна (корисна тільки для школярів, які мають труднощі з виконанням домашнього завдання самостійно).
  • AI Reading та Math Practice — фічі, в основі яких працює LLM, тож для їхнього розвитку та підтримки контенту потрібно закладати окремі бюджети. Відповідно система оцінки їхньої якості більш складна, тому що потрібно аналізувати якість контенту та роботу алгоритмів.

Урок № 1. AI-фіча не є цінністю сама по собі. Важливо, кого саме вона активує в decision-loop платежу.

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

A/B-тест: розширений пакет пропозицій користувачу замість окремої фічі

Для тестової групи користувачів ми вирішили спробувати не запускати всі AI-фічі одразу, а відкривати їх поступово:

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

Які результати отримали (без абсолютних значень):

  1. SPR (Second payment rate) у тестовій групі зростає стабільно між когортами.
  2. iRPU 30d зріс завдяки вищій конверсії у другий платіж.
  3. Reading upsell rate також зріс — функція AI Reading зробила дисципліну читання «приємним відкриттям» для користувачів, а не абстрактним апселом.
  4. Show-up на перший урок ≈ без змін, тому що новий AI-функціонал впливає не на точку входу користувачів, а вже після неї.

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

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

  • Створили інструмент для пошуку причин відтоку клієнтів (13 сегментів причин відтоку, LLM-класифікація вільного тексту з CS-каналів).
  • Побудували ML-модель прогнозу другого платежу (за алгоритмом LightGBM, з тестуванням «walk-forward» та shift-калібруванням).
  • Запустили окремі експерименти на сторінці оплати, онбордингу, бажаного часу для старту занять.

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

Так ми потрапили одразу в кілька «пасток»:

1. Метрик у роадмапі більше, ніж ініціатив. Відповідно кожен стежив за своїм показником, але не розумів, чи робить це компанію успішнішою.

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

3. Пріоритизація ініціатив відбувалась за ентузіазмом, а не за метрикою, тому що не було визначено ключовий показник.

Щоб це виправити, ми вирішили виділити одну метрику — Second Payment Rate (SPR). Це відсоток клієнтів, які зробили другий платіж у період 25-45 днів після першої покупки. Для чистоти порівняння вибірок ми вибрали тільки тих користувачів, які зареєстровані вже 45 днів, щоб справедливо порівнювати тестову та контрольну групи.

Урок № 3. Важливо як пріоритет обрати метрику, яка відображає найпершу точку на шляху користувача, коли він «голосує» за продукт тим, що вам потрібно.

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

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

Що змінилося на практиці:

  • Команда утримання клієнтів перейшла на точкову роботу, сегментуючи користувачів на 3 групи: найризиковіші клієнти, які за перші 7 днів жодного разу так і не зайшли на платформу, отримують персональний дзвінок. І завдяки точній вибірці кожен другий дзвінок потрапляє в ціль.
  • Перезібрали продакт-беклог: кожну ініціативу оцінюємо за тим, який внесок вона зробить у SPR, а не за тим, «у скільки квадратиків OKR потрапить».
  • Кількість активних рісьорчів у команді ретеншну знизилась орієнтовно вдвічі — водночас кількість запущених продуктових ітерацій зросла.

Урок № 4. Декомпозиція = делегування. Один головний показник та 4-5 підметрик дають кожній субкоманді свою ділянку роботи та зону відповідальності, але всі мають один глобальний фокус та продовжують рухатися в одному напрямку.

Збираємо висновки з цього кейсу:

  1. Щоб зробити AI-фічу фінансово ефективною, потрібно аналізувати, кого вона повинна активувати в decision-loop платежу.
  2. Bundle-експеримент актуальний тоді, коли одиничні фічі невеликі, але разом вони мультиплікативні.
  3. Метрика, підвищення якої стає для команди основною ціллю — це найраніша точка «фактичного голосування за продукт» від користувача, а не найпізніша чи найлегша.
  4. Щоб чесно порівнювати різні групи користувачів, їхні результати потрібно оцінювати в однаковому часовому проміжку — інакше давніші клієнти завжди здаватимуться успішнішими.
  5. Вибір єдиного головного орієнтира та його розкладання на менші підметрики запобігає хаосу в команді та утримує єдиний вектор руху.

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

Дякую, що дочекалися повернення та до звʼязку в наступному матеріалі!

👍ПодобаєтьсяСподобалось13
До обраногоВ обраному0
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