Activer la mesure des conversions

La mesure de l'attribution des conversions peut impliquer plusieurs parties, allant de l'éditeur à l'annonceur, en passant par la technologie publicitaire de diffusion (l'entité qui diffuse l'annonce), le fournisseur de mesure, etc. Dans ce document, nous illustrons des scénarios courants de mesure des conversions. Toutefois, en règle générale, toute partie souhaitant recevoir un rapport sur l'attribution de l'API Attribution Reporting (ARA) doit s'assurer que les étapes d'intégration décrites dans ce document sont suivies.

Par exemple, il est courant qu'un éditeur ait une ou plusieurs technologies publicitaires responsables de la diffusion de l'annonce. Il peut s'agir des parties responsables de la fourniture du balisage pour la création, des parties fournissant le pixel d'impression ou de suivi sur la création, et des parties fournissant le SDK ou le tag pour l'emplacement publicitaire sur la page de l'éditeur. Ces technologies publicitaires peuvent ou non souhaiter recevoir des rapports d'attribution de l'ARA, mais sont en mesure de s'assurer que les technologies publicitaires en aval peuvent recevoir des rapports d'attribution.

De plus, l'annonceur peut également faire appel à un fournisseur tiers de mesure des conversions pour l'attribution cross-canal, ainsi que pour d'autres fonctionnalités de reporting. Les annonceurs utilisent ces données pour comprendre le retour sur investissement publicitaire sur plusieurs canaux et éditeurs 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 utilisant 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 d'attribution et des déclencheurs pour la même impression ou conversion, et de recevoir des rapports distincts de l'API. Par exemple, une DSP peut recevoir ses propres rapports sur l'attribution à partir 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 des sources d'attribution et des déclencheurs pour recevoir des rapports de l'API. L'attribution s'effectue 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 la mesure des 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 à l'inventaire publicitaire à l'aide d'un fournisseur de mesure tiers, et la technologie publicitaire qui héberge la création souhaite attribuer des conversions à l'inventaire publicitaire. C'est courant pour les DSP ou les ad servers d'annonceurs (ad server tiers, 3PAS) qui fournissent le balisage pour les créations publicitaires, effectuent leurs propres rapports sur l'attribution et travaillent avec des annonceurs qui s'intègrent à des fournisseurs tiers de solutions de mesure ou d'analyse.

Dans ce cas, la technologie publicitaire de diffusion est également responsable du déclenchement des é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 vérifier que les redirections sont correctement configurées. De plus, la technologie publicitaire de diffusion et le fournisseur de mesure tiers doivent vérifier 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 de configuration de campagne :

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

  2. La DSP offre la possibilité d'ajouter des pixels de suivi des impressions et des clics supplémentaires. Elle doit s'assurer que attributionsrc est inclus dans le balisage final de la création publicitaire avec laquelle elle fait des offres.

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

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

Dans ce cas, la partie responsable du déclenchement des événements de clics et d'impressions dans la configuration actuelle doit ajouter le nouvel attribut attributionsrc aux créations et vérifier que les redirections fonctionnent comme prévu. Cela dépend fortement de l'intégration de chaque éditeur, mais 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 généralement du fournisseur de mesure tiers.

Dans l'exemple de configuration de campagne typique du scénario 1, il se peut que le serveur publicitaire de l'éditeur, la SSP ou l'éditeur lui-même aient simplement besoin de vérifier que l'attribut attributionsrc fourni par le DSP figure bien sur la page de l'éditeur.

Détails de mise en œuvre

Le tableau suivant décrit les étapes d'implémentation de l'API Attribution Reporting de manière générale :

Étapes Responsabilité du travail Exemples
Étape 1 : Activer 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, c'est généralement un acheteur (DSP/ad server de l'annonceur) qui affiche la création et ajoute 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. Cela 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 Cela fonctionne prêt à 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 lister plusieurs ad servers technologiques.

 En général, tant que l'attribut attributionsrc est ajouté à la création, les redirections tierces devraient 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 Le DSP et le fournisseur de mesures tierces utilisés par l'annonceur

Notez que les spécificités de chaque étape dépendent de la façon dont les créations sont affichées et diffusées sur la page de l'éditeur, et des entités technologiques publicitaires qui reçoivent les rapports envoyés par l'API Attribution Reporting.

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

La première étape consiste à activer les sources d'attribution.

Fonctionnement de l'attribut attributionsrc

Le nouvel attribut attributionsrc spécifie l'emplacement où les requêtes de l'API Attribution Reporting seront envoyées. L'entité responsable du déclenchement des événements d'impression et de clic doit mettre à jour les créations avec l'attribut attributionsrc. Le attributionsrc doit être ajouté aux événements de clics et d'impressions existants. Il peut être vide ou non.

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

