API межсерверных событий для мобильных устройств (мобильный S2S)

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

S2S_us-en.png

API межсерверных событий для мобильных устройств

Начиная с iOS 14, для приложений iOS требуется отправлять параметр os (операционная система). 

Платформа AppsFlyer атрибутирует и записывает события мобильных приложений, отправленных через SDK AppsFlyer и по API. Используйте API S2S для сообщения о событиях, происходящих вне приложения; например, пользователь продлевает свою подписку, используя ваш веб-интерфейс. После регистрации события S2S доступны на всей платформе, включая дэшборды, сырые данные и аналитику. Для веб-событий PBA см. Web S2S для PBA.

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

  • Значения, отправленные в сообщении S2S
  • Некоторые значения атрибуции установок AppsFlyer, например, время установки и медиа-источник.

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

Заполнение параметров

Разница между органическими и неорганическими событиями

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

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

 Пример

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

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

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

Сопоставление идентификатора AppsFlyer ID с идентификатором клиента (CUID)

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

 Совет

Если при тестировании сообщений S2S вы используете сырые данные, ищите запись с медиа-источником «s2s_test». Это ваше тестовое устройство, а его идентификатор устройства AppsFlyer — это необходимый ID.

Метка времени для межсерверных событий

диаграмма логики метки времени

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

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

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

Пример

  • Событие отправлено с параметром eventTime = понедельник 21:00.
Прибытие в AppsFlyer Метка времени AppsFlyer Пояснение
Вторник 01:00 Понедельник 21:00 Прибыло до закрытия дня. Время устанавливается на значение eventTime.
Среда 09:00 Среда 09: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.45123.456 
  • Примеры недопустимых значений: 1,234.561,234

В событиях S2S заполнены не все поля

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

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