Миграция на AppsFlyer с решений других поставщиков

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

процесс миграции

Обзор

Миграция на AppsFlyer с решения другого поставщика включает следующие основные задачи:

Над решением этих задач можно работать одновременно. Однако мы рекомендуем:

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

Действия

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

Объем работ
Задача Необходимое действие Кто задействован Ожидаемое время выполнения Примечания
Необходимые условия
  1. Создайте аккаунт AppsFlyer.
  2. Добавьте приложение в AppsFlyer.
  3. [Необязательно] Измените заданное по умолчанию окно реатрибуции в 90 дней, чтобы оно соответствовало вашему определению активных пользователей.
Маркетолог / пользователь дэшборда AppsFlyer

2 часа

 
Интеграция SDK
  • Интегрируйте SDK AppsFlyer в приложение.
  • Сопоставьте внутренние события S2S или SDK.
  • Обновите версию приложения в магазинах приложений.
Разработчики приложений

1–2 недели

Приложение должно быть обновлено в магазинах приложений после выполнения всех остальных задач.

Миграция устройств [необязательно] Мигрируйте идентификаторы устройств, чтобы избежать двойной атрибуции имеющихся пользователей. Инженер данных 1–2 недели Перед миграцией рекомендуем приостановить текущие кампании и возобновить их после обновления версии приложения. 
Миграция кампаний

Перенесите текущие кампании из следующих источников: 

  • Сети с собственной атрибуцией (SRN)
  • Рекламные сети без собственной атрибуции (не SRN)
  • Собственные каналы взаимодействия
Маркетолог / менеджер по привлечению пользователей 1–3 недели
Настройка отчетов по данным
  • Адаптируйте / сопоставьте структуры имеющихся отчетов со структурами отчетов AppsFlyer.
  • Подготовьтесь к получению отчетов AppsFlyer.
Инженер данных 2–4 недели  

Интеграция SDK

Интеграция SDK

SDK AppsFlyer, интегрированный в приложение, является связующим звеном между приложением и платформой AppsFlyer. Он сообщает об установках, открытиях и внутренних событиях приложения и т. д.

Чтобы интегрировать SDK AppsFlyer:

  1. Интегрируйте SDK AppsFlyer в приложение.
    См. руководства по интеграции SDK для Android и iOS.
  2. Сопоставьте внутренние события приложения, которые вы хотите регистрировать, с помощью схем AppsFlyer.
    Это можно сделать через SDK или S2S.
  3. Удалите SDK другого поставщика систем атрибуции.
    Это можно сделать сразу, перейдя исключительно на AppsFlyer, или одновременно использовать оба SDK в течение нескольких недель. Смотрите описание этих вариантов в таблице ниже.
    Опция Что произойдет после
    релиза обновленной версии приложения
    Эффект
    Удалить SDK конкурента (рекомендуется) Новые установки и обновления регистрирует только AppsFlyer.
    Конкурент по-прежнему отображает события, выполненные пользователями, пока пользователи не обновят свое приложение.
    • Быстрый переход.
    • Отсутствие двойной атрибуции.
    Оставить SDK конкурента на период миграции Атрибутируют новые установки и регистрируют события и AppsFlyer, и конкурент. На следующем этапе следует удалить SDK конкурента.
    • Возможна проверка данных. Это означает, что вы можете сравнивать данные AppsFlyer и системы другого поставщика.
    • Двойная атрибуция может вызвать двойные расходы в рекламных сетях. См. приведенные ниже примеры.
    • Повышенная нагрузка.
  4. После выполнения всех задач по миграции выпустите обновленную версию приложения с SDK AppsFlyer. Новые пользователи будут атрибутироваться через AppsFlyer. 
    Примечание.
    • Обязательно обновите приложение для магазинов iOS, Google Play и всех независимых площадок для Android.
    • Ваше приложение для Android может быть выложено на неофициальных сайтах APK, даже если вы этого не знаете (чтобы это выяснить, введите в интернете название пакета вашего приложения). Сайтам APK требуется некоторое время для обновления до последней версии, поэтому они могут привлекать органических пользователей, которые устанавливают старые версии без SDK AppsFlyer.
    • Обновление приложения в магазинах приложений может занять пару дней. Пользователи, устанавливающие приложение в этот период, могут получить предыдущую версию.

Миграция устройств необязательно

О миграции устройств

