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

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

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

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

• Регистрация дохода в SDK
• Регистрация дохода в Unity

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

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

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

Значение дохода должно содержать только числа (и десятичную точку, если требуется):

• Не включайте никаких других символов и не форматируйте значение дохода каким-либо другим способом. Это означает отсутствие запятых, знаков валют (например, $), специальных символов и текста.
• AppsFlyer предоставляет значение дохода с точностью до пяти знаков после десятичного разделителя.
• Диапазон этого значения должен составлять от -10 000 до +10 000 в долларах или эквивалентную сумму в оригинальной валюте. Суммы за пределами диапазона отображаются в отчетах по сырым данным, а не в агрегированных отчетах.
• Пример: 1234.56
• Если доход передается в виде строки, то значение, заключенное в кавычки, должно быть действительным. Например: "1234.56".

Внимание:

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

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

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

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

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

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

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

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

AppsFlyer использует Open Exchange Rates для конвертации валют. Курс обмена обновляется ежечасно. Всякий раз, когда 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);

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

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

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

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

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

Отрасль	Название статьи
	Рекомендуемые события в игровых приложениях
	Рекомендуемые события в приложениях для электронной коммерции
	Рекомендуемые события в развлекательных приложениях
	Рекомендуемые события в финансовых и банковских приложениях
	Рекомендуемые события в приложениях для P2P-кредитования
	Рекомендуемые события в приложениях для онлайн-обучения
	Рекомендуемые события в приложениях для вызова такси и частных автомобилей
	Рекомендуемые события в приложениях для бронирования авиабилетов
	Рекомендуемые события в приложениях для бронирования отелей
	Рекомендуемые события в медицинских приложениях
	Рекомендуемые события в телекоммуникационных приложениях
	Рекомендуемые события в приложениях электронных кошельков
	Рекомендуемые события в приложениях для ставок на спорт

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

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

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

  {
    "af_level":"10",
    "af_score":"3387",
    "arena":"7",
    "char_type":"paladin"
  }

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

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

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

  

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

• Мы рекомендуем использовать в именах внутренних событий приложений только строчные буквы и цифры (a–z и 0–9). Имена событий AppsFlyer чувствительны к регистру. Например, af_purchase и af_PURCHASE — это два разных события в сырых данных. Однако в агрегированных отчетах (например, в обзорном и по событиям) они могут отображаться как одно событие.
• Существует ограничение по кратности: 300 уникальных событий в день. Подробнее
• Уникальные пользователи учитываются только по первым 100 событиям после установки приложения.
• Имена событий не могут начинаться с этих символов: " = + - 
• Значения событий не должны содержать символ +, за исключением в закодированных URL или закодированных в соответствии с ASCII.
• Названия событий не могут содержать пробелов. Вы можете использовать подчеркнутые пробелы (нижние подчеркивания) до или после названия события.
• Значения событий не должны превышать 2000 символов, так как они могут быть сокращены в отчетах по сырым данным. 
• Если вы включаете URL-адрес как значение события, нужно применить URL-кодировку.
• У Meta Ads есть свои ограничения относительно имен и параметров событий. Подробнее.

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

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

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

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

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

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

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

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

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

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

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

Используя комплексные внутренние события приложения, можно отправлять несколько событий в одном вызове 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"
   }
  ]
}

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

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

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

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

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

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

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

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