Reporte de Data Locker de Única fuente de verdad (SSOT) para marketers

Para habilitar los reportes de Única fuente de verdad o SSOT, completa uno de los siguientes procedimientos.

¿Actualmente obtienes datos a través de Data Locker?	Procedimiento
Sí	Para agregar los reportes a Data Locker: En AppsFlyer, desde el menú lateral, selecciona Exportar > Data Locker. Selecciona todos los reportes que desees obtener.  Haz clic en Guardar configuración. Los reportes estarán disponibles al día siguiente.
No	Para configurar Data Locker: Completa la configuración inicial de Data Locker (anunciante | partner). Agrega los reportes a Data Locker: En AppsFlyer, desde el menú lateral, selecciona Exportar > Data Locker. Selecciona todos los reportes que desees obtener.  Haz clic en Guardar configuración. Los reportes estarán disponibles al día siguiente.

AppsFlyer modela datos que los reportes básicos de SKAdNetwork no pueden proporcionar.

• Valores de conversión nulos (CV): en SKAN, Apple puede reemplazar los datos reales por un valor "Nulo" para mantener la privacidad del usuario. Para garantizar que no se omita ningún dato, estos valores nulos se modelan en SSOT. Saber más.
• Métricas posteriores a la instalación más largas: la granularidad de los datos de SKAN para los períodos posteriores a la instalación más allá de los dos primeros días es limitada, lo que puede generar imprecisiones. Para mantener una alta calidad de los datos, modelamos los ingresos y los usuarios únicos de eventos in-app para days_post_attribution superiores a 2. Saber más.

Datos de geolocalización: SKAN limita la granularidad de los datos y, a menudo, hace que los datos de geolocalización no estén disponibles. En estos casos, modelamos los datos para permitir un análisis de rendimiento eficiente. Saber más.

Al analizar los últimos días de instalación, es posible que las métricas de los períodos prolongados posteriores a la instalación (por ejemplo, 7 días) no sean completas. En esos casos, las métricas seguirán estando disponibles, pero reflejarán datos parciales.

Algunas reglas generales:

• El reporte muestra todos los datos existentes tan pronto como estén disponibles.
• Transcurridos 5 días, se completan las métricas de los dos días posteriores a la instalación*.
• Transcurridos 7 días, se completan las métricas de los siete días posteriores a la instalación. Hasta 15 días después de la instalación, el modelo puede refinar este valor.

Motivos de los datos parciales:

• Madurez de los datos: cuando el tiempo transcurrido desde la fecha de instalación es inferior al de los días que se están analizando, los datos se siguen acumulando y aún no están completos.
• Retrasos de SKAN: los datos de SKAN se reciben con un retraso aleatorio. Por ejemplo, la actividad posterior a la instalación de los dos primeros días se puede recibir hasta 96 horas (4 días) después de la instalación.
• Sincronización de datos modelados: se modelan los datos de SKAN para períodos superiores a 2 días después de la instalación. Nuestros modelos generan el primer valor estimado después de 7 días. Durante este período (días del 2 al 7), los datos de los métodos de atribución clásicos de AppsFlyer están disponibles, mientras que los datos modelados de SKAN no.

Ejemplos (suponiendo que la fecha de instalación sea el 1 de enero):

• El 2 de enero: aún no se han recibido los datos de SKAN. Los datos de 2 días después de la instalación equivaldrán a los datos de menos de 7 días después de la instalación, y ambos son parciales y consisten en datos de los métodos de atribución clásicos de AppsFlyer.
• El 3 de enero: los datos SKAN se reciben parcialmente. Los datos de los 2 días posteriores a la instalación seguirán siendo parciales y ahora contienen parcialmente datos de SKAN. Los datos de los 7 días posteriores a la instalación aún no incluirán ningún dato SKAN modelado (el primer valor modelado está disponible 7 días después de la instalación). Por lo tanto, entre los días 2 y 7 después de la instalación, es posible que veamos un valor inferior para los 7 días posteriores a la instalación en comparación con los 2 días posteriores a la instalación.
• El 6 de enero: los datos de SKAN de los dos primeros días posteriores a la instalación se recibieron en su totalidad, incluidos los postbacks con el máximo retraso posible. Se han completado las métricas correspondientes a los dos días posteriores a la instalación. En este momento, las estadísticas de los 7 días posteriores a la instalación aún no se han completado.
• El 8 de enero: los datos modelados de SKAN durante los 7 días posteriores a la finalización de las instalaciones. Nuestro modelo seguirá refinando el valor hasta el 16 de enero. 

• Las carpetas principales están organizadas por tipo de reporte. Posibles valores:
  • ssot_unified
  • ssot_retargeting
  • ssot_user_acquisition
• Dentro de estas carpetas, las subcarpetas están organizadas por fecha de instalación.

