La proposition de rapports sur l'attribution a subi un certain nombre de modifications pour répondre aux commentaires de la communauté, allant des modifications du mécanisme d'API aux 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: article publié pour la première fois.
À qui s'adresse ce post ?
Cet article s'adresse à 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).
- Si vous utilisez l'API Attribution Reporting dans une démonstration ou dans un test en production.
Si vous débutez avec cette API et/ou que vous ne l'avez pas encore testée, passez directement à la présentation de l'API.
Migration à venir
Une fois ces modifications implémentées dans Chrome: si vous utilisez des rapports au niveau des événements de l'API Attribution Reporting dans une démonstration ou dans un test en production (essai d'origine), vous devrez modifier votre code pour que l'API continue de fonctionner. Vous pouvez également envisager d'utiliser les nouvelles fonctionnalités.
Cet article liste également les modifications apportées aux rapports agrégables. Toutefois, si ces modifications sont implémentées, aucune action ni migration ne sera requise, car aucune implémentation dans le navigateur n'est encore disponible pour les rapports agrégables au moment de la rédaction de cet article.
Changements de noms
Rapports récapitulatifs et rapports agrégables
Les rapports agrégés, que vous avez peut-être déjà vus, 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 appelés contributions ou contributions d'histogramme.
Modifications apportées au mécanisme de l'API
Enregistrement de la source basé sur l'en-tête (rapports au niveau des événements)
Qu'est-ce qui change et pourquoi ?
Lorsque l'utilisateur regarde une annonce ou clique dessus, le navigateur (localement sur l'appareil de l'utilisateur) enregistre cet événement, ainsi que les paramètres spécifiques aux rapports sur l'attribution (comme les paramètres attributionsourceeventid, attributiondestination, attributionexpiry et d'autres). Les valeurs de ces paramètres sont définies par la technologie publicitaire.
La façon 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 basé sur 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 adtech.
Cela présente un certain nombre d'avantages, notamment en termes de sécurité: le mécanisme d'en-tête donne à l'origine des rapports (généralement une technologie publicitaire) un contrôle direct sur l'enregistrement d'une source d'attribution dans leur champ d'application. Cela atténue partiellement les problèmes de fraude, car avec ce changement, un navigateur authentique n'enregistrera jamais une source sans l'activation de l'origine des rapports.
Comment fonctionne l'enregistrement de sources ?
- Pour une annonce donnée, la technologie publicitaire doit désormais 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 inclura un nouvel en-tête HTTPAttribution-Reporting-Source-Infodont la valeur,navigationouevent,, indique si la source était un clic ou une vue, respectivement. - À 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, qui contient les paramètres d'attribution souhaités. L'origine qui renvoie cet en-tête est désormais l'origine des rapports (anciennement définie comme
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é sur l'en-tête (rapports au niveau des événements)
Qu'est-ce qui change et pourquoi ?
Tout comme pour l'enregistrement des clics ou des vues, la nouvelle proposition remplace le déclencheur d'attribution (lorsque la technologie publicitaire demande au navigateur d'enregistrer une conversion) par une approche basée sur les en-têtes.
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.
La raison en est une question d'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 de la fonctionnalité via un en-tête Permissions-Policy, mais ne pouvait pas contrôler de manière précise, au niveau de l'élément, si un élément pouvait envoyer une requête à un tiers qui déclencherait finalement une attribution. attributionsrc change cela: ce repère obligatoire permet à l'annonceur de surveiller et donc de contrôler les éléments pouvant déclencher une attribution.
Notez que côté source (généralement un site d'éditeur), un contrôle à l'échelle de la page via Permissions-Policy et un contrôle à l'échelle de l'élément via attributionsrc sont présents.
Comment fonctionne le déclencheur d'attribution ?
Lorsqu'une technologie publicitaire reçoit une requête de pixel et décide qu'elle doit être classée comme conversion, elle doit répondre avec un nouvel en-tête HTTP Attribution-Reporting-Register-Event-Trigger.
La valeur de cet en-tête spécifie comment traiter l'événement de déclencheur en tant qu'objet JSON. Il s'agit des mêmes informations qui ont été 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 adtech peut éventuellement faire de la réponse contenant Attribution-Reporting-Register-Event-Trigger une réponse de redirection.
Cela permet aux tiers d'observer l'événement de conversion et d'indiquer au navigateur de l'attribuer.
La redirection est facultative. Elle n'est pas nécessaire lorsque des pixels d'une technologie publicitaire et d'un tiers sont présents sur la page.
Pour en savoir plus, consultez la section Rapports tiers.
En savoir plus dans la vidéo d'explication technique
Participer à la discussion publique
Aucun worklet (rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Dans la proposition précédente de rapports agrégables, l'accès JavaScript était nécessaire pour appeler un worklet (un mécanisme basé sur JavaScript) qui générait ces rapports.
Dans la nouvelle proposition, aucun worklet n'est requis. Au lieu de cela, une technologie publicitaire définirait de manière déclarative (via des en-têtes HTTP) les règles que le navigateur doit utiliser pour générer des rapports agrégables.
La nouvelle proposition présente plusieurs avantages:
- Implémentation dans le navigateur:contrairement à la conception des worklets, la nouvelle conception est beaucoup plus simple, car elle ne nécessite pas de nouvel environnement d'exécution dans les navigateurs.
- Expérience pour les développeurs:la nouvelle conception repose sur des en-têtes, qui sont couramment utilisés et largement connus par les développeurs, contrairement aux worklets. Il s'aligne également étroitement sur la surface de l'API pour l'enregistrement de la source, ce qui facilite l'apprentissage et l'utilisation de l'API.
- Adoption:la nouvelle conception permet à davantage de systèmes de mesure existants d'utiliser des rapports agrégables. De nombreuses solutions de mesure sont uniquement HTTP: elles reposent sur des requêtes d'image (requêtes de pixel) qui ne nécessitent pas d'accès JavaScript. Toutefois, comme l'approche de travaillet nécessitait un accès JavaScript, il a peut-être été difficile de migrer vers certains systèmes de mesure existants.
- Robustesse:la nouvelle conception permet de limiter la perte de données, car elle est plus facile à intégrer à la sémantique
keepalive, par exemple si un clic ou une vue est enregistré 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 en saurez plus dans les sections suivantes.
Participer à la discussion publique
Enregistrement de la source basé sur l'en-tête (rapports agrégables)
Un nouveau mécanisme est proposé pour enregistrer une source pour un rapport agrégable. Il s'agit du même mécanisme que l'enregistrement de source au niveau des événements.
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é sur l'en-tête (rapports agrégables)
Un nouveau mécanisme est proposé pour enregistrer une source pour un rapport agrégable. Il s'agit du même mécanisme que le déclencheur d'attribution au niveau des événements.
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 des 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 leur propre enregistrement de source et de déclencheur. Il s'agit d'une méthode courante de configuration des tiers aujourd'hui. Cela facilite l'adoption de l'API, entre autres 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 permet de prendre en charge 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 et le déclencheur basés sur les réponses reposent sur les en-têtes HTTP. Une technologie publicitaire peut utiliser des redirections HTTP pour ces requêtes.
Si une requête de clic/d'affichage sur un site d'éditeur (enregistrement de la source) est ensuite redirigée vers plusieurs parties, chacune de ces parties peut enregistrer cette vue ou ce clic (événement source).
De même, une technologie publicitaire peut rediriger une requête d'attribution spécifique effectuée à partir d'un site d'annonceur, ce qui permet à plusieurs autres parties d'enregistrer une conversion (déclencheur d'attribution).
Chaque partie peut accéder à ses rapports distincts et les configurer avec des données distinctes.
Enregistrer plusieurs déclencheurs sans redirections
Vous pouvez également enregistrer plusieurs déclencheurs d'attribution sans utiliser de redirections, en ajoutant plusieurs éléments de pixel côté conversion (un par déclencheur).
Participer à la discussion publique
Mesure des vues (rapports au niveau des événements et rapports agrégables)
Qu'est-ce qui change et pourquoi ?
Dans la nouvelle proposition, les mesures des vues et des clics fonctionnent de manière unifiée:
registerattributionsrc, l'attribut spécifique à la vue qui indiquait au navigateur d'enregistrer les vues avec les clics, n'est plus inclus dans la proposition.- Les mécanismes de confidentialité sont désormais unifiés pour les clics et les vues. 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 prendre en charge à la fois la mesure des clics et des vues.
Comment fonctionne la mesure des conversions après affichage ?
La mesure des conversions après affichage et la mesure des conversions après clic reposent toutes deux sur l'enregistrement basé sur l'en-tête.
En savoir plus dans la vidéo d'explication 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, ainsi qu'à comparer les performances des rapports sur l'attribution aux solutions de mesure basées sur les cookies existantes.
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é 64 bits (c'est-à-dire un grand nombre).
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 cookie jar de l'origine du rapport au moment de l'enregistrement de la source et 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 agrégables incluront également ces deux nouveaux paramètres afin qu'ils puissent être associés au bon rapport de débogage.
En savoir plus dans la vidéo d'explication 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 prennent en charge des cas d'utilisation importants dans l'écosystème publicitaire actuel, un certain nombre de cas d'utilisation seront désormais pris en charge à la fois 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 clics et les vues sur les annonces.
- Incohérences d'attribution:filtrez les conversions qui ont été attribuées de manière incorrecte. Il s'agit d'un type spécifique de filtrage des conversions. Par exemple, filtrez les conversions associées au mauvais clic/visionnage d'annonce en raison de la portée 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 une 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 Attribution-Reporting-Filters facultatif.
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 du fichier JSON des filtres correspondent aux clés de source_data, le déclencheur est complètement ignoré si l'intersection est vide.
En savoir plus dans la vidéo d'explication 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é des rapports a été amélioré: les rapports sont soumis à une réponse aléatoire.
Cela signifie que certaines conversions réelles seront correctement enregistrées. Dans un certain pourcentage de cas, certaines conversions réelles seront supprimées ou de fausses conversions seront ajoutées.
Cette nouvelle technique présente plusieurs avantages:
- Il unifie le mécanisme de confidentialité pour les clics et les vues.
- Il est plus simple à appréhender qu'un mécanisme dans lequel les données de déclencheur (données de conversion) et le bruit de liaison entre le déclencheur et la source seraient séparés.
- Elle configure un cadre de confidentialité qui pourrait, avec les paramètres de bruit appropriés, garantir qu'aucune partie ne peut s'appuyer sur l'API pour savoir avec certitude qu'un utilisateur individuel a converti (ou non) pour une certaine annonce.
Ce nouveau mécanisme remplace le mécanisme précédent, dans lequel 5% du temps, les données de déclencheur (données de conversion) étaient remplacées par une valeur aléatoire.
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:
- Il 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 l'avenir, lorsque l'API sera compatible avec tous les 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 géreront 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 ou une vue sur une annonce est enregistré), le navigateur décide de manière aléatoire s'il attribuera des conversions de manière véridique et enverra des rapports pour ce clic/vue sur une annonce, ou s'il générera plutôt une sortie factice.
La fausse sortie peut être:
- Aucun rapport, que l'utilisateur ait effectué une conversion ou non ;
- Un ou plusieurs faux rapports, que l'utilisateur effectue ou non une conversion.
Dans les faux rapports, les données de déclencheur (données de conversion) sont aléatoires: une valeur aléatoire de 3 bits pour les clics (n'importe quel nombre compris entre 0 et 7) et une valeur aléatoire de 1 bit pour les vues (0 ou 1).
Comme les rapports réels, les faux rapports ne sont pas envoyés immédiatement après la conversion de l'utilisateur. Ils sont envoyés à la fin d'un intervalle de création de rapports aléatoire.
Trois périodes de référence sont disponibles pour les clics (deux, sept 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 dans une période est aléatoire.
En savoir plus dans la vidéo d'explication technique
Exemples de faux conversions bruyantes
Participer à la discussion publique
Limites des rapports (rapports au niveau des événements et rapports agrégables)
Limites des origines de création de rapports
Qu'est-ce qui change et pourquoi ?
La nouvelle proposition limite explicitement le nombre de parties pouvant mesurer les événements entre deux sites.
- Nous proposons de limiter le nombre maximal d'origines de création de rapports uniques (généralement des technologies publicitaires) pouvant enregistrer des sources par {publisher, advertiser} à 100 par période de 30 jours. Ce compteur est incrémenté pour chaque clic ou vue sur une annonce (événement source), même ceux qui ne sont pas attribués.
- Nous proposons de limiter le nombre maximal d'origines de création de rapports uniques (généralement des technologies publicitaires) pouvant envoyer des rapports par {publisher, advertiser} à 10 par période de 30 jours. Ce compteur sera incrémenté pour chaque conversion attribuée.
Ces limites doivent être suffisamment élevées pour ne pas limiter la capacité de mesure des conversions de n'importe quel acteur, mais suffisamment faibles pour atténuer certaines formes d'abus d'API.
Limites de débit / temps de récupération des rapports
Qu'est-ce qui change et pourquoi ?
Le délai de refroidissement des rapports est un mécanisme de confidentialité qui limite la quantité totale d'informations envoyées via cette API au cours d'une période donnée pour un utilisateur.
Dans la nouvelle proposition, 100 rapports par {site source, destination, origine des rapports} (généralement {éditeur, annonceur, technologie publicitaire}) peuvent être planifiés sur 30 jours.
Au-delà de cette limite, le navigateur cesse de planifier les rapports correspondant à ce {site source, destination, origine des rapports} donné (généralement {éditeur, annonceur, technologie publicitaire}), jusqu'à ce que le nombre de rapports sur 30 jours glissants tombe en dessous de 100 pour ce {site source, destination, origine des rapports}.
En savoir plus dans la vidéo explicative technique
Temps de récupération / Limites de débit des rapports
Plafonnement des destinations (rapports au niveau des événements uniquement)
Qu'est-ce qui change et pourquoi ?
Le plafonnement des destinations est modifié pour inclure l'origine des rapports (généralement une technologie publicitaire) dans le champ d'application: 100 destinations uniques en attente (généralement des sites d'annonceurs ou des sites où des conversions sont attendues) sont autorisées par {publisher, adtech}.
Il s'agit d'une mesure de protection de la confidentialité visant à 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 Rapports sur l'attribution.
- Consultez Ce que vous devez savoir sur l'API.
L'image de l'en-tête est de Diana Polekhina sur Unsplash.