Rapport SSOT (Single Source of Truth) Data Locker pour les réseaux publicitaires

Utilisez cette procédure pour mettre en place Data Locker. Les modifications apportées aux paramètres prennent effet dans les 3 heures. 

Conditions minimum :

Suivez une ou plusieurs des procédures de stockage suivantes :

• Compartiment AWS
• Compartiment GCS
• Compartiment Yandex [Beta]
• Centre de données BigQuery

 Pour configurer Data Locker :

1. Connectez-vous à votre Tableau de bord des partenaires AppsFlyer.
2. Allez dans :
   • Annonceurs : Rapport > Data Locker.
     
   • Partenaires marketing : Cliquez sur l’icône Menu du compte > Data Locker.
3. Suivez les étapes 3 à 16 des instructions de configuration de Data Locker

Réseaux publicitaires désignés (activés) par les agences : L’agence ne peut pas accorder d’autorisation. L’agence doit demander à l’annonceur de pouvoir accorder les autorisations.

Pour permettre au réseau publicitaire d’obtenir des données SSOT (Single Source of Truth) :

1. Dans AppsFlyer, dans le menu latéral, sélectionnez Collaborer > Partenaires intégrés. 
2. Sélectionnez le partenaire de votre choix. 
3. Cliquez sur Configurer l'intégration. Vous êtes alors dirigé vers la page de configuration de l'intégration.
4. Vérifiez que Activer le partenaire est coché. Si l'option n'est pas activée, les données ne seront pas partagées.
5. Allez dans l'onglet Autorisations. 
6. Activez les autorisations de réseau publicitaire suivantes :
   • Accéder aux données agrégées de conversion
   • Accéder aux données agrégées des événements in-app
   • Accéder aux données agrégées des revenus
7. Cliquez sur Enregistrer les autorisations. 
8. Informez le réseau publicitaire que vous lui avez accordé les autorisations.
9. Si vous avez plusieurs applications, répétez cette procédure pour chacune des apps intégrées au partenaire. 

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' et 'ssot_user_acquisition.
• Dans ces dossiers, les sous-dossiers sont créés selon la date d’installation.

Gérer les versions 

• Chaque dossier de jour d’installation contient plusieurs versions, qui sont créées quotidiennement.
• Chaque version présente le cumul des données mises à jour pour ce jour d’installation.
• Les rapports incluent toutes les données qui sont disponibles pour la date d’installation. Par exemple, au 18 avril, la dernière version de chaque jour d’installation contient toutes les données qui vont jusqu’au 18 avril.
• Conseil : Basez vous toujours sur la dernière version du rapport disponible pour garantir un résultat précis.

Chaque jour d’installation contient au maximum 15 versions. Après 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. Ce qui signifie que l’activité post-installation s’affiche en fonction du jour d’installation (où l’utilisateur a téléchargé l’app), et non en fonction du jour où l’action de l’utilisateur s’est produite.
• Version : Horodatage Unix indiquant quand la version a été créée.

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

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

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

• Pour les attributions (installations, réengagements, etc.), la valeur est 0.
• Pour les événements de revenus et les événements in-app, 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. Vous pouvez consulter l’exemple de requête ci-dessous.

Une erreur courante consiste à utiliser une méthode simplifiée qui additionne dans la colonne des revenus les chiffres pour un ensemble de dimensions donné. Ce calcul donne des chiffres incorrects, car certaines données de revenus sont comptées deux fois (une fois pour days_post_install=2 et une autre fois pour days_post_install=7). Cet exemple vaut également dans le cas de l’analyse des utilisateurs uniques pour des événements in-app précis.

N’oubliez pas :

• Dernière version : Interrogez toujours la dernière version disponible pour chaque date d’installation afin de vous assurer que vous utilisez les données les plus récentes et précises pour votre analyse.
• Calcul des revenus : Les revenus en USD sont calculés en utilisant le taux de change au jour de l’événement.
• Analyser les attributions : les enregistrements où event_name=af_conversion reflètent les attributions (installations, réattributions (re-téléchargements dans SKAN) et les réengagements). Le nombre d’attributions s’affiche dans la mesure des utilisateurs uniques, et les données de revenus pour ces champs seront vides. La valeur pour days_post_attribution sera 0.
• Comparer les résultats avec le tableau de bord : Lorsque vous comparez les installations avec le tableau de bord, additionnez les types de conversion de téléchargement et d’installation, car le tableau de bord inclut les deux dans la colonne des installations.
• Analyser les événements in-app : Les enregistrements où event_name n’est pas égal à « af_conversion » indiquent des événements in-app. Le nombre d’utilisateurs uniques qui ont exécuté l’événement apparaît dans la mesure des utilisateurs uniques, tandis que les revenus générés par ces événements apparaissent dans les mesures du revenu.
• Type de conversion : cette dimension vous permet de faire la différence entre l’acquisition d’utilisateurs et les conversions de retargeting. Notez qu’une division supplémentaire pour les données SKAN est disponible (installations et re-téléchargements). Lorsque l’on compare les données au tableau de bord SSOT, les deux types sont vus 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’app pour séparer les données par application, ou configurez Data Locker pour séparer chaque application.

Voici quelques exemples d’utilisation 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;