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
Developer Relations Engineer for security/privacy, Chrome and web
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".
- 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.
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
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
- 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, collezchrome://flags/#enable-experimental-web-platform-featuresdans la barre de recherche de Chrome et cliquez sur Activer. - Exécutez la démo localement (ou testez la démo en direct).
- 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é
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.
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.
Rapports basés sur les événements, clics uniquement :
- Démo en direct.
- Code source de cette démo, que vous pouvez dupliquer et personnaliser selon vos besoins.
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.
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.
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 :
É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.
Phase d'évaluation actuelle (test Chrome)
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.
| Proposition | Statut |
|---|---|
| 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
À 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
attributionsourceprioritycomme é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
- Firefox et Edge n'ont pas partagé de signaux.
- Safari/Webkit ne prend pas en charge et propose une API différente pour mesurer les conversions publicitaires, appelée Private Click Measurement.
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