Versiones 

• Cada carpeta de fecha de instalación contiene varias versiones, creadas diariamente.
• Cada versión refleja los datos acumulados actualizados para esa fecha de instalación.
• Los reportes incluirán todos los datos disponibles para la fecha de instalación. Por ejemplo, el 18 de abril, la última versión para cada fecha de instalación contiene todos los datos hasta el 18 de abril.
• Consejo: Procesa siempre la última versión del reporte disponible garantizar la precisión.

Cada fecha de instalación está limitada a un máximo de 15 versiones. Después de 15 días, todas las métricas están completamente fijadas y completadas. Saber más.

La ruta al reporte tiene el siguiente formato:

<bucket-name>/t=<ssot_unified O ssot_retargeting O ssot_user_acquisition>/install_date=<yyyy-mm-dd>/version=<unix timestamp>/<parquet file number>

Ejemplo de jerarquía de carpetas en el bucket del anunciante:

bucket
|
└── t=ssot_unified
    |
    ├── install_date=2024-05-05
    |   |
    |   └── version=1714890235
    |   |    |
    |   |    ├── part-00000-4762858-d62a-446e-b499-dd05f2d5434d-c000.csv.gz
    |   |    |
    |   |    ├── part-00001-4762858-d62a-446e-b499-dd05f2d5434d-c000.csv.gz
    |   |    │
    |   |    └── part-00002-4762858-d62a-446e-b499-dd05f2d5434d-c000.csv.gz
    |   |
    |   |
    |   └── version=1714890286
    |        |
    |        ├── part-00000-1d295376-d024-4321-8d34-1fbb37cbb58d-c000.csv.gz
    |        |
    |        ├── part-00001-1d295376-d024-4321-8d34-1fbb37cbb58d-c000.csv.gz
    |        │
    |        └── part-00002-1d295376-d024-4321-8d34-1fbb37cbb58d-c000.csv.gz
    |   |
    .   . 
    .   .

Leyenda:

• t: tema del reporte (tipo).
• install_date: la fecha de instalación de la aplicación. Significa que la actividad post-instalación aparecerá en función de la fecha de instalación en la que el usuario descargó la aplicación, no el día en que tuvo lugar la acción del usuario.
• version: marca de tiempo de Unix que indica cuándo se creó la versión.

Puedes cargar los reportes unificados, de adquisición de usuarios y de retargeting por separado o juntos en tu sistema de BI. Si los cargas juntos y quieres filtrar las vistas por tu cuenta:

• Reportes unificados: usa el campo is_primary_attribution=true o null .
• Reportes de adquisición de usuarios: usa conversion_type=install.
• Reportes de retargeting: usa conversion_type=re-engagement o re-attribution.
• Vista unificada: si usas la vista unificada en el proceso de carga de datos, puedes dividir los datos entre tipos de campaña:

• Usa conversion_type=install, re-engagement o re-attribution (descargas repetidas en SKAN).
• Consulta "Doble atribución de eventos de retargeting" para obtener más información.

• Para las atribuciones (instalaciones, reengagements, etc.), el valor es 0.
• Para los ingresos y los eventos in-app, los datos se clasifican en cohortes predefinidas, actualmente limitadas a “2” días y “7” días post-instalación.

Para analizar con precisión los eventos in-app y los ingresos, debes aplicar un filtro para la dimensión days_post_attribution. Observa el ejemplo de consulta que aparece a continuación.

Un ejemplo de un error común es aplicar una lógica simplificada que suma la columna de ingresos de un conjunto específico de dimensiones. Este enfoque da como resultado cifras incorrectas porque algunos datos de ingresos se cuentan dos veces (una vez para days_post_install=2 y otra vez para days_post_install=7). Este ejemplo también es relevante cuando se analizan usuarios únicos para eventos in-app específicos.

Consejos y consideraciones:

