Introduction à la création de rapports sur l'attribution (mesure des conversions)

Introduction et concepts clés pour comprendre l'API Attribution Reporting.

Published on Updated on

Translated to: Español, Português, 한국어, 中文, Pусский, 日本語, Deutsch

Cette API est une proposition et se développera au fil du temps. Cet article de blog décrit son état actuel et sera mis à jour au fur et à mesure de l'évolution de l'API.

Mises à jour :

  • Début 2021 : des rapports agrégés et des mesures d'affichage sont ajoutés à la proposition.
  • Début 2021 : l'API est renommée "Attribution Reporting API".
Caution
  • Cet article se concentre sur les cas d'utilisation liés à la publicité, mais l'API Attribution Reporting peut également être utilisée pour des cas d'utilisation qui ne le sont pas.
  • Les cas d'utilisation liés à la publicité de cette API se concentrent sur le lien entre les clics sur les annonces ou les vues et les conversions (mesure de la conversion).

Introduction

L'API Attribution Reporting permet de mesurer quand un clic sur une annonce ou une vue entraîne une conversion sur un site d'annonceur, comme une vente ou une inscription. L'API ne repose pas sur des cookies ou des mécanismes tiers pouvant être utilisés pour identifier les utilisateurs individuels sur les sites.

Cette proposition est développée de manière ouverte. La proposition et les discussions se trouvent dans le référentiel GitHub WICG.


Cette API fait partie de Privacy Sandbox, une série de propositions visant à répondre aux cas d'utilisation de tiers sans cookies tiers ou autres mécanismes de suivi intersites. Consultez les propositions de Privacy Sandbox.

Pourquoi cette API est-elle nécessaire ?

Aujourd'hui, la mesure des conversions publicitaires repose souvent sur des cookies tiers. Les navigateurs restreignent l'accès aux cookies tiers, car ils peuvent être utilisés pour effectuer le suivi des utilisateurs sur tous les sites et entraver la confidentialité des utilisateurs. Cette API permet ces mesures de manière à préserver la confidentialité, sans cookies tiers.

Qui doit avoir connaissance de cette API ?

  • Les plates-formes de technologie publicitaire (adtech), telles que les plates-formes côté demande (Demand Side Platform, DSP) ou les plates-formes de gestion de données (Data Management Platform, DMP) peuvent utiliser cette API pour prendre en charge des fonctionnalités qui reposent actuellement sur des cookies tiers.
  • Les annonceurs et les éditeurs qui s'appuient sur un code personnalisé pour la publicité ou la mesure des conversions peuvent utiliser cette API pour remplacer les techniques existantes.
  • Les annonceurs et les éditeurs qui s'appuient sur des plates-formes de technologie publicitaire pour mesurer les conversions n'ont pas besoin d'utiliser l'API directement, mais peuvent être intéressés à la comprendre s'ils travaillent avec des plates-formes de technologie publicitaire pouvant intégrer l'API.

Déboguer les erreurs d'API avec les outils pour les développeurs Chrome

Disponible à partir de Chrome 93. Les erreurs de l'API Attribution Reporting sont désormais signalées dans les outils pour les développeurs sous l'onglet Issues.

Erreurs de l'API Attribution Reporting dans l'onglet Issues

Participer


Votre participation est nécessaire ! Cette API peut avoir besoin de prendre en charge une grande variété de cas d'utilisation de mesure de conversion et d'optimisation. La contribution de l'écosystème est vitale pour garantir que les solutions permettant de prendre en charge ces cas d'utilisation soient discutées ouvertement.

Pour participer, rejoignez la discussion et essayez l'API. Faire les deux est optimal, mais vous pouvez participer à la discussion, que vous ayez ou non testé l'API.

Rejoindre le débat

  • Participez aux réunions bimensuelles (toutes les deux semaines). Dans ces appels, les participants discutent des propositions de conception d'API et de la manière dont l'API pourrait prendre en charge divers cas d'utilisation de mesure. Vous pouvez ajouter des sujets à l'ordre du jour de la prochaine réunion à tout moment. Tout le monde est le bienvenu pour participer à ces discussions, assurez-vous seulement de rejoindre le référentiel WICG.
  • Ouvrez un ticket pour poser des questions, proposer des fonctionnalités ou discuter de cas d'utilisation. Si vous ne savez pas comment formuler votre problème, consultez des exemples comme ce problème et ce problème. Vous pouvez également rejoindre la conversation dans les problèmes existants.

Tester l'API

Caution

