Спасибо!

Кто должен контролировать значение конверсии в SKAdNetwork?

Автор: Barak Witkowski
Valor de conversión y SKAd posterior al iOS14

До недавнего времени мало кто слышал термин SKAdNetwork (или SKAd). Однако благодаря недавним событиям все больше людей осознают важность SKAd в будущей маркетинговой экосистеме после релиза iOS 14.

В одном из наших прошлых блог-постов мы представили решение AppsFlyer для SKAd и рассказали о том, как нам удалось извлечь максимум пользы из данного фреймворка. Наше решение включает сбор данных, их валидацию и обогащение, а также активацию и “бесшовную” интеграцию как с рекламодателями, так и с рекламными сетями.

Механизм SKAd построен вокруг одного конкретного поля со значением конверсии. В этом блоге мы объясним, почему это поле так важно и как получить от него максимальную пользу, а также ответим на один из наиболее часто задаваемых в последнее время вопросов: Кто и когда должен контролировать/определять значение конверсии?

Значение конверсии

Значение конверсии — это поле с диапазоном от 0 до 63 (только целые числа). Данное поле полностью контролируется рекламируемым приложением. Постбэк SKAd, который Apple передает на атрибутированную рекламную сеть, просто пересылает это значение. Все просто, правда? Тогда почему оно так важно?

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

Без этого поля аналитика SKAd выглядела бы примерно так:
У моего приложения было 100 установок из кампании A на прошлой неделе и 200 установок из кампании B. Означает ли это, что кампания B лучше? Необязательно. Может быть, пользователи из кампании А демонстрируют лучшие показатели с точки зрения моих KPI?

Вот в чем заключается ценность конверсии. Она позволяет владельцам приложений «оценивать» своих конечных пользователей. Например: какой доход был получен от конкретного пользователя? Сколько уровней он прошел в моей игре? Сколько раз он нажимал на рекламу?

С полем конверсии маркетинговые инсайты становятся гораздо более информативными. Используя значения конверсии, мы можем прийти к такому выводу, как: «Хотя кампания B сгенерировала вдвое больше установок, пользователи из кампании A принесли гораздо больше прибыли и показали большую вовлеченность».

Отлично, значит, значение конверсии – это все, что вам нужно, верно?

Не совсем.

Прежде всего, все данные необходимо «закодировать» в одно ограниченное поле с диапазоном от 0 до 63. Это означает, что владельцы приложений не могут провести все измерения. Им нужно выбрать то, что для них наиболее важно.

Во-вторых, в SKAd существуют ограничения по времени.

  • Измерение событий, которые произошли более чем через 24 часа после установки, является проблематичным. Для этого нужно, чтобы приложение открывалось каждый день, пока не произойдет событие, или необходим какой-либо фоновый поток для периодического сброса таймеров.
  • Каждое обновление сбрасывает таймеры, в результате чего (уже и так отложенный) постбэк откладывается еще больше. В конце концов, эта задержка делает краткосрочную оптимизацию практически невозможной.

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

Итак, значение конверсии контролируется на стороне рекламируемого приложения. В чем же дилемма?

Верно, в конечном итоге контроль принадлежит рекламодателю.

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

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

Извлечение максимума из данных конверсии

Как уже упоминалось, получение максимальной пользы от значения конверсии на самом деле означает получение максимальной отдачи от SKAd. Если вы учли все нижеперечисленные пункты, вы сделали правильный выбор.

1) Единое управление

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


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

2) Полная инкапсуляция на стороне сервера

Значения конверсии могут быть изменены только на стороне клиента. Означает ли это, что вам нужно менять код приложения при каждом изменении конфигурации? Нет.


Требование: в любое время измените конфигурации на дэшборде SaaS. Фактический “mapping” должен быть немедленно передан стороне приложения, без необходимости обновлять версию в магазине приложений.

3) Простой процесс настройки

Конфигурация значения конверсии будет основываться на уже существующих in-app событиях приложения.


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

4) Гибкая конфигурация

Чтобы получить максимальную отдачу от этих 6 бит, необходима полная гибкость.


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

Например:

  • 2 бита для измерения прибыли, 3 бита для вовлечения, 1 бит для более точного времени установки
  • 4 бита для измерения конверсий 4-х различных событий, 2 бита для типа аватара пользователя