Миграция устройств — это процесс загрузки в AppsFlyer списка идентификаторов устройств ваших имеющихся пользователей (IDFA, IDFV, GAID, CUID). Этот процесс нужно выполнить до выпуска новой версии приложения, в которой есть SDK AppsFlyer. Есть два варианта миграции устройств — с атрибуцией и без атрибуции.

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

 Пример

  • Новый пользователь кликает по рекламному объявлению в Facebook и устанавливает ваше приложение 15 июня.
  • 24 июня этот пользователь обновляет приложение до версии с SDK AppsFlyer и запускает его. Для AppsFlyer это новый пользователь, которого нужно атрибутировать в реальном времени.
  • AppsFlyer запрашивает у Facebook идентификатор устройства пользователя. Поскольку пользователь все еще находится в рамках 28-дневного окна атрибуции Facebook, то Facebook атрибутирует пользователя себе. Из-за этого владелец приложения несет двойные расходы за этого пользователя.

После миграции устройств данные отражаются в AppsFlyer следующим образом:

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

Как мигрировать устройства

Для миграции устройств: 

  1. Решите, какую группу пользователей мигрировать. Вы можете перенести всех имеющихся пользователей (что может помешать получить точные данные реатрибуции из AppsFlyer), или только тех пользователей, которые недавно установили приложение (что может привести к двойной оплате по более давним пользователям).
    Мы рекомендуем мигрировать пользователей, которые были активны в течение текущего окна реатрибуции. Например, если у вашего приложения 90-дневное окно реатрибуции, мигрируйте тех пользователей, у которых за предыдущие 90 дней была хотя бы одна сессия.
  2. [Необязательно] Попросите маркетолога / менеджера по привлечению пользователей приостановить текущие маркетинговые кампании (в рекламных сетях SRN, не SRN, в собственных каналах и др.), пока не завершится миграция устройств.
    Если вы решите не приостанавливать кампании, перенесите все оставшиеся идентификаторы устройств из системы другого поставщика, как только обновленная версия приложения с SDK AppsFlyer будет выпущена в магазинах приложений. 
  3. Подготовьте CSV-файл на основе выбранной группы пользователей, используя структуру миграции с атрибуцией или без атрибуции.
  4. Отправьте CSV-файл своему менеджеру AppsFlyer.
    Ваш менеджер проведет миграцию идентификаторов устройств в AppsFlyer. 

Атрибутируемая миграция

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

Имя
столбца
Описание Обязательно Примеры
app_id

Идентификатор приложения (App id) в том виде, в каком он отображается на дэшборде AppsFlyer

Да
  • Android: com.great.app1 
  • iOS: id123456789

platform

Платформа устройства: iOS или Android

Да
  • iOS.
  • Android;

device_id

  • Android: GAID 
  • iOS: IDFA или IDFV

 

Да
  • GAID (нижний регистр): 9c9a82fb-d5de-4cd1-90c3-527441c11828
  • IDFA (верхний регистр): 9876F1SS-2983-3855-27RR-2R626772VFNB
  • IDFV (верхний регистр): A7328D98-A973-402A-8B87-D22A8611F2AF
id_type
  • Android: advertiserId 
  • iOS:idfa или idfv
  • В настоящее время другие идентификаторы (OAID, IMEI и Android ID) не поддерживаются. 
    Используйте метод миграции без атрибуции для пользователей Android, которые загрузили приложение не из магазина Google Play.
Да
  • advertiserId
  • idfa
  • idfv
install_time

Время первоначальной установки приложения в формате UTC ISO 8601:
yyyy-mm-ddTHH:MM:SS.SSS

  • Рекомендация: оставьте это поле пустым. В этом случае будет использоваться время миграции.
  • Если вы все же указываете дату, это должна быть допустимая дата в прошлом, не выходящая за рамки окна реатрибуции.
    • В некоторых случаях перенесенные устройства при первом запуске учитываются как новые установки.
      Пример 1. Устройство со временем установки, предшествующим дате создания файла минус окно реатрибуции приложения, не переносится с данными атрибуции. При первом запуске устройство воспринимается как новая установка (скорее всего органическая).
      Пример 2. Устройство перенесено со временем установки, но первый запуск выполняется после миграции и за рамками окна реатрибуции. В этом случае регистрируется новая установка.
Нет

2018-01-22T08:45:33.412

media_source
  • Или:
    • Идентификатор партнера AppsFlyer в том виде, в каком он отображается на дэшборде AppsFlyer.
    • Настраиваемый медиа-источник (не может быть идентификатором партнера).
  • Обязательно получите список точных идентификаторов партнеров от AppsFlyer.
  • Формат: значения чувствительны к регистру
Да


Неорганические: facebook_int, googleadwords_int

Органические: organic

integrated_partner
  • Указывает, является ли медиа-источник интегрированным партнером. Имеется в виду органический или индивидуально настраиваемый медиа-источник.
  • Формат: значения чувствительны к регистру
Да  
  • Да
  • нет
campaign

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

Формат: строка

Нет  
campaign_id

 Для более детальной атрибуции укажите исходный идентификатор кампании.

Формат: строка без пробелов

