Eventos in-app: descripción general

Siempre que envíes eventos dentro de la aplicación, como una compra o un vuelo reserva, Lo envías con sus ingresos asociados. El único parámetro que genera ingresos en eventos in-app es af_revenue

• Registro de ingresos en el SDK
• Registro de ingresos en Unity

También puede registrar ingresos negativos en caso de que un usuario cancele una compra o si se emite un reembolso. Para registrar ingresos negativos, todo lo que necesitas hacer es añadir el signo menos (-) al valor de ingreso que tú af_revenue

af_revenue es el único parámetro que acumula los ingresos de tus usuarios. Úsalo siempre con eventos in-app que representen generación de ingresos reales en tu lógica de negocio.

af_revenue también puede tener valores de ingresos negativos si necesitas registrar eventos como transacciones canceladas o reembolsos.

El valor de ingresos debe contener solo números (y un punto decimal si es necesario):

• No incluyas ningún otro carácter o formato al valor de ingresos de ninguna otra manera. Esto significa sin comas, signos de moneda (por ejemplo, $), caracteres especiales o texto.
• AppsFlyer proporciona el valor de ingresos con precisión de hasta cinco decimales.
• El intervalo de este valor debe ser de -1.000.000 a 1.000.000 en dólares o en su equivalente en la moneda original. Los valores fuera de este rango se incluyen en los informes de datos brutos, pero no en los informes agregados.
• Ejemplo: 1234,56
• Cuando los ingresos se envían como una cadena, el valor dentro de las comillas debe ser válido. Por ejemplo: "1234,56".

Nota:

• AppsFlyer muestra los ingresos exactos tal como se envían desde el SDK. No se incluye ningún cálculo de IVA ni comisiones de la tienda de aplicaciones, etc., a menos que estos hayan sido añadidos por el desarrollador en el módulo SDK antes de enviarlo a AppsFlyer.

af_currency representa la moneda que se indica en af_revenue (o af_price). Si af_currency falta en los parámetros del evento, AppsFlyer lo envía con el valor predeterminado "USD".

Puede usar af_price como un parámetro monetario que no se cuenta como ingreso (como en un evento "Agregar al carrito"). Este parámetro se refiere al precio de un artículo individual. La cantidad total de todas las compras aparece bajo el parámetro af_revenue.

Los anunciantes usan los ingresos proyectados para optimizar sus campañas tempranamente en el ciclo de vida del usuario al predecir el valor potencial del usuario. Los ingresos proyectados se calculan con base en las interacciones y comportamientos previos del usuario. Nota: Contacte al soporte de AppsFlyer para saber si su red publicitaria admite los ingresos proyectados.

¿Cómo deberían reportarse los ingresos proyectados a AppsFlyer?

Al reportar los ingresos proyectados a AppsFlyer, se deben enviar en eventos separados de aquellos que contienen ingresos reales. Los anunciantes deben asegurarse de que:

• Eventos con ingresos reales y eventos con ingresos proyectados se traten y se reporten como eventos distintos.
• Los datos de ingresos proyectados se incluyen en el valor del evento, por ejemplo:

      "event_value": {
          "af_projected_revenue": 0.79
      }

Ingresos proyectados en el panel de AppsFlyer y en los informes

• Los ingresos proyectados no están incluidos en los cálculos de ingresos totales o métricas mostrados en el panel de AppsFlyer. Esto asegura que el panel solo refleje los ingresos reales obtenidos.
• En los datos en bruto, no se informan los ingresos proyectados en un campo específico campo, pero está disponible dentro del valor del evento valor que contiene el importe de ingresos enviado por el anunciante.

Enviar postbacks de ingresos proyectados

Para saber cómo enviar postbacks de ingresos proyectados a redes publicitarias, consulta Compartir ingresos de proyecto.

Es importante entender cómo AppsFlyer maneja la configuración de moneda y la conversión de monedas.

AppsFlyer gestiona la diferencia entre la moneda configurada en la aplicación y y la moneda de los eventos in-app utilizando la conversión de moneda.