Si vous testez l'API dans Chrome, vous aurez accès à toutes les fonctionnalités actuellement implémentées. Toutes les fonctionnalités discutées dans le référentiel et les réunions ne sont pas implémentées dans la phase d'évaluation de Chrome. Consultez l'état actuel de la fonctionnalité dans État. Les fonctionnalités disponibles pour l'expérimentation sont également un sous-ensemble de ce qui sera finalement pris en charge par l'API, et sont susceptibles de changer à mesure que l'API est développée de manière ouverte et que les commentaires de l'écosystème sont collectés.

Expérimentez localement ou avec une démo

  1. Pour activer l'API localement dans votre navigateur, activez l'indicateur #enable-experimental-web-platform-features. Un indicateur Chrome est une bouton qui permet d'indiquer à votre navigateur d'activer ou de désactiver certaines fonctionnalités expérimentales. Pour activer cet indicateur, collez chrome://flags/#enable-experimental-web-platform-features dans la barre de recherche de Chrome et cliquez sur Activer.
  2. Exécutez la démo localement (ou testez la démo en direct).
  3. Dupliquez le code de démonstration et personnalisez-le, ou créez votre propre démo à partir de zéro.

Expérimentez avec des utilisateurs finaux sur un site déployé

  1. Activez l'API pour les utilisateurs finaux en vous inscrivant à une phase d'évaluation si disponible. Cela vous permet d'accéder aux fonctionnalités expérimentales et de créer des fonctionnalités que vous pouvez essayer pendant une durée limitée. Notez que les phases d'évaluation tiers permettent à des acteurs tiers tels que des fournisseurs de services de publicité et de mesure de tester une API sur plusieurs sites. Pour voir les phases d'évaluation actuellement disponibles pour cette API, rendez-vous sur État. Pour être informé des futures phases d'évaluation, rejoignez la liste de diffusion Attribution Reporting pour les développeurs.

  2. Intégrez l'API dans vos sites et systèmes.


Si vous avez des questions sur l'implémentation, rejoignez la liste de diffusion Attribution Reporting pour les développeurs.

Si vous avez des questions techniques générales sur votre cas d'utilisation, envisagez d'ouvrir un ticket sur le référentiel d'assistance au développement Privacy Sandbox.

Démo

Il est possible de tester quelques démos.

Cas d'utilisation et fonctionnalités

Cette API est un travail en cours et évoluera au fil du temps, en fonction des commentaires et des contributions de l'écosystème.

Toutes les fonctionnalités prises en charge par cette API sont des propositions. Chacune de ces propositions est ouverte à la discussion et aux commentaires, y compris celles pour lesquelles une implémentation initiale du navigateur est prête.

Cette API est incubée et développée de manière ouverte. Pensez à participer à la discussion.

Cette API permet aux sites de mesurer les conversions dans les cas suivants :

  • Clics sur une annonce et vues.
  • Annonces dans un iframe tiers , telles que les annonces sur un site d'éditeur qui utilise un fournisseur de technologie publicitaire tiers.
  • Annonces dans un contexte propriétaire, telles que des annonces sur un réseau social ou une page de résultats de moteur de recherche, ou un éditeur diffusant ses propres annonces.

Un modèle d'attribution flexible est pris en charge. Consultez les détails dans État.

Cette API donne accès à différents types d'insights via deux types de rapports qui peuvent être envoyés à un annonceur ou à un fournisseur de technologie publicitaire tiers. Ces deux types de rapports peuvent être utilisés simultanément : ils sont complémentaires.

Les rapports basés sur les événements associent un clic sur une annonce ou une vue à des données de conversion approximatives.

rapport basé sur les événements
Exemple de rapport basé sur les événements : un clic sur l'ID 200400600 sur news.example (associé à l'ID utilisateur Bob_Doe sur news.example) a conduit à un achat sur shop.example.

Les rapports basés sur les événements sont adaptés aux cas suivants :

  • Cas d'utilisation d'optimisation : les rapports basés sur les événements aident à répondre à des questions telles que "Comment améliorer mon retour sur investissement ?". En particulier, ils peuvent être utilisés pour optimiser l'emplacement des annonces, car un identifiant unique pour le côté annonce peut être mis à disposition dans les rapports. Les rapports basés sur les événements peuvent fournir des données d'entraînement pour les modèles d'apprentissage automatique.
  • Cas d'utilisation de rapports approximatifs : lorsque très peu d'informations sont nécessaires sur la conversion. La limitation actuelle est de 3 bits de données de conversion pour les clics, ce qui signifie qu'une conversion peut se voir attribuer l'une des huit catégories et 1 bit pour les vues. L'encodage de données granulaires de conversion, telles qu'un prix ou une durée de conversion spécifique, n'est donc pas pris en charge dans les rapports basés sur les événements.
  • Cas d'utilisation de détection de fraude : les données de certains rapports peuvent être utiles pour la détection et l'analyse de la fraude publicitaire, en vous permettant de comprendre les modèles qui peuvent être utilisés pour identifier les activités de spam ou non valides.

