Як за допомогою ML ми покращили продукт, збільшили retention та використання преміум-фічі на 8%
Привіт! Мене звати Антон Шуляк, я Senior Product Analyst у дейтинг-застосунку Hily в українській продуктовій IT-компанії appflame.
Уже понад чотири роки я працюю в продукті в напрямку монетизації: разом із командою генерую і тестую гіпотези та допомагаю приймати рішення, які впливають на дохід і розвиток продукту.
Hily на ринку вже понад сім років, має 41+ мільйон користувачів і стабільно входить у Топ-5 за кількістю завантажень у США. Продукт працює за freemium-моделлю монетизації: базові функції доступні безкоштовно, а за преміум фічі потрібно заплатити.


В експерименті нижче я розповідаю, як ми впровадили
Хоч дейтинг і нішева галузь, але інсайти із цього кейсу виходять далеко за її межі. Тож якщо ви працюєте з мобільним freemium-продуктом, в експерименті буде, що взяти для себе.
Продакти й аналітики знайдуть для себе приклад роботи з преміум фічами. Ті, хто ще думає про впровадження ML у продукт, побачать конкретний кейс із результатами, який допоможе швидше прийняти рішення. А монетизаційні команди можуть зацікавитися принципом розширення охоплення преміум фічі завдяки гнучким алгоритмам.
Про команду та виклики
У нашій продуктовій команді працюють три підкоманди: Revenue Team, Core Experience Team і Algorithms Team. Я працюю в Algorithms Team, де ми розробляємо та вдосконалюємо внутрішні алгоритми, щоби покращити роботу застосунку. Це стосується як безкоштовних, так і преміум фічей.
Зокрема, для безкоштовних фічей ми працюємо над алгоритмами, які:
- підбирають найбільш релевантних користувачів у Finder — розділі на головному екрані застосунку, де можна переглядати профілі, свайпати їх, ставити лайки або надсилати повідомлення;
- автоматично підбирають і показують найкраще фото користувача першим у профілі у Finder, щоби профіль виглядав привабливіше й більше людей заходили подивитися його повністю.

Що стосується преміум фічей, то тут у нас подвійна задача. По-перше, зробити так, щоби користувачі отримували від цих фічей цінність і розуміли, за що платять гроші. По-друге, ці фічі мають допомагати нам збільшувати дохід. Тож балансувати між цими двома полярностями — це наша найскладніша задача й головний виклик сьогодні.
Контекст кейсу та проблема
Так як я працюю із напрямом монетизації, сьогодні говоритиму про те, як ми покращуємо логіки в наших преміум фічах.
Одна з таких фічей — Major Crush (Message Before Match), вона дозволяє написати іншому користувачу ще до того, як між ними відбудеться метч (у дейтингу взаємний лайк/метч є обов’язковою умовою для початку діалогу). Далі мʼяч на стороні іншого користувача — він або вона може прийняти, або відхилити запит на діалог.



Якось ми побачили, що Major Crush використовують рідше, ніж ми очікували, і шукали спосіб, як збільшити використання цієї фічі й конверсію в покупку. У попередній статті для рубрики Experiments Hub я докладніше розповідав про цей експеримент.
Якщо коротко, тоді ми вирішлили:
- додати можливість надсилати Major Crush прямо з екрана діалогів. Цим екраном активно користуються і він ідеально вписується в механіку фічі;
- показувати в рекомендаціях на Major Crush профілі людей, які в конкретний момент часу онлайн і зазвичай швидко відповідають.