El diagrama anterior explica el siguiente proceso:

1. Se envían eventos dentro de la aplicación: moneda diferente para cada evento
2. AppsFlyer normaliza todas las monedas a USD
3. AppsFlyer procesa los datos de ingresos
4. Los datos de ingresos en el panel se muestran según la configuración de la aplicación signos de moneda
5. AppsFlyer completa los datos de ingresos en los informes de datos en bruto en ambas moneda de evento y configuración de la aplicación.

AppsFlyer utiliza Open Exchange Rates para la conversión de moneda. El tipo de cambio se actualiza cada hora base. Cada vez que AppsFlyer realiza una conversión de moneda, utiliza el tipo de cambio de la última actualización horaria.

Conversión de moneda

Map<String, Object> eventValue = new HashMap<String, Object>();
eventValue.put(AFInAppEventParameterName.REVENUE,200);
eventValue.put(AFInAppEventParameterName.CONTENT_TYPE,"category_a");
eventValue.put(AFInAppEventParameterName.CONTENT_ID,"1234567");
eventValue.put(AFInAppEventParameterName.CURRENCY,"EUR");
AppsFlyerLib.getInstance().trackEvent(getApplicationContext() , AFInAppEventType.PURCHASE , eventValue);

Visualización de la moneda

La moneda se establece en la configuración de la aplicación. La moneda que establezcas en la configuración de la aplicación será la moneda que que aparecerá en el panel. No importa qué moneda envíes a través de la aplicación. eventos, los ingresos en el panel siempre aparecen en la moneda que configures en los ajustes de la aplicación.

Una vez que determines los eventos in-app que deseas medir, utiliza nuestro generador de eventos in-app para definir los eventos y parámetros de la siguiente manera:

1. Selecciona el nombre de evento que mejor se adapte al escenario que quieres registrar.
2. Seleccione los parámetros que desea asociar con el evento. Elija parámetros que proporcionen contexto adicional al evento y enriquezcan los datos.
3. Descargue el archivo finalizado desde el generador de eventos de la aplicación y compártalo con su desarrollador.

La siguiente tabla proporciona enlaces a artículos con ejemplos y flujos de eventos típicos que recomendamos registrar por vertical.

Sector empresarial	Título del artículo
	Eventos recomendados para aplicaciones de juegos
	Eventos recomendados para apps de comercio electrónico
	Eventos recomendados para apps de entretenimiento
	Eventos recomendados para apps de banca y finanzas
	Eventos recomendados para aplicaciones de préstamos P2P
	Eventos recomendados para apps de educación online
	Eventos recomendados para apps de transporte compartido
	Eventos recomendados de la aplicación de reserva de vuelos
	Eventos recomendados para apps de reserva de hoteles
	Eventos recomendados para apps de salud
	Eventos recomendados para apps de telecomunicaciones
	Eventos recomendados para aplicaciones eWallet
	Eventos recomendados para apuestas deportivas

Los eventos in-app se atribuyen a la fuente de medios que ha hecho posible la instalación durante toda la vida del usuario. Los datos de los eventos se presentan como Valor de Vida o datos de Actividad. 

Puede consultar sus datos de eventos in-app en los siguientes lugares:

• Página de visión general del panel de control : Muestra el rendimiento en tiempo real de la adquisición de usuarios (UA) en base al Valor de Vida (LTV). Nota: Esto incluye ingresos divididos entre usuarios orgánicos y no orgánicos reportados a través de eventos in-app, y los ingresos por reorientación que son doblemente atribuidos.
• Página de eventos: Muestra el rendimiento de eventos in-app LTV en todas las fuentes de medios
• Página de actividad: Muestra las actividades in-app para el rango de fechas seleccionado.