• Última versión: consulta siempre la última versión disponible para cada fecha de instalación para garantizar que estás trabajando con los datos más actualizados y precisos para tu análisis.
• Cálculo de ingresos: los ingresos en USD se calculan utilizando el tipo de cambio del día del evento.
• Análisis de las atribuciones: registros donde event_name=af_conversion refleja las atribuciones (instalaciones, reatribuciones (descargas repetidas en SKAN) y reengagements). El recuento de atribuciones aparece debajo de la métrica de usuarios únicos, y las métricas de ingresos de estos campos estarán vacías. El valor en days_post_attribution será 0.
• Comparación de paneles de control: al comparar las instalaciones con el panel de control, suma los tipos de conversión de descarga repetida e instalación, ya que el panel de control considera ambos en la columna de instalación.
• Análisis de eventos in-app: los registros donde event_name no es igual a 'af_conversion' reflejan eventos in-app. El recuento de usuarios únicos que realizan el evento aparece debajo de la métrica de usuarios únicos, mientras que los ingresos generados por estos eventos aparecen debajo de las métricas de ingresos.
• Tipo de conversión: diferencia entre la adquisición de usuarios y las conversiones de retargeting mediante esta dimensión. Ten en cuenta que hay disponible un desglose adicional para los datos de SKAN (instalaciones frente a descargas repetidas). Al comparar los datos con el panel de control de SSOT, ambos tipos son considerados como instalaciones.
• Eventos de ingresos por publicidad: se incluyen cuando están disponibles.
• Segregación de datos: los datos de todas las aplicaciones se proporcionan en un único archivo. Usa el campo ID de aplicación para segregar los datos por aplicación o configura Data Locker para segregar por aplicación.
• Los datos de preatribución, como costos, clics e impresiones, deben tomarse del reporte de ETL de costos.

Los siguientes son ejemplos de algunas aplicaciones prácticas y populares de los datos que los desarrolladores de BI pueden extraer a través de Data Locker. Cada ejemplo está ilustrado con una declaración SQL y un ejemplo visual de Excel.

SELECT install_date, SUM(unique_users) AS total_attributions
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND af_c_id = '4475903638579'  -- Change to your specific campaign
    AND app_id = 'YOUR_APP'
GROUP BY install_date;

SELECT install_date, conversion_type, SUM(unique_users) AS total_conversions
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND af_c_id = '4475903638579'  -- Change to your specific campaign
    AND conversion_type IN ('install', 're-download')  
-- The dashboard sums both under the install field
    AND app_id = 'YOUR_APP'
GROUP BY install_date, conversion_type;

SELECT install_date, conversion_type, geo, SUM(unique_users) AS total_conversions
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND conversion_type IN ('re-attribution', 're-engagement')  
-- Both types are relevant for re-targeting
    AND app_id = 'YOUR_APP'
GROUP BY install_date, conversion_type, geo;

SELECT install_date, attribution_method, media_source, SUM(unique_users) 
AS total_installs
FROM ssot_unified
WHERE event_name = 'af_conversion'
    AND conversion_type = 'install'
    AND app_id = 'YOUR_APP'
GROUP BY install_date, attribution_method, media_source;

SELECT install_date,
       af_adset,
       SUM(revenue_usd) AS total_revenue_day_7
FROM ssot_unified
WHERE media_source = 'facebook'
    AND days_post_attribution = 7  -- Choose a specific post-install period (cohort)
    AND app_id = 'YOUR_APP'
GROUP BY install_date, af_adset;

SELECT install_date,
       SUM(IF(days_post_attribution = 2, revenue_usd, 0)) AS total_revenue_day2,
       SUM(IF(days_post_attribution = 7, revenue_usd, 0)) AS total_revenue_day7
FROM ssot_unified
WHERE app_id = 'YOUR_APP'
GROUP BY install_date;

SELECT install_date, media_source, SUM(revenue_usd) AS total_purchase_revenue
FROM ssot_unified
WHERE event_name = 'af_purchase'  -- Change to your specific event
    AND days_post_attribution = 7  -- Choose a specific post-install period (cohort)
    AND app_id = 'YOUR_APP'
GROUP BY install_date, media_source;

SELECT install_date,
  SUM(IF(days_post_attribution = 2 AND 
event_name = 'af_complete_tutorial', unique_users, 0)) 
  / SUM(IF(event_name = 'af_conversion', unique_users, 0)) 
AS conversion_rate_day2_af_tutorial_conversion
FROM ssot_unified
WHERE conversion_type = 'install'  
-- Choose the conversion types for the sample group you want to measure
    AND app_id = 'YOUR_APP'
GROUP BY install_date;

SELECT install_date,
       af_c_id,
       SUM(IF(days_post_attribution = 2, revenue_usd, 0)) 
       / SUM(IF(event_name = 'af_conversion', unique_users, 0)) AS ARPU_day2,
       SUM(IF(days_post_attribution = 7, revenue_usd, 0)) 
       / SUM(IF(event_name = 'af_conversion', unique_users, 0)) AS ARPU_day7
FROM ssot_unified
WHERE conversion_type = 'install'  
       -- Choose the conversion types for the sample group you want to measure
    AND app_id = 'YOUR_APP'
GROUP BY install_date, af_c_id;

SELECT install_date, media_source, SUM(skan_duplicates)
FROM ssot_unified
WHERE app_id = 'YOUR_APP'
    AND event_name = 'af_conversion'
GROUP BY install_date, media_source;

SELECT install_date, media_source, SUM(skan_duplicates)
FROM ssot_unified
WHERE app_id = 'YOUR_APP'
GROUP BY install_date, media_source;