Нет  
Структура CSV-файла для миграции устройств с атрибуцией

Правила для CSV-файла:

  • CSV-файл может содержать сведения об устройствах пользователей по нескольким приложениям.
  • Каждая строка содержит один идентификатор устройства для одного приложения.
  • Должны быть включены все заголовки столбцов: app_id,platform,device_id,id_type,install_time,media_source,integrated_partner,
    campaign,campaign_id
  • Каждая строка должна содержать ровно 9 полей, разделенных запятыми.
  • Оставьте необязательные поля пустыми
  • Файлы могут содержать до 20 млн строк.
  • Если у вас несколько файлов, дайте каждому файлу уникальное имя.
  • В качестве кодировки используйте UTF-8.
  • [Необязательно] Сжимайте файлы с помощью ZIP или GZIP.

Неатрибутируемая миграция

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

Столбцы Когда использовать Пример
App ID + IDFA/GAID/IDFV
  • Если у всех ваших пользователей Android есть идентификаторы GAID.
  • Только пользователи iOS 
device_migration_file_option_1.png
App ID + Device ID + Device ID type
  • Если у некоторых из ваших пользователей Android есть только IMEI или Android ID, но нет GAID (независимые площадки, версии Android ниже 4.4.2).
  • Android ID должен иметь шестнадцатеричный формат.

Используйте точно эти строки для столбца ID type: advertiserId, idfa, android_id, imei.

device_migration_file_option_2.png
Структура CSV-файла для миграции устройств без атрибуции

Правила для CSV-файла:

  • CSV-файл может содержать сведения об устройствах пользователей по нескольким приложениям.
  • Каждая строка содержит один идентификатор устройства для одного приложения.
  • Файлы должны содержать все заголовки столбцов, как указано ниже:
    • Вариант 1: файл содержит все заголовки столбцов, а именно: app_id,device_id 
    • Вариант 2: app_id,device_id,id_type 
  • App ID в нижнем регистре
  • Идентификаторы Android в нижнем регистре
  • IDFA/IDFV в верхнем регистре
  • Допускается до 25 млн строк

Миграция кампаний

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

Примечание. Не обязательно переносить все маркетинговые кампании сразу. Чтобы мигрировать несколько кампаний, выделите их в сегмент по медиа-источнику (такому как, рекламная сеть или агентство), геоданным или кампании. 

Сети с собственной атрибуцией (SRN)

SRN отвечают партнерам по измерению эффективности мобильной рекламы (MMP) на запросы об интеракциях конкретных устройств. Если два MMP, например AppsFlyer и конкурирующий поставщик системы атрибуции, запрашивают одну и ту же сеть SRN об установке на одно и то же устройство, это может повлечь двойную оплату.

Чтобы мигрировать кампании в SRN:

  • Активируйте и настройте в AppsFlyer соответствующие SRN.

 Примечание

  • В SRN (кроме Facebook и Twitter) может быть запущено несколько MMP.
  • Facebook не может выполнять дедупликацию внутренних событий приложения.

Рекламные сети без собственной атрибуции (не SRN)

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

Чтобы мигрировать кампании рекламных сетей без самостоятельной атрибуции (не SRN):

  1. Активируйте соответствующие рекламные сети в AppsFlyer.
  2. Сформируйте ссылки атрибуции AppsFlyer для каждой рекламной сети.
  3. Замените имеющиеся ссылки в каждой вашей кампании на ссылки атрибуции AppsFlyer. 

Собственные каналы взаимодействия

К собственным медиа относятся ссылки атрибуции, используемые в следующих каналах:

  • Использование функции "поделиться контентом"
  • Web-to-app
  • Электронная почта
  • СМС
  • Посты в социальных сетях
  • Блоги
  • Интернет-сообщества (например, Quora)
  • и др.

Для таких кампаний AppsFlyer использует настраиваемые ссылки OneLink. Настраиваемые ссылки OneLink перенаправляют пользователей с учетом их устройств в нужный магазин приложений, непосредственно в приложение или на веб-страницу/лэндинг.

Чтобы изменить ссылки других поставщиков на ссылки OneLink AppsFlyer:

  • Свяжитесь со своим менеджером. Он поможет выполнить массовую миграцию всех ваших ссылок. 

Настройка отчетов по данным

Адаптация и сопоставление структур отчетов

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

Чтобы адаптировать и сопоставить структуры отчетов:

  • Свяжитесь со своим менеджером AppsFlyer, чтобы быстро адаптировать и сопоставить структуры данных ваших отчетов от Adjust, Branch/Tune или Kochava с используемыми AppsFlyer.

Настройка методов создания отчетов

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

Методы создания отчетов:

  • Экспорт CSV
  • Push API
  • Pull API
  • Data Locker

 

Была ли эта статья полезной?