• Informe de eventos in-app con datos en bruto: Muestra datos de actividad, es decir, una lista cronológica de las acciones realizadas por toda tu base de usuarios. Este informe incluye valores de parámetros de eventos, por ejemplo:

  {
    "af_level":"10",
    "af_score":"3387",
    "arena":"7",
    "char_type":"paladin"
  }

  Ten en cuenta que el informe de datos en bruto es una función premium.

Ten en cuenta lo siguiente al definir nombres de eventos y parámetros en la app:

• Para mantener la coherencia de datos en los informes de datos en bruto, recomendamos definir y utilizar los mismos nombres y estructuras de eventos in-app en todas las plataformas.
• Usa un número mínimo de eventos para facilitar la comparación de la calidad de usuarios provenientes de diferentes fuentes.
• Es crucial que garantices la privacidad de tus usuarios. Evita completar los valores de eventos in-app con datos restringidos que puedan identificarlos directamente. Por ejemplo, dirección de correo electrónico, nombre, número de identificación y, en algunos lugares, código postal. Para obtener más información sobre los datos restringidos, consulta la política de privacidad de los servicios.
• Ten en cuenta que AppsFlyer incluye la dirección IP de los dispositivos durante las interacciones. En algunas jurisdicciones o escenarios de uso, la dirección IP puede considerarse información de identificación personal. Usamos la dirección IP para determinar la ubicación geográfica general (ciudad, distrito) del dispositivo, pero no la dirección específica. Si es necesario, puedes optar por enmascarar las direcciones IP para que no aparezcan en los informes de datos en bruto. 
• Los eventos in-app son la única fuente de datos de ingresos en AppsFlyer. Puedes asignar un valor específico de ingresos a cada evento y visualizarlo en el panel de tu aplicación. Obtén más información sobre los parámetros de monetización. altrevenue_data.pngalt

Ten en cuenta lo siguiente al definir nombres de eventos y parámetros en la app:

• Recomendamos usar solo caracteres alfanuméricos en minúscula (a-z y 0-9) para los nombres de eventos in-app. Los nombres de los eventos distinguen entre mayúsculas y minúsculas, lo que significa que af_purchase y af_PURCHASE son dos eventos diferentes en los datos sin procesar. Sin embargo, en informes agregados (como Descripción general o Eventos) se pueden mostrar como un único evento.
• Existe un límite de cardinalidad de 300 eventos únicos por día. Más información
• Los usuarios únicos solo se cuentan para los primeros 100 eventos después de instalar la aplicación.
• Los nombres de eventos no pueden comenzar con estos caracteres: " = + -
• Los valores de evento no deben contener el carácter +, salvo en URLs codificadas o según ASCII.
• Los nombres de eventos no pueden contener espacios vacíos. Puede utilizar guiones bajos antes o después del nombre del evento.
• Los valores de los eventos no deben exceder los 2000 caracteres para evitar que se acorten en los informes de datos sin procesar. Sin embargo, si el evento se origina en el SDK, se recomienda mantenerlo por debajo de los 1000 caracteres para asegurarse de que la carga útil no se trunque al enviarse en la solicitud HTTP.
• Si incluye la URL de referencia como valor de evento, debe estar codificada como URL.
• Los anuncios de Meta tienen algunas limitaciones con respecto a los nombres y parámetros de los eventos. Lea sobre las limitaciones aquí.

Puede enviar valores de ingresos con cualquier nombre de parámetro y evento. Sin embargo, para registrar los ingresos (incluidos los ingresos negativos) en los datos brutos y agregados de AppsFlyer, DEBE utilizar el parámetro af_revenue . Úselo siempre con eventos in-app que representen la generación de ingresos reales en su lógica comercial.

af_currency representa la moneda que se indica en af_revenue (o af_price). Si falta af_currency en los parámetros del evento, AppsFlyer lo envía con el valor predeterminado "USD".

Para más información sobre el parámetro af_revenue , consulte la guía de atribución de ingresos.

Los eventos in-app se atribuyen a la fuente original de medios de la instalación de la app.

