1. AppsFlyer Support
  2. Marketers
  3. Análisis y optimización
  4. Analiza tus datos
  5. API/Reportes de raw data

Información general de los reportes de raw data

Avatar
Gray Goldstein
Última actualización:
  • Marketers
  • Agencias

En resumen: Los datos a nivel de fila (también conocidos como raw data) describen eventos relacionados con los usuarios, como instalaciones, eventos in-app, visitas al sitio web, instalaciones bloqueadas por Protect360, ingresos por publicidad generados y postbacks asociados al usuario enviados a los partners. Los reportes de raw data están disponibles a través de descarga, API y Data Locker.

Reportes de raw data: herramientas y reportes

Lectura relacionada: Analíticas y reportes agregados

Los reportes de raw data te permiten analizar el comportamiento y las trayectorias de los usuarios, conciliar las cuentas de redes de publicidad y enriquecer tus sistemas CRM y de Business Intelligence. Al usar raw data, aumentas tu capacidad de analizar, optimizar y mejorar el rendimiento de las aplicaciones. 

Los reportes están disponibles a través de herramientas de reportes. Las herramientas tienen diferentes características que se adaptan a diferentes casos de uso. Por ejemplo, para conciliar una cuenta de una red de publicidad determinada, descarga el reporte según sea necesario a través de la página Datos exportados. Para que los datos de rendimiento de los usuarios se carguen en tus sistemas de Business Intelligence, obtén los datos programáticamente mediante Data Locker o Pull API.

Herramientas de reportes: características y funciones

Los reportes están disponibles a través de las herramientas de reportes que se enumeran en esta sección.

Consideraciones:

Herramientas de reportes
Herramienta Descripción Aplicaciones múltiples / aplicación única (1) Capacidad de actualización de los datos (2) Incrustar en scripts Zona horaria Moneda
Página de exportación de raw data
  • Descarga del reporte usando la interfaz de usuario
  • Formato: archivo CSV
 Única Actualizado continuamente X

Específico de la aplicación

 Específico de la aplicación
Pull API*
  • Descarga del reporte usando las llamadas de la API.
  • Formato: archivos CSV
 Única Actualizado continuamente ✓
  • Seleccionable
  • Predeterminado: UTC
  • Seleccionable
  • Predeterminado: USD
Data Locker P
  • Transmisión de datos a un bucket en la nube
  • Sin limitaciones de volumen
  • Ventana de disponibilidad de datos: 14 días.
  • Formato: CSV o parquet
 Múltiple Actualizado continuamente con un retraso de varias horas ✓ UTC USD 
Push API P
  • Datos de la trayectoria del usuario (instalaciones, in-app, retargeting, SKAN) enviados a tus servidores en tiempo real.
  • Formato: JSON o parámetros de consulta
 Puede usar el mismo punto de conexión Minutos después de que se atribuya el evento en AppsFlyer ✓ UTC + específica de la aplicación USD + específica de la aplicación
Datos de conversión del SDK (3)
  • Obtener datos de conversión de atribuciones dentro de la aplicación.
  • Formato: JSON
 N/A  Tiempo real <5 segundos  ✓ UTC N/A

Notas y abreviaturas:
(1) Soporte de múltiples aplicaciones
(2) La actualización real de los datos depende del reporte en sí, ya que algunos reportes son diarios.
(3) Los datos de conversión del SDK recuperan los datos de atribución del usuario en menos de 5 segundos desde el primer inicio de la aplicación y, por lo tanto, es el método menos preciso.
(P) Característica premium
 (*) Se aplican cuotas de generación de reportes
Limitaciones de la herramienta
Limitación  Pull API (*) API push Data Locker Datos de conversión del SDK
Límite de datos 1 millón de filas por llamada N/A N/A N/A
Opciones de selección de datos Seleccionar los tipos de datos. Opciones limitadas de selección de campo Seleccionar los tipos de datos, los campos e in-app. Seleccionar los tipos de datos, los campos e in-app. No
Ventana de disponibilidad de datos 90 días N/A 14 días  Vida útil (disponible en el SDK)

