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

Cuando AppsFlyer procesa eventos S2S dentro de la app, 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 dentro de la app.

Esto significa que algunos datos que AppsFlyer asocia con eventos S2S no orgánicos dentro de la app, no se asocian con eventos S2S orgánicos dentro de la misma.

Es necesario desarrollar lógica de backend para obtener los valores y completar los parámetros. A continuación se muestra cómo obtener el ID de AppsFlyer:

• El ID de AppsFlyer es esencial y se utiliza para atribuir eventos.
• Se genera cuando un usuario instala la aplicación móvil por primera vez.
• Para poder relacionar su CUID con el ID de AppsFlyer, debe configurar el CUID en la aplicación. 

Para facilitar la identificación del usuario que realizó cada evento, implemente el siguiente proceso:

• Configure el ID de usuario del cliente cuando el usuario instale la aplicación.
• Los informes de datos brutos de AppsFlyer incluyen el CUID y el ID de AppsFlyer. Utilice una de las herramientas de entrega de datos o la API Push de AppsFlyer para obtener esto. 
• Use los informes de datos brutos para hacer coincidir el CUID con el ID de AppsFlyer. 
• El ID de AppsFlyer está disponible en el SDK integrado en su aplicación (Android/iOS).
• Relacione el ID de AppsFlyer con el ID de usuario del cliente en sus sistemas internos (importante para uso futuro).

Una vez que asigne el ID de AppsFlyer a su CUID, podrá relacionar al usuario con los eventos realizados. Después, puede obtener otros valores (valor del evento, moneda del evento, hora del evento, etc.) y enviarlos de servidor a servidor en la aplicación.

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

• Desde el dispositivo móvil llamando a la API del SDK de AppsFlyer:
  Android nativoiOS nativoUnityReact Native

  obtenerUIDdeAppsFlyer

  obtenerUIDdeAppsFlyer

  obtenerIDdeAppsFlyer

  obtenerUIDdeAppsFlyer

• Desde la plataforma de AppsFlyer usando uno de los siguientes: API de extracción, API Push, exportación de instalación de datos brutos.

Diagrama lógico de timestamping altalt

Cuando los eventos S2S llegan en gran cantidad a AppsFlyer, se les asigna una marca de tiempo según los valores de su propiedad eventTime y la hora de llegada. La propiedad eventTime indica el momento en el que ocurre el evento dentro de la aplicación.

Al llegar, los eventos se marcan con el siguiente criterio de tiempo:

• Si el parámetro eventTime no está incluido en el registro del evento, la hora del evento se establece a la hora de llegada del mensaje HTTP.
• Los eventos que llegan antes de las 02:00 UTC se marcan con el valor de eventTime. Es decir, para que los eventos se marquen con eventTime, deben reportarse el mismo día del evento o al día siguiente antes de las 02:00 UTC.
• Los eventos que ocurrieron el día anterior o antes, y llegan después de las 02:00 UTC, se registran 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 están en el mismo día del calendario, el evento se marca con el valor eventTime.
  • Si el eventTime reportado es para el día siguiente en el calendario, el evento se marca con la hora de llegada.
• Los eventos con un valor eventTime no válido se registran con la hora de llegada del mensaje HTTP.

Ejemplo

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

Se pueden enviar eventos con un valor de ingresos negativo. Por ejemplo, si se cancela una compra. El parámetro af_revenue puede adoptar valores negativos para registrar este tipo de situaciones. 

Si decide rellenar af_quantity, tal vez desee hacerlo con un valor negativo, según la lógica de su sistema. AppsFlyer no utiliza af_quantity.

• Punto final: Asegúrate de que el punto final usado sea correcto.
• Verifica que la carga útil incluya los parámetros obligatorios. Consulta aquí.
• Asegúrate de que el ID de AppsFlyer que usas para disparar el evento sea un appsflyer_id real y esté vinculado a una instalación de aplicación válida. Consulta aquí.
• Los eventos S2S no permiten múltiples eventos en una sola solicitud S2S. Cada evento debe enviarse por separado.
  • Los eventos pueden enviarse de manera asincrónica para facilitar el tiempo de respuesta.
• En el panel de resumen, el rango 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 rango de fechas adecuado.
  • Asegúrate de que el rango de fechas del panel se corresponda con la fecha de instalación del dispositivo (appsflyer_id) y no con la fecha del evento.
• En los informes de datos brutos de eventos, el rango de fechas se refiere a la fecha del evento y no a la de instalación. 

Si envías eventos S2S y sus ingresos no se registran, asegúrate de que el JSON enviado esté convertido en cadena. La parte más importante es el parámetro de valor del evento en el JSON. Debe estar convertido en cadena como se muestra en el siguiente ejemplo.

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

Si no está codificado como cadena, el valor del evento no se procesa correctamente y los ingresos no se registran.

Los valores de ingresos no deben tener ningún formato. Pueden incluir un punto decimal. No incluya signos o códigos de moneda ni delimitadores ,. Los ingresos pueden estar precedidos por un -.

• Algunos ejemplos de valores válidos son: 123, -123.45, 123.456. 
• Ejemplos de valores no permitidos: 1,234.56, 1,234.

Los campos de datos sin procesar se llenan exclusivamente con los valores enviados en la llamada S2S (a diferencia de los campos de postback, que pueden llenarse con valores derivados del evento de instalación).

Los siguientes campos no pueden informarse a través de la API S2S y, por lo tanto, no se completan para eventos S2S en los informes de datos sin procesar:

• Wi-Fi
• Operador
• Idioma
• Modelo del dispositivo
• Categoría del dispositivo
• Versión de la aplicación: Puedes utilizar app_version_name.
• Nombre de la aplicación
• Agente de usuario

Los eventos S2S, como los de inicio de sesión, pueden llegar a AppsFlyer en cuanto se instala la aplicación y se activa el SDK. Sin embargo, si los eventos S2S dentro de la aplicación llegan antes de que AppsFlyer termine de procesar el evento de instalación, lo cual generalmente tarda entre 20 y 30 segundos o más, pueden ser marcados como eventos orgánicos no atribuidos.

Recomendamos introducir un breve retraso antes de enviar los eventos S2S dentro de la aplicación que ocurren inmediatamente después de la instalación a nuestros servidores.