Activer la mesure des conversions

La mesure de l'attribution des conversions peut impliquer plusieurs parties, comme l'éditeur, l'annonceur, la technologie publicitaire de diffusion (l'entité qui diffuse l'annonce), le fournisseur de mesure, etc. Ce document présente des scénarios courants de mesure des conversions. Toutefois, d'une manière générale, toute partie qui souhaite recevoir un rapport sur l'attribution de l'API Attribution Reporting (ARA) doit s'assurer de suivre les étapes d'intégration décrites dans ce document.

Par exemple, il est courant qu'un éditeur dispose d'une ou plusieurs technologies publicitaires pour diffuser l'annonce. Il peut s'agir de parties chargées du balisage de la création, de celles qui fournissent le pixel d'impression ou de suivi pour la création et de celles qui fournissent le SDK ou le tag pour l'espace publicitaire sur la page de l'éditeur. Ces technologies publicitaires peuvent souhaiter ou non recevoir des rapports sur l'attribution de l'ARA, mais elles sont positionnées de manière à garantir que les technologies publicitaires en aval peuvent recevoir des rapports sur l'attribution.

Il est également possible que l'annonceur fasse appel à un fournisseur tiers de mesure des conversions pour l'attribution multiréseau et pour d'autres fonctionnalités de reporting. Les annonceurs utilisent ces données pour comprendre le retour sur investissement publicitaire de plusieurs éditeurs et canaux uniques. Il est donc important que les DSP ou les ad servers comprennent comment activer l'API Attribution Reporting pour prendre en charge ces cas d'utilisation. Les annonceurs qui souhaitent faire appel à un tiers peuvent continuer à le faire, soit en faisant appel à un fournisseur de mesure tiers, soit en configurant un serveur interne pour enregistrer et recevoir les rapports de l'API.

L'API Attribution Reporting permet à plusieurs technologies publicitaires d'enregistrer des sources et des déclencheurs d'attribution pour la même impression ou conversion, et de recevoir des rapports distincts de la part de l'API. Par exemple, une DSP peut recevoir ses propres rapports sur l'attribution de l'API Attribution Reporting et autoriser des rapports distincts pour le fournisseur de mesure tiers de l'annonceur. Une technologie publicitaire doit enregistrer à la fois les sources d'attribution et les déclencheurs pour recevoir des rapports de l'API. L'attribution est effectuée entre les sources d'attribution et les déclencheurs que la technologie publicitaire a enregistrés individuellement auprès de l'API.

Scénarios courants de mesure des conversions

Dans cette section, nous allons examiner deux scénarios courants pour mesurer les conversions.

Scénario 1: La technologie publicitaire de diffusion et le fournisseur de mesure tiers doivent recevoir des rapports de l'API Attribution Reporting

Un annonceur souhaite attribuer des conversions à un inventaire publicitaire à l'aide d'un fournisseur de mesure tiers, tandis que la technologie publicitaire hébergeant la création souhaite attribuer les conversions à l'inventaire publicitaire. Cela est courant pour les DSP ou les ad servers d'annonceurs (ad server tiers) qui fournissent le balisage des créations publicitaires, effectuent leurs propres rapports sur l'attribution et travaillent avec des annonceurs qui intègrent des fournisseurs de solutions de mesure ou d'analyse tiers.

Dans ce cas, la technologie publicitaire de diffusion est également la partie chargée de déclencher les événements de clic et d'impression dans la configuration actuelle. La technologie publicitaire de diffusion doit définir le nouveau attributionsrc aux emplacements appropriés et s'assurer que les redirections sont correctement configurées. En outre, la technologie publicitaire de diffusion et le fournisseur de mesure tiers doivent s'assurer qu'ils sont inscrits, et que leurs serveurs sont prêts à recevoir les requêtes de l'API Attribution Reporting et à y répondre.