(*) Se aplican cuotas de generación de reportes
Consideraciones de integración
Consideración  API pull API push Data Locker Datos de conversión del
SDK
Desarrollo del lado del servidor OPCIONAL OBLIGATORIA OPCIONAL OPCIONAL
Requiere procesamiento de datos OPCIONAL OBLIGATORIA OPCIONAL OPCIONAL
Riesgo de pérdida de datos No Sí, si los servidores de recepción están caídos. No Pequeños, si hay retrasos en la respuesta de las redes de publicidad
Costos de procesamiento cliente-servidor Ninguna Alta Baja Ninguno (a menos que envíes los datos a los servidores)
Mantenimiento cliente-servidor Ninguna Alta Baja Ninguno (a menos que envíes los datos a los servidores)
Formato de datos Archivo CSV Parámetros JSON o de consulta CSV o parquet JSON

Las atribuciones de raw data que ocurren en un contexto determinado se agrupan en reportes. Por ejemplo, instalaciones no orgánicas, eventos in-app orgánicos. Para facilitar la explicación, los reportes se agrupan de la siguiente manera:

  • Trayectoria del usuario: úsala para rastrear la trayectoria y el engagement de un usuario con la aplicación.
    Por ejemplo: clic > instalación > evento in-app > desinstalación.
  • Función: se relacionan con una función determinada de AppsFlyer, pero no forman parte de la trayectoria principal del usuario. Por ejemplo, postbacks a redes de publicidad, reportes de reglas de fraude y validación y reportes de ingresos por publicidad a nivel de usuario.

Campos de reporte

El diccionario de campos de raw data contiene los campos relevantes para los reportes de trayectoria del usuario y algunos campos de reportes de funciones. Los principios son los siguientes:

  • Trayectoria del usuario:
    • Tener un conjunto común de campos.
    • El relleno de campos depende del contexto de la trayectoria. Por ejemplo, los reportes no orgánicos contienen la fuente de medios acreditada por traer al usuario. Los campos de atribución en los reportes orgánicos no se rellenan porque no hay una fuente de medios. 
  • Función: tener un conjunto único de campos o contener campos de trayectoria del usuario y campos adicionales relevantes para la función. Por ejemplo, los reportes de SKAdNetwork tienen una lista única de campos, mientras que los reportes de postback contienen los campos de trayectoria del usuario y los campos adicionales relacionados con el envío de postbacks a los partners. 

¡Consejo! La mejor manera de familiarizarse con los reportes es ver los reportes. Puedes descargar tus reportes a través de la página Datos exportados. 

Para facilitar la comprensión, los campos de trayectoria del usuario se dividen en grupos en función del contexto.

Grupos de campos de raw data de la trayectoria del usuario
Grupo de campo Relevante para usuarios orgánicos Campos de ejemplo
Aplicación Sí ID de aplicación, nombre de aplicación, versión de aplicación, versión de SDK, ATT
Atribución

No, excepto por la hora de instalación

Hora de instalación, hora de toque atribuido, fuente de medios, campaña, conjunto de anuncios, anuncio, partner, tipo de conversión de retargeting
Atribución de colaboradores No Partner colaborador, tipo de coincidencia
Información del dispositivo Sí ID de publicidad, ID de publicidad de Google (GAID), OAID, tipo de dispositivo, ID de usuario del cliente
Ubicación del dispositivo Sí Dirección IP, ciudad, país
Evento

Sí

Rellenado en reportes de eventos in-app:

Nombre del evento, valor del evento, ingresos del evento

Reportes de trayectoria del usuario

Raw_data_-_User_acquisition_.png

Conceptos básicos de la trayectoria del usuario

Los reportes de trayectoria del usuario contienen datos recopilados de los eventos que ocurren durante el tiempo de vida de un usuario. Los datos se dividen en reportes de acuerdo con:

  • Fuente del usuario: orgánica o no orgánica
  • Contexto de la trayectoria:
    • Engagement con anuncios antes de la instalación de la aplicación (impresiones y clics)
    • Adquisición
    • Retargeting

Los reportes de adquisición de usuarios (UA) contienen:

  • Las impresiones y los clics que se producen antes de la instalación por parte de cualquier usuario potencial que interactúe con un anuncio.
  • Evento de instalación.
  • Eventos in-app posteriores realizados por el usuario.

