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

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

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

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

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

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

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

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

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

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

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

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

Нативный AndroidНативный iOS

Запуск SDK в нативном приложении Android

ВЫБЕРИТЕ, В КАКОМ КЛАССЕ ЗАПУСКАТЬ SDK

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

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

ИНСТРУКЦИИ ДЛЯ РАЗРАБОТЧИКОВ ANDROID

  • Сообщите разработчику о своем решении по следующему вопросу:
    • В каком классе, Application или Activity, запустить SDK?
    • Какой сценарий согласия / отказа на предоставление данных использовать?

Выбор стратегии сохранения конфиденциальности

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

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

Атрибуция

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

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

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

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

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

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

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

Более подробно о CUID можно узнать из этой статьи.

Только для Android

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

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

РЕФЕРЕР УСТАНОВКИ В GOOGLE PLAY

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

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

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.
      Нативный AndroidUnity

      См. справку по Android SDK:

    • Согласие на сбор идентификатора устройства: Заставляет SDK собирать IMEI или Android ID с помощью функций setCollectIMEI и setCollectAndroidID (см. справку по функциям на вкладках ниже).
      Нативный AndroidUnityНативный React

      См. справку по Android SDK:

  • 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.

Нативный iOSUnity

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

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

Обзор waitForATTUserAuthorization

 Важно!

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

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

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

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

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

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

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

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

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

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

Нативный iOSUnity

Инструкции для разработчиков по настройке диалогового окна согласия на 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.

Нативный iOSUnityНативный React

Для отключения атрибуции SKAN используйте disableSKAdNetwork

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

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

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

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

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

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

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

Нативный AndroidНативный iOSUnity

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

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

При покупках в приложении 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» протестировать органические и неорганические установки, внутренние события приложения и диплинкинг (ретаргетинг). Это позволяет проверить корректность регистрации и атрибуции установок и внутренних событий.

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

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

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

См. также