Plusieurs modifications ont été apportées à la proposition Attribution Reporting pour répondre aux commentaires de la communauté, comme la modification du mécanisme d'API et l'ajout de nouvelles fonctionnalités.
Journal des modifications
- 7 février 2022: ajout d'une section sur la redirection du déclencheur d'en-tête.
- 27 janvier 2022: premier article publié.
À qui s'adresse ce post ?
Ce post est pour vous:
- Si vous comprenez déjà l'API, par exemple si vous avez observé ou participé aux discussions sur le dépôt WICG et que vous souhaitez comprendre le lot de modifications apportées à la proposition en janvier 2022.
- Vous utilisez l'API Attribution Reporting dans une version de démonstration ou un test en production.
Si vous débutez avec cette API et/ou si vous ne l'avez pas encore testée, consultez plutôt la présentation de l'API.
Migration à venir
Une fois ces modifications implémentées dans Chrome: si vous utilisez les rapports au niveau des événements de l'API Attribution Reporting dans une version de démonstration ou un test en production (phase d'évaluation), vous devrez modifier votre code pour que l'API continue de fonctionner. Vous pouvez également envisager d'utiliser les nouvelles fonctionnalités.
Cet article présente également les modifications apportées aux rapports agrégables. Toutefois, si ces modifications sont mises en œuvre, elles ne nécessitent aucune action ni migration, car il n'existe pas encore de mise en œuvre de navigateur pour les rapports agrégables au moment de la rédaction de ce document.
Changements de noms
Rapports de synthèse et rapports agrégables
Les rapports agrégés sont désormais appelés rapports récapitulatifs.
Les rapports récapitulatifs sont le résultat final de l'agrégation de plusieurs rapports agrégables (anciennement "contributions" ou "contributions à l'histogramme").
Modifications apportées au mécanisme de l'API
Enregistrement de la source basé sur les en-têtes (rapports au niveau des événements)
Qu'est-ce qui change et pourquoi ?
Lorsque l'utilisateur voit une annonce ou clique dessus, le navigateur enregistre cet événement (localement sur son appareil), ainsi que les paramètres propres aux rapports sur l'attribution (tels que attributionsourceeventid, attributiondestination, attributionexpiry et d'autres paramètres). Les valeurs de ces paramètres sont définies par la technologie publicitaire.
La manière dont ces paramètres sont définis évolue.
Dans la proposition précédente, les paramètres devaient être inclus côté client: soit dans les balises d'ancrage en tant qu'attributs HTML, soit en tant qu'arguments d'un appel JS. Les paramètres devaient être connus au moment du clic ou de la vue.
Dans la nouvelle proposition, la valeur de ces paramètres est définie sur le serveur de technologie publicitaire.
Cela présente de nombreux avantages, notamment en termes de sécurité: le mécanisme d'en-tête donne à l'origine du rapport (généralement une technologie publicitaire) un contrôle direct sur l'enregistrement d'une source d'attribution dans son champ d'application. Cela réduit partiellement les risques de fraude, car avec ce changement, un véritable navigateur n'enregistrera jamais de source sans l'activation de l'origine des rapports.
Comment fonctionne l'enregistrement de la source ?
- Pour une annonce donnée, la technologie publicitaire doit maintenant définir un attribut côté client spécifique
attributionsrc. La valeur de cet attribut est une URL à laquelle le navigateur enverra une requête. Cette requête inclut un nouvel en-tête HTTPAttribution-Reporting-Source-Infodont la valeur,navigationouevent,, indique si la source était respectivement un clic ou une vue. - À la réception de cette requête, le serveur de suivi des clics/vues doit répondre avec un en-tête HTTP,
Attribution-Reporting-Register-Source, contenant les paramètres d'attribution souhaités. L'origine qui renvoie cet en-tête est désormais l'origine du rapport (anciennement
attributionreportto).En-tête de réponse HTTP
Attribution-Reporting-Register-Source:{ "source_event_id": "267630968326743374", "destination": "https://toasters.example", "expiry": "604800000" }
En savoir plus dans la vidéo explicative technique
Enregistrer des sources d'attribution
Participer à la discussion publique
Déclencheur d'attribution basée sur les en-têtes (rapports au niveau des événements)
Qu'est-ce qui change et pourquoi ?
Tout comme l'enregistrement des clics ou des vues, la nouvelle proposition modifie le déclencheur d'attribution (lorsqu'une technologie publicitaire demande au navigateur d'enregistrer une conversion) en une approche basée sur l'en-tête.
Ce mécanisme est aligné sur l'enregistrement de la source basé sur l'en-tête et est plus conventionnel que le mécanisme de redirection utilisé précédemment.
De plus, dans la nouvelle proposition, l'attribut attributionsrc est nécessaire sur la page de conversion.
Le raisonnement est lié aux autorisations: dans la proposition précédente, le site côté déclencheur (généralement, un site d'annonceur) disposait d'un contrôle général sur la fonctionnalité via un en-tête Permissions-Policy, mais ne disposait pas d'un contrôle précis au niveau de l'élément pour déterminer si un élément pouvait envoyer une requête à une partie qui déclencherait finalement une attribution. attributionsrc change cette situation: ce repère obligatoire permet à l'annonceur de surveiller, et donc de contrôler les éléments pouvant déclencher une attribution.
Notez que du côté source (généralement un site d'éditeur), une commande sur l'ensemble de la page via Permissions-Policy et une commande à l'échelle de l'élément via attributionsrc sont présentes.
Comment le déclencheur d'attribution fonctionne-t-il ?
Lorsqu'elle reçoit une demande de pixel et décide qu'elle doit être classée en tant que conversion, une technologie publicitaire doit répondre avec un nouvel en-tête HTTP
Attribution-Reporting-Register-Event-Trigger.
La valeur de cet en-tête indique comment traiter l'événement déclencheur en tant qu'objet JSON. Il s'agit des mêmes informations que celles définies comme paramètres de requête dans la proposition précédente.
En-tête de réponse HTTP Attribution-Reporting-Register-Event-Trigger:
[{
trigger_data: (unsigned 3-bit integer),
trigger_priority: (signed 64-bit integer),
deduplication_key: (signed 64-bit integer)
}]
Redirection (facultatif)
Le serveur de technologie publicitaire peut éventuellement générer la réponse contenant Attribution-Reporting-Register-Event-Trigger comme réponse de redirection.
Cela permet aux tiers d'observer l'événement de conversion et de demander au navigateur de l'attribuer.
La redirection est facultative. Elle n'est pas nécessaire lorsqu'une technologie publicitaire et un tiers comportent des pixels sur la page.
Pour en savoir plus, consultez Rapports tiers.
En savoir plus dans la vidéo explicative technique
Participer à la discussion publique
Aucun worklet (rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Dans la proposition précédente concernant les rapports agrégables, un accès JavaScript était nécessaire pour appeler un worklet (un mécanisme basé sur JavaScript) qui générerait ces rapports.
Dans la nouvelle proposition, aucun worklet n'est requis. À la place, une technologie publicitaire définirait de manière déclarative (à l'aide d'en-têtes HTTP) les règles que le navigateur doit utiliser pour générer des rapports agrégables.
Cette nouvelle proposition offre plusieurs avantages:
- Implémentation via le navigateur:contrairement à la conception des Worklet, la nouvelle conception est nettement plus simple, car elle ne nécessite pas de nouvel environnement d'exécution dans les navigateurs.
- Expérience du développeur:la nouvelle conception repose sur des en-têtes, qui sont couramment utilisés et largement connus par les développeurs, contrairement aux Worklets. De plus, elle s'aligne étroitement avec la surface de l'API pour l'enregistrement de la source, ce qui facilite l'apprentissage et l'utilisation de l'API.
- Adoption:le nouveau design permet à davantage de systèmes de mesure existants d'utiliser des rapports agrégables. De nombreuses solutions de mesure ne fonctionnent qu'avec HTTP: elles reposent sur des requêtes d'image (requêtes de pixels) qui ne nécessitent pas d'accès JavaScript. Toutefois, comme l'approche des Worklet nécessitait un accès JavaScript, la migration de certains systèmes de mesure existants a pu être difficile.
- Robustesse:la nouvelle conception permet d'atténuer la perte de données, car il est plus facile d'intégrer la sémantique
keepalive, par exemple si un clic ou une vue sont enregistrés lorsqu'un utilisateur quitte une page.
Comment fonctionne le mécanisme sans worklet ?
Ce mécanisme déclaratif est basé sur des en-têtes HTTP, tout comme l'enregistrement de la source au niveau de l'événement et l'en-tête du déclencheur d'attribution. Vous trouverez plus de détails à ce sujet dans les sections suivantes.
Participer à la discussion publique
Enregistrement de la source basé sur les en-têtes (rapports agrégables)
Un nouveau mécanisme est proposé afin d'enregistrer une source pour un rapport agrégable. Ce mécanisme est identique à l'enregistrement de la source au niveau de l'événement.
Seul le nom de l'en-tête est différent: Attribution-Reporting-Register-Aggregatable-Source.
En savoir plus dans la vidéo explicative technique
Enregistrement de la source d'attribution
Déclencheur d'attribution basée sur les en-têtes (rapports agrégables)
Un nouveau mécanisme est proposé afin d'enregistrer une source pour un rapport agrégable. Ce mécanisme est identique au déclencheur d'attribution au niveau de l'événement.
Seul le nom de l'en-tête est différent: Attribution-Reporting-Register-Aggregatable-Trigger-Data.
En savoir plus dans la vidéo explicative technique
Enregistrement du déclencheur d'attribution
Nouvelles fonctionnalités
Rapports tiers (rapports au niveau des événements et rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Deux aspects de la nouvelle proposition permettent de mieux prendre en charge les cas d'utilisation de la création de rapports tiers:
- Les technologies publicitaires peuvent éventuellement rediriger les requêtes réseau vers d'autres serveurs de technologies publicitaires, ce qui permet à ces autres technologies publicitaires d'effectuer leurs propres enregistrements de la source et de déclenchement. C'est une façon courante de configurer les tiers aujourd'hui. Cela facilite l'adoption de l'API, par exemple dans les systèmes de création de rapports tiers existants.
- Les origines des rapports (généralement les technologies publicitaires) ne partagent plus la plupart des limites de confidentialité. Cela est possible dans les cas d'utilisation où plusieurs technologies publicitaires travaillent avec les mêmes éditeurs ou annonceurs.
Comment fonctionnent les rapports tiers ?
Dans la nouvelle proposition, l'enregistrement de la source basée sur les réponses et le déclencheur reposent sur des en-têtes HTTP. Une technologie publicitaire peut exploiter les redirections HTTP pour ces requêtes.
Si une demande de clic/vue sur le site d'un éditeur (enregistrement de la source) est ensuite redirigée vers plusieurs parties, chacune d'elles peut enregistrer cette vue ou ce clic (événement source).
De même, une technologie publicitaire peut rediriger une demande d'attribution spécifique effectuée à partir d'un site d'adivertiseur, ce qui permet à plusieurs autres parties d'enregistrer une conversion (déclencheur d'attribution).
Chaque partie peut accéder à ses propres rapports et les configurer avec des données distinctes.
Enregistrer plusieurs déclencheurs sans redirection
Vous pouvez également enregistrer plusieurs déclencheurs d'attribution sans utiliser de redirections, en ajoutant plusieurs éléments de pixel du côté conversion (un par déclencheur).
Participer à la discussion publique
Mesure des conversions après affichage (rapports au niveau des événements et rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Dans la nouvelle proposition, la mesure des conversions après affichage et la mesure des clics fonctionnent de manière unifiée:
registerattributionsrc, l'attribut spécifique à une vue demandant au navigateur d'enregistrer des vues avec les clics, ne fait plus partie de la proposition.- Les mécanismes de confidentialité sont désormais unifiés pour les vues et les clics. Pour en savoir plus, consultez la section Bruit et transparence.
Cette modification est proposée pour s'aligner sur le nouveau mécanisme d'enregistrement basé sur l'en-tête. Il simplifie également l'expérience des développeurs lorsqu'ils souhaitent permettre la mesure des clics et des conversions après affichage.
Comment fonctionne la mesure des conversions après affichage ?
La mesure des conversions après affichage et des clics est basée sur l'enregistrement par en-tête.
En savoir plus dans la vidéo explicative technique
Rapports au niveau des événements (pour les clics et les vues)
Participer à la discussion publique
Débogage / Analyse des performances (rapports au niveau des événements et rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Un mécanisme de débogage a été ajouté à la proposition pour aider les développeurs à détecter les bugs et à comparer les performances d'Attribution Reporting avec celles des solutions de mesure existantes basées sur les cookies.
Comment fonctionne le débogage ?
L'enregistrement de la source et du déclencheur accepte un nouveau paramètre debug_key, un entier non signé de 64 bits (c'est-à-dire un nombre élevé).
Si un rapport est créé avec des clés de débogage pour la source et le déclencheur, et si un cookie Samesite=None ar_debug=1 est présent dans le fichier de cookies de l'origine du rapport à la source et au moment de l'enregistrement du déclencheur, un rapport de débogage (JSON) est envoyé à un point de terminaison .well-known/attribution-reporting/debug:
{
"source_debug_key": 1234567890987,
"trigger_debug_key": 4567654345028
}
Les rapports au niveau des événements et les rapports agrégables incluront également ces deux nouveaux paramètres, afin qu'ils puissent être associés au rapport de débogage approprié.
En savoir plus dans la vidéo explicative technique
Facultatif: rapports de débogage étendus
Participer à la discussion publique
Fonctionnalités de filtrage (rapports au niveau des événements et rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Étant donné qu'ils répondent à des cas d'utilisation importants dans l'écosystème publicitaire actuel, un certain nombre de ces cas d'utilisation seront désormais pris en charge dans les rapports au niveau des événements et dans les rapports agrégables:
- Filtrage des conversions:filtrez une conversion en fonction des informations côté source. Par exemple, sélectionnez différentes données de déclencheur (données de conversion) pour les vues et les clics sur les annonces.
- Attribution incohérente:filtrez les conversions qui ont été mal attribuées. Il s'agit d'un type spécifique de filtrage des conversions. Par exemple, filtrez les conversions qui sont mises en correspondance avec le mauvais clic ou la mauvaise vue d'annonce en raison du champ d'application de la destination etld+1 dans l'API.
Comment fonctionnent les fonctionnalités de filtrage ? (pour les rapports au niveau des événements)
Un champ source_data facultatif dans l'objet JSON côté source peut définir des éléments qui seront ensuite utilisés par le navigateur au moment de la conversion pour appliquer la logique de filtrage.
{
source_event_id: "267630968326743374",
destination: "https://toasters.example",
expiry: "604800000"
source_data: {
conversion_subdomain: ["electronics.megastore"
"electronics2.megastore"],
product: "198764",
// Note that "source_type" will be automatically generated as one of {"navigation", "event"}
}
}
L'enregistrement du déclencheur accepte désormais un en-tête facultatif Attribution-Reporting-Filters.
En-tête de réponse HTTP Attribution-Reporting-Filters:
{
"conversion_subdomain": "electronics.megastore",
"directory": "/store/electronics"
}
Vous pouvez également étendre l'en-tête Attribution-Reporting-Register-Event-Trigger avec un champ filters pour effectuer un filtrage sélectif afin de définir trigger_data en fonction de source_data.
Si les clés dans les filtres JSON correspondent à des clés dans source_data, le déclencheur est
complètement ignoré si l'intersection est vide.
En savoir plus dans la vidéo explicative technique
Filtres d'attribution facultatifs
Participer à la discussion publique
Modifications apportées à la protection de la confidentialité
Bruit et transparence (rapports au niveau des événements et rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Dans la nouvelle proposition, l'un des mécanismes de confidentialité pour les rapports a été amélioré: les rapports sont soumis à une réponse aléatoire.
Cela signifie que certaines conversions réelles seront comptabilisées correctement et qu'un certain pourcentage du temps, certaines conversions réelles seront supprimées ou de fausses conversions seront ajoutées.
Cette nouvelle technique présente plusieurs avantages:
- Elle unifie le mécanisme de confidentialité pour les clics et les vues.
- C'est plus simple qu'un mécanisme où les données du déclencheur (données de conversion) et le bruit du lien source du déclencheur sont séparés.
- Elle définit un framework de confidentialité qui pourrait, avec des paramètres de bruit adaptés, garantir qu'aucune partie ne puisse s'appuyer sur l'API pour savoir avec certitude qu'un utilisateur a effectué (ou non) une conversion pour une annonce donnée.
Ce nouveau mécanisme remplace le précédent, où les données de déclenchement (données de conversion) étaient remplacées par une valeur aléatoire 5% du temps.
De plus, la valeur de probabilité de réponse aléatoire a été ajoutée au corps du rapport (champ randomized_trigger_rate). Ce champ spécifie la probabilité (0 à 1) qu'une source soit soumise à une réponse aléatoire.
Cela présente deux avantages principaux:
- Cela rend le comportement sous-jacent du navigateur transparent pour les parties qui recevront les rapports (généralement, les technologies publicitaires).
- Cela est utile pour une future compatibilité de l'API avec plusieurs navigateurs: différents navigateurs peuvent décider d'appliquer différents niveaux de bruit en fonction de leurs objectifs de confidentialité, et les parties qui traiteront le rapport auront besoin de visibilité à ce sujet.
Comment fonctionne le bruit ?
Dans la nouvelle proposition, au moment où une source est enregistrée (c'est-à-dire qu'un clic sur une annonce ou une vue est enregistré), le navigateur détermine de manière aléatoire s'il attribuera fidèlement les conversions et enverra des rapports pour ce clic ou cette vue d'annonce, ou s'il générera un faux résultat à la place.
La sortie fictive peut être:
- Aucun rapport, que l'utilisateur effectue ou non une conversion
- Un ou plusieurs rapports falsifiés, que l'utilisateur effectue ou non une conversion.
Dans les rapports falsifiés, les données du déclencheur (données de conversion) sont aléatoires: une valeur aléatoire de 3 bits pour les clics (tout nombre compris entre 0 et 7) et une valeur aléatoire de 1 bit pour les vues (0 ou 1).
Comme pour les rapports réels, les faux rapports ne sont pas envoyés immédiatement après la conversion d'un utilisateur. Ils sont envoyés à la fin d'une période de rapport aléatoire.
Les rapports peuvent porter sur les clics à trois jours (deux jours, sept jours ou 30 jours après le clic). Chaque faux rapport est attribué de manière aléatoire à l'une des périodes de référence.
Par ailleurs, comme indiqué dans la proposition précédente, l'ordre des rapports au cours d'une même fenêtre est aléatoire.
En savoir plus dans la vidéo explicative technique
Exemples de fausses conversions avec bruit
Participer à la discussion publique
Limites concernant les rapports (rapports au niveau des événements et rapports agrégables)
Limites applicables aux origines de création de rapports
Qu'est-ce qui change et pourquoi ?
La nouvelle proposition limite explicitement le nombre de parties pouvant mesurer des événements entre deux sites.
- Le nombre maximal d'origines de création de rapports uniques (généralement des technologies publicitaires) pouvant enregistrer des sources par {publisher, advertiser} est limité à 100 par période de 30 jours. Ce compteur est incrémenté pour chaque clic sur une annonce ou vue (événement source), même pour ceux qui ne sont pas attribués.
- Le nombre maximal d'origines de création de rapports uniques (généralement des technologies publicitaires) pouvant envoyer des rapports par {publisher, advertiser} est limité à 10 par période de 30 jours. Ce compteur est incrémenté pour chaque conversion attribuée.
Ces limites sont censées être suffisamment élevées pour ne pas limiter la capacité d'un acteur à mesurer les conversions, mais suffisamment basses pour aider à atténuer certaines formes d'utilisation abusive des API.
Délai de création des rapports / Limites de débit
Qu'est-ce qui change et pourquoi ?
La période d'attente des rapports est un mécanisme de confidentialité qui limite la quantité totale d'informations envoyées via cette API pendant une période donnée pour un utilisateur.
Dans la nouvelle proposition, vous pouvez planifier 100 rapports par {site source, destination, origine des rapports} (généralement {publisher, advertiser, adtech}) sur 30 jours.
Au-delà de cette limite, le navigateur cesse de planifier les rapports correspondant à {source site, destination, reporting origin} (généralement {publisher, advertiser, adtech}) jusqu'à ce que le nombre de rapports glissants sur 30 jours soit inférieur à 100 pour {source site, destination, reporting origin}.
En savoir plus dans la vidéo explicative technique
Délai d'application des rapports / Limites de débit
Limitation de la destination (rapports au niveau des événements uniquement)
Qu'est-ce qui change et pourquoi ?
La limitation de la destination est modifiée pour inclure l'origine du rapport (généralement une technologie publicitaire) dans le champ d'application: 100 destinations en attente uniques (généralement des sites d'annonceurs ou des sites sur lesquels des conversions sont censées avoir lieu) sont autorisées par {publisher, adtech}.
Cette fonctionnalité de protection de la confidentialité permet de limiter la reconstruction de l'historique de navigation.
En savoir plus dans la vidéo explicative technique
Limiter le nombre de destinations uniques couvertes par les sources en attente
Toutes les ressources
- Consultez Attribution Reporting.
- Lisez Ce que vous devez savoir sur l'API.
L'image d'en-tête provient de Diana Polekhina sur Unsplash.