Los reportes de retargeting contienen:

  • Las impresiones y los clics que ocurren cuando se reorienta al usuario.
  • Eventos de conversión: ya sea un re-engagement o una nueva atribución.
  • Eventos in-app posteriores realizados como parte del re-engagement. Ten en cuenta lo siguiente:
    • Los datos de retargeting siempre son no orgánicos.
    • Los eventos in-app de retargeting están tanto en los reportes de eventos in-app de la UA como en los de retargeting. Consulta la metodología de doble atribución de retargeting.

      Raw_data_-_Retargeting.png

Para seguir la trayectoria de un usuario, combina los reportes relativos a la parte de trayectoria que te interese, por ejemplo, instalaciones y eventos in-app. Una vez hecho esto, ordena el reporte utilizando el ID de AppsFlyer, la hora del evento y el tipo de reporte. El resultado son los eventos de un usuario determinado a lo largo del tiempo, es decir, la trayectoria del usuario. 

Disponibilidad del reporte de trayectoria del usuario

  • La disponibilidad de reportes depende de tu plan de suscripción.
  • Los reportes pueden incluir a los usuarios orgánicos, a los no orgánicos, o ambos, según se indique.
  • Las políticas de retención se aplican a reportes de raw data históricos en función de la herramienta de reportes y el origen del raw data. En general, los datos están disponibles para los 90 días anteriores. Nota: Las políticas de retención no se aplican a los datos agregados. 
Reportes de trayectoria del usuario
Categoría Exclusivo del Data Locker Tema de los reportes Orgánico No orgánico
La adquisición de usuarios ✓ Clics N/A
Retargeting ✓ Clics de campañas de retargeting  Retargeting siempre no orgánico
La adquisición de usuarios ✓ Impresiones N/A
Retargeting ✓ Impresiones de campañas de retargeting Retargeting siempre no orgánico
La adquisición de usuarios - Instalaciones  ✓ ✓
La adquisición de usuarios - Eventos in-app  ✓ ✓
La adquisición de usuarios - Ingresos por publicidad atribuidos - ✓
La adquisición de usuarios - Ingresos por publicidad orgánicos ✓ -
Retargeting - Ingresos por publicidad por retargeting Retargeting siempre no orgánico
Retargeting - Conversiones de retargeting (re-engagements y reatribuciones)x Retargeting siempre no orgánico
Retargeting - Eventos in-app de retargeting (re-engagement y reatribuciones) Retargeting siempre no orgánico
Retargeting  ✓ Sesiones de retargeting (re-engagement y reatribuciones) Retargeting siempre no orgánico
La adquisición de usuarios  ✓ Sesiones ✓ ✓
La adquisición de usuarios - Desinstalaciones no orgánicas  - ✓
La adquisición de usuarios - Desinstalaciones orgánicas ✓ -
La adquisición de usuarios ✓ Engagements multiplataforma ✓ ✓

Descripciones del reporte de trayectoria del usuario

Clics e impresiones
Reporte Características

Contexto		 Un usuario se involucra con una campaña y hace clic o ve un anuncio.
Características Los reportes contienen un registro del enlace de atribución y los encabezados HTTP presentes cuando un usuario hace clic o visualiza un anuncio.
Caso de uso
  • Optimizar las campañas que no conducen a la apertura de una aplicación (instalación, reatribución, re-engagement).
  • Retargeting de estos usuarios mediante diferentes campañas.
Ejemplo de reporte Clics
Observaciones

Los datos de SRN no están disponibles.
Usuarios restringidos En algunos casos, debido a las reglas de privacidad, los datos de impresiones y clics están restringidos (no tienen identificadores de usuario) o no están disponibles en absoluto. La disponibilidad depende de la fuente de medios y la plataforma. 
Instalaciones y conversiones de retargeting
Nombre del reporte 

Adquisición de usuarios: instalaciones

 Retargeting: conversiones

Contexto

Cuando un usuario abre una aplicación por primera vez.

Después de que un usuario se involucre con un anuncio de retargeting y luego abra la aplicación. Una conversión de retargeting es un re-engagement o una nueva atribución.

