Mises à jour des propositions Attribution Reporting en janvier 2022

Plusieurs modifications ont été apportées à la proposition Attribution Reporting sur les commentaires de la communauté, qu'il s'agisse de modifications du mécanisme d'API ou de nouvelles fonctionnalités.

Journal des modifications

À qui s'adresse ce post ?

Ce post est pour vous:

  • Si vous comprenez déjà l'API, par exemple, si vous avez observé ou aux discussions sur le référentiel WICG et nous voulons comprendre le lot modifications apportées à la proposition en janvier 2022.
  • Si vous utilisez l'API Attribution Reporting dans le cadre d'une démonstration ou d'un test en production.

Si vous débutez avec cette API et/ou si vous n'avez pas encore testé cette API, allez directement vers Présentation de l'API à la place.

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 démonstration ou dans 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 répertorie également les modifications apportées aux rapports agrégables. Cependant, s'ils sont implémentés, ces modifications ne nécessitent aucune action ni migration, car il n'existe pas encore d'implémentation dans un navigateur pour les rapports agrégables au moment de la rédaction de ce document.

Changements de noms

Rapports récapitulatifs et rapports agrégables

Les rapports globaux seront désormais appelés sous forme de rapports récapitulatifs.

Les rapports récapitulatifs sont le résultat final de l'agrégation de plusieurs rapports agrégables. auparavant appelés "contributions" ou "contributions d'histogramme".