Les rapports agrégés, en revanche, offrent des données de conversion plus détaillées et plus de flexibilité pour associer les données de clic/d'affichage et les données de conversion.

rapport global
Exemple d'insights issus de rapports agrégés : l'ID de campagne 1234567 sur news.example a généré 518 conversions sur shoes.example, et une dépense totale de 38 174 $. La moitié des conversions provenaient d'utilisateurs de New York, aux États-Unis.

Les rapports agrégés sont les mieux adaptés pour signaler des cas d'utilisation. Ils aident à répondre à des questions telles que "Quel est mon retour sur investissement ?".
L'utilisation de rapports agrégés pour les cas d'utilisation d'optimisation, par exemple pour optimiser une valeur d'achat qui n'est pas prise en charge par les rapports basés sur les événements car les données de conversion sont trop approximatives, est un domaine de recherche active. Consultez les questions ouvertes.



Pourquoi deux types de rapports sont-ils nécessaires ?

Les rapports basés sur les événements ne proposent que des données de conversion approximatives afin de préserver la confidentialité des utilisateurs.

Mais ces données approximatives peuvent ne pas être suffisantes pour mesurer l'efficacité d'une campagne. Les spécialistes du marketing peuvent avoir besoin d'obtenir des informations sur les conversions, telles que la valeur d'achat, les données démographiques agrégées côté annonceur pour les utilisateurs qui ont effectué une conversion, les catégories de produits achetés, si les utilisateurs ayant effectué une conversion sont des nouveaux clients ou des récurrents, le contenu des paniers, etc.

C'est pourquoi les rapports agrégés ont été conçus.

Les autres fonctionnalités proposées dans cette API sont l'attribution app-to-web (voir ou cliquer sur une annonce dans une application et effectuer une conversion sur le Web) et l'attribution multi-appareils (voir ou cliquer sur une annonce sur mobile et effectuer une conversion sur ordinateur).


Dans un futur sans cookies tiers, cette API serait combinée à d'autres API publicitaires préservant la confidentialité afin de couvrir les cas d'utilisation de bout en bout :

  • Remarketing : voir FLEDGE
  • Sélection d'annonces basées sur les centres d'intérêt : voir FLoC

État

🕙 Dernière mise à jour : août 2021