Consulta la guía de atribución de retargeting. 
CASOS DE USO
  • Generar reportes agregados utilizando campos no disponibles a través de las herramientas de analíticas de AppsFlyer.
  • Combinar con otros reportes para realizar un análisis transversal avanzado.
  • Analizar el rendimiento en diferentes dimensiones, como ciudades, áreas metropolitanas, etc. 
  • Segmentar a los usuarios según el país, la ciudad y el idioma con fines de targeting.
  • Obtener el ID de dispositivo del usuario para fines de retargeting.
 Similar a las instalaciones.
Orgánico vs. no orgánico
  • No orgánico: los grupos de campos de atribución de los colaboradores y la atribución se completan.
  • Orgánico: el campo de la fuente de medios está vacío, es nulo u orgánico. Tenlo en cuenta cuando cargues datos en tus sistemas. 
 No correponde
Ejemplo de reporte Instalaciones El reporte de conversiones de retargeting tiene la misma estructura que el reporte de instalaciones. Algunos campos se rellenan en el contexto del retargeting. Ver Raw data de retargeting. 
Eventos in-app
Reporte Características

Contexto del reporte

Lista cronológica de las acciones realizadas por los usuarios después de la atribución (instalación, reatribución o re-engagement)

Características
  • La estructura y los campos del reporte son similares a los de los reportes de instalaciones.
  • Los campos dedicados describen el evento. Estos incluyen el nombre del evento, el valor, los ingresos y la hora. 

Caso de uso

Usa el reporte para:

  • Obtener insights observando la trayectoria del usuario durante el tiempo de vida de este.

  • Combinar el raw data de la instalación y del evento in-app para seguir la trayectoria completa del usuario. 

Valores de evento

Campo de valor de evento

El campo de valor del evento contiene todos los datos relacionados con el evento en un JSON. Puedes cargarlo en tu sistema de Business Intelligence para un análisis más detallado.

¡Consejo!Puedes utilizar Power Query en Microsoft Excel para analizar los parámetros de eventos de las cadenas de texto JSON.


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

Reporte de ingresos

Los datos de ingresos y ROI en AppsFlyer se derivan del af_revenue enviado en los eventos. 

Cuando el parámetro af_revenue se envía en un evento in-app, AppsFlyer lo usa para completar el campo de ingresos del evento. AppsFlyer utiliza este campo para actualizar el panel de control y los reportes agregados. 

¡Nota! Usa el parámetro af_revenue únicamente con eventos in-app que describan los ingresos reales generados.Para otros eventos que implican ingresos, pero que no son finales, por ejemplo, add_to_cart, usa parámetros diferentes como af_price.

Ejemplo de reporte

 Eventos in-app

Observaciones
  • Los eventos in-app de retargeting se atribuyen doblemente en los reportes de raw data de eventos in-app de UA y de retargeting. 
  • Los eventos in-app no incluyen el evento de inicio (af_app_opened). Este está disponible en el reporte de raw data de sesiones. 
  • Geolocalización: se deriva utilizando la dirección IP del usuario en el momento en que se realiza el evento. 
Sesiones
Reporte Características

Contexto		 Cuando el usuario abre la aplicación, se envía un evento de sesión a AppsFlyer. El evento se atribuye si se excede el umbral de tiempo mínimo entre sesiones. 
Características

La estructura del reporte es la misma que la de los reportes de eventos in-app. Las sesiones (eventos de sesión) se encuentran en un reporte separado debido al gran número de tales eventos.
Caso de uso Comprender el engagement del usuario con la aplicación.
Ejemplo de reporte El reporte de sesiones es similar al reporte de eventos in-app. Nota: En el raw data, las sesiones tienen el nombre de evento launch. 
Desinstalar
Reporte Características

Contexto		 Registro de usuarios que desinstalan la aplicación. 
Características
  • Este reporte se actualiza a diario y no continuamente, como sucede con otros reportes de trayectoria del usuario. 
  • En el reporte, la hora del evento representa el momento en que AppsFlyer determina que se desinstaló la aplicación y no la desinstalación en sí misma. Consulta Medición de desinstalaciones.
