{"id":13570,"url":"\/distributions\/13570\/click?bit=1&hash=f1bacf5c4cbd7b3a89944cb6a24ea229537917b3fe32459e3adc3e5edc200946","title":"\u041a\u043e\u0442\u044b \u0440\u0430\u0441\u0441\u043a\u0430\u0437\u044b\u0432\u0430\u044e\u0442 \u043e \u0441\u043e\u0446\u0441\u0435\u0442\u0438 \u0441 \u0432\u0435\u0440\u0442\u0438\u043a\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u0432\u0438\u0434\u0435\u043e","buttonText":"\u041c\u044f\u0443!","imageUuid":"af50a6ca-4f1a-5649-a992-94e85a4ba2c0","isPaidAndBannersEnabled":false}
Маркетинг
Maria Kurnosova

Как оценить рентабельность SKAN кампаний при помощи платформы Predicted.io

Тема сложностей после update 14.5 OS — одна из самых злободневных в мобайле за этот год. Многие уже прочувствовали на себе все ограничения при запуске кампаний SKAN и часто можно услышать мнение, что «кампании на 14.5+ не работают». И тут хочется задать встречный вопрос, а правильно ли вы оцениваете рентабельность SKAN кампаний?

Давайте рассмотрим основные подходы к анализу SKAN кампаний, но сперва кратко обсудим 2 основные проблемы, мешающих нам корректно оценить ROAS по кампаниям.

Проблема 1: Ивенты только первых 24ч.

Вы можете отправлять в SKAdNetwork ивенты первых 24 часов, что очень сильно ограничивает оценку перформанса рекламной кампании. Еще куда не шло, если у вас, например, годовая безтриальная подписка и большинство покупок происходят на онбординге. Но как оценить окупаемость, если у вас:

а) триальная модель с закупкой на WW (где конверт из trial в paid разнится в несколько раз в зависимости от ГЕО/канала)? Ок, ивент триала мы сможем отправить в SKAN, но как триалы конвертировались в покупки и какой Revenue принесли? Это мы уже не увидим в разрезе по каналам и кампаниям.

б) несколько цен на пейволе? А распределение по приобретаемым подпискам может значимо менять LTV в зависимости от ГЕО/канала?

в) разные цены на разных ГЕО, а SKAN не отдает данные по стране?

«Ладно, - говорит Head of UA/CMO/UA, - давайте посчитаем средние конверты trial -> paid и LTV и будем как-то предиктить». Звучит как план, но тут мы сталкиваемся с другой проблемой:

Проблема 2: Недотекание ивентов-постбеков по SKAN кампаниям.

При несоблюдении Apple’s privacy трешхолда, часть постбэк ивентов просто не будут записываться на кампанию (ист Apple)

Мы точно знаем, что часть покупок не доходит (видно как растет органика в закупаемом гео), но не знаем какая именно это часть и с каких кампаний/каналов. Для решения задачи распределения «псевдо» органики по каналам и кампаниям разные команды используют разные подходы:

Подход 1: Считать окупаемость платного трафика вместе с органикой / ее долей.

Скорее всего данный поход может вполне адекватно работать при закупке 1 канала на гео и невысокой долей органики. Но как только вы подключаете 2+ канал на одно и то же гео — то тут отделить мух от органики будет получатся очень «на глаз». Замеренный органик лифт (включение/отключение платного канала трафика на конкретном ГЕО и замер роста органики) на одном гео может сильно отличаться от другого + может значимо варьироваться от периода к периоду + будет отличаться в зависимости от канала.

Подход 2: Предиктить данные по SKAN кампаниям на основании атрибуцированных пользователей, которые разрешили трекинг

Упрощенно: берем конверт из инстала в подписку атрибуцированных юзеров и применяем его на инсталы SKAN. Метод может работать, если а) доля разрешивших трекинг юзеров высокая и данных по покупкам атрибцированных юзеров достаточно; б) допустить, что атрибуцированные и неатрибуцированные юзеры ведут себя одинаково (спойлер — часто это не так), в) распределение по странам внутри канала/кампании стабильно. Как правило, все условия очень редко работают одновременно

Подход 3: Брать исторические данные по закупке в канале и ГЕО и применять коэф (например, install-trial и install-paid) к кампаниям 14.5+.

По нашим данным значения CPM, CPI, CR% Instal → Trial/Paid значимо отличаются между SKAN и не SKAN кампаниями, что обусловлено изменениями работы алгоритмов и сложностью таргетинга в самих рекламных сетках, конкуренцией.

Подход 4: Уйти в web-to-web/web-to-app для IOS или в Android

Кажется, самый точный из всех подходов : -)

Наше решение для анализа SKAN кампаний

Мы понимаем почему команды используют перечисленные выше методы, ведь надо как-то считать экономику в новых условиях, но вместе с тем понятны и ограничения и неудобство данных подходов. Для наших клиентов мы разработали другой подход к оценке рентабельности рекламных кампаний SKAN и вот как решаем перечисленные выше проблемы:

Проблема 1: Ивенты только первых 24ч

У наших клиентов часто используется триальная модель и разные цены на пэйволе, большое число каналов и ГЕО в закупке, поэтому отправлять в SKAN только факт ивента триала/покупки не дает возможности корректно оценить эффективность кампаний.

