Rapport SSOT (Single Source of Truth) Data Locker pour les marketeurs

Pour activer les rapports SSOT, effectuez l'une des procédures suivantes.

Obtenez-vous actuellement des données via Data Locker ?	Marche à suivre
Oui	Pour ajouter les rapports à Data Locker : Dans AppsFlyer, dans le menu latéral, sélectionnez Exporter > Data Locker. Sélectionnez tous les rapports que vous souhaitez obtenir.  Cliquez sur Enregistrer la configuration.  Les rapports seront disponibles le lendemain.
Non	Pour configurer Data Locker : Achevez la toute première configuration Data Locker (annonceur | partenaire). Ajoutez des rapports à Data Locker : Dans AppsFlyer, dans le menu latéral, sélectionnez Exporter > Data Locker. Sélectionnez tous les rapports que vous souhaitez obtenir.  Cliquez sur Enregistrer la configuration.  Les rapports seront disponibles le lendemain.

AppsFlyer modélise des données que les rapports de base de SKAdNetwork ne peuvent pas fournir.

• Valeurs de conversion (CV) nulles : Dans SKAN, Apple peut remplacer les données réelles par une valeur « Null » afin de protéger la confidentialité de l’utilisateur. Pour s’assurer qu’aucune donnée n’est omise, ces valeurs nulles sont modélisées dans la SSOT. En savoir plus.
• Métriques post-installation plus longues : Il y a une diminution dans la précision des données de SKAN pour les périodes post-installation qui dépassent des deux premiers jours, ce qui peut entraîner des inexactitudes. Pour maintenir un haut niveau des données, nous modélisons les revenus et les utilisateurs uniques d’événements in-app avec une days_post_attribution supérieure à 2. En savoir plus.

Données géographiques : SKAN limite la granularité des données, de fait les données géo sont souvent indisponibles. Lorsque cela se produit, nous modélisons les données pour permettre une bonne analyse des performances. En savoir plus.

Lors de l’analyse des jours d’installation récents, les mesures relatives aux périodes post-installation plus longues (ex. 7 jours) peuvent être approximatives. Dans ce cas, les mesures sont disponibles mais correspondent à des données partielles.

Quelques règles de base :

• Le rapport affiche toutes les données dès lors qu’elles sont disponibles.
• Après 5 jours, les mesures pour les deux jours post-installation sont complètes*.
• Après 7 jours, les mesures pour les sept jours post-installation sont complètes*. Jusqu’à 15 jours post-installation, le modèle peut continuer à affiner la valeur.

Pourquoi les données partielles apparaissent :

• Maturité des données : lorsque la période écoulée depuis le jour d’installation est plus courte que le nombre de jours analysés, les données continuent à arriver et ne sont pas complètes.
• Retards SKAN : Les données SKAN sont reçues avec un décalage aléatoire. Par exemple, l’activité post-installation des deux premiers jours peut être reçue jusqu’à 96 heures (4 jours) après l’installation.
• Synchronisation des données modélisées : Les données SKAN pour les périodes qui dépassent les 2 jours post-installation sont modélisées. Nos modèles génèrent la première estimation de valeur après 7 jours. Sur cette période (jours 2 à 7), les données issues des méthodes d’attribution classiques AppsFlyer sont disponibles, ce qui n’est pas le cas des données modélisées par SKAN.

Exemples (pour une date d’installation au 1er janvier) :

• Le 2 janvier : Les données SKAN n’ont pas encore été reçues. Les données des 2 jours post-installation seront égales aux données sur moins de 7 jours après l’installation. Toutes les données seront partielles, et composées des données issues des méthodes d’attribution classiques AppsFlyer.
• Le 3 janvier : Les données SKAN sont partiellement reçues. Les données des 2 jours post-installation sont toujours partielles, et contiennent alors partiellement des données SKAN. Les données des 7 jours suivant l’installation n’incluent pas encore de données SKAN modélisées (la première valeur modélisée est disponible 7 jours après l’installation). Par conséquent, entre 2 et 7 jours après l’installation, il est possible d’avoir un résultat plus petit pour les 7 jours post-installation que pour la période des 2 jours post-installation.
• Le 6 janvier : Les données SKAN des deux premiers jours qui suivent l’installation ont été entièrement reçues, y compris les postbacks qui ont le décalage le plus long. Les mesures des deux jours suivant l’installation sont terminées. À ce stade, les mesures des 7 jours suivant l’installation ne sont pas encore complètes.
• Le 8 janvier : Les données modélisées par SKAN pour les 7 jours post-installation sont terminées. Notre modèle continuera à affiner la valeur jusqu’au 16 janvier. 

• Les dossiers principaux sont organisés par type de rapport. Valeurs possibles :
  • ssot_unified
  • ssot_retargeting
  • ssot_user_acquisition
• Dans ces dossiers, les sous-dossiers sont créés selon la date d’installation.