Campos disponibles
  • Si el usuario proviene de una fuente de medios no orgánica, se rellenan los campos de la fuente de medios. 
  • Ten en cuenta que el evento de desinstalación lo generan los servidores de AppsFlyer después de determinar que el usuario desinstaló. En consecuencia, muchos campos no se rellenan. 
  • Los identificadores de usuarios disponibles son aquellos registrados en el momento de la instalación. El CUID nunca está disponible. 
  • Los campos relacionados con la geolocalización se completan con la ubicación del usuario en el momento del engagement con la fuente de medios (clic o impresión). Si la ubicación del engagement no está disponible, se utiliza la ubicación asociada con el evento de instalación. 
Ejemplo de reporte Desinstalaciones ¡Nota! En el ejemplo, para mayor claridad, la fila 2 indica qué campos se rellenan, si hay datos relevantes disponibles. 
CASOS DE USO
  • Analizar las características del usuario, el evento de desinstalación y el dispositivo.
  • Construir una audiencia de eventos de desinstalación para el retargeting.

Disponibilidad del reporte de trayectoria del usuario por herramienta

Reporte Exportar datos API pull Data Locker API push Datos de conversión del
SDK
Impresiones (1) - - ✓ - -
Clics (1) - - ✓ - -
(1) Los datos de clics e impresiones son proporcionados por las no SRN. Las SRN no proporcionan estos datos.
Reporte de engagement con el anuncio por herramienta 
Reportes de adquisición de usuarios por herramienta 
Reporte Exportar datos API pull Data Locker API push Datos de conversión de SDK
Instalaciones ✓ ✓ ✓ ✓ ✓
Sesiones - - ✓ - -
Eventos in-app ✓ ✓ ✓ ✓ -
Desinstalar ✓ ✓ ✓ - -
Reporte Exportar datos API pull Data Locker API push Datos de conversión del
SDK
Clics (1) - - ✓ - -
Conversiones (reatribuciones + re-engagements) ✓ ✓ ✓ ✓ ✓
Impresiones - - ✓ - -
Sesiones - - ✓ - -
Eventos in-app ✓ ✓ ✓ ✓ -

(1) Los datos de clics e impresiones son proporcionados por las no SRN. Las SRN no proporcionan estos datos.
Reportes de raw data de retargeting por herramienta

Preguntas frecuentes

 
Detalles

¿Por qué falta el raw data de Facebook?

De forma predeterminada, el raw data de Facebook se atribuye a las fuentes de medios restringidas. Consulta los datos de nivel de usuario de Facebook.

¿Cuál es la diferencia entre las marcas de tiempo?

Las marcas de tiempo son comunes para todos los reportes. Esto permite combinar diferentes reportes.

Las siguientes marcas de tiempo son relevantes: 

  • Tiempo de toque atribuido: el tiempo que el usuario se involucró con un anuncio.
  • Hora de instalación: la hora en que se inicia la aplicación por primera vez.
  • Hora del evento: la hora en que tiene lugar el evento.

Ten en cuenta lo siguiente: 

  • En los reportes de instalaciones, las horas de instalación y evento son las mismas.
  • En los reportes de eventos in-app, las horas de instalación y del evento son diferentes. La diferencia puede mostrar el tiempo que pasa entre el inicio de la aplicación y el engagement del usuario con la aplicación.

¿Cuál es el propósito del campo de colaborador?

El campo de colaborador enumera las fuentes de medios de los colaboradores. A veces se les denomina instalaciones asistidas. En Protect360, también se usa para la corrección de la atribución de instalaciones secuestradas.

¿Qué es el campo de palabras clave? ¿Por qué no está disponible en todas las instalaciones no orgánicas? 

Las instalaciones atribuidas a Google Ads o Apple Search Ads pueden contener las palabras clave o el ID de palabra clave asociados con el anuncio que trae la instalación. 

Consejos para los reportes de instalaciones

Comprender la trayectoria del usuario

Una trayectoria del usuario es una serie de pasos que realiza el usuario antes de lograr un objetivo, como comprar un producto o reservar un vuelo. La idea detrás del análisis de la trayectoria de un usuario es ver qué hace el usuario en la aplicación, qué tan activo es y qué valor aporta durante un período determinado.

Puedes identificar y resaltar las trayectorias de los usuarios con la ayuda del ID de AppsFlyer. El ID se genera para cada instalación de la aplicación por dispositivo. El ID permanece sin cambios a lo largo del ciclo de vida del usuario (desde la instalación hasta la desinstalación). El ID persiste si el usuario restablece el ID de su dispositivo.