Ці зміни збільшили нам конверсію у використання Major Crush на 4 %, а частота використання фічі збільшилася на 3 % й це розширило монетизаційну воронку фічі на 40 %.
Але згодом ми зрозуміли, що умова з онлайном нас дуже обмежує. Річ у тім, що більшість людей у будь-який конкретний момент не онлайн і для багатьох користувачів застосунок не міг підібрати релевантного користувача в момент заходу на екран діалогів. Через це фічу рідко використовували.
Дизайн експерименту, гіпотеза й застосування ML
Тоді в мене зʼявилася ідея:
a) замінити умову онлайну на гнучкі критерії за допомогою
Заразом ми могли протестувати ще одну гіпотезу:
b) якщо рекомендувати більш релевантних користувачів, це може підвищити конверсію в початок діалогу після використання Major Crush.
Для того щоби зробити новий алгоритм, я вирішив дослідити історичні дані з відправками Major Crush і знайти параметри, які корелюють із ймовірністю відповіді після відправки цієї фічі. Серед ключових:
- користувач нещодавно заходив у застосунок — це підвищує ймовірність відповіді на повідомлення;
- має високий reply rate (часто відповідає на повідомлення);
- у користувача увімкнені push-повідомлення;
- і загалом він регулярно користується застосунком.
Потім я навчив на цих параметрах нашу самописну
Як працює
- коли користувач відкриває екран діалогів, застосунок передає в модель список людей, яких він уже лайкав;
- модель оцінює кожен із цих лайків → визначає, з яким користувачем є найвища ймовірність відповіді на Major Crush → миттєво обирає найкращий варіант;
- АЛЕ: коли в нас є користувач із найбільшою ймовірністю відповіді, ми не показуємо його автоматично в Major Crush Thread. Натомість застосунок перевіряє, чи результат моделі для нього вище певного порогу, який ми визначали при її розробці і якщо умова виконується, тоді користувач зʼявляється в треді для рекомендації.
Таким чином ми забезпечуємо високу ймовірність відповіді й підсилюємо довіру до фічі. А ще не надто обмежуємо пул потенційних користувачів, щоб зберігати гарне покриття в рекомендаціях Major Crush Thread (тобто щоб у покази потрапляла достатня кількість релевантних профілів).
У результаті, якщо раніше ми підбирали тільки онлайн користувача, то зараз ми могли б узяти користувача, який не був у застосунку декілька годин, але в якого увімкнені пуші і великий відсоток відповідей на вхідні повідомлення.
Результати експерименту
Ми влучили в ціль із нашими гіпотезами — після переходу на більш гнучкий алгоритм нам вдалося збільшити покази Major Crush Thread більше ніж удвічі. А так як цей тред уже був популярний серед користувачів, у нас не зменшилася конверсія в клік на тред і у відправку Major Crush. Із цього треда ми отримали ріст відправок Major Crush майже ідентичний до збільшення його показів.
Тред для відправки Major Crush з діалогів не є нашим єдиним місцем відправки фічі — найбільша кількість відправок усе ж йде з Finder, тому нам також важливо було впевненитися, що ми суттєво не канібалізуємо інші джерела відправки. І як ми побачили з аналітики, інші джерела відправки Major Crush практично не змінилися. У результаті в тестовій групі ми спостерігали ріст у відправках Major Crush на 8 %.
Але найцікавіше, що і друга наша гіпотеза підтвердилася:
- оскільки ми за допомогою нової
ML-моделі рекомендували найбільш релевантих користувачів, нам вдалося покращити конверсію в початок діалогу із Major Crush на 11 %; - а також збільшити кількість діалогів, що починаються через Major Crush, на 6 % серед користувачів, які взаємодіяли із цією фічею.
Окрім зростання цінності фічі Major Crush, ми також удвічі покращили монетизаційну конверсію з неї. І, вишенька на торті, — ми збільшили ретеншн підписників на 2 %, що є доволі високим показником для одного тесту.
Висновки
Цей експеримент поки що є одним із найуспішніших серед тих, де ми використовували ML. Ми вкотре переконалися, що завдяки гнучності
Льорнінгом для нас було ще й те, що впровадження ML у продукт працює класно, коли ми точково покращуємо вже існуючий алгоритм, а не будуємо нові механіки з нуля.
Як результат ми бачимо, що користувачі готові платити за якісний функціонал і гарний досвід у застосунку. І для нас ці результати дають гарну базу для покращення продукту й майбутніх експериментів, котрими я та мої колеги будемо ділитися з вами тут у подальшому.
Буду радий відповісти на ваші запитання щодо статті або нашого кейсу в коментарях:)
3 коментарі
Додати коментар Підписатись на коментаріВідписатись від коментарівДякую що поділилися досвідом. Гарні ідеї і їх валідація, і розуміння їх впливу на різні аспекти застосунку. Але алгоритм, що ви описали, вхідні дані — не зовсім розумію як саме ML був задіяний — у вас чіткі структуровані дані, чіткі залежності — все так само можна вирахувати простими алгоритмами. Можете більше розкрити деталей по ML частині?
Дякую за коментар!
У нас є історичні дані із відправками Major Crush, і факт чи була отримана відповідь. Нашим завданням було на основі метрик отримувача(reply rate, час останнього відкриття застосунку, активність тощо) передбачити ймовірність відповіді.
Процес навчання:
- Зібрали датасет відправлених Major Crush з фактом отримання відповіді(target).
- Додали фічі, які були актуальні на момент відправки.
- Натренували модель класифікації на пайтон(бібліотека sklearn).
- Додатково модель валідували на відкладеній вибірці і намагалися отримати якомога вищий AUC.
На виході модель повертає значення від 0 до 1 — оцінку ймовірності того, що Major Crush з такими метриками отримає відповідь. Саме це значення ми використовуємо для рекомендації потенційного отримувача.Сподіваюся, що відповів на запитання!
Так, дякую — цікаво, чи ви порівнювали ML із простішими baseline-підходами і який був результат по метриках? Бо ML, як не крути, додає складності в підтримці та інфраструктурі.