App Inbox у дії: як впровадити центр нотифікацій і протестувати його ефективність
Надсилаєте багато e-mail? Досягли стелі продуктивності? Не знаєте, як ще зачепити й утримати користувача комунікаціями? Шукаєте нові канали, але не знаєте, з чого розпочати? Уже впровадили нові канали, але вони живуть окремим життям? Не знаєте, як оцінити ефективність і чи варто вкладатися в нові канали? Тоді ця стаття для вас.
Чому App Inbox, або «як ми тут опинилися»
App Inbox — це інструмент для внутрішніх повідомлень у мобільних застосунках або в особистому кабінеті користувача. Відмінність від пуш-сповіщень у тому, що повідомлення в App Inbox залишаються в застосунку й не зникають, поки користувач їх не перегляне.
Такий власний центр нотифікацій користувача на сайті — уже знайомий багатьом спосіб комунікації. Від інтернет-магазину до банку: ви, напевно, бачили застосування «магічного дзвоника», куди сиплються повідомлення у ваш особистий кабінет користувача.
Проте не всі маркетологи знають, що подібний сервіс комунікації надається «з коробки» популярними платформами, як-от ESP/CDP, і може бути легко вбудований у наявні сценарії комунікації.
Знову впершись у стелю покращень метрик email-маркетингу, де кожен додатковий 1% вимагає надзусиль, я дізнався про можливість додати в продукт центр нотифікацій (він же App Inbox).
За останні 10 років у маркетингу я дійшов висновку, що в такі моменти, коли досягнення цілей стає все важче, потрібно шукати game changer. Саме таким для мене і став новий канал App Inbox. У нашому продукті технічне впровадження було відносно легким: потрібно було лише дати згоду, оплатити тариф в сервісі (в нашому випадку, Customer Data Platform* eSputnik) і встановити певний простий скрипт собі на сайт, тому що рендеринг і менеджмент повідомлень відбувається на стороні CDP у тому ж акаунті, де ми шлемо email. Принаймні так здавалося, що це просто.
Тож після пітчингу для продакт-менеджерів і розробників ми стали розробляти дизайн UI/UX цього центру нотифікації на нашому продукті. Проте вже на цьому етапі виявилося, що не всі наші дизайнерські примхи можна реалізувати. Рендеринг відбувається на стороні CDP, вони використовують однакові принципи для всіх своїх клієнтів, тобто не можуть зробити певні відступи вліво-вправо, якщо це може конфліктувати десь на іншому кінці світу.
«Хай йому грець, це ж MVP. Для початку буде достатньо», — подумав я. Але мій шлях продовжився на менш цікаво. Після того ми налаштували атрибуцію й передачу цих даних з CDP на наш back-end, а також їхній вивід у наш дашборд Power BI.
Де з'явився App Inbox у кабінеті користувача і що саме надсилали
Далі я налаштував із десяток тригерних повідомлень у критичних точках транзакційної комунікації й трошки маркетингових upsell-промо. Не став вигадувати відомі двоколісні засоби, тож за основну лінію комунікації узяв підтримку наявних топових e-mail за обсягом і метриками.
А саме:
- сповіщення про розміщення замовлення;
- інші статуси щодо замовлення;
- нове сповіщення від виконавця;
- поштовх завершити DOI* для e-mail-каналу;
- поштовх завершити кинутий ордер.
Надалі також додали ручні масові розсилки з промоакціями (на скриншоті — приклад Black Friday Sale) й деякі інші маркетингові тригерні розсилки (на скриншоті — приклад Anniversary reactivation).
І вже буквально за місяць я побачив потенціал у шестизначних цифрах на квартал, що атрибутуються до цього каналу в дашборді. Варто додати, що в нас є декілька схожих проєктів, і ми практикуємо масштабування успішних кейсів між ними. Тож ви можете уявити, як у моїх очах з'явилися долари, наче у Скруджа МакДака.
Поділившись результатами зі своїм менеджером, ми стали планувати масштабування на наступний квартал. Власне, далі ми залучили ще чотири проєкти, стали рухатися второваною дорогою та впроваджувати App Inbox й у них.
Чому вирішили запустити А/Б-тести
Тут мене спіткав найцікавіший челендж. Десь на розі кварталів, уже після того, як ми затвердили алгоритм дій, ми отримали такий фідбек:
Підписуйтеся на наші соцмережі
«Ми не можемо довіряти даним атрибуції, тому що не знаємо напевно, скільки цей канал насправді заробляє грошей і чи не канібалізує він гроші з іншого каналу».
До того ж було слушне зауваження, що цей канал не можна розглядати як класичний інструмент утримання, бо він не повертає користувачів у продукт, а лише працює з тими, хто вже й без нього тут опинився. Тобто потрібно було мати більш чітку картинку аналітики перед тим, як діяти далі.
Особливо цікаво було те, що ми одразу запускали App Inbox лінійно, хоча зазвичай робимо А/Б-тести. Також варто додати, що в нас за рік до того був не дуже позитивний досвід тестування всього email-каналу. Тоді ми не змогли довести чіткий апліфт від наших дій у каналі email із погляду маркетингових комунікацій. Тож можете уявити мій не найпозитивніший настрій, коли я почув цю новину.
Що робити, довелося засукати рукава та планувати запуск А/Б-тесту. Варто додати, що всі стейкхолдери вірили, що цей канал дає позитивний вплив. Просто ніхто не міг вирахувати, який саме. І це означає, що ми не можемо планувати й пріоритезувати задачі з розвитку цього каналу, оскільки не можемо порівняти його вплив з іншими ініціативами. Усе ускладнювалося ще й тим, що мені потрібно було обґрунтувати запуск так званого «downlift А/Б-тесту», тобто ми свідомо йшли на втрати, для того, щоб уточнити ефективність нової фічі.
Відгуки колег про фічу
Основний плюс — легко та швидко налаштовувати повідомлення, гнучкість у визначенні TTL (Time to Live для повідомлення) відповідно до релевантності кожного повідомлення на момент, коли користувач його побачить.
- Приблизне співвідношення маркетингових і транзакційних за Revenue, Placements і Paids — 19% до 81%.
- Основний висновок: працюють транзакційні, які припускають, що користувач із високою ймовірністю перебуває наразі на сайті.
- У випадку з маркетинговими, мабуть, треба прив'язувати до івенту «customer online».
- Плануємо ще спробувати зв'язку: відправляти e-mail «Ми відправили тобі інбокс, іди подивися» + Інбокс.
- Загалом процес впровадження трохи складніше, ніж ті самі вебпуші, передбачає більше кроків (особливо враховуючи спочатку додавання в тестове середовище, потім виливку на прод). Це і взаємодії з CDP і розробниками, і дизайн самих іконок, і визначення селекторів, де вони повинні розміщуватися на сайті. Проте з впровадженням не було особливих проблем, найскладніше було додати іконки на сайт, на локалях було темне тло, треба було окремо змінювати для них колір іконок
А/Б-тест: як перевіряли ефективність
Який сетап?
Ми взяли два проєкти з найбільшою кількістю нового трафіку, це приблизно сотні нових якісних реєстрацій на кожному щоденно.
Далі розділили цей потік навпіл: 50% нових користувачів бачили функціонал App Inbox (дзвоник у меню й повідомлення в ньому), як і всі старі користувачі, а 50% — не бачили, наче його й не було ніколи.
Хід тесту, перші висновки
А/Б-тест несподівано став швидко набирати статистичну значущість, і вже за тиждень аналітик порадив зупинити його, щоб мінімізувати втрати. Загалом від пуску до зупинки й аналізу пройшло лише 11 днів.
Ми дивилися на такі групи сегментів із метриками:
- FCO-ордери, конверсійні й грошові метрики
Спостерігали різке падіння як ревеню, так і профіту у варіанті без App Inbox. RPO і PPO впали більш як на 20%
- nFCO-ордери, конверсійні та грошові метрики
NFCO ордерів було мало в цьому тесті (фокус був тільки на FCO), щоб робити якісь додатковий поділ за сегментами. Проте загалом ми не бачили змін у конверсіях між варіантами. Варто зазначити, що у варіанті без App Inbox менше ордерів в абсолюті, що опосередковано може свідчити про гірший ретеншн без App Inbox. Водночас однаково трекаємо статистично значне падіння як у ревеню, так і в профіті.
Підсумки: Попри недовгу тривалість, тест показав став значно нижчий перформанс користувачів у варіанті, де були відключені App Inbox:
- Нижчий p2p FCO;
- Нижчий RPO/PPO;
- Нижчу кількість оплат на одного користувача;
- В підсумку – падіння комплексної метрики PPU >20%
Основні інсайти з А/Б-тесту з точки зору впливу на комунікації:
1. Зрозуміли, що варто переглянути комунікації з апсел VAS*, які взагалі не працюють + впровадити нові комунікації з просування VAS
2. Порадувала статистика із FCO (First Customer Order), будемо робити ще більше упору в App Inbox на замовлення такого типу. Для бізнесу перша оплата – це стратегічно важлива точка взаємодії.
Що потрібно перед запуском для уникнення помилок
1. Можна посилатися на подібні use cases під час пітчингу задачі з впровадження каналу. Проте в будь-якому разі варто одразу планувати чітке бачення: який вигляд матимуть ваші повідомлення у вашому продукті, як ви вирішите «задизайнити» свій А/Б-тест і як заміряєте результат.
2. Дізнатися заздалегідь про технічні обмеження від вашого провайдера каналу App Inbox: на що в дизайні чи в тілі повідомлення ви можете впливати, а на що — ні.
3. Бувають випадки, коли провайдер може «впасти». Траплялося щось на кшталт DDoS-атаки. Можна заздалегідь попросити провайдера сповіщати вас про подібні проблеми на його стороні, щоб ви не втрачали ресурси в пошуках проблеми в себе.
Замість висновку
У нашому випадку вдалося довести значний вплив використання тригерних повідомлень на збільшення профіту з користувача в середньому на 20% порівняно з тими, хто не мав у кабінеті функціоналу App Inbox і не бачив цих повідомлень.
Які сценарії найкраще працюють
- Насамперед ті, які мають на увазі, що користувач уже на сайті й точно побачить ваше повідомлення. Пам’ятайте, самотужки цей канал не може повернути користувача «з офлайну».
- Ті, що прості й короткі у своєму вигляді, і дають вигоду за один клік. Наприклад: «Ваше замовлення готово, тисніть на повідомлення, щоб побачити його» або «Ось ваша знижка, натисніть на повідомлення, щоб застосувати її».
- Ті, для яких ви зробите зв’язку з іншим каналом: наприклад, email повернув користувача з офлайну, і в цей момент тригериться повідомлення App Inbox, яке допоможе довести користувача до конверсії в потрібну дію.
Глосарій
ESP (Email Service Provider) — це сервіс, який допомагає компаніям надсилати багато електронних листів клієнтам. Наприклад, рекламні листи, акції, розсилки тощо. Усе надсилається автоматично і зручно.
CDP (Customer Data Platform) — це система, яка збирає всі дані про клієнтів (що вони купують, які сторінки дивляться, як часто заходять тощо) в одному місці. Потім ці дані можна використати, щоб краще розуміти клієнтів і робити персональні пропозиції.
FCO — First Customer Order
nFCO — non-First Customer Order
PPU — Profit Per User
VAS — Value Added Service
RPO — Revenue Per Order
PPO — Profit Per Order
P2P — Place To Paid
MVP — Minimum Viable Product
DOI — Double Opt-In (в контексті подвійного підтвердження підписки користувачем)
Uplift, Downlift — підйом або спад (часто в контексті позитивного/негативного впливу на ревеню)
Пітчити — «продавати» свою ідею, захопити нею осіб, що впливають на рішення.
Retention — метрика утримання користувачів.
Дашборд Power BI — це інтерактивна панель, яка містить візуалізації даних, що допомагають аналізувати ключові показники та приймати рішення. Він створюється у Power BI Service та є статичним оглядом даних із різних звітів.
Статистична значущість — це міра впевненості в тому, що отриманий результат дослідження не є випадковим. Статистично значущий результат — той, якому можна вірити.