Al instalar una app (primer lanzamiento de la aplicación), AppsFlyer utiliza varios métodos de atribución para determinar la atribución de la instalación. Al mismo tiempo, el SDK de AppsFlyer genera un nuevo ID de AppsFlyer único, que se asocia con los detalles de atribución.

Cada evento posterior dentro de la aplicación realizado por el mismo dispositivo utiliza este ID. Esto permite a AppsFlyer atribuir el evento a la fuente original. Los anunciantes pueden usar esto para seguir la trayectoria completa del usuario en su aplicación.

Los eventos de usuarios recientemente reorientados pueden tener doble atribución.

AppsFlyer considera los eventos de instalaciones atribuidas como orgánicos cuando:

• Han transcurrido más de 24 meses desde la fecha de instalación.
• Los términos de la fuente mediática exigen la eliminación de los datos a nivel de usuario.
• El usuario borra los datos de la aplicación almacenados en el dispositivo, obligando a crear un nuevo ID de AppsFlyer.

Si un usuario inicia un evento sin conexión a internet, AppsFlyer aún puede registrarlo. Este es el procedimiento:

1. El SDK envía los eventos a los servidores de AppsFlyer y espera una respuesta exitosa.
2. Si el SDK no recibe una respuesta exitosa, el evento se guarda en caché.
3. Una vez que se recibe la siguiente respuesta exitosa, el evento almacenado se envía nuevamente al servidor.
4. Si hay múltiples eventos en la caché, se envían al servidor uno tras otro.

Los eventos complejos dentro de la aplicación permiten enviar múltiples eventos en una sola llamada API.

Son útiles cuando se desea ver varias acciones de usuario estrechamente relacionadas agrupadas (por ejemplo, añadir varios productos a la cesta en una sola sesión).
Ejemplo:

{
  "af_revenue":"50.87",
  "af_currency":"USD",
  "af_receipt_id":"57601333",
  "product":[ 
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1164_8186",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"1177_8185",
	 "af_price":"8.97",
	 "af_quantity":"1"
   },
   { 
	 "af_content_id":"0153_9077",
	 "af_price":"14.99",
	 "af_quantity":"1"
   }
  ]
}

Sí, puede agregar varios artículos a una sola transacción. En lugar de valores únicos por parámetro de evento, puede tener un conjunto de elementos que describa la transacción, separados por comas. El formato debe ser una cadena JSON.

"{\"af_content_id\": [\"123\",\"988\",\"399\"], \"af_quantity\": [\"2\",\"1\",\"1\"], \"af_price\": [\"25\",\"50\",\"10\"], \"af_revenue\": \"110\", \"af_currency\": \"USD\"}"

Contamos con un mecanismo de deduplicación de eventos in-app. Revisa todos los eventos in-app para ver si hubo algún evento in-app idéntico que provino del mismo appsflyer_id hace menos de 10 segundos. Si se encuentra un evento así, el mecanismo elimina el duplicado.

Dos eventos se consideran idénticos si los siguientes campos en ambos eventos son los mismos:

• Nombre del evento
• Valor del evento
• Identificación de la aplicación
• Identificación de AppsFlyer

AppsFlyer conserva los datos de usuario (sin procesar) durante 24 meses, excepto cuando la ley indique, requiera o permita lo contrario. Algunas SRN/socios requieren que los proveedores de atribución, incluido AppsFlyer, eliminen los datos a nivel de usuario relacionados con las SRN/socios antes de que expire el período de 24 meses.

Después de la eliminación, los eventos relacionados con los usuarios eliminados se muestran como orgánicos. Los datos agregados pasados no se modifican. Para obtener más información, consulte Obligaciones de retención y eliminación de datos.

• El SDK de Android y el SDK de iOS agregan automáticamente el parámetro OS (sistema operativo).
• Para la API S2S, a partir del 1 de julio de 2021, deberá enviar el parámetro OS (sistema operativo) para las aplicaciones iOS. Si no envía este parámetro, se considerará que los datos provienen de un usuario de iOS 14.5 y esto afecta la forma en que se ponen a disposición los datos sin procesar.