Eventos in-app
Aprende sobre los conceptos básicos y la terminología relacionados con 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í:
Nombre del evento | Parámetros del evento | Valores de parámetro | Dónde/Cuándo (Opcional) |
---|---|---|---|
af_content_view | af_price af_content_type af_content_id | af_price : Precio del artículoaf_content_type : Categoría del artículo.af_content_id : SKU del artículo. | Cuando un usuario navega a una vista del artículo. |
-
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.
Actualizado hace 12 meses