Modifications apportées aux mécanismes d'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). parallèlement aux paramètres propres aux rapports sur l'attribution (tels que attributionsourceeventid, attributiondestination, attributionexpiry et d'autres paramètres). La 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 ou en tant qu'arguments d'un appel JS. Les paramètres devaient être connus au moment du clic ou de la vue en temps réel.

Dans la nouvelle proposition, la valeur de ces paramètres est définie sur le serveur de technologie publicitaire.

Diagramme de l'enregistrement de la source basée sur l'en-tête

Cela présente un certain nombre d'avantages, notamment en termes de sécurité: le mécanisme d'en-tête permet aux rapports l'origine (généralement une technologie publicitaire) : contrôle direct de l'enregistrement d'une source d'attribution dans ses le champ d'application. Cela atténue partiellement les problèmes de fraude. En effet, avec ce changement, un navigateur authentique enregistrer une source sans l'activation de l'origine du rapport.

Comment l'enregistrement des sources fonctionne-t-il ?

  1. Pour une annonce donnée, la technologie publicitaire doit maintenant définir un attribut spécifique côté client attributionsrc La valeur de cet attribut est une URL à laquelle le navigateur enverra un requête ; cette requête inclura un nouvel en-tête HTTP Attribution-Reporting-Source-Info dont navigationou event,indique si la source était un clic ou une vue, respectivement.
  2. À la réception de cette demande, le serveur de suivi des clics/vues doit répondre avec un code en-tête, Attribution-Reporting-Register-Source, qui contient l'attribution souhaitée paramètres.

  3. L'origine qui renvoie cet en-tête est désormais l'origine de création de rapports (auparavant 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

Problème 261

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 d'un clic ou d'une vue, la nouvelle proposition modifie le déclencheur d'attribution. Lorsqu'un La technologie publicitaire indique au navigateur d'enregistrer une conversion selon 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 plus classique que le mécanisme de redirection précédemment utilisé.

De plus, dans la nouvelle proposition, l'attribut attributionsrc est nécessaire sur la page de conversion.

La justification est une question d'autorisations: dans la proposition précédente, le site côté déclencheur (généralement, le site d'un annonceur (contiennent un contrôle général sur la fonctionnalité via un en-tête Permissions-Policy) ; 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 demande à une partie qui, à terme, déclencheraient une attribution. attributionsrc modifie ceci: ce repère obligatoire permet à l'annonceur de surveiller, et donc de contrôler les éléments pouvant déclencher une l'attribution.

Notez que du côté de la source (généralement le site d'un éditeur) un contrôle sur l'ensemble de la page via Permissions-Policy, ainsi qu'une commande à l'échelle de l'élément via attributionsrc, sont présents.

Comment le déclencheur d'attribution fonctionne-t-il ?

Après avoir reçu une demande de pixel et décidé qu'elle devait être classée en tant que conversion, une technologie publicitaire doit répondre avec un nouveau code HTTP
en-tête 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. C'est la même chose 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 (facultative)

Le serveur de technologie publicitaire peut éventuellement transformer la réponse contenant Attribution-Reporting-Register-Event-Trigger en 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 une tierce partie comportent des pixels sur la page.

Pour en savoir plus, consultez la section Rapports tiers.

En savoir plus dans la vidéo explicative technique

Attribution à l'origine du déclenchement

Participer à la discussion publique

Problème 91

Aucun Worklet (rapports agrégables)

Qu'est-ce qui change, et pourquoi ?

Dans la proposition précédente de rapports agrégables, un accès JavaScript était nécessaire pour appeler un Worklet (mécanisme basé sur JavaScript) qui générerait 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 HTTP en-têtes : règles que le navigateur doit utiliser pour générer des rapports agrégables.

Cette nouvelle proposition offre plusieurs avantages:

  • Implémentation dans le navigateur:contrairement à la conception du Worklet, la nouvelle interface plus simple, car il ne nécessite pas de nouvel environnement d'exécution dans les navigateurs.
  • Expérience du développeur:la nouvelle interface repose sur les en-têtes, qui sont couramment utilisés et largement connus des développeurs, contrairement aux Worklets. De plus, il s'aligne étroitement sur la surface de l'API 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 les données agrégables rapports. De nombreuses solutions de mesure reposent sur des requêtes d'images (pixels) qui ne nécessitent pas d'accès JavaScript. Mais comme l'approche des Worklet nécessitait JavaScript, il a peut-être été difficile de migrer depuis certains systèmes de mesure existants.
  • Fiabilité:la nouvelle conception permet d'atténuer la perte de données, car elle est plus facile à intégrer. avec la sémantique keepalive, par exemple si un clic ou une vue est enregistré lorsqu'un utilisateur quitte le site. une page.

Comment fonctionne le mécanisme d'absence de 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 "Attribution". Vous trouverez plus d'informations à ce sujet dans les sections suivantes.

Participer à la discussion publique

Problème 194

Enregistrement de la source basé sur les en-têtes (rapports agrégables)

Un nouveau mécanisme est proposé pour 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 l'en-tête (rapports agrégables)

Un nouveau mécanisme est proposé pour 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 répondre aux cas d'utilisation de rapports tiers:

  • Les technologies publicitaires peuvent éventuellement rediriger les demandes réseau vers d'autres serveurs de technologies publicitaires, ce qui permet à ces autres d'effectuer leur propre enregistrement de la source et des déclencheurs. C'est une méthode couramment utilisée pour sont configurées aujourd'hui. Cela facilite l'adoption de l'API, par exemple dans les des systèmes de création de rapports tiers.
  • Les origines des rapports (généralement des technologies publicitaires) ne partagent plus la plupart des limites de confidentialité. Cela permet l'utilisation dans les cas où plusieurs technologies publicitaires travaillent avec les mêmes éditeurs ou annonceurs.

Comment les rapports tiers fonctionnent-ils ?

Dans la nouvelle proposition, l'enregistrement de la source et le déclencheur basés sur la réponse reposent sur 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'entre 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 de l'annonceur. 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 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

Problème 91 Problème 261

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, les mesures après affichage et après clic fonctionnent de manière unifiée:

  • registerattributionsrc, l'attribut spécifique à la vue qui indique au navigateur de enregistrer des vues en même temps que les clics, ne fait plus partie de 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 Noise et la transparence.

Cette modification est proposée afin de s'aligner sur le nouveau mécanisme d'inscription basé sur l'en-tête. Il simplifie également l'expérience des développeurs lorsqu'ils souhaitent accepter à la fois les conversions après clic et les conversions après affichage. les mesures.

Comment fonctionne la mesure des conversions après affichage ?

La mesure des conversions après affichage et celle des clics s'appuient toutes deux sur l'enregistrement basé sur l'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

Problème 261

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, comparer les performances d'Attribution Reporting à celles des solutions de mesure existantes basées sur les cookies

Schéma du nouveau système de débogage basé 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 paramètre non signé de 64 bits entier (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ésente dans le fichier "JAR de cookies" de l'origine de création de rapports à la source et lors de l'enregistrement du déclencheur, (JSON) sera 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. associé au bon rapport de débogage.

En savoir plus dans la vidéo explicative technique

Facultatif: rapports de débogage étendus

Participer à la discussion publique

Problème 174

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 sont compatibles avec des cas d'utilisation importants de l'écosystème publicitaire d'aujourd'hui, plusieurs cas d'utilisation est désormais compatible avec les rapports au niveau des événements et les rapports agrégables:

  • Filtrage des conversions:filtrez une conversion en fonction des informations côté source. Pour Par exemple, sélectionnez des données de déclencheur différentes (données de conversion) pour les clics et les vues sur les annonces.
  • Attribution incohérente:filtrez les conversions qui ont été détournées. ceci est 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 destination etld+1 dans l'API.

Comment les fonctionnalités de filtrage fonctionnent-elles ? (pour les rapports au niveau des événements)

Un champ facultatif source_data dans l'objet JSON côté source peut définir des éléments qui seront utilisé 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"
}

L'en-tête Attribution-Reporting-Register-Event-Trigger peut également être étendu avec une Champ filters pour effectuer un filtrage sélectif afin de définir trigger_data en fonction de source_data.

Si les clés des filtres JSON correspondent à celles de 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

Problème 194
Problème 201

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 cette nouvelle proposition, l'un des mécanismes de confidentialité des rapports a été amélioré: les rapports sont en faisant l'objet d'une réponse aléatoire.
Cela signifie que certaines conversions réelles seront enregistrées correctement. et un certain pourcentage 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 de le traiter qu'un mécanisme dans lequel les données du déclencheur (données de conversion) et le bruit de la liaison source du déclencheur seraient 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 peut s'appuyer sur l'API pour savoir avec certitude qu'un utilisateur individuel a effectué (ou non) une conversion pour une annonce donnée.

Ce nouveau mécanisme remplace le précédent qui, dans 5% des cas, déclenche (données de conversion) a été remplacé 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 indique la probabilité (0 à 1) qu'une source soit soumis à une réponse aléatoire.

Cela présente deux avantages principaux:

  • Il rend le comportement du navigateur sous-jacent transparent pour les parties qui reçoivent les rapports. (généralement des technologies publicitaires).
  • Elle s'avère utile lorsque, à l'avenir, l'API sera prise en charge dans différents navigateurs: les différents navigateurs peuvent décider d'appliquer différents niveaux de bruit en fonction objectifs de confidentialité, et les parties qui traiteront le rapport auront besoin de visibilité à ce sujet.

Comment le bruit fonctionne-t-il ?

Dans la nouvelle proposition, au moment où une source est enregistrée (c'est-à-dire qu'une vue ou un clic d'annonce est enregistré), le champ le navigateur détermine de manière aléatoire s'il attribuera les conversions de façon authentique et enverra des rapports pour le nombre de clics ou de vues sur une annonce, ou de générer une fausse sortie.

La sortie fictive peut se présenter comme suit:

  • Aucun rapport du tout, que l'utilisateur effectue une conversion ou non
  • Un ou plusieurs faux rapports, que l'utilisateur effectue une conversion ou non.

Dans les rapports falsifiés, les données du déclencheur (données de conversion) sont aléatoires: il s'agit d'une valeur aléatoire de 3 bits pour les clics (toute (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 rapports falsifiés ne sont pas envoyés immédiatement après la conversion de l'utilisateur. Ils sont envoyés à à la fin d'une période de rapport aléatoire

Il existe trois périodes de référence pour les clics (2 jours, 7 jours ou 30 jours après le clic). Chaque fausse adresse 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 période donnée est aléatoire.

En savoir plus dans la vidéo explicative technique

Exemples de conversions fictives comportant beaucoup de bruit

Participer à la discussion publique

Problème 84
Problème 273

Limites concernant la création de rapports (rapports au niveau des événements et rapports agrégables)

Limites d'origine des 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.

  • Nombre maximal d'origines de reporting uniques (généralement des technologies publicitaires) pouvant être enregistrées Le nombre de sources par {éditeur, annonceur} est proposé de limiter à 100 pour 30 jours. Ce est incrémenté pour chaque clic sur une annonce ou vue (événement source), même ceux qui ne le sont pas attribuée.
  • Nombre maximal d'origines de reporting uniques (généralement des technologies publicitaires) pouvant envoyer des rapports par Il est proposé de limiter {publisher, advertiser} à 10 pour 30 jours. Ce compteur sera pour chaque conversion attribuée.

Ces limites sont censées être suffisamment élevées pour ne limiter la capacité d'aucun acteur à mesurer de conversions, mais suffisamment faibles pour aider à limiter certaines formes d'utilisation abusive des API.

Limitation / Limitation du débit des rapports

Qu'est-ce qui change, et pourquoi ?

La limitation des rapports est un mécanisme de confidentialité qui limite la quantité totale d'informations envoyées via cette API sur une période donnée pour un utilisateur.

Dans la nouvelle proposition, 100 rapports par {site source, destination, origine des rapports} (généralement {publisher, advertiser, adtech}) peut être planifiée sur 30 jours.

Au-delà de cette limite, le navigateur cessera de planifier des rapports qui correspondent à ce {source site, destination, reporting origin} (généralement {publisher, advertiser, adtech}), jusqu'à la fin de la période glissante de 30 jours le nombre de rapports est inférieur à 100 pour ce {site source, destination, origine du rapport}.

En savoir plus dans la vidéo explicative technique

Limitation / Fréquence des rapports

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 uniques destinations en attente (généralement des sites d'annonceurs ou des sites sur lesquels les conversions sont censées durer lieu) sont autorisés par {publisher, adtech}.

Il s'agit d'une protection de la confidentialité afin 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

L'image d'en-tête provient de Diana Polekhina sur Unsplash.