1. AppsFlyer Support
  2. Интеграция SDK
  3. Внутренние события приложений

Руководство по насыщенным внутренним событиям

Avatar
Robin Daysy
Последнее обновление:
  • рекламодателей
ВведениеСтруктура событияЧастые вопросы

Краткий обзор. Регистрируйте насыщенные внутренние события после установки (таких как вход, регистрация, внутренние покупки), атрибутированные медиа-источникам и кампаниям.

Зачем регистрировать внутренние события?

Внутренние события приложения позволяют понять, что происходит в приложении. Это отличный инструмент для определения ценности пользователей приложения и качества трафика, поступающего из различных медиа-источников. Регистрация внутренних событий приложения позволит измерять такие KPI, как ROI (окупаемость инвестиций) и LTV (суммарная прибыль от пользователя).

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

О внутренних событиях приложения

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

travel.png

Стандартные и настраиваемые события

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

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

Отправка событий

Есть несколько способов отправки внутренних событий приложения в AppsFlyer:

  • AppsFlyer SDK: это наиболее распространенный способ отправки событий. Вы можете отправлять насыщенные внутренние события, отражающие активность ваших пользователей в приложении, через специальный API, созданный AppsFlyer для событий, происходящих на уровне SDK.
    Подробнее о реализации внутренних событий приложения в SDK см.:
  • API межсерверных событий: используйте этот API для передачи в AppsFlyer событий, которые происходят вне мобильного приложения. Например, если пользователь активен и в веб-, и в мобильном интерфейсах, в AppsFlyer можно зарегистрировать события из обоих источников и атрибутировать их одному пользователю. Это могут быть как внутренние события приложения, так и другие события, такие как события веб-сайта, события колл центра или покупки в вашей торговой точке.
  • Валидация покупки: это безопасный механизм, с помощью которого платформа осуществления оплаты (например, Apple или Google) проверяет подлинность сообщения о покупке в приложении. Это базовый механизм в борьбе против мошенничества с событиями дохода. Он также позволяет видеть фактический доход и отделять незавершенные покупки в приложении.
  • Гибридные приложения: эти приложения сочетают в себе собственные представления и HTML-контент, они также могут регистрировать внутренние события. Однако, поскольку SDK может отправлять события только с нативной стороны, разработчики должны переводить все данные о событии в нативный код.

Настройка внутренних событий приложения

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

Шаг Роль Задача Детали

1

Маркетолог

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

Рекомендуется начать с использования 3-5 событий, которые будут служить как KPI для оценки качества ваших пользователей (например, покупки, регистрация, обмен информацией). Параметры события являются необязательными, и можно использовать любой параметр с любым именем события.

Типичные внутренние события см. в разделе Рекомендуемые события для различных отраслей.
2 разработчик Внедряет код в приложение, где это применимо.
3 [Необязательно] Маркетолог Вместе с разработчиком настраивает поле идентификатора клиента (CUID).

Это поле позволяет дополнить данные по внутренним событиям за счет установления соответствий между данными атрибуции AppsFlyer и другими вашими данными, используя CUID в качестве ключа.
4 [Необязательно] Маркетолог Сопоставляет события с соответствующими партнерами на дэшборде.  Это постоянная задача, зависит от партнеров, с которыми вы интегрированы.

Определение внутреннего события

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

  1. Выберите имя события, наиболее подходящее для регистрируемого сценария.
  2. Выберите параметры события, которые требуется связать с событием. Эти параметры должны предоставлять контекст и дополнять данные по событию.
  3. Отправьте разработчику заполненную таблицу, как показано ниже.

 Пример

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

В следующей таблице показан пример структуры события, которую маркетолог передает разработчику.
Имя события Параметры события Значения параметра Момент запуска события
af_content_view af_price Цена товара

Пользователь просматривает страницу сведений о конкретном товаре.
af_content_type Название категории товара, например, «Обувь»
af_content_id

