Rapports sur l'attribution

Déterminez à quel moment un clic sur une annonce ou une vue génère une conversion, par exemple un achat sur le site d'un annonceur.

À qui cela s'adresse-t-il ?

Cet article présente les principes de base d'Attribution Reporting et explique certains concepts sous-jacents, sans entrer dans les détails techniques.

• Si vous travaillez dans la publicité ou la technologie publicitaire, vous découvrirez comment cette API fournit une fonctionnalité actuellement activée par les cookies tiers. Consultez les cas d'utilisation de l'API, qui expliquent plus en détail comment les rapports sont générés.
• Si vous êtes développeur ou ingénieur logiciel, accédez à la présentation complète du système ou effectuez des tests et participez avec l'API.

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 directement l'API. Vous souhaitez peut-être comprendre le fonctionnement d'Attribution Reporting si votre technologie publicitaire prévoit d'intégrer cette API.

Remarque:À l'avenir, l'API Attribution Reporting pourra proposer des cas d'utilisation sans rapport avec la publicité.

Qu'est-ce que l'API Attribution Reporting ?

Aujourd'hui, la mesure des conversions publicitaires repose souvent sur des cookies tiers. Les navigateurs limitent l'accès aux cookies tiers, car ils peuvent servir à suivre les utilisateurs sur plusieurs sites et entraver la confidentialité des utilisateurs.

L'API Attribution Reporting permet d'effectuer ces mesures en protégeant la confidentialité, sans cookies tiers.

Cette API permet aux annonceurs et aux fournisseurs de technologie publicitaire de mesurer les conversions dans les cas suivants:

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

Si vous ne connaissez pas certains de ces termes ou concepts, consultez le glossaire de la Privacy Sandbox.

Try the API

• Testez en local dans votre navigateur. Définissez un indicateur qui indique au navigateur Chrome d'activer des fonctionnalités expérimentales spécifiques.

Si vous souhaitez tester l'API, accédez à Attribution Reporting: tester et participer.

Remarque:Cette API est en cours d'élaboration et évoluera au fil du temps en fonction des commentaires et des contributions de l'écosystème. Votre contribution permet de garantir que les solutions à différents cas d'utilisation sont discutées. Cette API est en cours d'incubation et de développement à l'ouverture. Envisagez de participer à la discussion.

Modifications apportées à l'API

• Suivez les modifications de l'API.
• Découvrez pourquoi nous prévoyons de proposer l'API Attribution Reporting au cours du premier semestre 2023.

Remarque:Attribution Reporting était auparavant appelée "API de mesure des conversions d'événements". Ce nom a été modifié en 2022, lorsque la portée d'origine au niveau de l'événement a été élargie pour couvrir d'autres cas d'utilisation de la mesure.

Garantie de disponibilité