Lorsque 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). Lorsque l'attribut attributionsrc est 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 l'intégration 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 l'intégration ARA
<a href="[CLICKTHROUGH_URL]">...</a> <a href="[CLICKTHROUGH_URL]" attributionsrc="[ATTRIBUTION_SRC_URL]">...</a>

Lorsque 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.
    • Les balises d'ancrage avec des événements de clic doivent être associées à un attribut attributionsrc.
    • Les clics utilisant 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 de 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 utilisant l'API Fetch doivent inclure un objet attributionReporting dans l'argument options transmis à l'appel de l'API Fetch.

Consultez le tableau suivant pour obtenir un récapitulatif des modifications nécessaires pour les événements de clic et d'impression :

Événement Tag Votre configuration existante Après l'intégration d'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 des sources d'attribution dans une enchère Protected Audience

Pour mesurer les conversions dans les enchères Protected Audience, vous pouvez utiliser registerAdBeacon/registerAdMacro et setReportEventDataForAutomaticBeacons/reportEvent au lieu de attributionsrc pour enregistrer les sources d'attribution.

Pour signaler les signaux Protected Audience, la fonction registerAdBeacon est disponible dans les worklets de reporting, et registerAdMacro est disponible dans le worklet de reporting des enchères remportées par l'acheteur. Ensuite, les données d'événement à l'intérieur du frame d'annonce peuvent être ajoutées aux balises et macros enregistrées avec les fonctions reportEvent et setReportEventDataForAutomaticBeacons de l'API Fenced Frame Ads Reporting. Cela permet d'associer les signaux des worklets de reporting Protected Audience et la charge utile de l'événement de frame de la 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'un frame, ou lorsque les balises automatiques sont déclenchées par le navigateur. Vous pouvez utiliser la réponse du beacon pour enregistrer une source d'attribution. Les demandes de balise peuvent être redirigées pour permettre la mesure tierce.

Pour en savoir plus, consultez la section Prise en charge d'Attribution Reporting de l'explication de l'API Fenced Frame Ad Reporting.

Activer les rapports sur l'attribution pour les formats VAST

VAST est un format courant pour diffuser et mesurer l'inventaire d'annonces vidéo. La plupart des é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 pour la prise en charge des rapports sur l'attribution couvre ce point en détail, mais en résumé, tous les événements <Tracking>, <Impression>, <*ClickThrough> et <*ClickTracking> sont des événements sources d'attribution potentiels. Toutes les implémentations VAST doivent permettre l'enregistrement de ces événements.

L'addendum VAST définit de nouveaux attributs pour ces éléments afin de permettre la définition d'une URL secondaire spécifiquement pour l'enregistrement de l'attribution. 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 une couverture maximale, les implémentations VAST doivent, par défaut, rendre tous les événements listés éligibles à l'enregistrement lorsque les pings d'événements sont déclenchés. 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 sur l'appel de récupération), afin de toujours permettre au 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 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 avec l'API Attribution Reporting si la cible de clic d'origine a été 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é lors des redirections. Pour les enchères Protected Audience, si eventData est transmis à reportEvent et que setReportEventDataForAutomaticBeacons doit être utilisé dans la redirection, il doit être transmis explicitement 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 dispose de son propre produit de reporting. Le fournisseur de mesure tiers peut être une entité que l'annonceur utilise pour les rapports sur les conversions.

Schéma décrivant comment le propriétaire enregistre la source.
Exemple de fonctionnement de la mesure des conversions avec un tiers.

Lors de l'enregistrement de la source, les étapes suivantes ont lieu :

  1. serving-adtech.example définit l'attribut attributionsrc dans la création. L'utilisateur accède à la page de l'éditeur, et le navigateur envoie une requête à serving-adtech.example..
  2. serving-adtech.example répond avec l'en-tête Attribution-Reporting-Register-Source et l'en-tête 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 que l'en-tête Location est probablement 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. Étant donné que cette requête est une redirection, le navigateur envoie également une nouvelle requête à 3p-measurement.example.
  5. 3p-measurement.example répond avec 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 le 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 qui ne font pas partie d'une chaîne de redirection

Si plusieurs origines de rapporteur souhaitent enregistrer une source lors d'un événement de navigation, mais ne peuvent pas apparaître dans une chaîne de redirection pour une raison quelconque, vous pouvez répertorier plusieurs sites comme sources d'attribution dans attributionsrc comme solution alternative.

Votre configuration existante Avec modification 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 à l'API Attribution Reporting seront envoyées à REPORTING_URL_1 et à REPORTING_URL_2. La requête de navigation envoyée à l'URL de destination est également éligible à l'enregistrement 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, vérifiez 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 savoir comment construire 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 listant 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 les événements déclencheurs générés par les mêmes origines seront mis en correspondance.