Gérer les versions 

• Chaque dossier de date d'installation contient plusieurs versions, créées chaque jour.
• Chaque version reflète les données cumulées mises à jour pour cette date d'installation.
• Les rapports incluent toutes les données qui sont disponibles pour la date d’installation. Par exemple, le 18 avril, la dernière version pour chaque date d’installation contient toutes les données recueillies jusqu'à cette date pour le 18 avril.
• Conseil : traitez toujours la dernière version du rapport disponible pour garantir la précision.

Chaque jour d’installation contient au maximum 15 versions. Au bout de 15 jours, toutes les mesures ont été entièrement corrigées et sont terminées. En savoir plus.

Le chemin d’accès au rapport a le format suivant :

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

Exemple de structure de dossier dans le compartiment d’un annonceur :

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
    |   |
    .   . 
    .   .

Légende :

• t : Sujet du rapport (type).
• install_date: La date de l’installation de l’application. Cela signifie que cette activité post-installation apparaîtra en fonction de la date d’installation à laquelle l'utilisateur a téléchargé l'application, et non le jour où l’action a eu lieu.
• Version : Horodatage Unix indiquant quand la version a été créée.

Vous pouvez charger des rapports unifiés, d'acquisition d'utilisateurs et de retargeting séparément ou ensemble dans votre système BI. Si vous les chargez ensemble et souhaitez filtrer les vues :

• Rapports unifiés : Utilisez le champ is_primary_attribution=true ou null .
• Rapports d’acquisition d’utilisateurs : Utilisez conversion_type=Install.
• Rapports de retargeting : Utilisez conversion_type=re-engagement ou réattribution :
• Vue unifiée : si vous utilisez la vue unifiée lors du processus de chargement de vos données, vous pouvez répartir les données entre les types de campagnes :

• Utilisez conversion_type=install, re-engagement ou re-attribution (retéléchargements dans SKAN).
• Consultez la section « Double attribution des événements de retargeting » pour en savoir plus détails

• Pour les attributions (installations, réengagements, etc.), la valeur est 0.
• Pour les revenus et les événements intégrés à l'application, les données sont classées en cohortes prédéfinies, actuellement limitées à 2 jours et à 7 jours après l'installation.

Pour analyser avec précision les événements et revenus in-app, vous devez appliquer un filtre pour la dimension days_post_attribution. Voir : l'exemple de requête ci-dessous.

Un exemple d'erreur courante consiste à appliquer une logique simplifiée qui cumule la colonne des recettes pour un ensemble spécifique de dimensions. Cette approche aboutit à des chiffres incorrects, car certaines données de revenus sont comptées deux fois (une fois pour days_post_install=2 et une fois de plus pour days_post_install=7). Cet exemple est également pertinent pour l’analyse des utilisateurs uniques pour des événements in-app spécifiques.

N’oubliez pas :

• Dernière version : recherchez toujours la dernière version disponible pour chaque date d'installation, pour vous assurer de travailler avec le plus de données à jour et précises pour votre analyse.
• Calcul des revenus : Le chiffre d'affaires en dollars américains est basé sur le taux de change le jour de l'événement.
• Analyser les attributions : enregistrements où event_name=af_conversion reflète les attributions (installations), les réattributions (re-téléchargements) dans SKAN) et les réengagements). Le décompte des attributions apparaît sous la métrique des utilisateurs uniques, et la métrique des revenus pour ces champs sera vide. La valeur sous days_post_attribution sera égale à 0.
• Comparer les résultats avec le tableau de bord : lorsque vous comparez les installations au tableau de bord, additionnez les types de conversion de téléchargement et d'installation, comme le tableau de bord considère les deux dans la colonne d'installation.
• Analyser les événements in-app : enregistrements où event_name n’est pas égal à « af_conversion » dans les évènements in-app. Le comte d’utilisateurs uniques effectuant l'événement apparaissent dans la métrique unique des utilisateurs, tandis que les revenus générés par ces événements apparaissent sous les indicateurs de revenus.
• Type de conversion : différencier l'acquisition d'utilisateurs et le retargeting des conversions avec cette dimension. À noter qu'une ventilation supplémentaire des données SKAN est disponible (installations vs réinstallations). Lorsque vous comparez les données au tableau de bord SSOT, les deux types sont considérés comme des installations.
• Événement de revenus publicitaires : ils sont inclus lorsque disponibles.
• Segmentation des données : Toutes les données de l’app sont fournies dans un même fichier. Utilisez le champ ID d'application pour segmenter les données par application ou configurez Data Locker pour une segmentation par application.
• Les données de pré-attribution telles que le coût, les clics et les impressions doivent être extraites du rapport ETL des coûts.

Voici quelques exemples d'applications pratiques et populaires des données que les développeurs BI peuvent extraire via Data Locker. Chaque exemple propose une requête SQL et un exemple de visuel 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;