Proposition	État
Rapports au niveau des événements pour les clics et les vues Explication	Disponible dans Chrome
Rapports agrégables pour les clics et les vues Explication	Disponible dans Chrome
Parcours de conversion: application/Web Explication sur le Web et Explication sur Android Annonce sur la liste de diffusion	Disponible dans Chrome et Android pour la phase d'évaluation
Parcours de conversion: multi-appareil Texte explicatif	Cette proposition a été archivée. Nous ne prévoyons pas de les mettre en œuvre actuellement.
Empêcher les rapports agrégables non valides grâce à la validation des rapports Message explicatif	Prévues dans Chrome au premier semestre 2024
Prise en charge de plusieurs destinations lors de l'enregistrement du code source Bug Chromium	Disponible dans Chrome au 1er trimestre 2023
La liste d'autorisation par défaut pour les autorisations de l'API Attribution Reporting sera conservée * Annonce concernant la liste de diffusion	Disponible dans Chrome au 1er trimestre 2023
Compatibilité avec les clés de déduplication basées sur des filtres pour les rapports agrégables Annonce de la liste de diffusion	Disponible dans Chrome au 1er trimestre 2023
Prise en charge des rapports de réussite de l'enregistrement des sources dans le débogage détaillé Livre de recettes sur le débogage	Disponible dans Chrome au 1er trimestre 2023
Réduire les délais d'agrégation des rapports agrégables Problème GitHub | Présentation mise à jour	Disponible dans Chrome au 2e trimestre 2023
Phase 1 Lite flexible au niveau de l'événement Explication des configurations flexibles au niveau de l'événement	Prévues dans Chrome au 4e trimestre 2023
Phase 2 : flexibilité complète au niveau de l'événement Explication des configurations flexibles au niveau de l'événement	Prévues dans Chrome au 1er trimestre 2024
Assistance pour le débogage d'Attribution Reporting après l'abandon des cookies tiers Rechercher des commentaires sur GitHub	Prévues dans Chrome au premier semestre 2024
Compatibilité avec l'API Attribution Reporting et le service d'agrégation pour Google Cloud Présentation de l'API Attribution Reporting Présentation du service d'agrégation	Disponible dans Chrome au 2e semestre 2023

Remarque:Pour obtenir un aperçu de l'état de toutes les API Privacy Sandbox, consultez le calendrier de la Privacy Sandbox.

Cas d'utilisation et fonctionnalités

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

• Les rapports au niveau des événements associent un clic ou une vue sur une annonce spécifique (côté annonce) aux données concernant la conversion. Les données côté conversion sont très limitées et comportent du bruit (pour un faible pourcentage des cas, des données aléatoires sont envoyées au lieu de rapports réels). Cela préserve la confidentialité des utilisateurs en empêchant une jointure de l'identité d'utilisateur entre les sites. Pour plus de protection de la confidentialité, les rapports ne sont pas envoyés immédiatement.
• Les rapports récapitulatifs ne sont pas liés à un événement spécifique côté annonce. Ces rapports fournissent des données de conversion plus riches et plus fiables que les rapports au niveau des événements. Une combinaison de techniques de confidentialité permet de réduire le risque de jonction d'identité entre les sites.

Rapports au niveau des événements

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

Exemple de rapport au niveau des événements: l'ID de clic 200400600 sur news.example (associé à l'ID utilisateur Bob_Doe sur news.example) a généré un achat le shop.example.

Les rapports au niveau des événements sont adaptés aux éléments suivants:

• Optimisation. Répondez à des questions telles que "Comment puis-je améliorer mon retour sur investissement ?". En particulier, ces rapports peuvent servir à optimiser l'emplacement des annonces, car des identifiants uniques côté annonce peuvent être disponibles dans les rapports. Les rapports au niveau des événements peuvent fournir des données d'entraînement pour les modèles de machine learning.
• Les rapports généraux, qui nécessitent très peu d'informations sur la conversion. La limite actuelle est de 3 bits de données de conversion pour les clics. Cela signifie qu'une conversion peut se voir attribuer l'une des huit catégories suivantes ⏤ et 1 bit pour les vues. Les rapports au niveau des événements ne permettent pas d'encoder des données précises côté conversion (un prix spécifique ou une date et une heure de conversion, par exemple).
• Détection de fraudes : Les données de certains rapports peuvent être utiles pour la détection et l'analyse des fraudes publicitaires, car elles vous permettent de comprendre des modèles permettant d'identifier des activités incorrectes ou du spam.

Rapports de synthèse

Les rapports récapitulatifs (anciennement "rapports globaux") offrent des données de conversion plus détaillées et offrent plus de flexibilité pour associer les données de clic/vue et les données de conversion.

En savoir plus sur les rapports récapitulatifs

Voici un exemple d'insights issus des rapports récapitulatifs: l'ID de campagne 1234567 pour le news.example a généré 518 conversions le shoes.example, pour des dépenses totales de 38 174 $. La moitié des conversions provenaient d'utilisateurs de New York (États-Unis).

