Использование скоринг-модели в оптимизации кампаний для приложений Google Ads

Текущие алгоритмы кампаний для приложений в Google Ads отлично справляются со своей главной задачей (для рекламодателей) — генерацией установок. Также алгоритмы хорошо оптимизируют под события внутри приложений. Главное правило — соблюдать рекомендации по объему установок, событий, отношению событий к установкам и быть очень аккуратными с изменениями настроек активной кампании.

Вся эта модель прекрасно работает, когда в приложении нет большого числа «китов» и/или есть ограниченное количество предопределенных подписок, а события четко определены по воронке и достаточно часто происходят.

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

Даже если попытаться реализовать ROAS модель, возникает проблема с огромным разбросом ценности конверсии, которая свойственна такому бизнесу. В этом случае алгоритм потребует столько данных, что понадобится кампания с охватом в сотни миллионов пользователей и гигантские бюджеты на оптимизацию. И все равно не факт, что это может сработать.

Первые кампании для приложений мы в Forex Club запустили практически сразу, как они появились, — в 2016 году. Тогда мы получили несколько тысяч установок, регистраций, но результаты были настолько далеки от желаемых, что мы отвели фокус в сторону более перспективных проектов.

Долгое время мы были крайне довольны поисковыми кампаниями для приложений на Android и iOS, ровно до того момента, пока Google не закрыл их в конце 2017 года, вынудив рекламодателей переходить на UAC (универсальные кампании для приложений, с февраля 2019-го — кампании для приложений).

Несмотря на то что в целом показатели кампаний повысились благодаря улучшенным алгоритмам, мы все равно были слишком далеки от целей. Тогда мы начали думать над тем, как можно заставить алгоритмы работать на нас.

Поиск решений

Идея заключалась в поиске событий, которые происходят как можно чаще, но при этом содержат в себе показатель качества. У нас в Forex Club есть департамент Data Scientists, который занимается анализом массивов данных и построением моделей по предсказанию ценности пользователей.

Для работы с кампаниями для приложений мы решили упростить модель. Если построить график ценности (далее — «скор») пользователей по убыванию, получится примерно следующее:

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

Мы решили, что если будем сообщать в систему только о «хороших» событиях, то система сможет построить модели этих пользователей и сможет оптимизироваться под них.

Чтобы проверить эту гипотезу, мы решили сначала протестировать возможности автоматической оптимизации с более простой модели.

Сегментирование данных

Независимо от выбранного подхода к сегментированию пользователей или событий в них должен содержаться набор параметров, по которым их можно отличить. Мы понимали, что для оптимизации по качеству мы будем использовать сотни параметров начиная с имени пользователя и заканчивая количеством сделок на демо-счете. Поэтому для теста мы выбирали из того, что уже знаем об этих пользователях от платформы — рекламную сеть. Google передает эту информацию, она доступна и в интерфейсе. Мы создали кастомное событие, которое засчитывалось при удовлетворении двух условий:

Пользователь зарегистрировал аккаунт (30–60% конверсия из установки).
Пользователь пришел из рекламной сети «Поиск».

Затем мы запустили четыре кампании с оптимизацией под это событие. Таким образом несмотря на то что трафика в КМС значительно больше, стоимость установок и регистраций там значительно ниже, для алгоритма все выглядело так, как будто пользователи из КМС (и YouTube) вообще не совершают нужного действия.

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

На старте более 75% трафика приходилось на КМС.
По прошествии первой недели трафик делился пополам.
К началу третьей недели около 80% трафика приходило из поиска.
Тест закончился, когда мы стали получать более 95% трафика из поиска.

Результаты были усредненными по показателям четырех кампаний, запущенных на разные страны. Лучше всего (быстрее) получилось там, где было больше данных.

Мы убедились сразу в двух вещах:

Алгоритм действительно работает.
Мы можем им управлять.

Хорошие и плохие

Мы улучшили в несколько раз рентабельность кампаний, но знали, что это не предел, так как:

в кампаниях для iOS поиска практически нет;
не весь поиск одинаково хорош;
в КМС и YouTube очень много трафика и нам нужно научиться его покупать.

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

Пользователь зарегистрировался.
Скор пользователя выше заданного значения.

Скор пользователя рассчитывается спустя некоторое время, так как значительный вес скора составляет поведение внутри приложения. Нам удалось оптимизировать оценку и сократить ее до суток. Таким образом, Google получал информацию за понедельник утром в среду и так далее. Это не сказалось на работе алгоритма (по крайней мере, мы не заметили проблем). Но тем не менее имеются определенные доводы в пользу того, что лучшие результаты достигаются при отсутствии задержек в отправке данных.

Для расчета «отсечки» скора, при котором записывалось событие, мы воспользовались простой математикой так, чтобы отношение отправляемых событий было не менее 5% от количества установок с учетом объема в конкретной стране. Так, для каждой комбинации операционной системы и страны было рассчитано значение скора.

По аналогии с первыми тестами кампании начинали оптимизироваться под наше кастомное событие, их стоимость падала, объемы и отношение к установкам росли.

Автоматизация и оценка эффективности

На первых этапах все расчеты проводились вручную: выгружался массив данных, строились сводные таблицы, подбиралось значение исходя из требуемых цифр на выходе и записывалось в модель. Так как у нас достаточно много стран (более 40), две операционные системы, к тому же мы решили применить эту модель и в других источниках трафика, мы решили одновременно и автоматизировать процесс, и отслеживать прогресс оптимизации.

Весь процесс мы запрограммировали и вывели в виде конечных цифр в Google Spreadsheets. Фактическое значение форматируется в процентах, которые и выступают отсечкой по скору, где 0% — это 0 событий от регистраций, а 100% — это отправка каждой регистрации в качестве кастомного события.

Для отслеживания оптимизации каждый день мы выгружаем все регистрации по каждому набору данных за последние 30 дней и считаем, какому проценту от всех регистраций соответствуют те, что проходят по условию. Таким образом мы начали наблюдать, что в стране Х при изначально выставленной отсечке 30% по прошествии двух месяцев уже 45% регистраций приходит со скором выше выставленного, а это означает улучшение качества трафика на 50%. То есть те 30% хороших регистраций теперь уже половина, притом что критерий качества не менялся. Алгоритм работает, модель работает, кампании рентабельны.

Благодаря этому мы масштабировались в закупке кампаний для приложений в 13 раз за восемь месяцев, при этом рентабельность инвестиций увеличилась на 470%.