États :

  • 🤿 Under exploration (en cours d'exploration) : cette idée est aux premiers stades de discussion.
  • 🥚 Proposal (proposition) : un premier design est prêt et en incubation publique.
  • 🏗️ Under development (BROWSER_NAME) (en cours de développement): la fonctionnalité est en cours d'implémentation dans BROWSER_NAME.
  • 🧪 Experiment (BROWSER_NAME) (tests) : une version de test est disponible dans BROWSER_NAME. Dans Chrome, une version de test s'appelle une phase d'évaluation.
  • 🚀 Stable (BROWSER_NAME) : la fonctionnalité est livrée par défaut dans BROWSER_NAME.

Caution


Des phases d'évaluation multiples (expériences) seront effectuées. Chaque version est utilisée pour améliorer et ajuster l'API en fonction des commentaires de l'écosystème.

PropositionStatut
Rapports basés sur les événements pour les clics
Explication
🧪 Experiment (Chrome)
Rapports basés sur les événements pour les vues
Explication
🏗️ Under development (Chrome)
Rapports agrégés pour les clics et les vues
Explication
🥚 Proposal
Parcours de conversion : multi-appareils
Explication
🥚 Proposal
Parcours de conversion : app-to-web
Explication
🥚 Proposal
Modèle d'attribution : dernier clic
Explication
🧪 Experiment (Chrome)
Modèle d'attribution : basé sur les priorités
Explication
🏗️ Under development (Chrome)
Modèle d'attribution : flexible🤿 Under exploration

À propos des modèles d'attribution

Avec le modèle basé sur la priorité, le navigateur peut associer une priorité à chaque source d'attribution. Cela peut être utilisé pour :

  • Décider si un clic ou une vue était la cause la plus probable de la conversion (un clic est généralement considéré comme un signal plus direct de l'intérêt de l'utilisateur).
  • Définir un modèle d'attribution au premier contact, en définissant attributionsourcepriority comme étant relative au temps.
  • Définir un modèle d'attribution linéaire (probabiliste), en choisissant la priorité uniformément au hasard.

D'autres modèles d'attribution pourraient être pris en charge à l'avenir. Dans les rapports agrégés, le schéma basé sur les worklets permet éventuellement des options d'attribution plus flexibles, notamment en spécifiant un crédit partiel pour plusieurs sources d'attribution précédentes.

Prise en charge du navigateur

Bien que les deux API soient différentes, Chrome et WebKit travaillent ensemble de manière ouverte pour simplifier l'expérience des développeurs, par exemple en s'alignant sur les noms d'attributs et sur la structure JSON pour les rapports.



Différences entre l'API proposée par Chrome et l'API proposée par WebKit


L'ensemble de fonctionnalités de l'API Attribution Reporting proposé par Chrome est différent de celui de l'API Private Click Measurement proposée par Safari/WebKit.
Notamment, avec l'API Attribution Reporting proposée par Chrome :

  • La mesure après affichage est prise en charge.
  • Des rapports basés sur les événements peuvent être fournis.
  • Les liens d'annonces dans un contexte propriétaire (comme des annonces sur un réseau social ou une page de résultats de moteur de recherche, ou un éditeur diffusant ses propres annonces) et des liens d'annonces dans un iFrame tiers (comme des annonces sur un site d'éditeur qui utilise un fournisseur de technologie publicitaire tiers) sont pris en charge.
  • Les tiers, tels que les plates-formes de technologie publicitaire, peuvent recevoir des rapports au nom des éditeurs et des annonceurs.

Fonctionnement

Rapports basés sur les événements

rapport basé sur les événements
Les rapports basés sur les événements sont générés comme suit : le navigateur fait correspondre les clics ou les vues ("événements de source d'attribution") avec les données de conversion ("données de déclenchement d'attribution") définies par une technologie publicitaire. Ensuite, le navigateur envoie les rapports résultants à un point de terminaison prédéfini, avec un certain délai et du bruit.



Fonctionnement en détail : rapports basés sur les événements


Les liens d'annonces peuvent être configurés avec des attributs spécifiques aux conversions publicitaires :

Remarque : il est également possible d'enregistrer une source d'attribution pour les navigations initiées par window.open() ou pour les vues, via une API JavaScript.

Lorsque l'utilisateur clique ou voit une annonce spécialement configurée, le navigateur sur l'appareil local de l'utilisateur enregistre cet événement, ainsi que les données de configuration d'attribution qui ont été spécifiées.

Ensuite, l'utilisateur visite le site web de l'annonceur et effectue une action que l'annonceur ou son fournisseur de technologie publicitaire identifie comme une conversion, par exemple un achat. Lorsque cela se produit, l'annonceur ou le fournisseur de technologie publicitaire déclenche une attribution : il demande au navigateur d'enregistrer une conversion avec une certaine valeur trigger-data, et le clic sur l'annonce (ou la vue) et l'événement de conversion sont mis en correspondance par le navigateur de l'utilisateur.

Pour finir, le navigateur planifie un rapport à envoyer au point de terminaison spécifié du côté de l'annonce. Ce rapport comprend :

Si plusieurs conversions sont enregistrées pour un clic sur une annonce donné (ou une vue), les rapports correspondants sont planifiés pour être envoyés. Un seul rapport peut être envoyé pour les vues et jusqu'à trois rapports pour les clics.

Les rapports sont envoyés par le navigateur après un délai de plusieurs jours ou parfois semaines après une conversion.

Rapports agrégés

ALT_TEXT_HERE
Les rapports agrégés sont générés comme suit : le navigateur met en correspondance les clics ou les vues détaillés ("événements de source d'attribution") avec des données de conversion détaillées ("données de déclenchement d'attribution") définies par une technologie publicitaire. Le code défini par technologie publicitaire s'exécute dans un worklet pour définir les contributions qui seront envoyées par le navigateur afin d'être utilisées pour calculer des rapports agrégés. Les services d'agrégation sont responsables du calcul privé des rapports agrégés pour la technologie publicitaire.



Fonctionnement en détail : rapports agrégés

Les liens d'annonces peuvent être configurés avec des attributs spécifiques aux conversions publicitaires.

Lorsque l'utilisateur clique ou voit une annonce spécialement configurée, le navigateur sur l'appareil local de l'utilisateur enregistre cet événement, ainsi que les données de configuration d'attribution qui ont été spécifiées.

Le code défini par technologie publicitaire est ensuite exécuté dans un worklet pour définir les contributions, à savoir les jointures des données côté annonce et côté conversion.

Ces contributions (rapports bruts) sont envoyées chiffrées à un serveur de technologie publicitaire, puis à des services d'agrégation qui calculeront les rapports agrégés de manière privée.

Notez que les rapports agrégés ne sont pas retardés dans la même mesure que les rapports basés sur les événements.

Confidentialité

Aperçu

Prenons l'exemple d'une personne nommée Bob. Bob voit une annonce en lisant les actualités sur news.com. Une semaine plus tard, Bob achète des chaussures sur shoes.example.

Aujourd'hui, cette conversion serait suivie par un cookie tiers utilisé comme identifiant intersites. Avec les cookies tiers, une entreprise de technologie publicitaire peut accéder à de nombreux détails sur l'activité de Bob sur news.example et shoes.example, et fusionner ces informations pour créer un profil détaillé de Bob. Une entreprise de technologie publicitaire peut ainsi découvrir la localisation de Bob, ses habitudes de navigation et ses thèmes préférés sur news.com, {nbsp}ainsi que ses achats, son activité et ses informations de carte de crédit sur shoes.com. Cette jointure intersites est utile pour mesurer les conversions publicitaires, mais cela entrave la confidentialité des utilisateurs : l'activité de Bob est suivie sur des sites avec un niveau d'informations élevées.

D'autre part, l'API Attribution Reporting permet aux agences de publicité d'obtenir des informations sur les conversions sans suivre l'activité d'un individu sur les sites. Une petite quantité d'informations est jointe entre les sites, assez pour mesurer les conversions, mais pas assez pour suivre en détail l'activité de Bob sur les sites. L'activité de Bob sur news.example et sur shoes.example reste distincte.

Diagramme : vue côte à côte du web d'aujourd'hui (identité jointe) et du web de demain (identité partitionnée)

En détail

ALT_TEXT_HERE
Contrairement aux cookies tiers, l'API Attribution Reporting fournit des informations sans identifiants intersites afin de préserver le partitionnement des identités par site.
Les rapports basés sur les événements associent un identifiant côté annonce avec seulement une petite quantité de données côté conversion. Ils fournissent donc des informations intersites sur une conversion, mais les informations côté conversion sont trop approximatives pour joindre l'identité de l'utilisateur sur tous les sites.
Les rapports agrégés fournissent des informations détaillées, mais uniquement à un niveau agrégé. En raison des techniques de confidentialité différentielles, du calcul privé et de la cryptographie, les rapports agrégés ne peuvent pas être utilisés pour suivre l'activité d'un utilisateur individuel sur plusieurs sites.
Des protections supplémentaires de la confidentialité, telles que des limitations de débit, sont imposées à la fois aux rapports basés sur les événements et aux rapports agrégés.



En détail : rapports basés sur les événements et confidentialité

Les rapports basés sur les événements fournissent des informations sur les conversions sans suivre les utilisateurs sur les sites, grâce aux mécanismes de confidentialité suivants :


Il est possible de récupérer le véritable nombre de conversions tout en préservant la confidentialité. Consultez l'exemple de script.



En détail : rapports agrégés et confidentialité

Les rapports agrégés associent un événement de clic ou de vue détaillé à des données de conversion détaillées. Cependant, ils fournissent des informations sur les conversions sans suivre les utilisateurs sur les sites grâce aux mécanismes de confidentialité suivants :

Sites et contrôle des utilisateurs

Questions ouvertes

Un certain nombre de questions restent ouvertes et seront résolues au fur et à mesure que l'API est développée de manière ouverte. Nous vous invitons à participer à ces discussions. En particulier :


Cette API combine plusieurs techniques de confidentialité afin d'atteindre la confidentialité et l'utilité. Cela signifie que la limitation des données à 3 bits (ou 1 bit pour les vues) et les autres mécanismes de confidentialité utilisés par cette API sont un moyen pour atteindre un objectif. Ils sont sujets à changement. S'il existe des moyens pour les entreprises de technologie publicitaire d'obtenir des données plus utiles pour leurs cas d'utilisation tout en obtenant de solides garanties de confidentialité, cette API évoluera en conséquence.

Last updated: Improve article

We serve cookies on this site to analyze traffic, remember your preferences, and optimize your experience.