API de eventos de servidor a servidor

La API de eventos de servidor a servidor permite enviar eventos que no se envían mediante el SDK de AppsFlyer. Por ejemplo, si tienes una interfaz web y una interfaz móvil, puedes registrar eventos de ambos medios en AppsFlyer utilizando la API de eventos de servidor a servidor. 

Los eventos de servidor a servidor deben prepararse de la siguiente manera:

  • Tipo de contenido: establecido como aplicación/json.
  • URL del punto de conexión:
    https://api2.appsflyer.com/inappevent/{app_id}
    • Ejemplo en Android:
      https://api2.appsflyer.com/inappevent/com.appsflyer.myapp
    • Ejemplo en iOS:
      https://api2.appsflyer.com/inappevent/id123456789
      Nota: El ID de la aplicación es el ID de iTunes de la aplicación. Asegúrate de que el ID de la aplicación en iOS contenga un ID principal antes del ID. De lo contrario, se obtiene un código de retorno válido de 200 OK, pero el evento no se registra.
    • Ejemplo en Windows:
      https://api2.appsflyer.com/inappevent/a1b2c3d4e5f6
      Nota: El ID de la aplicación es el ID de la aplicación en la tienda de aplicaciones de Microsoft.
  • Tamaño máximo de la carga útil JSON: 1K 
  • La carga de datos del JSON se debe pasar como secuencia y al valor del evento se le debe dar formato de secuencia.
  • La carga útil JSON debe incluir el parámetro: "af_events_api" :"true"
    Este parámetro garantiza que el evento se estructure como evento enriquecido para permitir la asignación automática de los valores de eventos a varios partners.

Consulte los ejemplos a continuación.

Método: POST

Encabezado - "authentication"= {dev-key}

La clave de desarrollador se encuentra en Panel de control > Configuración de la aplicación > Clave de desarrollador

iOSAndroid y Windows
{
  "appsflyer_id": {AppsFlyer Device ID }, // e.g. 1415211453000-6513894
  "idfa":{idfa},
  "customer_user_id": {customer_user_id}, // Customer User ID optional parameter
  "eventName": {The event name}, // e.g. "af_purchase"
  "eventValue": {A JSON containing a rich in-app event value - must be stringfied},
  "{

    \"af_revenue\":\"6\",
    \"af_content_type\":\"wallets\",
    \"af_content_id\":\"15854\"

  }",
  "eventCurrency": {Event currency}, // e.g "USD"
  "ip": {device IP},
  "eventTime": {Event timestamp in UTC +0}, // e.g "2014-05-15 12:17:00.000"
  "af_events_api" :"true"
}

 Nota

