В этой статье мы разберем основы, связанные с ретаргетингом, а именно:

1. Что это такое?

2. Для каких игр он подходит?

3. В чем принцип его работы?

4. Каких пользователей имеет смысл возвращать?

5. Как оценивать результаты?

Давайте начнем.

Что такое Retargeting?

Retargeting — это процесс повторного привлечения пользователя в приложение для последующей монетизации его в рамках этого приложения. В нашем случае приложением является игра.

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

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

Также существуют косвенные признаки того, что продукт готов к запуску ретаргетинговых кампаний.

Нужен ли нам Retargeting?

Разрушение надежд

Изначально Retargeting не подходит для любого продукта. Его нельзя воспринимать как волшебную таблетку, которая решит ваши проблемы (если они у вас есть, то сначала нужно решить их, а затем думать о ретаргетинге) или позволит масштабировать прибыль в 10 раз. Согласно различным источникам, хорошим показателем для Retargeting считается ситуация, когда 10% всех маркетинговых затрат направляется на этот канал.

Также, размышляя о Retargeting, важно понять, что пользователь будет делать в вашем приложении, когда вернется. В играх, например, не стоит ожидать высоких результатов от Retargeting в hyper-casual проектах, где у пользователя контента хватает в среднем на две недели. В такой конфигурации ретаргетинг все еще возможен, но вряд ли принесет много денег. Чаще всего для ретаргетинга подходят игры с длительностью жизни пользователя более полугода, когда он может покинуть игру до того, как ознакомится со всем контентом.

Возможные бенчмарки для проб Retargeting

Если проект имеет Lifetime хотя бы 180 дней, то уже можно задумываться о том, что Retargeting может стать вашей точкой роста. Однако одного этого показателя недостаточно.

По различным оценкам от разных платформ (Google Ads, Moloco, Remerge), минимальный порог для запуска Retargeting — когда аудитория, которую вы хотите вернуть, превышает 50 тысяч пользователей.

Так как вы явно хотите возвращать не всех пользователей, можно ориентироваться на 1-2 миллиона уникальных установок за весь период жизни проекта.

Далее все слишком индивидуально для каждого проекта, и зависит от набора метрик (LTV, CPI, Retention). Здесь уже начинается поле для экспериментов.

В чем принцип работы?

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

Подсветка аудитории работает по-разному на разных платформах. Где-то используются кастомные списки с advertising ID или IDFA (на iOS, несмотря на отсутствие IDFA у большого числа пользователей из-за ATT Consent, все еще остаются пользователи с IDFA, которых можно выделить), в зависимости от платформы, на которой вы запускаете кампанию. Где-то вы полностью передаете информацию платформе и задаете правила по заранее определенным критериям (чаще всего это дни отсутствия в игре, совершение каких-то событий и доход).

Далее вы выбираете, по какому принципу будет работать кампания:

1. Запуск кампании как обычной кампании для первичного привлечения и оценка ее так же, как обычной кампании.
   Я не буду останавливаться на этом способе, так как на практике не встречал таких рекламных кампаний. Считаю, что он непредсказуем с точки зрения окупаемости, так как мы не знаем, сколько принесла бы выделенная когорта, если бы мы не запускали ретаргетинг. Например, я видел ситуации, когда дополнительные затраты приводили к тому, что в среднем мы получали меньше, чем если бы не запускали ретаргетинг.

2. Conversion Lift Test, A/B Test и другие названия, фигурирующие на разных платформах.
   Суть этого метода проста: разделить пользователей на тестовую и контрольную группы. Тестовой группе показывают рекламу, а контрольной — нет. Далее в течение фиксированного периода (например, две недели) наблюдают за кампанией. Иногда тест останавливают, если показатели значительно хуже целевых, установленных перед запуском кампании. Одни из самых базовых целевых метрик: CPR (Cost per Re-engagement), CPSS (Cost per Session-Start) и ROAS. По завершении теста начинается его оценка, о которой мы поговорим позже.

В какое время запускать Retargeting?

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

1. Длинные ивенты. Вы можете заметить, что во многих играх проходят различные длительные ивенты (Пасха, Рождество, Хэллоуин). Предлагается именно в эти даты запускать ретаргетинговые кампании, так как в эти периоды появляется новый контент для всех пользователей, и не нужно затрачивать дополнительные усилия разработчиков на добавление новых механик. Механизм достаточно прост: создается креатив в стилистике ивента с призывом вернуться в игру.

   

2. Короткие ивенты. Суть у них такая же, как у длинных ивентов. Единственное отличие — запуск на несколько дней.

3. Награды по deep link. Это лучший подход для ретаргетинговых кампаний в приложении, так как позволяет полностью контролировать их запуск. Контроль заключается в том, что вы выдаете разные награды для разных пользователей и аудиторий. Грамотный анализ может помочь вернуть большое количество пользователей, предложив каждому персонализированный набор вознаграждений.

   

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

Кого возвращать?

Это самый сложный вопрос, так как существует много способов его понять:

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

2. Регион пользователя. Разные страны приносят разное количество дохода в играх, и смешивая их в одну аудиторию, можно получить странные результаты.

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

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

Как оценивать?

На самом деле алгоритм оценки очень похож на метод оценки фичи в A/B тесте, но немного модернизирован для нужд маркетинга.

1. Считаем объем аудитории в тестовой и контрольной группах.

2. Считаем количество пользователей и их доход.

3. Считаем коэффициент разделения аудитории на тест/контроль (k).

4. Считаем инкремент установок.

5. Installs Increment = N(test) - k * N(control).

6. Далее есть два метода оценки:

   1. Считать, что у пользователей, которые вернулись сами из теста, тот же ARPU, что и у контроля, и считать их ARPU равным среднему ARPU(test).

   2. Считать, что у них разное ARPU и что в тесте мы привлекаем более качественных пользователей.

Пример

За выделенный период количество пользователей, которым мы показали рекламу, составило 200 000 человек, а количество пользователей, которых мы

оставили в контроле, — 60 000 человек.

Количество установок из тестовой группы составило 12 000 человек, из контрольной — 3 000 человек.

• ARPU для d30 теста = $1.

• ARPU для d30 контроля = $0.5.

• Spend = $1 000.

• k = 200 000 / 60 000 = 3.33 (коэффициент разбиения по группам условный).

• Incremental installs = 12 000 - 3.33 * 3 000 = 2 000.

Далее считаем инкремент дохода, исходя из инкремента установок:

• Incremental Revenue = $1 * 2 000 = $2 000.

• ROAS d30 Incremental = $2 000 / $1 000 = 2.

Эта методология чаще всего используется для оптимизации верхнеуровневых ивентов типа launch и install (точнее re-engagement), так как в этом случае задача платформы сводится практически к одному — вернуть пользователя.

Вторая методология (аналогичные входные данные и обозначения метрик):

• k = 3.33.

• Revenue control = $1 500.

• Revenue test = $12 000.

• Incremental Revenue = $12 000 - 3.33 * $1 500 = $7 000.

• ROAS d30 Incremental = 7.

Этот метод чаще всего используется для оптимизации ценности (value optimization), чтобы учесть тот факт, что задача платформы — привлечь пользователей с высокой ценностью, а не просто вернуть пользователя в игру.

Заключение

С Retargeting нужно уметь работать, но так же нужно понимать что это не кнопка "Деньги". Так же стоит понимать что не для всех проектов он подходит.

Если хотите больше про маркетинговую аналитику мобильных игр, то можете подписаться на мой канал: https://t.me/analyst_in_jungle