Руководство по базовой интеграции SDK

Для:
маркетологов
Последнее обновление:

Краткий обзор. Совместно с мобильным разработчиком или разработчиком приложений для CTV выполните интеграцию и установку SDK в приложения для Android или iOS. Когда вы выполните задачи базовой интеграции, приложение будет готово к атрибуции установок и измерению внутренних событий. Когда вы выполните задачи базовой интеграции, приложение будет готово к атрибуции установок и измерению внутренних событий.   

 Материалы по теме

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

Получение ключа разработчика

Чтобы разработчик мог установить и интегрировать SDK, вы должны получить ключ разработчика. AppsFlyer использует ключ разработчика в качестве уникального идентификатора аккаунта. Ключ разработчика является обязательным, поскольку он позволяет SDK безопасно отправлять и получать данные, которые относятся к вашему аккаунту.

Чтобы получить ваш ключ разработчика:

  1. В AppsFlyer перейдите в раздел Configuration (Настройки) > App Settings (Настройки приложения). 
  2. Скопируйте ключ разработчика и отправьте его мобильному разработчику.

    af_devkey.png

  3. Предоставьте мобильному разработчику инструкции по установке и интеграции SDK.

Где запустить SDK?

При планировании интеграции SDK AppsFlyer первое решение, которое вы должны принять, — это где инициализировать и запустить SDK в потоке запуска приложения.

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

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

Запуск SDK в Android

Выберите, в каком классе запускать SDK

Выберите, следует ли запускать SDK в глобальном классе Application или в классе Activity:

  • Запуск SDK в глобальном классе Application: Как правило, инициализация SDK в глобальном классе/подклассе Application является хорошей практикой, поскольку класс Application загружается и инициализируется до отображения пользовательского интерфейса приложения. Это обеспечит запуск SDK для всех сценариев, включая диплинкинг.
  • Запустите SDK в классе Activity (отложенный запуск), чтобы дать пользователям возможность согласиться на предоставление своих данных. Это связано с тем, что для получения согласия пользователя требуется пользовательский интерфейс (UI), отображаемый в классе Activity.

Выберите сценарий согласия / отказа на предоставление данных

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

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

Указания для разработчиков на Android

Запуск SDK в iOS

Задержка запуска SDK в iOS

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

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

Для получения дополнительной информации о потоке данных для метода и его взаимодействии с фреймворком iOS ATT см. раздел Настройка поддержки фреймворка App Tracking Transparency (ATT).

Выберите сценарий согласия / отказа на предоставление данных

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

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

Указания для разработчиков на iOS

Поделитесь с вашим разработчиком следующей информацией:

Атрибуция

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

Все платформы

Уникальный идентификатор для установок

Идентификатор AppsFlyer ID автоматически создается для каждой новой установки приложения. От маркетолога никаких действий не требуется.

С помощью этого идентификатора можно:

Интеграция уникальных идентификаторов из системы бизнес-аналитики с AppsFlyer

Укажите свой идентификатор клиента (CUID) в SDK AppsFlyer, чтобы установить связь между уникальным ID из вашей системы бизнес-аналитики, ID AppsFlyer и другими идентификаторами. CUID можно посмотреть в отчетах AppsFlyer с сырыми данным. Он также может использоваться в API постбэков для связывания с вашими внутренними ID. 

См. инструкции для разработчиков по реализации CUID.

Только для Android

В следующих разделах приведены примечания по атрибуции для Google Play Store и сторонних магазинов приложений.

Атрибуция приложений, опубликованных в Google Play 

Google Play Install Referrer

API Google Play Install Referrer повышает точность атрибуции, защищает от мошенничества с установками и позволяет безопасно извлекать данные о рефералах из Google Play (например, версию приложения на момент первой установки приложения). 

Рекомендуем предоставить разработчику эти инструкции по добавлению API Google Play Install Referrer. 

GAID

Начиная с SDK 4.8.0, AppsFlyer автоматически собирает этот идентификатор устройства.

Атрибуция приложений в сторонних магазинах приложений

AppsFlyer позволяет атрибутировать установки, источником которых являются сторонние магазины приложений, такие как Amazon, Opera, GetJar, Baidu и Huawei. Благодаря этому у вас есть возможность продвигать свои приложения на рынках, где Google Play недоступен, и расширять аудиторию.

AppsFlyer поддерживает атрибуцию в контексте сторонних магазинов приложений следующим образом:

  • IMEI или Android ID: SDK не собирает IMEI или Android ID автоматически. Однако, если есть необходимость в сборе этих идентификаторов (например, в случае приложений для китайского рынка) ваш разработчик может реализовать один из следующих методов сбора таких данных:
    • Сбор вручную: приложение передает IMEI или Android ID в SDK (через API setImeiData или setAndroidIdData). SDK отправляет данные на серверы AppsFlyer. 
    • Разрешение на сбор идентификаторов устройств: заставляет SDK собирать IMEI или Android ID. 
  • OAID: атрибутирует установки из сторонних магазинов приложений для Android. Подробную информацию см. в руководстве по внедрению OAID.
  • Рефереры установок: SDK поддерживает получение данных о рефералах из Samsung Gallery и Huawei AppGallery.