Todos los caracteres reservados (https://tools.ietf.org/html/rfc3986#section-2.1) deben codificarse como porcentaje antes de formar la URI.

Parámetros

Nombre de parámetro Tipo Descripción
appsflyer_id Obligatorio Atribuye el evento a una fuente de medios y campaña.
eventName Obligatorio Especifica el nombre del evento.
valor del evento Recomendado Excepción: el parámetro es obligatorio para calcular los ingresos.
af_events_api Obligatorio El valor debe ser verdadero.
idfa Recomendado Excepción: el parámetro es obligatorio para enviar postbacks de eventos in-app a partners externos.

advertising_id

Recomendado

Excepción: el parámetro es obligatorio para enviar postbacks de eventos in-app a partners externos.

ip Recomendado
  • La dirección IP (ip) es la IP del dispositivo móvil (durante la ocurrencia de un evento).
  • La dirección IP determina el país del evento. Si no se especifica una dirección IP, el campo del país muestra N/A en el raw data.
customer_user_id OPCIONAL El ID de usuario de cliente se usa para asociar eventos in-app con usuarios en sistemas de Business Intelligence.

 

Preparación de datos para parámetros

La lógica de backend es necesaria para obtener ciertos valores para los parámetros mencionados anteriormente. A continuación encontrará el flujo recomendado para la obtención de estos valores:

Asignación de ID de AppsFlyer con ID de usuario de cliente

El ID de AppsFlyer es un parámetro obligatorio para el envío de eventos in-app de servidor a servidor. Para que le sea más fácil saber qué usuario ejecutó qué evento, implemente el siguiente flujo:

  1. Configure el ID de usuario de cliente cuando el usuario instala la aplicación.
  2. Descargue el reporte de raw data para instalaciones a través de datos de exportación o pull API.
  3. Para obtener el ID de AppsFlyer, haz coincidir el ID de usuario de cliente que figura en tus sistemas internos con el ID de usuario de cliente que figura en el reporte de raw data.
    Nota: puedes obtener el ID de AppsFlyer de tus usuarios a partir del SDK integrado de AppsFlyer en tus aplicaciones (Android/iOS).
  4. Asigne el ID de AppsFlyer al ID de usuario de cliente de su sistema interno (importante para uso futuro).

Una vez que asocie el ID de AppsFlyer al ID de usuario de cliente interno, podrá saber fácilmente qué usuario ejecutó qué evento. Así, podrá obtener el ID de AppsFlyer y otros valores (valor del evento, moneda del evento, hora del evento, etc.) y enviar el evento in-app de servidor a servidor.

Programación Temporal de los Eventos

Los eventos de servidor a servidor se pueden enviar en tiempo real o con una marca temporal del evento.

También puedes usar el parámetro opcional eventTime para especificar la hora a la que ocurre el evento (en zona horaria UTC +0). Si el parámetro no se incluye en el mensaje, AppsFlyer usará la marca temporal del mensaje HTTPS recibido. 

El formato de eventTime es: "yyyy-MM-dd HH:mm:ss.SSS" (p. ej. "2014-05-15 12:17:00.000")

Al enviar eventos con marcas temporales, para que estos eventos se registren con sus marcas de tiempo real (cuando realmente sucedieron), todas se deben enviar a AppsFlyer antes de las 02:00 AM (UTC+0) del día siguiente.

Los eventos con marcas temporales pasadas, que no se envían antes de las 2:00 AM se registran bajo la hora a la que se envían.

Evento con marca temporal enviada antes de las 2 AM UTC+0

Activación de evento: 2 de mayo @ 22:00

Evento enviado a los servidores de AppsFlyer: 3 de mayo @ 01:00

El evento se atribuye en la plataforma en la hora real en que ocurrió el evento (2 de mayo a las 22:00).

Evento con marca temporal enviada después de las 2 AM UTC+0

Activación de evento: 2 de mayo @ 22:00

Evento enviado a los servidores de AppsFlyer: 4 de mayo @ 09:00

El evento se atribuye en la plataforma en la hora que se envía al servidor de AppsFlyer y no en la hora que ocurrió el evento (4 de mayo a las 09:00).

Evento con marcas temporales futuras

Los eventos enviados con marcas temporales futuras siempre se registran en AppsFlyer con la hora a la que se enviaron a AppsFlyer, y no a la hora de la marca temporal del evento incluida en la carga útil.

Sincronización de eventos: línea de tiempo visual

Server-to-Server-Events.PNG

 Nota

El número máximo de solicitudes S2S es de 60K por minuto o 1K por segundo. Contacta a tu Gerente de Atención al Cliente si tienes requisitos diferentes.

Códigos de Respuesta del Servicio

200
Aceptar cuando el sistema de AppsFlyer haya procesado la solicitud.
401
No autorizado: cuando la clave incluida en el encabezado de autenticación no es la dev-key de esta aplicación.
400
Solicitud errónea: cuando la solicitud no cumplió por lo menos uno de los criterios de validación.
500
Error interno del servidor: esto indica un error en el servidor.

Si tus servidores están protegidos por un firewall, deberás agregar a la lista blanca las respuestas de los intervalos de direcciones IP de AWS para recibir los mensajes de respuesta.

Ejemplo de Mensaje de Solicitud

{
  "appsflyer_id": "1415211453000-6513894",
	"advertising_id": "38412345-8cf0-aa78-b23e-10b96e40000d",
	"eventName": "af_purchase",
	"eventValue": 
	"{
		\"af_revenue\": \"6\",
		\"af_content_type\": \"wallets\",
		\"af_content_id\": \"15854\",
		\"af_quantity\" :\"1\"
   }",
	"eventCurrency": "USD",
	"ip": "1.2.3.4",
	"eventTime": "2014-05-15 12:17:00.000",
	"af_events_api" :"true"
}


En este caso, AppsFlyer recibe un evento in-app S2S que representa un evento de compra con ingresos, así como propiedades adicionales tales como tipo de contenido, etc.

Casos especiales

Envío de ingresos negativos

Si desea enviar un evento con ingresos negativos (para eventos tales como una compra cancelada o un reembolso), puede especificar un valor negativo en el parámetro de ingresos. Por ejemplo:

{
  "appsflyer_id": "1415211453000-6513894",
	"advertising_id": "38412345-8cf0-aa78-b23e-10b96e40000d",
	"eventName": "cancel_purchase",
	"eventValue": 
	"{
		\"af_revenue\": \"-6\",
		\"af_content_type\": \"wallets\",
		\"af_content_id\": \"15854\",
		\"af_quantity\" :\"1\"
   }",
	"eventCurrency": "USD",
	"ip": "1.2.3.4",
	"eventTime": "2014-05-15 12:17:00.000",
	"af_events_api" :"true"
}

Envío de eventos sin valor de evento

Si quiere enviar eventos sin valor de evento, simplemente envíe una secuencia vacía al valor del evento: "event_value":""

De esta manera, AppsFlyer puede, según la configuración del anunciante, enviar tales eventos in-app enriquecidos a fuentes de medios con fines avanzados de targeting, optimización y creación de audiencias.

Obtener el ID de Dispositivo de AppsFlyer

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. El ID se puede obtener de la siguiente manera:

 Consejo

Cuando pruebes mensajes S2S, si estás usando raw data o las API Push o Pull, busca el registro con la fuente de medios "s2s_test". Este es tu dispositivo de prueba y su ID de dispositivo de AppsFlyer es el ID que necesitas.

Diferencia entre orgánicos y no orgánicos

Cuando envía eventos in-app S2S, AppsFlyer automáticamente asocia los datos adicionales con los eventos. Los datos adicionales provienen del evento de instalación que precede 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.

 Ejemplo

Por ejemplo, si se comparan los reportes de datos sin procesar de eventos in-app S2S orgánicos y no orgánicos, se observa que los eventos no orgánicos contienen datos que no los orgánicos no.

Los eventos in-app no orgánicos contienen datos sobre la fuente de medios, la campaña, el tipo de toque atribuido y la hora de toque atribuido.

Por otra parte, los eventos in-app orgánicos siguen una instalación orgánica. La instalación orgánica no tiene datos asociados a la campaña, las fuentes de medios o el tipo y la hora de toque atribuido. 

¿Fue útil este artículo?