Voici un exemple type de configuration de campagne:

  1. L'ad server de l'annonceur fournit à la DSP le balisage de la création publicitaire, qui inclut les pixels de suivi des impressions et des clics du fournisseur tiers de solutions de mesure. L'ad server doit s'assurer que attributionsrc est inclus dans le balisage de la création publicitaire.

  2. La DSP permet d'ajouter des pixels de mesure supplémentaires pour les impressions et le suivi des clics. Elle doit s'assurer que attributionsrc est inclus dans le balisage final des créations publicitaires sur lesquelles il enchérit.

Scénario 2: Seul le fournisseur de solutions de mesure tiers a besoin de recevoir des rapports de l'API Attribution Reporting

Un annonceur souhaite attribuer des conversions à un inventaire publicitaire à l'aide d'un fournisseur de mesure tiers, mais la technologie publicitaire qui héberge la création n'a aucune exigence de mesure de l'attribution. Cela est courant pour les éditeurs, les SSP ou les ad servers d'éditeurs qui hébergent des créations et qui ne prévoient pas d'utiliser les rapports sur l'attribution eux-mêmes, mais qui souhaitent activer l'API Attribution Reporting soit pour leurs DSP partenaires, soit pour les entreprises d'ajout de tags de mesure telles que les ad servers tiers, les fournisseurs de solutions de mesure ou d'analyse.

Dans ce cas, la partie responsable du déclenchement des événements de clic et d'impression dans la configuration actuelle doit ajouter le nouvel attribut attributionsrc aux créations et s'assurer que les redirections fonctionnent comme prévu. Cela dépend fortement de l'intégration de chaque éditeur. Toutefois, pour les événements de clic, il peut s'agir de la SSP, de la technologie publicitaire de diffusion ou de l'éditeur lui-même. Pour les événements d'impression, il s'agit le plus souvent du fournisseur de mesure tiers.

Dans l'exemple de configuration de campagne typique du scénario 1, l'ad server de l'éditeur, la SSP ou l'éditeur lui-même peuvent avoir uniquement besoin de s'assurer que l'attribut attributionsrc fourni par la DSP arrive sur la page de l'éditeur.

Détails de mise en œuvre

Le tableau suivant décrit dans les grandes lignes les étapes d'implémentation de l'API Attribution Reporting:

