Краткий обзор: Повторная установка происходит, когда пользователь сначала устанавливает приложение, затем удаляет его и вновь устанавливает. Повторные установки приводят к одному из следующих типов атрибуции: неорганическая повторная установка, органическая повторная установка или реатрибуция (ретаргетинг). Повторные установки помогают избежать многократных расходов для пользователей, которые удаляют и устанавливают приложение повторно.
Что такое повторная установка
Повторная установка происходит, когда пользователь удаляет приложение и устанавливает заново в течение окна реатрибуции.
Повторная установка может прийти из ретаргетинговой кампании (реатрибуция), органического или неорганического источника.
Повторные установки, которые происходят из органического или неорганического источника и находятся в рамках окна реатрибуции, так и называются повторными установками.
Повторные установки, которые происходят в результате кампаний ретаргетинга, называются здесь реатрибуцией.
Они различаются тем, как атрибутируются события повторной установки и события в приложении.
Если установка происходит вне окна реатрибуции, то повторная установка считается новой установкой. Новая установка атрибутируется медиа-источнику (или органическому источнику, если интеракции не зарегистрировано), и начинается новое окно реатрибуции.
В таблице ниже показано, как AppsFlyer называет различные виды повторных установок
| Источник повторной установки | Окно реатрибуции действует? | Взаимодействовал ли пользователь с кампанией ретаргетинга? | Взаимодействовал ли пользователь с кампанией UA? | Как это называется |
|---|---|---|---|---|
| Из кампании ретаргетинга | Да | Да | Нет | Повторная атрибуция |
| Из органического или неорганического источника | Да | Нет | Да или Нет | Переустановка |
| Из органического или неорганического источника | Нет | Нет | Да или Нет | Новые установки |
Почему важно учитывать повторные установки?
Правильная атрибуция повторной установки не только является хорошим показателем того, что пользователи возвращаются к вашему приложению и что ваши кампании работают, но и важна для того, чтобы избежать многократных трат на таргетинг пользователей, которые удаляют и снова устанавливают приложение в течение окна реатрибуции.
Более того, атрибуция внутренних событий приложения при повторных установках к первоначальному медиаисточнику (первой установке) даёт рекламодателям более полное представление о взаимодействии пользователей с приложением. Так можно понять, насколько эффективны UA-кампании и реклама в рамках ретаргетинговых кампаний. Подробные сведения см. в разделе овнутренних событиях приложения ниже.
Процесс и результат повторных установок
Переустановка
После первой установки приложения пользователь удаляет его и затем устанавливает заново во время окна реатрибуции. Повторная установка может быть органической или в результате кампании UA (см. примеры).
Происходит следующее:
- Установка НЕ атрибутируется; она не отображается ни на дэшборде, ни в данных.
- Партнёры могут получать постбэки о переустановке, только если такая возможность поддерживается и получены явные разрешения от AppsFlyer. Рекламодатели могут выбрать отправку постбэков переустановки только этому партнёру или всем медиаисточникам, включая органические, на странице Активные интеграции партнёра в разделе постбэков установки.
- Информацию о том, как атрибутируются события в приложении, см. в разделе про внутренние события приложения.
Повторная атрибуция
После первой установки приложения пользователь удаляет его, затем взаимодействует с кампанией ретаргетинга и устанавливает заново во время окна реатрибуции.
Происходит следующее:
- Установка атрибутируется медиа-источнику ретаргетинга в представлении Ретаргетинг и объединенном представлении обзорного дэшборда.
- Представление привлечения пользователей не содержит реатрибуций.
- Все последующие внутренние события также атрибутируются медиа-источнику ретаргетинга (подробнее см. в разделе про внутренние события приложения).
- В медиа-источник ретаргетинга отправляется постбэк об установке.
Подробные сведения об атрибуции ретаргетинга см. здесь.
Внутренние события после повторной установки
События в приложении, совершенные пользователем после повторной установки, либо атрибутируются как органические или неорганические, либо не атрибутируются как органические в зависимости от статуса атрибуции событий после повторной установки (см. схему ниже). Примером внутреннего события приложения является пользователь, который переустанавливает приложение, а затем совершает покупку в приложении.
Статус атрибуции событий после повторной установки
| Статус атрибуции событий после повторной установки | После повторной установки | После реатрибуции |
|---|---|---|
| Атрибутируются как органические внутренние события приложения | неатрибутированные органические | Ретаргетинг |
| Атрибутируются первой установке(1) | медиа-источник первой установки | Ретаргетинг (2) |
|
(1) См. ограничения ниже (2) В поле первичного источника. Медиа-источник первой установки будет указан в поле вторичного источника (вы увидите это только в сырых данных). | ||
Неатрибутированные органические внутренние события
Переустановка
- Все внутренние события приложения учитываются как органические или полностью игнорируются в зависимости от метода отчётности.
- Внутренние события приложения будут передаваться с параметрами conversion_type (тип конверсии) и campaign_type (тип кампании) как «unknown» (неизвестно).
-
Дата, используемая для агрегирования данных, зависит от события:
- Для большинства внутренних событий приложения, инициированных SDK, для агрегирования данных используется дата загрузки приложения, а не дата повторной установки.
- Для событий доходов от рекламы (af_ad_revenue), отправленных коннектором SDK, для агрегирования данных используется дата повторной установки.
Повторная атрибуция
- Все внутренние события приложения атрибутируются медиа-источнику ретаргетинга.
Атрибуция к первой установке (режим первой установки)
Необходимые условия
Для режима первой установки требуется включение. Обратитесь к вашему менеджеру по работе с клиентами.
Режим первой установки даёт рекламодателям более полное представление о вовлечённости пользователей. Он показывает, насколько эффективны кампании UA и ретаргетинговые объявления, атрибутируя события в приложении первоначальному источнику, а не как органические.
- Переустановка в режиме первой установки: Все события в приложении, возникающие из повторной установки, атрибутируются к первоначальной установке (1). Временем установки атрибутированного внутреннего события будет время первой установки приложения, а не время переустановки. Например, если установка была произведена 1 марта, а переустановка 5 марта, и если активирована опция «Атрибуция событий после установки», любая покупка, совершенная после переустановки, будет атрибутирована к моменту установки 1 марта.
- Повторная атрибуция в режиме первой установки: Все события в приложении атрибутируются к ретаргетинговому объявлению в первичном источнике и к первоначальной установке во вторичном источнике. (2)
(1) См. ограничения ниже.
(2) Вы увидите это только в сырых данных.
Примечание
Органические данные по KPI на дэшборде могут показать более низкое значение, если для параметра Атрибуция событий после повторной установки установить значение Атрибутируются первой установке, поскольку некоторые из этих установок теперь могут быть атрибутированы к неорганическому медиа-источнику.
Примеры атрибуции в режиме первой установки.
Пример 1
Пользователь устанавливает приложение (день 0), совершает покупку за $10, а затем удаляет приложение.
На следующий день (день 1) пользователь снова устанавливает приложение и совершает покупку на сумму $5.
Поскольку пользователь уже совершил покупку до переустановки, он не учитывается в количестве уникальных пользователей.
Медиа-источник |
users |
Af_purchase: Уникальные пользователи День 0 |
Af_purchase: Уникальные пользователи День 1 (кумулятивно) |
Доход День 0 |
Доход День 1 (кумулятивно) |
Media_source_A |
1 | 1 | 1 | $10 | $15 |
Мы увидим увеличение дохода по тому же параметру device_identifier.
Appsflyer_id |
Идентификатор устройства | Медиа-источник |
Название события |
Дата события |
| 111 | XXX | media_source_A |
install | день 0 |
| 111 | XXX | media_source_A |
af_purchase | день 0 |
| 222 | XXX | органический |
reinstall | день 1 |
| 222 | XXX | media_source_A |
af_purchase | день 1 |
Пример 2
Пользователь устанавливает приложение (день 0), совершает покупку, а затем удаляет приложение.
На следующий день (день 1) пользователь снова устанавливает приложение из кампании UA и совершает покупку.
Медиа-источник |
Название события |
Дата события |
Атрибуция повторных установок |
Атрибуция внутренних событий приложения |
media_source_A |
install | день 0 | media_source_A | |
media_source_A |
af_purchase | день 0 | media_source_A | |
media_source_B |
reinstall | день 1 | media_source_B | |
media_source_B |
af_purchase | день 1 | media_source_A |
Проверьте, чтобы внутренние события атрибутировались к оригинальной установке
Вы можете проверить в отчёте о сырых данных, что внутренние события приложения после установки находятся в режиме первой установки, выполнив следующие шаги:
- Проверьте поле
install_timeдля внутренних событий приложения. Если оно отражает время первоначальной установки (не переустановки), событие будет атрибутировано к первой установке. - Проверьте
device_id(GAID или IDFA). Он остается неизменным при установке и переустановке, поэтому вы можете использовать его для связывания события с первоначальной установкой. - Обратите внимание, что значение
appsflyer_idвнутреннего события приложения отличается от значения исходной установки. AppsFlyer генерирует новый идентификатор AppsFlyer после каждой переустановки.
Ограничения
-
Только для пользователей, которые дали согласие на передачу идентификатора устройства (например, IDFA или GAID) приложению при установке и переустановке, события в приложении будут атрибутироваться к первоначальной установке.
- Идентификаторы устройств при первой установке и повторной установке должны совпадать.
- Повторная установка должна произойти в течение окна реатрибуции последней зарегистрированной установки.
-
Каждая установка и повторная установка по-прежнему будет иметь свой собственный уникальный
appsflyer_id. -
На дэшбордах не различаются события в приложении после установки или повторной установки.
- Разницу можно увидеть в сырых данных.
Как данные отображаются на дэшбордах AppsFlyer
| Повторные установки неорганические | Повторные установки органические | Повторная атрибуция | ||
|---|---|---|---|---|
| Сама повторная установка | Не видна | Не видна | Медиа-источник ретаргетинга* | |
| Атрибуция внутренних событий приложения далее | События после повторной установки: Атрибутируются как органические | неатрибутированные органические | неатрибутированные органические | Медиа-источник ретаргетинга |
| События после повторной установки: Атрибутируются первой установке | Первый медиа-источник | Первый медиа-источник | Ретаргетинговая кампания | |
| *Только на обзорном дэшборде. | ||||
Отчеты по повторным установкам с сырыми данными
Необходимые условия
Требуется включение. Свяжитесь с вашим менеджером по работе с клиентами, чтобы обсудить этот вопрос.
Как атрибутируются установка и внутренние события приложения
| Повторные установки неорганические | Повторные установки органические | Повторная атрибуция | Неорганическая установка | Органическая установка | ||
|---|---|---|---|---|---|---|
| Чему атрибутирована | Кампания UA | Органический | Ретаргетинговая кампания | Кампания UA | Органический | |
| Атрибуция событий далее | События после повторной установки: Атрибутируются как органические | Органический | Органический | Ретаргетинговая кампания | Кампания UA | Органический |
| События после повторной установки: Атрибутируются первой установке | Первая установка | Первая установка | Ретаргетинговая кампания | Кампания UA | Органический | |
Доступность отчетов о повторных установках
- Отчеты по повторным установкам с сырыми данными доступны с помощью средств доставки, указанных в следующей таблице.
- Отчеты имеют ту же структуру и заполняются аналогично отчетам по установкам:
- Медиа-источник: поля заполняются параметром медиа-источника, который привел к повторной установке, или как органическая установка.
- Время установки интерпретируется как время повторной установки, то есть время первого открытия приложения после повторной установки.
- Название события: Переустановка
| Способ получения отчета | Неорганические повторные установки | Органические повторные установки |
|---|---|---|
| Экспорт данных | ✓ | ✓ |
| Pull API | ✓ | ✓ |
| Data Locker | ✓ | ✓ |
| Push API | ✓ | ✓ |