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

Это означает, что некоторые данные, которые AppsFlyer связывает с неорганическими S2S-событиями, не будут связаны с органическими S2S-событиями в приложении.

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

• Идентификатор AppsFlyer является обязательным и используется для атрибуции событий.
• Он генерируется, когда пользователь впервые устанавливает мобильное приложение.
• Чтобы вы могли сопоставить свой CUID с идентификатором AppsFlyer, вам нужно задать CUID в приложении. 

Простой способ сопоставления пользователей с выполненными ими событиями приведен ниже.

• Задайте идентификатор клиента при установке приложения пользователем.
• Отчеты по сырым данным AppsFlyer содержат CUID и идентификатор AppsFlyer. Используйте один из инструментов доставки данных или AppsFlyer Push API. 
• Используйте отчеты о сырых данных, чтобы сопоставить CUID с идентификатором AppsFlyer. 
• Идентификаторы AppsFlyer можно получить с помощью SDK AppsFlyer, интегрированных в ваши приложения (Android / IOS).
• Сопоставьте идентификатор AppsFlyer с идентификатором клиента во внутренних системах (важно для использования в будущем).

Сопоставив идентификатор AppsFlyer с CUID, вы можете определить пользователя, выполнившего события. Затем вы сможете получить другие значения (значение события, валюту события, время события и т.д.) и отправить внутреннее событие приложения от сервера к серверу.

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

• С мобильного устройства путем вызова API SDK AppsFlyer:
  Android iOSUnity

  getAppsFlyerId

  getAppsFlyerId

  getAppsFlyerId

• От платформы AppsFlyer с использованием одного из следующих способов: Pull API, Push API, Экспорт отчета по сырым данным об установках  

Когда межсерверные события массово поступают в AppsFlyer, они маркируются по времени в соответствии со значениями их свойства eventTime и временем прибытия. Свойство eventTime обозначает время совершения события в приложении.

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

• Если параметр eventTime не включен в запись события, время события устанавливается как время прибытия HTTP-сообщения.
• События, поступающие до 02:00 UTC, отмечаются значением eventTime. Это значит, что для того чтобы события были отмечены eventTime, отчет о них должен быть передан либо в день возникновения события или на следующий день до 02:00 UTC.
• События предыдущего дня или ранее, отчет о которых был передан после 02:00 UTC, отмечаются временем прибытия (время вызова API).
• События, прибывающие с будущим значением eventTime (eventTime > время прибытия):
  • Если сообщенное eventTime и время прибытия приходятся на один и тот же календарный день, событие маркируется по времени значением eventTime.
  • Если переданное значение eventTime приходится на следующий календарный день, то событие отмечается временем прибытия.

Пример

• Событие отправлено с параметром eventTime = понедельник 21:00.

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

Если вы заполняете af_quantity, возможно, вы захотите заполнить его отрицательным значением в зависимости от логики вашей системы. AppsFlyer не использует af_quantity.

• Конечная точка: убедитесь, что используемая конечная точка верна.
• Убедитесь, что полезные данные содержат обязательные параметры. См. здесь.
• Убедитесь, что AppsFlyer ID, используемый для запуска события, является действительным идентификатором appsflyer_id, который установлен в конкретном приложении. Что это не тестовый идентификатор, представленный в документации. См. здесь.
• Для S2S-событий групповая отправка событий в одном запросе S2S не поддерживается. Каждое событие необходимо отправлять отдельно.
  • События могут быть отправлены асинхронным методом для уменьшения времени отклика.
• На обзорном дэшборде диапазон дат относится к дате установки приложения (LTV), а не к дате события.
  • Убедитесь, что вы ввели правильный диапазон дат.
  • Убедитесь, что диапазон дат на дэшборде соответствует дате установки устройства (appsflyer_id), а не дате события.
• Отчет по сырым данным о событиях: диапазон дат относится к дате события, а не дате установки. 

Если после отправки S2S-событий окажется, что данные о доходе не записаны, убедитесь, что отправленные данные в формате JSON преобразованы в строки. Самое важное — это значение параметра события в формате JSON. Он должен быть преобразован в строку, как показано на следующем примере.

"{\"af_revenue\":\"6\" ,\"af_content_type\":\"wallets\"}"

Если значение события не преобразовано в строку, оно обрабатывается неправильно и величина дохода не записывается.

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

• Пример допустимых значений: 123 , -123.45 , 123.456 
• Примеры недопустимых значений: 1,234.56, 1,234

Поля сырых данных заполняются с использованием значения, отправленного в вызове S2S, а некоторые поля заполняются с помощью события установки.  Аналогичное поведение, но не идентичное, наблюдается для событий в приложении, сообщаемых с помощью AppsFlyer SDK. Существуют некоторые различия, в частности, следующие поля не заполняются для событий S2S:

• wifi
• operator
• language
• Модель устройства
• Категория устройства
• Версия приложения: используйте app_version_name.
• Имя приложения
• Агент пользователя