Étapes Responsabilité du travail Exemples
Étape 1: Activez la source d'attribution pour les créations et le code de mesure existants L'entité responsable du déclenchement des événements d'impression ou de la gestion des événements de clic ajoute l'attribut attributionsrc. Pour les événements de clic, un acheteur (DSP/ad server de l'annonceur) qui diffuse la création ajoute généralement l'attribut.

Pour les événements d'impression, la plate-forme côté demande (DSP), la plate-forme côté offre (SSP), l'éditeur, l'ad server ou un fournisseur de solutions de mesure ajoutent l'attribut. Celui-ci dépend de la configuration de l'éditeur.

Pour les annonces vidéo au format VAST, l'éditeur et le SDK vidéo ajoutent l'attribut.

Étape 2: Activez Attribution Reporting pour les origines tierces Cette solution est prête à l'emploi si vous utilisez un chemin de redirection existant avec des redirections 302.

Si les redirections 302 ne peuvent pas être utilisées, l'attribut attributionsrc peut être utilisé pour répertorier plusieurs serveurs de technologie publicitaire.

En règle générale, tant que l'attribut attributionsrc est ajouté à la création, les redirections tierces doivent recevoir les appels de l'API Attribution Reporting.
Étape 3: Configurez les réponses aux requêtes de l'API Attribution Reporting Toute entité souhaitant recevoir des rapports de l'API Attribution Reporting La DSP et le fournisseur de mesure tiers utilisés par l'annonceur

Notez que les spécificités de chaque étape dépendent de la manière dont les créations sont affichées et diffusées sur la page de l'éditeur, et quelles entités ad tech reçoivent les rapports envoyés par l'API Attribution Reporting.

Étape 1: Activez la source d'attribution pour les créations et le code de mesure existants

Lors de la première étape, les sources d'attribution sont activées.

Fonctionnement de l'attribut attributionsrc

Le nouvel attribut attributionsrc indique la destination vers laquelle les requêtes de l'API Attribution Reporting seront envoyées. L'entité responsable du déclenchement des événements de clic et d'impression doit mettre à jour les créations avec l'attribut attributionsrc. Le attributionsrc doit être ajouté aux événements de clic et d'impression existants. Il peut être vide ou non vide.

Pour les événements de clic utilisant des redirections, l'attribut attributionsrc doit être ajouté à la navigation. Les redirections 302 effectuées après la navigation n'ont pas besoin d'ajouter l'attribut attributionsrc et sont éligibles pour l'ARA à condition que la navigation initiale ait ajouté attributionsrc.

Lorsque le champ attributionsrc est vide, les demandes ARA sont envoyées à l'URL définie dans l'attribut href de la balise d'ancrage (URL de destination). Une fois l'attribut attributionsrc défini, les demandes ARA sont envoyées à l'URL définie dans l'attribut attributionsrc. L'URL de destination peut également enregistrer des sources.

En règle générale, utilisez un attribut attributionsrc vide si le serveur hébergeant l'URL de destination peut recevoir des requêtes de l'API Attribution Reporting et y répondre. Définissez votre propre URL attributionsrc si vous souhaitez que les requêtes de l'API Attribution Reporting soient envoyées à un autre serveur.

Exemple d'attribut attributionsrc vide:

Votre configuration existante Avec intégration de l'ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>

Lorsque l'attribut attributionsrc est vide, les requêtes de l'API Attribution Reporting sont envoyées à l'URL définie par l'attribut href de la balise d'ancrage.

Exemple d'attribut attributionsrc non vide:

Votre configuration existante Avec intégration de l'ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>

Lorsque le champ attributionsrc n'est pas vide, les requêtes de l'API Attribution Reporting sont envoyées à l'URL définie par la balise attributionsrc. L'URL de destination peut également enregistrer des sources.

Ajouter attributionsrc pour les événements de clic et d'impression

  • Événements de clic:
    • L'entité responsable de l'ajout de attributionsrc est généralement la technologie publicitaire de diffusion.
    • Un attribut attributionsrc doit être ajouté aux balises d'ancrage avec des événements de clic.
    • Les clics qui utilisent window.open doivent utiliser l'argument windowFeatures de l'appel window.open pour spécifier la source d'attribution.
  • Événements d'impression:
    • L'entité responsable de l'ajout des attributionsrc est généralement la technologie publicitaire de diffusion et le ou les fournisseurs de mesure.
    • Les événements d'impression déclenchés à partir de la balise <img> ou de la balise <script> doivent inclure un attribut attributionsrc.
    • Les événements d'impression qui utilisent l'API Fetch doivent inclure un objet attributionReporting dans l'argument options transmis à l'appel d'API de récupération.

Le tableau suivant récapitule les modifications à apporter pour les événements de clic et d'impression:

Événement Tag Votre configuration existante Après l'intégration de l'ARA
Clic HTML <a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc>...</a>
JavaScript window.open("[CLICKTHROUGH_URL]", "_blank"); window.open("[CLICKTHROUGH_URL]", "_blank", "attributionsrc");
Impression Balise HTML <img> <img src="[IMPRESSION_URL]"> <img src="[IMPRESSION_URL]" attributionsrc>
Balise HTML <script> <script src="[IMPRESSION_URL]"></script> <script src="[IMPRESSION_URL]" attributionsrc></script>
JavaScript const options = {...}
window.fetch("[IMPRESSION_URL]", options);
const options = {
  attributionReporting: {
    eventSourceEligible: true,
    triggerEligible: false,
  },
  ...
};
window.fetch("[IMPRESSION_URL]", options);

Activer l'enregistrement de la source d'attribution dans une enchère Protected Audience

Pour mesurer les conversions dans une enchère Protected Audience, au lieu d'utiliser attributionsrc, vous pouvez utiliser registerAdBeacon/registerAdMacro et setReportEventDataForAutomaticBeacons/reportEvent pour activer l'enregistrement des sources d'attribution.

Pour la création de rapports sur les signaux Protected Audience, la fonction registerAdBeacon est disponible dans les Worklets de création de rapports, tandis que registerAdMacro est disponible dans le Worklet de création de rapports gagnants de l'acheteur. Les données d'événement du frame publicitaire peuvent ensuite être ajoutées aux balises et aux macros enregistrées à l'aide des fonctions reportEvent et setReportEventDataForAutomaticBeacons de l'API Fenced Frame Ads Reporting. Cela permet d'associer les signaux des Worklets de création de rapports Protected Audience et la charge utile de l'événement de frame de création publicitaire.

L'en-tête HTTP Attribution-Reporting-Eligible est ajouté à la requête lorsque les balises et les macros sont déclenchées par l'appel reportEvent à partir d'une trame ou lorsque les balises automatiques sont déclenchées par le navigateur. Vous pouvez utiliser la réponse de la balise pour enregistrer une source d'attribution. Les requêtes de la balise peuvent être redirigées pour autoriser les mesures tierces.

Pour en savoir plus, consultez la section Compatibilité avec Attribution Reporting de la vidéo d'explication de l'API Fenced Frame Ad Reporting.

Activer la création de rapports sur l'attribution pour les formats VAST

VAST est un format courant permettant de diffuser et de mesurer l'inventaire d'annonces vidéo. De nombreux événements définis dans cette norme doivent être considérés comme des événements sources potentiels pouvant être enregistrés avec l'API Attribution Reporting. L'Avenant VAST concernant la prise en charge des rapports Attribution Reporting aborde ce point en détail. Toutefois, pour résumer, tous les événements <Tracking>, <Impression>, <*ClickThrough> et <*ClickTracking> sont des événements de sources d'attribution potentiels. Toutes les implémentations VAST doivent offrir une couverture d'éligibilité à l'enregistrement pour ces événements.

L'avenant VAST définit de nouveaux attributs pour ces éléments afin de permettre de définir une URL secondaire spécifiquement pour l'enregistrement d'attributions. Lorsqu'un événement contient attributiontype="DOUBLE_PING" et attributionsrc="[URL]", le code qui déclenche cet événement doit utiliser [URL] comme valeur de l'attribut attributionsrc lors de l'activation de l'API Attribution Reporting. L'avenant VAST contient des exemples pour chaque scénario.

Pour garantir une couverture maximale, les implémentations VAST doivent rendre l'enregistrement de tous les événements listés éligibles par défaut lors du déclenchement de pings d'événement. Par exemple, lors du déclenchement d'une URL d'événement <Impression>, l'attribut attributionsrc (vide) doit être utilisé sur l'élément <img> utilisé pour envoyer la requête (ou l'équivalent dans l'appel de récupération), afin de toujours permettre à la partie destinataire d'enregistrer potentiellement cet événement avec l'API Attribution Reporting.

Étape 2: Activez Attribution Reporting pour les origines tierces

Pour autoriser des tiers à utiliser l'API Attribution Reporting, vous pouvez utiliser des redirections existantes ou ajouter une liste de tiers à l'attribut attributionsrc. Dans la plupart des cas, chaque technologie publicitaire dispose de son propre outil de suivi des impressions indépendant. Les redirections sont donc plus pertinentes pour les outils de suivi des clics.

Gérer les origines tierces dans une chaîne de redirection existante

Lors d'un clic classique sur une annonce, de nombreux outils de suivi des clics peuvent être présents sous la forme d'une chaîne de redirections 302 effectuées lors de la navigation vers la page de destination finale. Chaque requête de la chaîne de redirection peut être enregistrée auprès de l'API Attribution Reporting si la cible de clic d'origine était annotée avec attributionsrc ou enregistrée avec registerAdBeacon/registerAdMacro dans l'API Protected Audience. La technologie publicitaire de la chaîne de redirection doit également être enregistrée.

Notez que le corps de la requête initiale n'est pas envoyé sur les redirections. Pour les enchères Protected Audience, si eventData transmis à reportEvent et setReportEventDataForAutomaticBeacons doit être utilisé dans la redirection, il doit être explicitement transmis dans l'URL de redirection.

Dans l'exemple suivant, nous utiliserons une technologie publicitaire de diffusion (serving-adtech.example) et un fournisseur de mesure tiers (3p-measurement.example) comme deux entités distinctes qui souhaitent générer et recevoir des rapports sur l'attribution. Dans cet exemple, la technologie publicitaire de diffusion peut être une DSP qui affiche la création sur le site de l'éditeur et qui possède son propre produit de création de rapports. Le fournisseur de mesure tiers peut être une entité dont l'annonceur se sert pour les rapports sur les conversions.

Schéma décrivant comment le propriétaire enregistre la source, puis le tiers enregistre la

Au moment de l'enregistrement de la source, les étapes suivantes sont effectuées:

  1. serving-adtech.example définit l'attribut attributionsrc dans la création. L'internaute consulte la page de l'éditeur et le navigateur envoie une demande à serving-adtech.example..
  2. serving-adtech.example répond avec les en-têtes Attribution-Reporting-Register-Source et Location.
    1. serving-adtech.example utilise l'en-tête Attribution-Reporting-Register-Source pour répondre avec des métadonnées sur la source à enregistrer.
    2. serving-adtech.example utilise l'en-tête Location pour inclure une redirection vers 3p-measurement.example. Notez qu'il est probable que l'en-tête Location soit déjà utilisé dans vos flux de suivi des clics existants pour prendre en charge les redirections 302 vers un tiers.
  3. Le navigateur reçoit la réponse de serving-adtech.example et analyse l'en-tête Attribution-Reporting-Register-Source. Le navigateur stocke l'événement source en utilisant serving-adtech.example comme origine du rapport.
  4. Comme cette requête est une redirection, le navigateur envoie également une nouvelle requête à 3p-measurement.example.
  5. 3p-measurement.example renvoie une réponse contenant l'en-tête Attribution-Reporting-Register-Source.
  6. Le navigateur reçoit cette réponse de 3p-measurement.example et lit Attribution-Reporting-Register-Source. Le navigateur stocke l'événement source en utilisant 3p-measurement.example comme origine du rapport.

Utiliser attributionsrc pour les origines tierces ne faisant pas partie d'une chaîne de redirection

Si plusieurs origines de rapport souhaitent enregistrer une source pour un événement de navigation, mais qu'elles ne peuvent pas apparaître dans une chaîne de redirection pour une raison quelconque, vous pouvez lister plusieurs sites comme sources d'attribution dans attributionsrc.

Votre configuration existante Avec modification de l'ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[REPORTING_URL_1] [REPORTING_URL_2]">...</a>

Dans cet exemple, les requêtes éligibles pour l'API Attribution Reporting seront envoyées à REPORTING_URL_1 et à REPORTING_URL_2. La demande de navigation envoyée à l'URL de destination peut également enregistrer des sources d'attribution.

Étape 3: Configurez les réponses aux requêtes de l'API Attribution Reporting

Pour toutes les origines recevant une requête de l'API Attribution Reporting, assurez-vous que le serveur répond avec l'en-tête Attribution-Reporting-Register-Source approprié. Consultez le guide Enregistrer des sources et l'explication pour découvrir comment créer la réponse.

Enregistrer plusieurs déclencheurs

Vous pouvez enregistrer plusieurs déclencheurs d'attribution en ajoutant plusieurs éléments de pixel côté conversion (un par déclencheur). L'élément attributionsrc est facultatif pour l'enregistrement du déclencheur.

Vous pouvez également enregistrer plusieurs déclencheurs à partir d'un seul élément de pixel en utilisant des requêtes de redirection ou en répertoriant plusieurs URL dans l'élément attributionsrc de la même manière que pour l'enregistrement de la source. Les événements sources et déclencheurs générés par les mêmes origines seront mis en correspondance.