Решение: мы строим предикт LTV юзера на нужный период (например, 1 год) в первые 24ч и отправляем его как conversion value в SKAN. Работает это так: когда наш клиент интегрируется с нашей системой, на момент покупки подписки его приложение запрашивает у нашего сервера значение Conversion Value (относительная ценность конверсии), а мы ему возвращаем значение (от 0 до 63), в котором зашифрован предикт выручки от этого пользователя. Благодаря такому механизму наш клиент как и раньше может видеть ROAS по кампаниям в рекламных кабинетах, в панели MMP (Appsflyer) и в нашем дашборде.

* пример отчета по всем каналам трафика

Отправка предиктивного eRevenue (по сравнению с отправкой просто ивента триала/покупки) значимо повышает уровень точности, корректности и скорость принимаемых решений, а также дает возможность запускать кампании с оптимизацией на ROAS.

Проблема 2: Недотекание ивентов-постбеков по SKAN кампаниям

Часть информации по постбекам SKAdNetwork возвращает обнуленной, т.е. мы ему послали CV=50, а он возвращает NULL - это значит, что какое-то количество предиктивной выручки затерлось и не попало в статистику.

Мы на своей стороне получаем все SKAN постбэки, определяем долю "потерянного" Revenue и перераспределяем ее по кампаниям. В среднем по всем каналам мы видим потерю около 20-30% Revenue, но самое интересное тут — это распределение этих постбеков между каналами и кампаниями. В кампаниях с одинаковым числом инсталов/день, может теряться от 3 до 30% eRevenue, а это уже, согласитесь, значимые для закупки цифры. Подробнее о методе подсчета и результатах мы можем поделиться на Демо нашей BI платформы Predicted.io.

Кстати, решение по SKAN кампаниям - это только один модуль в нашей платформе. Predicted.io - это полноценная маркетинговая аналитическая платформа, прогнозирующая выручку от привлеченных юзеров, которую вы получите через 1 мес/3 мес/6 мес/1 год/2 года. Если для вашей команды актуальна задача автоматизации отчетности и пересчета LTV, и вы хотите быстрее принимать корректные маркетинговые решения - оставляйте заявку на сайте Predicted.io или пишите на [email protected]. Мы будем рады рассказать подробнее о нашей платформе и ответить на все вопросы.

0
9 комментариев
Написать комментарий...
Мирослав Гузевич

Отличная статья, спасибо!

А как быть если большАя доля подписок приходит после 24 часов?

Ответить
Развернуть ветку
Maria Kurnosova
Автор

Мирослав, в случае большого числа подписок на 2+ день актуально учитывать конверт от таких юзеров в предикте и отправляемом CV, а также настроить обновление таймера update conversion value под ваши нужды

Ответить
Развернуть ветку
KazExpress

test

Ответить
Развернуть ветку
Maria Kurnosova
Автор

KazExpress, ваш тест cработал!)

Ответить
Развернуть ветку
Ihnat Kandrashou

"на момент покупки подписки его приложение запрашивает у нашего сервера значение Conversion Value"
А как вы собственно считаете этот CV? Вам же в любом случае надо использовать один или несколько из вышеописанных подходов

"Мы на своей стороне получаем все SKAN постбэки"
Это справедливо только для пользователей с версией ios 15+ ?

Ответить
Развернуть ветку
Maria Kurnosova
Автор

"А как вы собственно считаете этот CV? "
В нашей реализации CV - это и есть предиктивный Revenue, который мы получим от конкретного пользователя через период N (например, 1 год).
Считаем его на основании данных о пользователе (например, его страна), а также его действий в апе (например, юзер взял месячную подписку за 9.99$). Учитывая исторические данные, мы строим предиктивную модель и назначаем eRevenue (например, 34$). И так по каждому юзеру. Понятно ли я описала?

"Это справедливо только для пользователей с версией ios 15+ ?"
Для получения копий постбеков самостоятельно - только для 15+ OS, но также есть возможность выгружать постбеки из MMP, там постбеки всех 14.5+.

Ответить
Развернуть ветку
Ihnat Kandrashou

Из объяснения понял, что вы используете подход 3 из статьи :)
Ну а если к вам приходит клиент без исторических данных, что тогда ?

Ответить
Развернуть ветку
Maria Kurnosova
Автор

1. Про 3-ий поход - это не совсем так. 3-ий подход в статье: это, например, видеть по FB кампании спенд 10000$ и 5000 инсталов и, используя конверт исторической закупки на 13 ось из инстала в пейд (6%), считать pCAC и ROAS.

Мы тоже используем исторические значения при построении предиктов LTV юзера, но ключевая разница в том, что
а) мы постоянно обновляем применяемые исторические коэф-ты и, если, например, конверт из триала в платеж снизился по GB - это будет учтено в наших предиктах
б) мы доуточняем наши предикты полученными реальными данными

2. Если нет исторической статы - ищем вместе с клиентом рабочее решение, которое позволит отвечать на вопросы бизнеса, учитывая ограничения в исторических данных. Каждый кейс уникален и зависит от - периода горизонта планирования предикта, - это совсем новое приложение или не достает части данных по каким-то новым подпискам и т.д.

Ответить
Развернуть ветку
Maria Kurnosova
Автор

.

Ответить
Развернуть ветку
Читать все 9 комментариев
null