Насыщенные внутренние события: обзор

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

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

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

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

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

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

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

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

travel.png

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

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

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

События дохода

Каждый раз, когда вы отправляете внутренние события, такие как покупка или бронирование авиабилетов, вы отправляете их с соответствующим доходом. Единственным параметром, который несет доход во внутренних событиях, является af_revenue.

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

af_revenue — это единственный параметр, который применяется для подсчета дохода от пользователей. Всегда используйте его для внутренних событий приложения, которые отображают фактическое получение дохода в вашей бизнес-системе.

Диапазон этого значения должен составлять от -10 000$ до +10 000$ или эквивалентную сумму в оригинальной валюте. Суммы за пределами диапазона отображаются в отчетах по сырым данным, а не в агрегированных отчетах. 

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

Внимание:

  • Для значений дохода нельзя применять какое бы то ни было форматирование. В значениях нельзя использовать запятые-разделители, знаки валюты, специальные символы или текст. Значение дохода должно иметь, например, такой формат: 1234.56. AppsFlyer предоставляет значение дохода с точностью до пяти знаков после десятичного разделителя.
  • В AppsFlyer отображается точная сумма дохода, полученная от SDK. Эти данные не включают никаких расчетов НДС, комиссий магазина приложений и т. п., кроме случаев, когда это предусмотрено разработчиком на стороне SDK перед отправкой в AppsFlyer.

Параметр af_currency содержит обозначение валюты, указанной в параметре af_revenue (или af_price). Если в параметрах события нет af_currency, то AppsFlyer отправляет его со значением по умолчанию — «USD».

Можно использовать af_price как денежный параметр, который не считается доходом (как, например, в событии «Добавить в корзину»). Этот параметр относится к цене отдельного товара.  Общая сумма всех покупок отображается параметром af_revenue.

Валюта дохода

Важно понимать, как AppsFlyer обрабатывает настройки валюты и конвертацию валюты.

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

revenue_normalization_flow.png

На вышеприведенной диаграмме показаны такой процесс:

  1. Отправлены внутренние события — разная валюта для каждого события.
  2. AppsFlyer приводит все валюты к доллару США.
  3. AppsFlyer обрабатывает данные о доходах.
  4. На дэшборде данные о доходах отображаются в валюте настроек приложения.
  5. AppsFlyer вводит данные о доходах в отчеты по сырым данным как в валюте события, так и в валюте настроек приложения.

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

Конвертация валюты

 Пример

В настройках приложения вы установили валюту GBP. Пользователь из Франции приобретает товар в вашем приложении. Цена указана в евро (€). Внутреннее событие, которое вы отправляете в AppsFlyer, выглядит следующим образом:

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"category_a");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"EUR");
AppsFlyerLib.getInstance().trackEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);

В этом случае AppsFlyer конвертирует доход из евро в доллары США и затем в фунты стерлингов. Предположим, что обменный курс составляет €1 = $1,13. Таким образом, €200 превращаются в $226,85. Далее AppsFlyer конвертирует доллары США в фунты стерлингов. Предположим, что обменный курс составляет $1 = £0,78. Таким образом, $226,85 превращается в £176,92.

Отображение валюты

Валюта устанавливается в настройках приложения. Валюта, которую вы установили в настройках приложения, является валютой, которая отображается на дэшборде. Независимо от того, в какой валюте вы отправляете внутренние события приложения, доход на дэшборде всегда отображается в той валюте, которую вы установили в настройках приложения.

 Пример

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

Вы отправляете три внутренних события в AppsFlyer.

  1. Событие A имеет доход 234 и GBP в качестве валюты.
  2. Событие B имеет доход 171 и EUR в качестве валюты.
  3. Событие C имеет доход 171 , но валюта не указана.

Данные о доходах на дэшборде

Доход, который отображается на дэшборде, — это конвертированное значение из валюты внутреннего события в доллары США, а затем в валюту настроек приложения.

Если в событии не указана валюта, AppsFlyer по умолчанию использует USD. На дэшборде отображается событие и доход следующим образом:

Внутренние события Unique Users (Уникальные пользователи) Кол-во действий Прибыль
A 1 1 £234
B 1 1 £149.4 — в пересчете из EUR в USD, а затем в GBP.
C 1 1 £132.9 — по умолчанию в долларах США, так как валюта не указана. Конвертируется из USD в GBP напрямую.

Данные о доходах в отчетах по сырым данным

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

Если в настройках приложения вы установили валюту GBP, но отправляете внутренние события без валюты, отчет по сырым данным показывает доход в валюте настроек приложения и в долларах США.

Отчет по сырым данным о внутренних событиях отображает событие и доход следующим образом:

Событие Выручка от события Валюта выручки от событий Доход от события GBP
A 234 GBP 234
B 171 EUR 149.4 — в пересчете из EUR в USD, а затем в GBP.
C 171 USD 132.9 — по умолчанию в долларах США, так как валюта не указана. Конвертируется из USD в GBP напрямую.

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

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

  • SDK AppsFlyer: наиболее распространенный способ отправки событий. Вы можете отправлять насыщенные внутренние события, отражающие активность пользователей в приложении, через специальный API, созданный AppsFlyer для событий, происходящих на уровне 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

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

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

