Reporte de Data Locker de Single Source of Truth (SSOT) para ad networks

Usa este procedimiento para configurar Data Locker. Los cambios en la configuración tienen efecto en 3 horas. 

Requisitos previos:

Completa uno o más de los siguientes procedimientos de almacenamiento:

• AWS bucket
• GCS bucket
• [Beta] Yandex bucket
• Almacén de datos de BigQuery 

 Para configurar Data Locker:

1. Inicia sesión en tu dashboard de partners de AppsFlyer.
2. Ve a:
   • Anunciantes: Reporte > Data Locker.
     
   • Partners de marketing: Haz clic en el  menú de la cuenta > Data Locker.
3. Sigue los pasos 3 al 16 para Instrucciones de configuración de Data Locker .

Ad networks designadas (activadas) por las agencias: La agencia no puede conceder el permiso. La agencia debe pedirle al anunciante que le otorgue los permisos. 

Para permitir que la ad networks obtenga datos de Single Source of Truth (SSOT):

1. En AppsFlyer, en el menú lateral, selecciona Colaborar > Partners integrados. 
2. Busca al partner y selecciónalo. 
3. Haz clic en Configurar integración. Se te dirigirá a la página de configuración de la integración.
4. Verifica que Activar partner esté encendido. De lo contrario, los datos no se comparten.
5. Ve a la pestaña Permisos .
6. Activa los siguientes permisos de ad network:
   • Acceder a datos agregados de conversiones.
   • Acceder a datos agregados de eventos in-app.
   • Acceder a datos agregados de ingresos.
7. Haz clic en Guardar permisos. 
8. Notifica a la ad network que has concedido los permisos.
9. Si tienes varias aplicaciones, repite el procedimiento para cada aplicación integrada con el partner. 

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. Valores posibles: ‘ssot_unified’, ‘ssot_retargeting’, and ‘ssot_user_acquisition’.
• Dentro de estas carpetas, las subcarpetas se organizan por fecha de instalación.

Versiones 

• Cada carpeta de fecha de instalación contiene varias versiones, que se crean a diario.
• Cada versión refleja los datos acumulativos 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 versión más reciente de cada fecha de instalación contiene todos los datos hasta ese momento del 18 de abril.
• Consejo: Procesa siempre la última versión del reporte disponible para 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 corregidas y completadas. Saber más

La ruta al reporte tiene el siguiente formato:

<bucket-name>/t=<ssot_unified OR ssot_retargeting OR 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 Esto significa que la actividad posterior a la instalación aparecerá en función de la fecha de instalación en la que el usuario descargó la aplicación, no del día en que se produjo la acción del usuario.
• Versión: Marca de tiempo de Unix que indica cuándo se creó la versión.

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

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

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

• Para las atribuciones (instalaciones, re-engagements, etc.), el valor es 0.
• En cuanto a los ingresos y los eventos in-app, los datos se clasifican en grupos predefinidos, actualmente limitados a “2” días y “7” días después de la 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. Consulta el ejemplo de query que aparece a continuación.

Un ejemplo de 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 números incorrectos porque algunos datos de ingresos se cuentan dos veces (una vez para days_post_install=2 y otra 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 asegurarte de 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 usando el tipo de cambio del día del evento.
• Analiza las atribuciones: Registros en los que event_name=af_conversion reflejan las atribuciones (instalaciones, reatribuciones (descargas en SKAN) y re-engagements). El recuento de atribuciones aparece en la métrica de usuarios únicos y las métricas de ingresos de estos campos estarán vacías. El valor de days_post_attribution será 0.
• Comparación de dashboard: Al comparar las instalaciones con las del dashboard, suma los tipos de conversión que se vuelven a descargar y los que se instalan, ya que el dashboard considera ambos en la columna de instalación.
• Analiza los eventos in-app: Los registros en los que event_name no es igual a 'af_conversion' reflejan eventos in-app. El recuento de usuarios únicos que realizan el evento aparece en la métrica de usuarios únicos, mientras que los ingresos generados por estos eventos aparecen en las métricas de ingresos.
• Tipo de conversión: Diferencia las conversiones de adquisición de usuarios y de retargeting utilizando esta dimensión. Ten en cuenta que hay disponible una pausa adicional para los datos de SKAN (instalaciones vs volver a descargar la app). Al comparar los datos con el dashboard de SSOT, ambos tipos se consideran instalaciones.
• Eventos de ingresos por publicidad: Se incluyen cuando están disponibles.
• Segregación de datos: Todos los datos de la aplicación se proporcionan en un único archivo. Usa el campo ID de aplicación para segregar datos por aplicación o configura Data Locker para que segregue por aplicación.

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 por una declaración SQL y un objeto visual de Excel de muestra.

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;