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:
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.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 |
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'argumentwindowFeatures
de l'appelwindow.open
pour spécifier la source d'attribution.
- L'entité responsable de l'ajout de
- É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 attributattributionsrc
. - 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.
- L'entité responsable de l'ajout des
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 = {...} |
const 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.
Au moment de l'enregistrement de la source, les étapes suivantes sont effectuées:
serving-adtech.example
définit l'attributattributionsrc
dans la création. L'internaute consulte la page de l'éditeur et le navigateur envoie une demande àserving-adtech.example.
.serving-adtech.example
répond avec les en-têtesAttribution-Reporting-Register-Source
etLocation
.serving-adtech.example
utilise l'en-têteAttribution-Reporting-Register-Source
pour répondre avec des métadonnées sur la source à enregistrer.serving-adtech.example
utilise l'en-têteLocation
pour inclure une redirection vers3p-measurement.example
. Notez qu'il est probable que l'en-têteLocation
soit déjà utilisé dans vos flux de suivi des clics existants pour prendre en charge les redirections302
vers un tiers.
- Le navigateur reçoit la réponse de
serving-adtech.example
et analyse l'en-têteAttribution-Reporting-Register-Source
. Le navigateur stocke l'événement source en utilisantserving-adtech.example
comme origine du rapport. - Comme cette requête est une redirection, le navigateur envoie également une nouvelle requête à
3p-measurement.example
. 3p-measurement.example
renvoie une réponse contenant l'en-têteAttribution-Reporting-Register-Source
.- Le navigateur reçoit cette réponse de
3p-measurement.example
et litAttribution-Reporting-Register-Source
. Le navigateur stocke l'événement source en utilisant3p-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.