Я Lukos — Android-разработчик, владелец команды по аутсорсу разработки арбитражных приложений и автор Telegram-канала «Про Mobile».
Последние полтора года все топовые команды говорят про то, что необходимо заливать трафик, оптимизируясь на события: регистрации, депозиты. Они ссылаются на свои тесты, утверждая, что при таком подходе конверт значительно выше.
В этой статье мы разберемся со следующим:
Сразу предупреждаю, что часть материала намеренно упрощена, и к примеру, те же нейронные сети Facebook сведутся к линейной регрессии, так как это является базисом, на который все наслаивается.
Что такое оптимизация за события?
Оптимизация за события — это рекламная кампания, которая нацелена на конкретное действие, к примеру, депозит. Facebook будет искать вам аудиторию, которая с большей вероятностью внесет депозит, тем самым оптимизируясь на данное событие.
Поскольку у Facebook большая и разноплановая аудитория, нам достаточно получить несколько событий, чтобы дальше по принципу Look-alike находились нужные нам пользователи. В своей документации Facebook рекомендует получить 50 событий. Другими словами, после 50 регистраций, депозитов, покупок и других необходимых действий Facebook будет подбирать аудиторию таким образом, что будет заметна разница в конверте между трафиком на событие и трафиком за инсталлы.
Что не так с оптимизацией за события?
В теории, все звучит крайне привлекательно — получили 50 событий, и вот Facebook уже неплохо собирает нужную нам аудиторию. Но на деле все не так радужно, как хотелось бы.
Это происходит потому что:
1. Facebook позволяет оптимизироваться на событие после того, как оно хоть раз произошло. Чаще всего, для того, чтобы убедиться, что в приложение все интегрировано правильно, первое событие воспроизводится искусственным образом. Соответственно, если на данном этапе медиабайер будет пытаться залить трафик с оптимизацией на событие, то эффективность будет крайне сомнительной, а цена лида может выходить значительно выше, нежели если бы отлив был за установки.
2. К примеру, вы берете приложение в аренду (или у партнерки) и на него одновременно льют несколько команд. Для упрощения расчетов, будем считать, что их два. Первая команда таргетируется на нужную, качественную аудиторию. Вторая команда не заморачивается этим вопросом и качество ее аудитории значительно хуже.
В таком случае, мы получаем следующую ситуацию. Две команды налили по 25 событий (ось X), качество трафика мы ранжируем от 0 до 100 (ось Y).
Примечание. В контексте данной статьи качество трафика — это условная метрика, которая служит для упрощения сравнения.
На графике можно увидеть 3 варианта качества трафика при оптимизации за событие:
Получается, что первая команда, которая пытается заливать качественный трафик, с учетом того, что на это приложение заливается и другая команда, будет получать качество почти в 2 раза хуже (напоминаю, что метрика условная), нежели если бы на приложение лили только они. И это при условии, что объемы у них примерно одинаковые. А если же перевес по объему составит 30/70, то общее качество трафика будет еще хуже.
3. С учетом того, что в казино, к примеру, играют миллионы людей по всему миру, а для должной оптимизации необходимо хотя бы 50 депозитов, то получается, что с точки зрения статистики выборка нерепрезентативная. Похожая аудитория, которую Facebook будет пытаться найти, может оказаться не самой лучшей.
Как решить эту проблему ?
По сути, все 3 проблемы вытекают из нерепрезентативной выборки. Больше людей — больше общего объема данных. В случае с белым приложением эти данные накопились бы со временем без каких-либо проблем. Но что делать с серыми приложениями, которые постоянно попадают в бан? Сохранять информацию о каждом пользователе, который внес депозит. Затем обучать приложение на уже имеющейся базе.
Тут вытекает преимущество крупных команд и партнерок над мелкими игроками рынка. У них есть объемы и ресурсы, чтобы накапливать эти данные и в дальнейшем их использовать. Получается, что крупная команда, которая оптимизируется за события, будет делать это значительно эффективнее (по подсчетам в статье разница получилась почти в 2 раза), нежели маленькая команда. Более того, у популярных среди вебмастеров партнерок на этом поле есть туз в рукаве — так как они бесплатно отдают партнерам приложения, то соответственно, они могут для обучения своих приложений накапливать более широкую базу, чем любая крупная команда.
Однако, стоит учесть, что нежелательно обучать приложение на основе всей выборки, которая имеется. Почему? Потому что, помимо того, что можно столкнуться с проблемой переобучения, стоит учитывать поведенческие факторы пользователя, которые могут существенно меняться. Год назад он бы с удовольствием выполнил целевое действие, а сейчас он ненавидит ваш продукт, но при этом участвует в обучении для оптимизации за событие.
Когда таких пользователей много, это портит общее качество модели. Другими словами, даже имея большое количество данных, лучше использовать не все, а только скользящую выборку за последние несколько месяцев. При этом, в выборку должны попасть только те пользователи, которые не просто совершили целевое действие, но еще и успешно прошли KPI. Таким образом, общая эффективность рекламной кампании вырастет, а среднее качество трафика будет выше, нежели когда приложение обогащалось сразу всеми данными.
Надеюсь, эта статья помогла вам разобраться с тем, как работает оптимизация за события, какие имеются подводные камни и почему такой залив трафика не всегда является панацеей.