Dado que los reportes de instalaciones y eventos in-app tienen las mismas estructuras, se pueden fusionar en un solo reporte. En el reporte fusionado, puedes agregar y filtrar por el ID de AppsFlyer y el ID de usuario del cliente (si está disponible) para analizar las trayectorias de los usuarios.

 Ejemplos

Usuario involucrado: fuerte

  • Un usuario instaló la aplicación el 20 de agosto a las 09:31.
  • El reporte fusionado muestra que realizó compras el 20 de agosto a las 10:31, el 22 de agosto a las 15:22 y el 25 de agosto a las 16:47.
  • De esto, concluimos que el usuario es un usuario involucrado. Hizo una compra una hora después de iniciar la aplicación y siguió comprando en los días posteriores a la instalación.

Usuario involucrado: débil

  • Un usuario instaló la aplicación el 30 de julio. El reporte fusionado muestra que agregó un artículo a su carrito el 15 de agosto, pero no hay eventos de compra posteriores.
  • Puedes asumir que el usuario tiene dudas para realizar una compra y volver a dirigirte a él con los artículos que agregó al carrito.

Analizar la trayectoria del usuario para optimizar la campaña

  • El administrador de adquisición de usuarios (UA) de una aplicación de viajes descarga los reportes de eventos de instalación e in-app y los fusiona.
  • Luego, para ver las trayectorias de los usuarios en la aplicación, filtra o agrega datos por el ID de AppsFlyer.
  • Observa que un usuario determinado, identificado por su ID de AppsFlyer, descargó la aplicación hace 12 meses y reservó un vuelo varios días después.
  • Posteriormente, el usuario vio algunas ofertas de vuelos, pero no hizo ninguna reserva. En una inspección más profunda, el administrador de UA descubre más usuarios con el mismo patrón y decide indagar aún más.
  • Descubre que la mayoría de estos usuarios procedían del Anuncio A de la Campaña B ejecutada en la Fuente de medios C. Resulta que este anuncio y esta campaña se dirigían a usuarios que querían viajar a un destino concreto.
  • Al analizar la trayectoria de los usuarios, el administrador de UA podría concluir que la campaña estaba demasiado limitada y que los usuarios no estaban lo suficientemente involucrados con la aplicación.

Reportes de funciones

Reportes relacionados con las funciones adicionales disponibles en la plataforma

Postbacks

Utiliza los reportes de postbacks para revisar las copias de los datos enviados a una red de publicidad. Por ejemplo, úsalos para investigar discrepancias. Estos reportes tienen fines informativos y no son necesarios para la integración con redes de publicidad.

Reportes de postbacks
(disponibles a través de la página Datos exportados y la Pull API)
Tema de los reportes Eventos enviados a la fuente de medios atribuida
Instalaciones Instalaciones no orgánicas (UA)
Eventos in-app Eventos In-App No Orgánicos

Postbacks de conversiones de retargeting

 Retargeting (re-engagement y reatribución)

Eventos In-App de Retargeting

Eventos In-App de Retargeting
Campos adicionales en reportes de postbacks
Campo Observaciones
URL de postback

Es posible que algunos valores, como los ingresos, no aparezcan en el campo apropiado, pero aún así puedes ver estos datos en la URL del postback.
Método de postback  
Código de respuesta HTTP del postback 200: confirma que la red de publicidad recibió el postback
Mensaje de error de postback   

Reglas de validación y fraude Protect360

  • Consulta Protect360 y los reportes de raw data de las reglas de validación.
  • Las redes de publicidad y las agencias necesitan permiso del anunciante para acceder a los reportes de Reglas de validación y Protect360.

Para conceder permiso a un partner integrado para acceder a Protect360:

  1. Ve a Integración > Partners integrados. 
  2. Selecciona un partner integrado.
  3. En la pestaña Permisos, activa Acceder a tu panel de control y al raw data de Protect360 a través de API.
  4. Para dar acceso al panel de control de eventos in-app (CPA), activa Acceder a datos agregados de eventos in-app.
¿Fue útil este artículo?

Artículos en esta sección

Artículos relacionados