Только для iOS

В следующих разделах содержится важная информация о поддержке устройств iOS 14+.

Настройка поддержки фреймворка App Tracking Transparency (ATT)

Фон

Начиная с iOS 14.5, для сбора IDFA нужно согласие пользователя. Фактически это означает, что доступом к IDFA управляет фреймворк App Tracking Transparency (ATT). На устройствах с iOS 14 и выше для получения доступа к IDFA устройства SDK использует фреймворк ATT. 

Базовую информацию об ATT см. в разделе Принципы ATT.

Если атрибуция выполняется с использованием IDFA, важно, чтобы IDFA отправлялся при первом запуске. Для этого в SDK предусмотрена утилита waitForATTUserAuthorization.

Обзор waitForATTUserAuthorization

 Важно!

Не вызывайте waitForATTUserAuthorization, если не собираете показывать запрос ATT.

waitForATTUserAuthorization позволяет задать, на сколько SDK будет задерживать отправку данных на серверы AppsFlyer, ожидая получения статуса ATT.

ATT-flowchart_en-us.png

Когда пользователь запускает приложение, ATT имеет статус notDetermined (Не определен). В течение времени ожидания waitForATTUserAuthorization SDK помещает в очередь в памяти событие запуска и последующие внутренние события приложения, аналогично тому, как регистрируются офлайн-события:

  • Если пользователь принимает запрос на ATT (сбор IDFA):
    • SDK добавляет IDFA к кэшированным событиям.
    • SDK запускается и отправляет кэшированные события с IDFA (не дожидаясь окончания времени ожидания).
  • Если пользователь отклоняет запрос ATT: SDK запускается и отправляет кэшированные события без IDFA (не дожидаясь окончания времени ожидания).
  • Если время ожидания истекло, а статус ATT остался notDetermined (Не определен): SDK запускается и отправляет кешированные события без IDFA.

Факторы, которые необходимо учитывать

  • Вызов requestTrackingAuthorization без настройки waitForATTUserAuthorization приведет к тому, что данные о запусках и событиях на устройствах iOS 14+ будут отправляться без IDFA.
  • Если в течение времени ожидания пользователь переводит приложение в фоновый режим:
    • Таймер приостанавливается, пока пользователь не вернется к окну приложения.
    • События кэшируются в памяти.
  • Если пользователь закрывает приложение, его работа прекращается в течение времени ожидания:
    • Таймер перезапускается при следующем запуске приложения.
    • Кэшированные события будут потеряны.

Настройка окна с запросом согласия ATT

Запрос ATT можно настроить. Сообщение, в котором четко указана цель запроса, может увеличить процент согласий.

При создании сообщения обратите внимание на следующее:

Закончив работу над сообщением, предоставьте разработчику текст и инструкции по реализации.

См. внешние примеры запросов ATT.

Поддержка атрибуции SKAN

 Примечание

Чтобы стала доступна полная поддержка атрибуции SKAN, обновите SDK iOS до версии 6.2.3+.

SKAN — это класс, используемый iOS для проверки установок приложений, стимулируемых рекламодателем. Для проверки установки нужны исходное и рекламируемое приложения. 

Исходное приложение — это приложение, которое участвует в рекламной кампании, показывая объявления из рекламной сети. Настройка вашего приложения для отображения рекламы не входит в задачи SDK AppsFlyer. Для настройки следуйте инструкциям Apple.

Для рекламируемого приложения (приложение с SDK AppsFlyer) решение AppsFlyer SKAN использует SKAN, чтобы отправлять постбэки об атрибуции. При этом AppsFlyer собирает, расшифровывает и агрегирует данные, обеспечивая конфиденциальность пользователей. При первом запуске приложения платформа AppsFlyer сообщает SDK, как задать значение конверсии SKAN, используя настройки, определенные маркетологом.

Чтобы использовать решение SKAN:

  • Маркетолог настраивает измерение SKAN в AppsFlyer. От разработчика действий не требуется.
  • SDK AppsFlyer автоматически вызывает необходимые API SKAN.
  • Если для атрибуции SKAN вы используете AppsFlyer, обязательно отключите вызовы SKAN в других SDK.
  • В магазине приложений не требуется каких-либо действий или регистраций со стороны разработчика или маркетолога. 

Чтобы отключить атрибуцию SKAN, попросите разработчика отключить ее в SDK. 

Регистрация внутренних событий приложения

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

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