Может ли эта полная гибкость сочетаться с простотой в использовании? Ответ – ДА.

5) Параллельная/многорежимная (multi-mode) поддержка

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


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


ПРИМЕЧАНИЕ. При использовании рандомального разделения (random split) убедитесь, что ваш дэшборд знает, как масштабировать результаты.

6) Настраиваемая длина окна

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


Требование: Простая настройка (со стороны сервера) окна для изменения значения конверсии. Как всегда, модификация не требует изменения кода или релиза новой версии приложения.

7) S2S и серверные события

Некоторые рекламодатели отправляют события с сервера/CRM.


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

8) Прогноз качества пользователей на основе их первоначального взаимодействия

В SKAd измерение событий через 24+ часа после установки лимитировано, поэтому понимание качества ваших пользователей на основе их первоначального взаимодействия с приложением имеет огромное значение.

Требование: Алгоритмы машинного обучения/искусственного интеллекта, прогнозирующие долгосрочный LTV/ROI пользователя на основе его взаимодействия в первые 24 часа.

9) Сведение к минимуму риска манипуляции данными

Рекламодатели не имеют прямого доступа к постбэкам. Что еще хуже, данные конверсии не подписаны Apple, поэтому их нельзя проверить. Кроме того, данные могут быть изменены в процессе передачи рекламодателям.


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

10) Осуществляйте валидацию данных, сопоставив их с другими моделями атрибуции

Некоторые игроки все еще могут пытаться манипулировать данными SKAd.


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

11) Использование данных

Некоторые владельцы приложений хотели бы видеть свои маркетинговые инсайты на настраиваемых дэшбордах или посредством вызовов API.


Требование:  Преобразование значения конверсии для отправки рекламодателям – это не простая задача. Конфигурации будут меняться со временем и могут различаться в зависимости от географического положения и пользователя. Иногда может потребоваться масштабирование. 

12) Поддержка оптимизация кампании

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


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

13) Поддержка будущих изменений Apple

Версия 2 SKAd скоро будет заменена на v3, v4 и v5. SKAd будет играть важную роль после релиза iOS14, и Apple обязательно будет вносить новые изменения.


Требование: ваш партнер должен держать руку на пульсе этих изменений и изменять логику без необходимости обновлять код приложения или выпускать новые версии.

Могут ли рекламодатели делать все это самостоятельно?

Некоторые из них – да, другие – категорически нет.

При наличии ресурсов, рекламодатели могут создать серверный объект, который передает команды на клиентскую сторону, собирает внутренние события приложения, вызывает функции ОС и осуществляет ротацию значения поля. Эти объекты также могут отслеживать изменения, внесенные Apple, и принимать соответствующие меры.

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

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

Итак, вывод: кто должен контролировать значение конверсии?

Непосредственными кандидатами являются: рекламные сети, инструменты аналитики и MMP.

Почему рекламные сети – это не решение проблемы

Можно сказать, что у них нет интеграции с другими сетями, поэтому оптимизация кампании находится под угрозой. Можно сказать, что атрибуция – это не их компетенция.

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

Почему MMP (партнеры по измерению эффективности мобильной рекламы) – это самый оптимальный выбор

Надежные и беспристрастные по определению, у MMP нет конфликта интересов. Их единственная цель – предоставить рекламодателю надежные и точные данные.

Оптимизация кампании MMP – единственные, у кого уже есть такая интеграция со всеми сетями. Без них оптимизация кампании не может работать.

Обогащение различных моделей атрибуции SKAd существует не в вакууме, есть и другие модели атрибуции. Владельцы приложений хотят, чтобы все модели обогащали друг друга. Более того, только партнер, владеющий другими моделями, может гарантировать, что данные SKAd скоординированы и что никаких манипуляций не произошло. «Чистая» среда – ключевой элемент для принятия правильных маркетинговых решений.

И последняя рекомендация

Компания, контролирующая значение конверсии, также должна контролировать всю технологическую последовательность SKAd.

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

Barak Witkowski

Barak is the Chief Product Officer at AppsFlyer. He is a seasoned entrepreneur who has launched mobile apps with tens of millions of users worldwide.

Follow Barak Witkowski

Background
Готовы сделать правильный выбор?