API de eventos de servidor a servidor para móviles (S2S móvil)

Cuando AppsFlyer procesa los eventos in-app de S2S, los campos de atribución se rellenan usando el ID de AppsFlyer para identificar el evento de instalación asociado que precedió a los eventos in-app.

Esto significa que algunos datos que AppsFlyer asocia con eventos in-app S2S no orgánicos no se asocian con eventos in-app S2S orgánicos.

Se requiere lógica de backend para obtener valores para rellenar el parámetro. A continuación, se describe cómo se puede obtener el ID de AppsFlyer:

• El ID de AppsFlyer es obligatorio y se usa para atribuir eventos.
• Se genera cuando un usuario instala por primera vez la aplicación móvil.
• Para que puedas asignar tu CUID al ID de AppsFlyer, debes configurar el CUID en la aplicación. 

Para que te sea más fácil saber qué usuario ejecutó qué evento, implementa el siguiente flujo:

• Configure el ID de usuario de cliente cuando el usuario instala la aplicación.
• Los reportes de raw data de AppsFlyer contienen el CUID y el ID de AppsFlyer. Usa una de las herramientas de entrega de datos para obtenerlo o la Push API de AppsFlyer. 
• Usa los reportes de raw data para hacer coincidir el CUID con el ID de AppsFlyer. 
• El ID de AppsFlyer está disponible en el SDK integrado en tu aplicación (Android/iOS).
• Asigna el ID de AppsFlyer al ID de usuario de cliente en tus sistemas internos (importante para uso futuro).

Una vez que asignas el ID de AppsFlyer con tu CUID, puedes hacer coincidir al usuario con los eventos realizados. Así, podrás obtener los demás valores (valor del evento, divisa del evento, fecha y hora del evento, etc.) y enviar el evento in-app de servidor a servidor.

appsflyer_id es un parámetro obligatorio en los mensajes de eventos de servidor a servidor. AppsFlyer usa este parámetro para atribuir el evento al dispositivo original y a la fuente de medios atribuida. Puedes obtener el ID usando uno de los siguientes métodos:

• Desde el dispositivo móvil llamando a la API del SDK de AppsFlyer:
  Android nativodeiOS nativo UnityReact Nativo

  getAppsFlyerId

  getAppsFlyerId

  getAppsFlyerId

  getAppsFlyerUID

• Desde la plataforma de AppsFlyer, usando uno de los siguientes: Pull API, Push API, Exportar raw data de instalación.

Cuando los eventos de S2S llegan en masa a AppsFlyer, obtienen una marca de tiempo de acuerdo con sus valores de la propiedad eventTime y la hora de llegada. La propiedad eventTime denota el tiempo de ocurrencia del evento in-app.

A la llegada, los eventos tienen la siguiente fecha y hora:

• Si el parámetro eventTime no está incluido en el registro de eventos, la hora del evento se establece en la hora de llegada del mensaje HTTP.
• Los eventos que llegan antes de las 02:00 UTC se marcan con el valor eventTime. Es decir, para que los eventos se marquen con el eventTime, deben ser reportados ya sea el día del evento, o al día siguiente hasta las 02:00 UTC.
• Los eventos que tuvieron lugar el día anterior o antes, que llegan después de las 02:00 UTC, se marcan con la hora de llegada (la hora de la llamada API).
• Eventos que llegan con un valor eventTime futuro (eventTime > hora de llegada):
  • Si el eventTime reportado y la hora de llegada son ambos en el mismo día calendario, el evento se marca con el valor eventTime.
  • Si el eventTime reportado está en el siguiente día calendario, el evento se marca con la hora de llegada.
• Los eventos con un valor eventTime no válido se marcan con la hora de llegada del mensaje HTTP.

Ejemplo

• Se envía un evento con eventTime = Monday 21:00.

Se pueden enviar los eventos que tienen un valor de ingresos negativo. Por ejemplo, si una compra se canceló. El parámetro af_revenue puede tener valores negativos para registrar esto. 

Si rellenas af_quantity, es posible que quieras rellenarlo con un valor negativo dependiendo de la lógica de tu sistema. AppsFlyer no hace uso de af_quantity.

• Punto de conexión: verifica que el punto de conexión utilizado sea el correcto.
• Verifica que la carga útil contiene los parámetros obligatorios. Ver aquí.
• Asegúrate de que el ID de AppsFlyer que estás usando para disparar el evento sea un appsflyer_id real que esté realmente instalado en la aplicación específica, y Ver aquí.
• Los eventos S2S no admiten múltiples eventos en una solicitud de S2S. Cada evento debe ser enviado como un evento separado.
  • Los eventos se pueden enviar con un método asíncrono para facilitar el tiempo de respuesta.
• En el panel de control de información general, el intervalo de fechas se refiere a la fecha de instalación de la aplicación (LTV) y no a la fecha del evento.
  • Asegúrate de seleccionar el intervalo de fechas correcto.
  • Asegúrate de que el intervalo de fechas del panel de control corresponda a la fecha de instalación del dispositivo (appsflyer_id) y no a la fecha del evento.
• Reportes de raw data de eventos: el intervalo de fechas se refiere a la fecha del evento y no a la fecha de instalación. 

Si envías eventos de S2S cuyos ingresos no se registran, asegúrate de que el JSON que envíes esté en formato de secuencia. Lo más importante es el parámetro de valor del evento en el JSON. Debe estar en formato de secuencia, como se muestra en el ejemplo que sigue.

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

Si no tiene formato de secuencia, el valor del evento no se procesará correctamente y no se podrán registrar los ingresos.

Los valores de los ingresos no deben ser formateados de ninguna manera. Pueden contener un punto decimal. No incluyas signos o códigos de divisa ni delimitadores ,. Los ingresos pueden tener un prefijo -

• Ejemplos de valores válidos: 123, -123.45, 123.456
• Ejemplos de valores inválidos: 1,234.56, 1,234

Los campos de raw data se rellenan con el valor enviado en la llamada de S2S y algunos campos se rellenan con el evento de instalación.  Se observa un comportamiento similar pero no idéntico para los eventos in-app reportados usando el SDK de AppsFlyer. Hay algunas diferencias; específicamente, los siguientes campos no se rellenan para los eventos de S2S:

• WIFI
• Operator
• language
• Device model
• Categoría de dispositivo
• Versión de la aplicación: Puedes usar app_version_name
• Nombre de aplicación
• Agente de usuario