Идентификатор товара, например, SKU
af_currency

Валюта на странице сведений о товаре, напр., доллар США

Рекомендуемые события для различных отраслей

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

Отрасль Название статьи
InApp_Events_games.png  Рекомендуемые события в игровых приложениях
InApp_Events_ecommerce.png Рекомендуемые события в приложениях для электронной коммерции
InApp_Events_streaming.png Рекомендуемые события в развлекательных приложениях
banking.png Рекомендуемые события в финансовых и банковских приложениях
InApp_Events_lending.png Рекомендуемые события в приложениях для P2P-кредитования
education.png Рекомендуемые события в приложениях для онлайн-обучения
InApp_Events_ride.png Рекомендуемые события в приложениях для вызова такси и частных автомобилей
InApp_Events_flight.png Рекомендуемые события в приложениях для бронирования авиабилетов
InApp_Events_hotel.png Рекомендуемые события в приложениях для бронирования отелей
5669_Healthcare_icon_3.png Рекомендуемые события в медицинских приложениях
telecommunications_icon.png Рекомендуемые события в телекоммуникационных приложениях

Просмотр данных по внутренним событиям приложения

В течение всего жизненного цикла пользователя внутренние события приложения атрибутируются медиа-источнику, который инициировал установку. Все данные по событиям представлены либо как данные LTV (суммарная прибыль от пользователя), либо как данные об активности.

Данные по событиям можно просматривать на следующих страницах:

  • Обзорная страница дэшборда: отображает эффективность привлечения пользователей (UA) как LTV.
  • Страница события: отображает эффективность внутренних событий приложения для разных медиа-источников как LTV.
  • Отчет с сырыми данными по внутренним событиям приложения: содержит данные об активности, то есть хронологический список действий, выполненных пользователями. В этот отчет входят значения параметров событий, например: 
    {
  "af_level":"10",
  "af_score":"3387",
  "arena":"7",
  "char_type":"paladin"
}

    Обратите внимание, что отчеты по сырым данным — это премиум-функция.

Советы

При добавлении имен и параметров событий учтите следующее:

  • Для согласованности данных в отчетах по сырым данным мы рекомендуем определять и использовать одни и те же имена и структуры событий в приложении на всех платформах.
  • Чтобы обеспечить конфиденциальность ваших пользователей, не вводите в значения событий в приложении информацию, которая может непосредственно идентифицировать пользователей. Например, адрес электронной почты, имя, идентификационный номер и — в некоторых регионах — почтовый индекс.
  • Обратите внимание, что во время взаимодействий с пользователем AppsFlyer собирает IP-адреса устройств. В некоторых юрисдикциях или сценариях использования IP-адрес может считаться персональными данными. Мы используем IP-адрес для определения географического местоположения устройства (город, район), но не конкретного адреса. При необходимости вы можете маскировать IP-адреса, чтобы они не отображались в отчетах с сырыми данными.
  • Внутренние события приложения являются единственным источником данных о доходе в AppsFlyer. К каждому событию можно прикрепить конкретное значение дохода и просмотреть его в дэшборде приложения. Подробнее о параметрах монетизации.

    revenue_data.png

Ограничения

При добавлении имен и параметров событий учтите следующее:

  • Мы рекомендуем использовать в именах внутренних событий приложений только строчные буквы и цифры (a-z и 0-9). Имена событий AppsFlyer чувствительны к регистру. Например, af_purchase и af_PURCHASE — это два разных события в сырых данных. Однако в агрегированных отчетах (например, в обзорном и по событиям) они могут отображаться как одно событие.
  • Имена событий не могут начинаться с этих символов: ", =, +, -.
  • Рекомендауем не превышать длину значения для каждого события в 1000 символов.
  • Если вы включаете URL-адрес как значение события, нужно применить URL-кодировку.
Была ли эта статья полезной?

Статьи в этом разделе

Больше

Похожие статьи