Подробнее о внутренних событиях приложения читайте в Руководстве по насыщенным внутренним событиям.

Все платформы

Регистрация дохода

Данные о доходе можно отправлять с любым внутренним событием приложения. Убедитесь, что для включения данных о доходе используется параметр af_revenue. Это единственный параметр события, который AppsFlyer учитывает как реальный доход на дэшборде и в отчетах с сырыми данными. Подробнее.

Инструкции для разработчиков см. в разделе Регистрация доходов.

Проверка покупок в приложении

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

Отраслевые категории

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

Диплинкинг при помощи OneLink

OneLink — это решение AppsFlyer для многоплатформенной атрибуции, перенаправления и диплинкинга.

Все платформы

Идентификация устройств и перенаправление пользователей

Если у пользователей не установлено ваше приложение, OneLink определяет тип устройства и перенаправляет их в нужное место назначения: в Google Play, Apple App Store, сторонний магазин приложений или на веб-страницу. Это зависит от ваших настроек шаблона OneLink. Узнать больше

Диплинкинг

Если у пользователей установлено ваше приложение, OneLink открывает приложение. Помимо открытия приложения, вы также можете перенаправлять пользователей по диплинкам на определенное действие или страницу в приложении. Для этого вашему разработчику нужно реализовать унифицированный диплинкинг (UDL).

Внимание:

  • Для UDL нужен SDK версии 6.1+.
  • Вместо UDL клиенты, уже применяющие OneLink для диплинкинга, могут использовать устаревшие методы.

См. руководство по настройке диплинкинга и отложенного диплинкинга.

Отложенная глубинная ссылка (диплинкинг)

Если у пользователей не установлено ваше приложение, OneLink определяет тип устройства и перенаправляет их в нужную точку: в Google Play, Apple App Store, сторонний магазин приложений или на веб-страницу. Когда пользователь загрузит приложение, вы можете направить его на определенную активность или страницу приложения с помощью отложенного диплинкинга.

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

Внимание:

  • Для UDL нужен SDK версии 6.1+.
  • Вместо UDL клиенты, уже применяющие OneLink для отложенного диплинкинга, могут использовать устаревшие методы.

См. руководство по настройке диплинкинга и отложенного диплинкинга.

Доступ к данным атрибуции и диплинкинга

В следующей таблице описаны доступные методы получения данных атрибуции и диплинкинга:

Метод Кто задействован? Возвращение результата Метод получения данных Данные атрибуции Данные глубинных ссылок Доступность
Push API
  • Маркетолог
  • Бэкенд-разработчик
 Обычно несколько минут. Обработка на стороне сервера Y N Премиум
Pull API
  • Маркетолог
  • Бэкенд-разработчик
  • Периодически (не в реальном времени).
  • Вы можете запланировать скачивание отчета с сырыми данными. 
 Обработка на стороне сервера Y Y Отчеты с сырыми данными — премиум-опция
Data Locker
  • Маркетолог
  • Бэкенд-разработчик

Ежечасные отчеты доступны через 1–3 часа

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

  • Корзина AppsFlyer в AWS
  • Ваше хранилище (в AWS или GCS)
 Y Y Премиум
Получение данных о конверсиях (GCD) 
  • Маркетолог
  • Мобильный разработчик

См. документацию для разработчиков

 До 5 сек.  SDK Y Y Все аккаунты
Unified Deep Linking (UDL)
  • Маркетолог
  • Мобильный разработчик

См. документацию для разработчиков

 До 1 сек. SDK N Y Все аккаунты

В отношении пользователей iOS 14.5+, не давших согласие, необходимо учитывать следующее:

  • При использовании UDL для платных и собственных медиа доступны данные диплинкинга.
  • При использовании GCD для платных медиа сведения ограничены и не включают данные атрибуции и диплинкинга.

 Совет

Наши рекомендации:

  • Используйте Push API, чтобы получать данные атрибуции и отправлять их на свои серверы для дальнейшей обработки. Этот метод ожидает, когда данные станут доступны, и поэтому является высокоточным и работает почти в реальном времени. GCD возвращает данные в реальном времени, но если окончательные решения об атрибуции принимаются более 5 секунд, возможны неточности.
  • Используйте Pull API, чтобы периодически (например, раз в день) дополнять данные атрибуции, поступающие в реальном времени, и компенсировать возможные ошибки связи.

протестировать его интеграцию

Когда интеграция SDK выполнена, можно открыть дэшборд AppsFlyer и со страницы SDK Integration Tests (Тесты интеграции SDK) протестировать органические и неорганические установки, внутренние события приложения и диплинкинг (ретаргетинг). Это позволяет проверить корректность регистрации и атрибуции установок и внутренних событий.

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

Сценарии тестирования и инструкции см. в разделе Тестирование интеграции SDK.