Les rapports de synthèse sont particulièrement adaptés aux cas d'utilisation de création de rapports. Ils permettent de répondre à des questions telles que: "Quel est mon retour sur investissement ?".

L'utilisation de rapports récapitulatifs pour l'optimisation (par exemple, pour optimiser la valeur des achats, ce qui n'est pas possible dans les rapports au niveau des événements (car les données de conversion sont trop approximatives)) est un domaine de recherche actif.

Autres fonctions

Cette API offre également d'autres fonctionnalités:

• Attribution Application/Web : consultez ou cliquez sur une annonce dans une application et effectuez une conversion sur le Web.
• Attribution multi-appareil : consultez ou cliquez sur une annonce sur un mobile, puis effectuez une conversion sur ordinateur.

Remarque:Dans le futur, sans cookies tiers, cette API sera combinée à d'autres API publicitaires protégeant la confidentialité pour couvrir les cas d'utilisation de bout en bout : - Remarketing: consultez l'API Protected Audience - Sélection d'annonces par centres d'intérêt: consultez Topics

Prise en charge des navigateurs

• Firefox et Edge n'ont pas partagé de signaux.
• Safari/Webkit est négatif et a proposé une autre API pour mesurer les conversions des annonces, appelée Mesure des clics privés.

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

Bien que les deux API soient différentes, Chrome et WebKit collaborent de façon ouverte pour simplifier l'expérience des développeurs, par exemple en harmonisant les noms d'attributs et la structure JSON des rapports.

Les fonctionnalités de l'API Attribution Reporting sont différentes de celles de l'API Private Click Measurement proposée par Safari/WebKit. avec l'API Attribution Reporting, en particulier:

• La mesure des conversions après affichage est acceptée.
• Des rapports au niveau des événements peuvent être fournis.
• Les rapports de synthèse contiennent des informations détaillées sur les clics/vues et les conversions.
• Les tiers tels que les plates-formes ad tech peuvent recevoir des rapports pour le compte des éditeurs et des annonceurs.

Configuration du navigateur

• Les utilisateurs peuvent désactiver l'API dans les paramètres utilisateur sur chrome://settings/adPrivacy.
• L'API n'est pas active en mode navigation privée.
• L'API n'est pas active lorsque les cookies tiers sont désactivés.

Remarque:L'API ne s'appuie pas sur des cookies tiers. Toutefois, pendant la phase de test, les cookies tiers doivent être activés pour activer l'API. Cela permet aux développeurs d'obtenir des rapports de débogage et de comparer les résultats de l'API avec l'attribution basée sur les cookies.

Comment les sites peuvent-ils contrôler l'accès ?

Si l'API est disponible dans un navigateur donné, elle l'est par défaut sur tous les sites, à la fois dans les documents et scripts de premier niveau, ainsi que dans les iFrames de même origine.

Les tiers arbitraires (par exemple, des iFrames d'annonces multi-origines qui n'ont pas été ajoutés à la page via un script disposant d'un accès de niveau supérieur) ne peuvent pas utiliser l'API à l'insu de l'éditeur ou de l'annonceur. Dans ces iFrame, l'API Attribution Reporting doit être explicitement activée via les Règles sur les autorisations.

<iframe src="..." allow="attribution-reporting"></iframe>

Les tiers disposant d'un accès de premier niveau qui ajoutent des iFrame multi-origines à une page peuvent également activer l'API Attribution Reporting via les règles d'autorisation.

Remarque : ### Avantages en termes de sécurité Ainsi, un script avec un accès de niveau supérieur autorise les frames qu'il ajoute lui-même à utiliser Attribution Reporting. Seul un script tiers approuvé par le site doit bénéficier d'un accès de niveau supérieur. Ce n'est donc pas un problème. Le principal avantage de la stratégie en termes de sécurité réside ailleurs: les frames ajoutés sans script de niveau supérieur ne doivent pas être approuvés par défaut pour enregistrer des sources ou des déclencheurs (sauf si leur intégrateur est déjà approuvé). C'est pourquoi le site de premier niveau doit activer explicitement l'API pour ces iFrames.

Un site peut désactiver l'API Attribution Reporting pour toutes les parties, y compris les scripts avec un accès de niveau supérieur, en envoyant l'en-tête de réponse HTTP:

Permissions-Policy: attribution-reporting=()

Comment fonctionne l'API Attribution Reporting ?

L'API Attribution Reporting permet de mesurer deux événements associés: un événement sur le site Web d'un éditeur (par exemple, un utilisateur qui voit une annonce ou clique dessus), et une conversion ultérieure sur le site d'un annonceur.

Remarque:L'API Attribution Reporting peut ne pas être adaptée aux besoins de facturation au coût par conversion, en raison du bruit ajouté aux rapports au niveau des événements et aux rapports récapitulatifs. N'hésitez pas à nous faire part de vos commentaires sur l'impact de l'API Attribution Reporting sur GitHub.

Rapports au niveau des événements

Les rapports au niveau des événements sont générés comme suit:
Le navigateur met en correspondance les clics ou les vues avec les données de conversion définies par une technologie publicitaire.
Plus tard, le navigateur envoie les rapports obtenus à un point de terminaison prédéfini, avec un certain délai et du bruit.

Rapports de synthèse

Génération de rapports récapitulatifs

Les rapports de synthèse sont générés comme suit:

• Un internaute clique sur une annonce spécialement configurée ou la voit. Le navigateur, sur l'appareil local de l'utilisateur, enregistre cet événement, ainsi que les données de configuration d'attribution prédéfinies.
• Par la suite, lorsque l'utilisateur effectue une conversion, le navigateur met en correspondance cet événement de clic ou de vue détaillé (appelé événement de source d'attribution) aux données de conversion détaillées (données du déclencheur d'attribution). Les dimensions de détail capturées sont prédéfinies par une société de technologie publicitaire, et le navigateur suit une logique spécifique définie par cette technologie. Le navigateur génère ces données dans un rapport agrégable.
• Les rapports agrégables sont chiffrés par le navigateur et envoyés à un serveur de technologie publicitaire. À partir du serveur de technologie publicitaire, les rapports agrégables sont envoyés au service d'agrégation pour générer un rapport récapitulatif.
• Les rapports de synthèse sont ensuite mis à la disposition de la technologie publicitaire. Notez que les rapports de synthèse ne sont pas retardés de la même manière que les rapports au niveau des événements.

En savoir plus sur les rapports récapitulatifs

Confidentialité

Contrairement aux cookies tiers, l'API Attribution Reporting permet aux entreprises publicitaires d'obtenir des insights sur les conversions sans suivre l'activité d'un individu sur les sites.

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

Aujourd'hui, le suivi de cette conversion serait effectué par un cookie tiers utilisé comme identifiant intersite. Grâce aux cookies tiers, une entreprise de technologie publicitaire peut accéder à de nombreux détails sur l'activité de Bob Marley sur news.example et shoes.example. La technologie publicitaire peut fusionner ces informations pour créer un profil détaillé de Bob, y compris l'emplacement de Bob, ses habitudes de navigation et ses lectures préférées sur news.example. Ce profil peut également inclure les achats, l'activité et les informations de carte de crédit sur shoes.example. Cette jointure intersite est utile pour mesurer les conversions d'annonces. Mais cela compromet la confidentialité des utilisateurs : l'activité de Bob est suivie sur plusieurs sites avec un niveau de détail élevé.

Une petite quantité d'informations est jointe entre les sites : suffisamment 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.

Protections dans chaque type de rapport

Les rapports au niveau des événements associent un identifiant côté annonce à une petite quantité de données côté conversion. Bien qu'elles fournissent des informations intersites sur une conversion, les informations côté conversion sont trop imprécises pour joindre l'identité des utilisateurs entre les sites.

Les rapports récapitulatifs fournissent des insights détaillés, mais uniquement au niveau agrégé. Étant donné que le contenu de ces rapports agrégables est chiffré lorsqu'ils sont envoyés à la technologie publicitaire, celle-ci ne peut pas obtenir d'informations des rapports sans utiliser de service d'agrégation. Le service d'agrégation ne fournit un accès qu'aux agrégats comportant du bruit.

D'autres protections de la confidentialité, telles que les limites de débit, sont appliquées aux rapports globaux et au niveau des événements.

En détail: rapports au niveau des événements et confidentialité

Les rapports au niveau des événements fournissent des insights sur les conversions sans suivre les utilisateurs sur les sites, en suivant les mécanismes de confidentialité suivants:

• Aucun identifiant intersite n'est utilisé, et aucune activité de navigation détaillée sur plusieurs sites ne quitte l'appareil.
• Les rapports au niveau des événements associent 64 bits d'informations côté annonce (news.example) à 1 bit ou 3 bits uniquement côté conversion (shop.example). 64 bits sont suffisants pour être mappés à un identifiant d'utilisateur individuel, mais ces 64 bits ne peuvent être liés qu'à de très faibles informations intersites: 1 bit ou 3 bits, qui ne suffisent pas pour contenir un identifiant.
  • Les 64 bits côté annonce ne sont pas des informations nouvelles. Un ID utilisateur peut déjà être disponible côté annonce. news.example ou adtech.example connaissent déjà l'activité d'un utilisateur sur news.example.
• Des protections supplémentaires sont appliquées pour éviter les abus et le suivi intersites :
  • L'envoi des rapports est différé.
  • Les données de conversion sont bruites: un certain pourcentage du temps, de faux rapports sont générés.
  • Le nombre de rapports sur les conversions attribuées est limité par clic ou par vue.

En détail: rapports récapitulatifs et confidentialité

Les rapports récapitulatifs associent un événement de clic ou de vue à des données de conversion détaillées. Ils fournissent des insights sur les conversions sans suivre les utilisateurs d'un site à l'autre, grâce aux mécanismes de confidentialité suivants:

• Aucun identifiant intersites n'est utilisé.
• Chaque attribution peut apporter plusieurs contributions à un rapport récapitulatif qui en résulte. Tout utilisateur peut déclencher plusieurs attributions pour un clic (ou une vue) et une conversion spécifiques.
• Les données sont agrégées au niveau de nombreux événements (nombreux utilisateurs), et aucun événement individuel ne peut être observé avec précision. Lorsque vous examinez les données agrégées, plus le niveau de détail augmente, plus le bruit relatif sur ces données augmente. Les segments de données qui regroupent un grand nombre d'événements et d'utilisateurs sont plus précis afin de préserver leur utilité.
• Les rapports bruts qui associent un événement de clic ou de vue détaillé à des données de conversion détaillées sont chiffrés et ne sont pas lisibles par l'entreprise de technologie publicitaire. Ces données ne peuvent être lues que par le service d'agrégation.
• Des protections supplémentaires sont appliquées pour éviter les abus et le suivi intersites :
  • Les rapports sont envoyés avec des retards aléatoires.
  • Les requêtes portant sur différentes tranches de données sont limitées en débit.

Interagir et partager des commentaires

• Pour toute question concernant l'API : signalez un problème dans le dépôt de l'API.
• Suivez les mises à jour et les annonces de l'API dans la liste de diffusion Attribution Reporting.
• Si vous avez des questions techniques, signalez un bug Chromium.
• Pour les questions sur l'implémentation, l'intégration et les bonnes pratiques générales : créez un problème dans le dépôt de l'assistance pour les développeurs de la Privacy Sandbox.