Отрасль Название статьи
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 Рекомендуемые события в телекоммуникационных приложениях
InApp_Events_eWallet.png Рекомендуемые события в приложениях электронных кошельков
soccer_ball.png Рекомендуемые события в приложениях для ставок на спорт

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

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

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

  • Обзорная страница дэшборда: отображает показатели LTV для привлечения пользователей (UA) в реальном времени. Примечание: сюда входит доход, разделенный между органическими и неорганическими пользователями, о котором сообщается через внутренние события, и доход от ретаргетинга, который дважды атрибутирован.
  • Страница события: отображает эффективность внутренних событий приложения для разных медиа-источников как 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 — это два разных события в сырых данных. Однако в агрегированных отчетах (например, в обзорном и по событиям) они могут отображаться как одно событие.
  • Существует ограничение по кратности: 300 уникальных событий в день. Подробнее
  • Уникальные пользователи учитываются только по первым 100 событиям после установки приложения.
  • Имена событий не могут начинаться с этих символов: " = + - 
  • Значения событий должны содержать не более 1000 символов. 
  • Если вы включаете URL-адрес как значение события, нужно применить URL-кодировку.
  • У Facebook есть свои ограничения относительно имен и параметров событий. Подробнее.

Вопросы и ответы

В следующем разделе приведены ответы на распространенные вопросы о внутренних событиях приложения.

Как использовать параметр дохода?

Значения дохода можно отправлять с любым событием и именем параметра. Но чтобы зарегистрировать доход (в том числе отрицательный доход) в сырых и агрегированных данных AppsFlyer, НЕОБХОДИМО использовать параметр af_revenue. Всегда используйте его для внутренних событий приложения, которые отображают фактическое получение дохода в вашей бизнес-системе.

Параметр af_currency содержит обозначение валюты, указанной в параметре af_revenue (или af_price). Если в параметрах события нет af_currency, то AppsFlyer отправляет его со значением по умолчанию — "USD".


Подробные сведения о параметре af_revenue см. в руководстве по атрибуции дохода.

Как AppsFlyer атрибутирует события?

Внутренние события приложения атрибутируются исходному медиа-источнику установки приложения.

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

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

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

AppsFlyer регистрирует события по атрибутированным установкам как органические, если:

Регистрируются ли события, если устройство не в сети?

Если пользователь инициирует событие, когда подключение к Интернету недоступно, Appsflyer все же сможет записать это событие. Вот как это работает:

  1. SDK отправляет события на серверы AppsFlyer и ждет положительного ответа.
  2. Если SDK не получит ответа об успешном результате, событие будет помещено в кэш.
  3. Если затем будет получен положительный ответ, сохраненное событие отправляется на сервер повторно.
  4. Если в кэше хранится несколько событий, они отправляются на сервер одно за другим.

 Примечание

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

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

Что такое комплексные события в приложении и как их настроить?

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

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

{
  "af_revenue":"50.87",
  "af_currency":"USD",
  "af_receipt_id":"57601333",
  "product":[ 
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1177_8185",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"0153_9077",
	 "af_price":"14.99",
	 "af_quantity":"1"
   }
  ]
}

 Внимание

Комплексные внутренние события приложения приводят к ошибкам в постбэках в Facebook и Criteo. Если требуется полное сопоставление события с Facebook и Criteo, отправляйте отдельные события для каждого действия пользователя (например, отправлять событие добавления в корзину для каждого добавленного товара). Используйте сырые данные внутренних событий приложения, чтобы сгруппировать эти события.

Можно ли добавить несколько элементов в одну транзакцию?

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

 Пример

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


"{\"af_content_id\": [\"123\",\"988\",\"399\"], \"af_quantity\": [\"2\",\"1\",\"1\"], \"af_price\": [\"25\",\"50\",\"10\"], \"af_revenue\": \"110\", \"af_currency\": \"USD\"}"

Несколько элементов отправляются далее в виде массива в постбэках. На данный момент Facebook и Twitter не могут корректно обрабатывать массивы параметров. По этой причине AppsFlyer суммирует количество элементов (af_quantity) вместо того, чтобы отправлять их в SRN в виде массива. В нашем примере Facebook получит af_quantity=4.

 Примечание

Несколько элементов можно использовать со следующими внутренними событиями приложения:

af_add_to_cart, af_add_to_wishlist, af_tutorial_completion, af_initiated_checkout, af_purchase, af_rate, af_spent_credits, af_content_view, af_travel_booking, af_update 

Как AppsFlyer обрабатывает дедупликацию событий?

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

Два события считаются идентичными, если в них совпадают следующие поля:

  • Имя события
  • Значение события
  • Идентификатор приложения
  • Идентификатор AppsFlyer ID

 Примечание

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

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

Как долго AppsFlyer хранит данные на уровне пользователя и каковы обязательства по их удалению?

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

После удаления данных события, связанные с удаленными пользователями, отображаются как органические. Агрегированные данные за прошлое время не изменяются. Подробнее см. в разделе Обязательства по хранению и удалению данных.

Нужно ли добавлять к моим событиям параметр os (операционная система)?

  • Android SDK и iOS SDK автоматически добавляют параметр os (операционная система).
  • Приложения iOS: с 1 июля 2021 года для API S2S требуется отправлять параметр OS (операционная система). Если этот параметр не отправлен, считается, что данные получены от пользователя iOS 14.5, что влияет на способ предоставления сырых данных.
Была ли эта статья полезной?