Eventos in-app

Los eventos in-app brindan información sobre cómo los usuarios interactúan con tu aplicación. Los SDK de AppsFlyer te permiten registrar fácilmente estas interacciones.

Guías de SDK de eventos in-app

Anatomía de un evento

Los eventos in-app constan de 2 partes:

• Nombre del evento: El identificador único del evento. Por lo general, es como los marketers ven el evento en el panel de control.
• Valores de eventos: Un objeto que consiste en pares clave-valor llamados parámetros de eventos. Los parámetros del evento te proporcionan más contexto e información sobre el evento que está ocurriendo.

Los nombres de eventos y los parámetros de eventos pueden ser predefinidos o personalizados.

👍

Consejo

Define y genera rápidamente un código de eventos in-app para las principales plataformas utilizando nuestra herramienta generadora de eventos in-app.

Constantes de eventos

En los SDK, los eventos y parámetros predefinidos se exponen como constantes.

Al enviar eventos, se recomienda utilizar las constantes en lugar de cadenas sin formato:

• Reduce la posibilidad de ingresar discrepancias en los nombres.
• Los cambios en los nombres de parámetros/eventos subyacentes son transparentes para ti y requieren menos mantenimiento.

Técnicamente, los nombres/parámetros de eventos predefinidos son cadenas con el prefijo af_.

Eventos personalizados y parámetros de eventos

Los nombres y parámetros de eventos personalizados están definidos por el usuario y suelen describir escenarios específicos de la lógica de negocio de tu aplicación y la interacción de tus usuarios con la aplicación.

🚧

Atención

Para evitar confusiones con los eventos predefinidos, no antepongas nombres de eventos personalizados con af_.

Valid custom event names

Los nombres de eventos personalizados deben seguir estas reglas:

• Tener hasta 100 caracteres.
• Se admiten caracteres no ingleses.

Valid custom event parameters

Parámetros de eventos personalizados:

• No debe exceder los 1000 caracteres; si es más largo, es probable que lo trunquemos.
• Precios e ingresos: usa solo dígitos y decimales, p. ej. 5 o 5.2.
• Los valores de precios e ingresos pueden tener hasta 5 dígitos después del punto, p. ej., 5.12345.

Comprender las definiciones de la estructura de eventos

Idealmente, el marketer debería proporcionarte definiciones claras de la estructura de eventos, basadas en las instrucciones de Definición de eventos in-app. Por ejemplo, una definición de un evento af_content_view para una aplicación de comercio electrónico se vería así:

• La primera columna (Nombre del evento) es el valor que pasas como segundo argumento de logEvent.

  af_content_view es como los marketers ven el evento en el panel de control. Se recomienda utilizar las constantes de eventos predefinidas en lugar de los valores de cadena sin formato que proporcionan los marketers.

• La segunda columna (Parámetros del evento) enumera los parámetros del evento asociados con el evento. En este caso, debes pasar los siguientes parámetros de evento a logEvent:

  • af_price
  • af_content_type
  • af_content_id

• La tercera columna (Valores de parámetro) contiene información adicional sobre valores concretos asignados a los parámetros de evento. En el ejemplo anterior, el marketer claramente comunica que el valor del parámetro del evento af_content_id debe ser el SKU del elemento visualizado.

• La cuarta columna es donde el marketer describe dónde y cuándo en la aplicación debe ocurrir el evento.

Consulta cómo se implementa la definición anterior de ejemplo en Android y iOS.

Eventos in-app sin conexión

El SDK puede almacenar en caché los eventos in-app que ocurren cuando no hay conexión a Internet disponible:

• El SDK envía los eventos a los servidores de AppsFlyer y espera una respuesta.
• Si el SDK no recibe una respuesta 200, el evento se almacena en el caché.
• Una vez recibida la respuesta 200, los eventos almacenados se vuelve a enviar al servidor.
• Si hay varios eventos en el caché, se envían al servidor uno tras otro (sin lotes, una solicitud de red por evento).

El SDK puede almacenar en el caché hasta 40 eventos. Solo se guardan los primeros 40 eventos sin conexión. Todo lo que suceda después se descartará, hasta la próxima respuesta satisfactoria.