Data Science у дії: як оцінити трафік і покращити маркетингові результати

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

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

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

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

Що таке модель оцінки трафіку та де її можна використати

Почнемо з визначення того, що ми сприймаємо як модель оцінки трафіку (МОТ) загалом.

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

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

То в яких кейсах модель оцінки трафіку може стати у пригоді?

• Прогнозування поведінки цільової аудиторії.

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

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

• Оцінка якості маркетингових кампаній та стратегій.

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

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

• Рекомендації з ухвалення рішень.

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

• Пошук ефективних івентів оптимізації.

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

Складові частини моделі оцінки трафіку

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

Збір даних

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

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

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

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

Вибір алгоритму

Коли дані зібрані, саме час переходити до вибору алгоритму. Визначимо вимоги до алгоритму, щоб він задовільняв саме потреби маркетингу:

1. Прогноз має бути точним.
2. Потрібно отримати його якомога швидше.
3. Система має бути якомога простішою, адже результатам моделі легше довіряти, маючи повне розуміння того, як вони формуються.

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

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

Тренування та валідація моделі

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

Отримання результатів моделі та впровадження їх у систему ухвалення рішень

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

Важливість бізнес-контексту для створення моделі

Крім описаних вище пунктів зі створення МОТ, не варто забувати про основний — бізнес-контекст. Жодна модель не може існувати у вакуумі, тож перед початком роботи над МОТ потрібно дати собі відповідь на запитання, а яку проблему ми вирішуємо? І тільки після цього братися до роботи.

Як самі бізнес-контексти можуть впливати на МОТ, розглянемо далі. В обох кейсах працюватимемо з продуктом із транзакційною моделлю монетизації, на котрому лише 1% від усіх реєстрацій стає платником.

Кейс 1

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

Ухвалили рішення розробляти синтетичний івент, основними бізнес-вимогами до якого стали:

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

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

Для пошуку такого івенту виконуємо базові кроки:

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

Для тестування івенту ми запускали парами кампанії з однаковими сетапами та в однаковий час, оптимізувавши одну на наш дефолтний на той час івент, а другу — на новостворений. Врешті-решт, отримали кращий перформанс другої кампанії, але якщо нам би пощастило менше, варто було би переглянути вимоги до івенту.

Кейс 2

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

Вирішили розробити модель прогнозування виручки, де використовуватимемо такі показники:

1. Точність прогнозу.
2. Швидкість отримання значень.
3. Інтерпретованість результатів.

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

Прогнозування виручки 180-го дня для користувача, котрий потрапив на продукт 6 годин тому, буде не сильно точним, тому ми вирішили виводити також довірчі інтервали крім прогнозованого значення.

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

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

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

1. Пояснюємо команді маркетингу, як працює модель, які фічі використовуються та який вплив вони мають. Бо простіше вірити цифрам, якщо розуміти, звідки вони беруться.
2. Додаємо прогнози до основної звітності й разом з командою перевіряємо кейси, де прогнози виглядають неправдоподібно.
3. Створюємо на основі прогнозованих значень оптимізаційні івенти. Це може бути як бінарний івент, для якого ми просто обираємо поріг, з якого хочемо відстрілювати користувачів, так і Value Event, в який будемо безпосередньо передавати прогноз виручки.

Це точно не вичерпний перелік кейсів, де можна використовувати ds-моделі для оцінки трафіку, а лише цікаві приклади, якими ми хотіли поділитися з вами.

За допомогою моделей ще можна:

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

Висновок

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