Mise en correspondance des cookies

La mise en correspondance des cookies est une fonctionnalité qui vous permet d'associer votre cookie (par exemple, un ID d'un utilisateur qui a consulté votre site Web) à un ID utilisateur Google spécifique à un enchérisseur correspondant, puis de créer des listes d'utilisateurs qui vous aideront à prendre de meilleures décisions d'enchères. Ce guide décrit les concepts utilisés dans la mise en correspondance des cookies, ainsi que les différents workflows de mise en correspondance des cookies et les variations qu'ils peuvent avoir pour certains cas d'utilisation.

Concepts

Les propriétaires de domaine définissent généralement le contenu des cookies pour les utilisateurs qui consultent leur site, lesquels permettent d'identifier les utilisateurs de ce domaine. Même si deux propriétaires de domaine accepteraient d'échanger ces données, le modèle de sécurité des navigateurs Internet empêche de lire un cookie défini par un autre domaine.

Dans le contexte de la publicité numérique, Google identifie les utilisateurs à l'aide de cookies appartenant au domaine doubleclick.net. Les enchérisseurs participant aux enchères en temps réel peuvent avoir leur propre domaine dans lequel ils identifient un ensemble d'utilisateurs auxquels ils souhaitent diffuser des annonces. La mise en correspondance des cookies permet à l'enchérisseur de mettre en correspondance ses cookies avec ceux de Google. Ainsi, il peut déterminer si une impression envoyée dans une demande d'enchère est associée à l'un des utilisateurs ciblés. Il recevra soit ses propres données de cookie, soit un ID utilisateur Google propre à l'enchérisseur, qui est une forme chiffrée du cookie doubleclick.net dans la demande d'enchère.

Le service de mise en correspondance des cookies décrit dans ce guide facilite la création et la maintenance de l'association entre le cookie d'un enchérisseur et l'ID utilisateur Google, et permet également de renseigner des listes d'utilisateurs.

Tableaux de correspondance

Une table de correspondance peut être utilisée pour mapper un ID ou d'autres données d'un domaine à un autre. Les enchérisseurs peuvent utiliser le service de cookie matching pour renseigner leurs propres tables de correspondance en mappant leur cookie pour un utilisateur donné sur son ID utilisateur Google, ou pour renseigner une table de correspondance hébergée par Google. Les tables de correspondance sont nécessaires pour que l'application d'enchères d'un enchérisseur puisse accéder aux données de cookie de l'utilisateur auquel l'impression est diffusée.

Tableaux de correspondance hébergés par Google

Pour faciliter la maintenance, améliorer la latence et accéder aux données de correspondance pour les utilisateurs de certaines régions, nous vous recommandons d'autoriser Google à héberger votre table de correspondance. Cela vous permet de spécifier une chaîne au format base64 adaptée au Web (appelée ci-après "données de correspondance hébergées") qui sera mappée à l'ID utilisateur Google d'un utilisateur donné. Une fois une correspondance établie, vous pouvez l'utiliser de différentes manières:

  • Enchères en temps réel: dans les demandes d'enchères ultérieures pour les impressions associées à l'utilisateur, Google vous enverra les données de correspondance hébergées que vous avez mises en correspondance avec son ID utilisateur Google. Dans l'implémentation OpenRTB de Google, BidRequest.user.buyeruid spécifie cela sous la forme d'une chaîne encodée en base64 adaptée au Web. Si votre point de terminaison d'enchères est configuré pour utiliser le protocole Google RTB obsolète, vous le recevrez sous forme d'octets décodés via le champ BidRequest.hosted_match_data.

  • Listes d'utilisateurs: vous pouvez renseigner les listes d'utilisateurs avec des ID utilisateur Google ou des données de correspondance hébergées.

  • Préciblage : vous pouvez configurer votre préciblage de sorte à ne recevoir que des demandes d'enchères contenant des données de correspondance hébergées. Vous pouvez ainsi supprimer les impressions moins pertinentes pour les utilisateurs en dehors de votre espace de cookies.

Listes d'utilisateurs

Vous pouvez créer et gérer des listes d'utilisateurs avec l'API Real-Time Bidding. Une fois créées, vous pouvez renseigner ces listes à l'aide des workflows de mise en correspondance des cookies décrits ci-dessous ou via le service d'importation groupée.

Premiers pas

Pour commencer à utiliser la mise en correspondance des cookies, vous devez contacter votre responsable de compte technique, qui peut activer des workflows spécifiques et vous aider à configurer les éléments suivants:

  • ID de réseau de mise en correspondance des cookies (NID): identifiant de chaîne identifiant de manière unique un compte d'enchérisseur pour la mise en correspondance des cookies et d'autres opérations associées.
  • URL de mise en correspondance des cookies: URL de base d'un point de terminaison qui accepte et gère les requêtes entrantes dans le cadre des workflows de mise en correspondance des cookies. Les enchérisseurs peuvent intégrer des macros dans cette URL pour contrôler l'ordre des paramètres qui lui sont transmis dans les workflows de lecture des cookies.
  • Balise de correspondance: balise que vous devez placer dans le navigateur d'un utilisateur pour le workflow de cookie matching déclenché par l'enchérisseur. Ils peuvent être diffusés à côté d'annonces ou placés sur des propriétés Web en dehors des annonces.
  • URL du rapport de mise en correspondance des cookies (facultatif): dans le workflow unidirectionnel de mise en correspondance des cookies, il s'agit d'une URL facultative permettant de spécifier un point de terminaison qui recevra les détails de l'erreur en cas d'échec de la mise en correspondance des cookies via une redirection HTTP 302. Par défaut, les réponses ne seront envoyées à cette URL qu'en cas d'erreur lors de l'opération de mise en correspondance des cookies. Toutefois, les enchérisseurs peuvent demander que la redirection soit toujours envoyée.
  • URL de Cookie Match Assist: pour les places de marché implémentant le workflow Cookie Match Assist, il s'agit de l'URL de base du point de terminaison destiné à répondre aux demandes entrantes.
  • Quota Cookie Match Assist: pour les places de marché implémentant le workflow Cookie Match Assist, il s'agit du nombre maximal de requêtes que leur URL de mise en correspondance des cookies peut recevoir chaque seconde. Cela vise à éviter que les requêtes CMA ne surchargent les serveurs de la place de marché.

Dans l'un des workflows de mise en correspondance des cookies compatibles, des paramètres sont généralement ajoutés à l'URL de mise en correspondance des cookies d'un enchérisseur dans un ordre non garanti. Les enchérisseurs dont les intégrations nécessitent un ordre cohérent des paramètres peuvent placer des macros dans leur URL de mise en correspondance des cookies pour garantir leur emplacement.

Macros prises en charge

Les enchérisseurs peuvent éventuellement configurer leur URL de mise en correspondance des cookies pour inclure une ou plusieurs macros au format %%GOOGLE_<PARAM_NAME>%% ou %%GOOGLE_<PARAM_NAME>_PAIR%%. Les macros acceptées et leurs valeurs développées sont les suivantes:

Macro Valeur développée
GOOGLE_GID GOOGLE_USER_ID
GOOGLE_GID_PAIR &google_gid=GOOGLE_USER_ID
GOOGLE_CVER COOKIE_VERSION_NUMBER
GOOGLE_CVER_PAIR &cver=COOKIE_VERSION_NUMBER
GOOGLE_ERROR ERROR_ID
GOOGLE_ERROR_PAIR &google_error=ERROR_ID
GOOGLE_PUSH PIXEL_MATCH_DATA
GOOGLE_PUSH_PAIR &google_push=PIXEL_MATCH_DATA
GOOGLE_ALL_PARAMS google_gid=GOOGLE_USER_ID&cver=COOKIE_VERSION_NUMBER&google_error=ERROR_ID

Exemple de macro

Un enchérisseur dispose d'une intégration de mise en correspondance des cookies avec un point de terminaison hébergé sur https://user.bidder.com.cookies. Leur implémentation nécessite des paramètres prédéfinis définis par l'enchérisseur en plus des paramètres de mise en correspondance des pixels dans l'ordre suivant: google_push, google_gid, google_cver et google_error. Pour ce faire, l'enchérisseur peut définir son URL de mise en correspondance des cookies sur:

https://user.bidder.com/cookies?w=0%%GOOGLE_PUSH_PAIR%%&x=1%%GOOGLE_GID_PAIR%%&y=2%%GOOGLE_CVER_PAIR%%&z=3%%GOOGLE_ERROR_PAIR%%

Lorsque Google enverra ultérieurement une requête de mise en correspondance à cet enchérisseur, elle sera développée comme suit:

https://user.bidder.com/cookies?w=0&google_push=PUSH_DATA&x=1&google_gid=GOOGLE_GID&y=2&google_cver=1&z=3

Le service de lecture des cookies de Google accepte actuellement trois workflows pour différents cas d'utilisation, décrits ci-dessous.

La mise en correspondance bidirectionnelle des cookies fait référence à un flux de travail initié par l'enchérisseur, où il place une balise de correspondance dans le navigateur de l'utilisateur qui la redirige vers Google. Ce workflow permet à Google et à l'enchérisseur de remplir les tables des correspondances. Vous trouverez ci-dessous un exemple simple de ce workflow.

Étape 1: Placez la balise de correspondance

Pour lancer ce flux, l'enchérisseur doit placer sa balise de correspondance de sorte qu'elle s'affiche dans le navigateur de l'utilisateur. Une balise de correspondance simple qui ne renvoie que l'ID utilisateur Google à l'enchérisseur peut être structurée comme suit:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm" />

Vous pouvez inclure d'autres paramètres dans la balise de correspondance pour répondre à différents cas d'utilisation. Pour en savoir plus sur ces paramètres, consultez la section Paramètres d'URL de la balise de correspondance.

Étape 2: Google répond avec une redirection incluant les données de correspondance

La balise de mise en correspondance permet au service de mise en correspondance des cookies de Google de recevoir une requête du navigateur de l'utilisateur, qui émet une redirection HTTP 302 vers l'URL de mise en correspondance des cookies de l'enchérisseur. La redirection inclura des paramètres de requête spécifiant l'ID utilisateur Google et son numéro de version dans l'URL. L'enchérisseur recevra également son cookie inclus dans les en-têtes de requête. En pratique, pour une URL de mise en correspondance des cookies spécifiée comme https://ad.network.com/pixel, l'URL de redirection de la balise de correspondance simple, comme indiqué ci-dessus, peut se présenter comme suit:

https://ad.network.com/pixel?google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

L'ID utilisateur Google transmis via le paramètre google_gid est une chaîne encodée en base64 adaptée au Web, sans remplissage. Pour les enchérisseurs qui choisissent d'héberger une table de correspondance, il est recommandé de stocker la chaîne exacte renvoyée par le service de mise en correspondance des cookies. Dans les demandes d'enchères ultérieures, cela correspondra aux valeurs spécifiées via BidRequest.user.id dans OpenRTB ou BidRequest.google_user_id dans le protocole Google RTB obsolète.

La version spécifiée dans google_cver indique le numéro de version numérique de l'ID utilisateur Google. L'ID utilisateur Google d'un utilisateur donné change rarement, puis est incrémenté.

Si Google rencontre une erreur lors du traitement de votre requête de mise en correspondance, un paramètre google_error sera spécifié à la place.

Étape 3: L'enchérisseur traite la redirection et répond avec un pixel

L'enchérisseur reçoit une redirection vers son URL de mise en correspondance des cookies, y compris les paramètres qu'il a spécifiés à la première étape et ceux fournis par Google à la deuxième étape. De plus, le cookie sera également reçu dans les en-têtes HTTP. Si l'opération a réussi, un enchérisseur hébergeant sa propre table de correspondance peut faire correspondre son cookie à l'ID utilisateur Google inclus dans la réponse. Nous recommandons aux enchérisseurs de stocker la chaîne exacte renvoyée par le service de mise en correspondance des cookies.

Si l'opération a échoué, l'enchérisseur reçoit un paramètre google_error dans la redirection. Il s'agit d'une valeur numérique correspondant à différents états d'erreur qui identifient l'erreur spécifique qui s'est produite. Pour en savoir plus sur les valeurs d'erreur possibles, cliquez ici. Si une erreur s'affiche, vous pouvez réessayer de mettre en correspondance cet utilisateur en plaçant une nouvelle balise de correspondance.

L'enchérisseur doit toujours répondre en diffusant une image de pixel invisible de 1 x 1 pixel ou renvoyer une réponse HTTP 204 Aucun contenu.

Ce workflow est illustré par le schéma ci-dessous, dans lequel les requêtes et les réponses sont représentées par une flèche, et les éléments de données qui les accompagnent sont indiqués entre parenthèses.

Paramètres d'URL de la balise de correspondance

Paramètre Description
google_nid ID de réseau (NID) du compte d'enchérisseur. Cet ID peut être récupéré via la ressource Enchères.
google_cm Indique au service de mise en correspondance des cookies de Google qu'il doit effectuer une mise en correspondance des cookies. La valeur du paramètre est ignorée et peut être omise.
google_sc Ce paramètre est obsolète. Définit le cookie de Google pour l'utilisateur, le cas échéant. La valeur du paramètre est ignorée et peut être omise. L'omission du paramètre génère une erreur si aucun cookie n'existe.
google_no_sc Ce paramètre est obsolète. Cette valeur indique au service de lecture des cookies de Google qu'il ne doit pas définir de cookie pour l'utilisateur s'il n'en existe aucun. La valeur du paramètre est ignorée et peut être omise.
google_hm

Données que l'enchérisseur souhaite stocker dans une table de correspondance hébergée par Google.

La valeur est une chaîne encodée en base64 adaptée au Web (marge intérieure facultative). Les données brutes ne doivent pas dépasser 40 octets. Par exemple, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.

google_redir Chaîne encodée en URL qu'un enchérisseur peut spécifier s'il souhaite demander à Google d'envoyer la redirection HTTP 302 à l'URL encodée pour cette balise de correspondance. Cela permet à Google d'être placé en premier dans un appel en série aux partenaires. Une erreur se produit si elle est spécifiée sans google_hm ou avec google_cm.
google_ula Chaîne utilisée pour ajouter l'utilisateur à une liste d'utilisateurs existante. Le format attendu pour cette valeur est userlistid[,timestamp] :
  • userlistid: un seul ID numérique de liste d'utilisateurs.
  • timestamp: code temporel facultatif au format POSIX, indique quand l'utilisateur a été ajouté à la liste des utilisateurs.

Ce paramètre d'URL peut être répété pour ajouter l'utilisateur à plusieurs listes.

gdpr Indique que la requête est soumise aux restrictions du RGPD concernant l'utilisation des données. Pour en savoir plus, consultez les Exigences relatives au consentement de l'utilisateur dans l'UE ci-dessous ou la section Impact sur l'éligibilité de la mise en correspondance des cookies dans la documentation de la version 2.0 du TCF de l'IAB pour les acheteurs autorisés.

Exemple : gdpr=1

gdpr_consent Chaîne TC représentant le consentement de l'utilisateur final. Pour en savoir plus, consultez les Exigences relatives au consentement de l'utilisateur dans l'UE ci-dessous ou la section Comment la chaîne TC sera-t-elle transmise ? dans la Documentation de la version 2.0 du TCF de l'IAB pour les acheteurs autorisés.
process_consent Indique que l'enchérisseur a obtenu le consentement de l'utilisateur final pour les utilisations des données spécifiées dans les Règles de Google relatives au consentement de l'utilisateur dans l'UE.

Si la demande n'est pas soumise aux règles relatives au consentement de l'utilisateur dans l'UE ou si d'autres paramètres de consentement sont disponibles dans la demande (gdpr_consent), ce paramètre est ignoré.

Exemple : process_consent=T

En plus des paramètres ci-dessus, les enchérisseurs peuvent spécifier leurs propres paramètres, qui seront ajoutés en tant que paramètres à l'URL de redirection. Notez que les paramètres définis par l'enchérisseur portant le préfixe google_ seront ignorés, car ils sont réservés par Google pour un développement futur, et la préservation de l'ordre des paramètres n'est pas garantie. Une balise de correspondance incluant des paramètres définis par l'enchérisseur peut se présenter comme suit:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_cm&extra1=xx&extra2=yy" />

Paramètres d'URL de redirection

L'URL de redirection est créée à partir de l'URL de base de la mise en correspondance des cookies configurée pour le compte d'un enchérisseur, y compris google_ et les paramètres définis par l'enchérisseur en fonction de ceux spécifiés dans la balise de correspondance. Les paramètres de réponse google_ suivants sont définis:

Paramètre Description
google_gid ID utilisateur Google Défini si google_cm est spécifié dans la requête et si la requête a abouti.
google_cver Version du cookie. Défini si google_cm est spécifié dans la requête et si la requête a abouti.
google_error

Valeur entière indiquant l'erreur globale de la requête. Lorsqu'elle est reçue, elle indique qu'aucune opération n'a été effectuée et qu'aucun autre paramètre de réponse google_ n'est défini. Les valeurs d'erreur acceptées sont les suivantes:

  • 1: l'utilisateur dispose d'un cookie Google, mais a désactivé tout suivi à l'aide de ce cookie.
  • 2: aucune opération valide n'a été spécifiée. Par exemple, une requête sans opération a été reçue.
  • 3: l'utilisateur ne dispose pas de cookie Google. Google ne définira pas le cookie via le service de mise en correspondance des cookies.
  • 4: opérations en conflit spécifiées. Vous n'êtes pas autorisé à spécifier à la fois les indicateurs google_push et google_cm dans la même requête, car ils ont des objectifs contradictoires.
  • 5: un paramètre google_push non valide a été transmis dans une redirection à un serveur Google dans le cadre d'une requête de mise en correspondance de pixels bidirectionnelle. Votre redirection doit définir google_push sur la même valeur qui vous a été transmise dans la requête de pixel initiale.
  • 6: un NID non valide a été fourni dans la balise de correspondance.
  • 7: un cookie non valide a été détecté.
  • 8: obsolète. Aucun cookie n'a été trouvé.
  • 9: aucun cookie n'a été trouvé. Une tentative de définition d'un cookie de test est effectuée.
  • 10: le paramètre google_redir a été utilisé sans que google_hm ne soit spécifié ou en plus de google_cm.
  • 15: la requête provient d'une région où Google exige que la table des correspondances soit hébergée par Google. Par conséquent, cette réponse ne contient pas d'ID utilisateur Google. Cette fonctionnalité n'est actuellement activée que pour un petit pourcentage du trafic, mais elle devrait être entièrement activée en juin 2020.
google_hm

Ne s'affiche que si la tentative d'écriture dans la table des correspondances hébergée par Google échoue. Dans ce cas, sa valeur correspond à l'un des codes d'état suivants:

  • 1 : interdit : le client ne figure pas encore sur la liste blanche permettant d'écrire des entrées de table des correspondances hébergées.
  • 2 : erreur de décodage : la valeur du paramètre n'a pas pu être décodée.
  • 3 : charge utile trop longue : valeur du paramètre décodée en plus de 24 octets de données.
  • 4 : erreur interne : une erreur interne s'est produite lors du stockage des données.
  • 5 : limité : cette écriture n'a pas été traitée en raison d'une limitation.
google_ula

État de l'opération d'ajout de la liste d'utilisateurs, répété si plusieurs google_ula ont été spécifiés dans la requête. Le format est le suivant:
userlistid,status code

Ex. : google_ula=1234567890,0

L'opération google_ula peut renvoyer l'un des codes d'état suivants:

  • 0 : aucune erreur. L'utilisateur a été ajouté à la liste des utilisateurs.
  • 2 : autorisation refusée. Vous n'êtes pas autorisé à ajouter des utilisateurs à la liste d'utilisateurs donnée.
  • 5 : mauvais ID de liste d'utilisateurs. L'ID de la liste d'utilisateurs fourni n'est pas valide.
  • 6 : ID de l'attribut fermé. L'ID de la liste d'utilisateurs fourni est fermé.
  • 10 : erreur interne. Le service de lecture des cookies a rencontré une erreur interne. Vous pouvez réessayer de faire correspondre l'utilisateur.

Les scénarios suivants décrivent à quoi peut ressembler la mise en correspondance des cookies pour un utilisateur type qui parcourt une page Web.

Scénario 1: L'utilisateur efface ses cookies et consulte un site

Jane vide son cache de tous les cookies. Il accède ensuite à la page d'accueil de ExampleNews.com.

Voici le processus :

  1. ExampleNews.com s'affiche et appelle les annonces à partir de Google (Ad Manager).
  2. Comme le bloc d'annonces est éligible pour l'allocation dynamique, Google envoie des demandes d'enchères à FinestDSP et à d'autres enchérisseurs via le service d'enchères en temps réel.
  3. L'application d'enchérisseur de FinestDSP reçoit et traite la demande d'enchère, puis envoie sa réponse à l'enchère.
  4. Google reçoit les réponses aux enchères des enchérisseurs, y compris la réponse de FinestDSP qui spécifie une annonce avec un tag de correspondance (pixel).
  5. FinestDSP remporte les enchères. Google diffuse l'annonce de FinestDSP et fait correspondre la balise à Jane.
  6. La balise de correspondance appelle le service de mise en correspondance des cookies de Google, en spécifiant les paramètres google_nid et google_cm.
  7. Le service de mise en correspondance des cookies lit le cookie Google de Jane et envoie au navigateur de Jane une redirection vers l'URL de mise en correspondance des cookies de FinestDSP avec les paramètres google_gid et google_cver définis.
  8. Le navigateur de Jane charge la redirection vers l'URL de lecture des cookies de FinestDSP.
  9. Le point de terminaison de mise en correspondance des cookies de FinestDSP traite la requête de redirection, qui inclut les paramètres d'URL définis par Google et son cookie pour Jane dans les en-têtes HTTP. FinestDSP peut désormais stocker le mappage de son cookie sur google_gid dans sa table des correspondances.
  10. FinestDSP répond à la redirection avec un pixel invisible de 1 x 1.
Scénario 2: Utilisateur avec un mappage existant

Une semaine après le scénario 1, Jane accède de nouveau à ExampleNews.com. Maintenant que Jane dispose à la fois de cookies d'enchérisseur et d'Ad Manager sur sa machine, voici comment la mise en correspondance fonctionne.

  1. La page Web s'affiche, ce qui incite Google (Ad Manager) à demander les annonces qui seront diffusées sur la page.
  2. Lors de l'enchère d'annonces, Google envoie une demande d'enchère aux enchérisseurs éligibles, y compris FinestDSP.
  3. FinestDSP reçoit la demande d'enchère, y compris des signaux tels que google_gid.
  4. FinestDSP recherche le google_gid dans sa table des correspondances et trouve le cookie associé à Jane, créé une semaine plus tôt (dans le scénario 1).
  5. En fonction des informations associées au cookie, la logique d'enchères de FinestDSP place une enchère sur l'impression et remporte l'enchère.
  6. Jeanne peut voir une annonce personnalisée en fonction de ses centres d'intérêt, en fonction des informations dont dispose FinestDSP.

La mise en correspondance unidirectionnelle des cookies est semblable au workflow bidirectionnel, à l'exception qu'elle est modifiée de sorte que seul Google héberge et renseigne une table de correspondance. Cette option peut être utilisée lorsque l'enchérisseur n'est pas autorisé à héberger des ID utilisateur Google dans sa propre table de correspondance. Pour utiliser ce flux, les enchérisseurs doivent autoriser Google à héberger la table des correspondances, ne peuvent plus spécifier google_cm dans les requêtes adressées au service de lecture des cookies de Google et ne recevront donc pas de google_gid pour remplir leur propre table des correspondances. Une fois que Google a établi une correspondance pour un utilisateur, les enchérisseurs peuvent l'ajouter à des listes d'utilisateurs à l'aide de leurs propres données de cookies. De même, les demandes d'enchères pour ces utilisateurs excluront l'ID utilisateur Google, mais incluront les données de ciblage hébergé. Un exemple simple du workflow révisé est résumé dans les étapes ci-dessous.

Pour lancer ce processus, un enchérisseur doit placer une balise de correspondance de sorte qu'elle s'affiche dans le navigateur de l'utilisateur. Contrairement au workflow pour les utilisateurs qui ne se trouvent pas dans un État américain soumis à des restrictions de confidentialité, la balise de correspondance doit rediriger le navigateur de l'utilisateur vers votre URL de mise en correspondance des cookies. Par exemple, avec une URL de mise en correspondance des cookies configurée sur https://ad.network.com/pixel, elle se présente comme suit:

<img src="https://ad.network.com/pixel" />

Lors du chargement dans le navigateur de l'utilisateur, il demande un pixel à l'URL de mise en correspondance des cookies de l'enchérisseur. Cette requête contiendra son cookie dans l'en-tête HTTP, qui doit être extrait pour l'étape suivante.

Le point de terminaison de mise en correspondance des cookies de l'enchérisseur doit rediriger vers le service de mise en correspondance des cookies de Google, y compris le paramètre google_hm renseigné avec les données de son cookie encodées en base64 adaptées au Web. L'URL de redirection peut se présenter comme suit:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA

Google recevra une redirection contenant les paramètres que vous avez spécifiés, en plus du cookie de Google dans les en-têtes HTTP.

Étape 4: Google diffuse le pixel en cas de redirection de réussite ou d'erreur si l'URL du rapport est spécifiée

Si l'opération de mise en correspondance des cookies aboutit ou si aucune URL de rapport sur la mise en correspondance des cookies n'a été spécifiée pour le compte de l'enchérisseur, Google diffuse un pixel transparent de 1 x 1 par défaut, et le workflow se termine ici. Les impressions de cet utilisateur dans les demandes d'enchères suivantes incluront les données de ciblage hébergées de l'enchérisseur dans BidRequest.user.buyeruid pour OpenRTB ou BidRequest.hosted_match_data pour le protocole RTB Google obsolète. Les enchérisseurs peuvent également renseigner les listes d'utilisateurs à l'aide des données de correspondance hébergées qu'ils ont spécifiées.

Sinon, si une erreur s'est produite, Google enverra une redirection vers l'URL du rapport sur la mise en correspondance des cookies de l'enchérisseur, en spécifiant la cause de l'erreur dans le paramètre google_error. Si l'URL du rapport sur la mise en correspondance des cookies de l'enchérisseur était https://ad.network.com/report, l'URL de redirection se présenterait comme suit:

<img src="https://ad.network.com/report?google_error=ERROR_ID" />

Le navigateur de l'utilisateur est redirigé vers l'URL du rapport sur la mise en correspondance des cookies de l'enchérisseur, y compris le motif d'erreur (le cas échéant) spécifié par Google dans le paramètre google_error. Pour en savoir plus sur l'interprétation du code d'erreur, consultez la description du paramètre.

Étape 6: L'enchérisseur diffuse un pixel transparent de 1 x 1

L'enchérisseur doit répondre en diffusant un pixel transparent de 1 x 1 pixel dans le navigateur de l'utilisateur.

Le workflow par défaut pour les utilisateurs situés dans les États américains soumis à des restrictions de confidentialité est illustré par le diagramme ci-dessous, où les requêtes et les réponses sont représentées par une flèche, et les éléments de données qui les accompagnent sont indiqués entre parenthèses.

Paramètre Description
google_nid ID de réseau (NID) du compte d'enchérisseur. Cet ID peut être récupéré via la ressource Enchères.
google_sc Ce paramètre est obsolète. Définit le cookie de Google pour l'utilisateur, le cas échéant. La valeur du paramètre est ignorée et peut être omise. Si ce paramètre est omis, une erreur est renvoyée si aucun cookie n'existe.
google_no_sc Ce paramètre est obsolète. Cela indique au service de mise en correspondance des cookies de Google qu'il ne doit pas définir de cookie pour l'utilisateur s'il n'en existe pas. La valeur du paramètre est ignorée et peut être omise.
google_hm

Contient les données que l'enchérisseur souhaite stocker dans une table de correspondance hébergée par Google.

google_redir URL encodée pour laquelle vous souhaitez que Google envoie une redirection HTTP 302. L'URL spécifiée recevra des redirections avec le paramètre google_error pour les erreurs et les opérations réussies.
google_ula Chaîne utilisée pour ajouter l'utilisateur à une liste d'utilisateurs existante. Le format attendu de la valeur est userlistid[,timestamp] :
  • userlistid: un seul ID numérique de liste d'utilisateurs.
  • timestamp: code temporel facultatif au format POSIX, indique quand l'utilisateur a été ajouté à la liste des utilisateurs.

Ce paramètre d'URL peut être répété pour ajouter l'utilisateur à plusieurs listes.

gdpr Indique que la requête est soumise aux restrictions du RGPD concernant l'utilisation des données. Pour en savoir plus, consultez les Exigences relatives au consentement de l'utilisateur dans l'UE ci-dessous ou la section Impact sur l'éligibilité de la mise en correspondance des cookies dans la documentation de la version 2.0 du TCF de l'IAB pour les acheteurs autorisés.

Exemple : gdpr=1

gdpr_consent Chaîne TC représentant le consentement de l'utilisateur final. Pour en savoir plus, consultez Exigences relatives au consentement de l'utilisateur dans l'UE ci-dessous ou Comment la chaîne TC sera-t-elle transmise ? dans la documentation de la version 2.0 du TCF de l'IAB Authorized Buyers.
process_consent Indique que l'enchérisseur a obtenu le consentement de l'utilisateur final pour les utilisations des données spécifiées dans les Règles de Google relatives au consentement de l'utilisateur dans l'UE.

Si la demande n'est pas soumise aux règles relatives au consentement de l'utilisateur dans l'UE ou si d'autres paramètres de consentement sont disponibles dans la demande (gdpr_consent), ce paramètre est ignoré.

Exemple : process_consent=T

Paramètre Description
google_error

Valeur entière indiquant l'erreur globale de la requête. Lorsqu'il est reçu, il indique qu'aucune opération n'a été effectuée et qu'aucun autre paramètre de réponse google_ ne sera défini. Les valeurs d'erreur acceptées sont les suivantes:

  • 1: l'utilisateur dispose d'un cookie Google, mais a désactivé tout suivi à l'aide de ce cookie.
  • 2: aucune opération valide n'a été spécifiée. Par exemple, une requête sans opération a été reçue.
  • 3: l'utilisateur ne dispose pas de cookie Google. Google ne définira pas le cookie via le service de mise en correspondance des cookies.
  • 4: opérations en conflit spécifiées. Vous n'êtes pas autorisé à spécifier à la fois les indicateurs google_push et google_cm dans la même requête, car ils ont des objectifs contradictoires.
  • 5: un paramètre google_push non valide a été transmis dans une redirection vers un serveur Google dans le cadre d'une requête de mise en correspondance des pixels bidirectionnelle. Votre redirection doit définir google_push sur la même valeur qui vous a été transmise dans la requête de pixel initiale.
  • 6: un NID non valide a été fourni dans la balise de correspondance.
  • 7: un cookie non valide a été détecté.
  • 8: obsolète. Aucun cookie n'a été trouvé.
  • 9: aucun cookie n'a été trouvé. Une tentative de définition d'un cookie de test est effectuée.
  • 10: le paramètre google_redir a été utilisé sans que google_hm ne soit spécifié ou en plus de google_cm.
  • 15: la requête provient d'une région où Google exige que la table des correspondances soit hébergée par Google. Par conséquent, cette réponse ne contient pas d'ID utilisateur Google. Cette fonctionnalité n'est actuellement activée que pour un faible pourcentage du trafic, mais elle devrait être complètement activée en juin 2020.

Initiée par Google: mise en correspondance bidirectionnelle des pixels

La mise en correspondance bidirectionnelle des pixels est un workflow du service de mise en correspondance des cookies de Google. Google tente de faire correspondre un ID utilisateur Google à un enchérisseur sélectionné par algorithme autre que le gagnant de l'enchère en temps réel. Lorsqu'une annonce est diffusée, Google place une balise de correspondance qui indique au navigateur de l'utilisateur de charger un pixel transparent à partir de l'URL de correspondance des cookies de l'enchérisseur choisi. Cela permettra à Google et à l'enchérisseur d'insérer des données dans un tableau de correspondance pour un utilisateur donné. Vous trouverez ci-dessous un exemple simple de ce workflow.

Étape 1: Google place une balise de correspondance

Lorsque la page d'un éditeur participant se charge dans le navigateur de l'utilisateur et que Google remplit un espace publicitaire sur cette page, une balise de correspondance peut être placée pour demander un pixel à un enchérisseur sélectionné par un algorithme. La balise de mise en correspondance des pixels placée par Google combine l'URL de mise en correspondance des cookies de l'enchérisseur avec des paramètres supplémentaires que l'enchérisseur peut utiliser pour renseigner son tableau de correspondance. Pour une URL de mise en correspondance des cookies spécifiée comme https://ad.network.com/pixel, elle est structurée comme suit:

<img src="https://ad.network.com/pixel?google_gid=GOOGLE_GID&google_cver=1&google_push=PUSH_DATA" />

Les enchérisseurs qui reçoivent des requêtes de mise en correspondance des pixels doivent répondre par une redirection vers le service de mise en correspondance des cookies de Google, structuré comme suit:

https://cm.g.doubleclick.net/pixel?google_nid=GOOGLE_NID&google_push=PUSH_DATA

Notez que l'URL de redirection ci-dessus est semblable à celle utilisée dans la balise de correspondance pour le workflow de mise en correspondance des cookies par l'enchérisseur. Dans la mise en correspondance de pixels, le paramètre google_cm est remplacé par le paramètre google_push. Sa valeur doit être égale à celle fournie par Google dans la requête. Comme pour le workflow initié par l'enchérisseur, vous pouvez spécifier des paramètres supplémentaires pour traiter des cas d'utilisation supplémentaires.

Étape 3: Google traite la redirection et répond par pixel

Google consigne qu'une correspondance a été créée pour l'utilisateur et gère toutes les opérations supplémentaires demandées via des paramètres de requête. Enfin, Google répond avec un pixel transparent de 1 x 1.

Schéma du workflow de mise en correspondance des pixels

Ce workflow est illustré par le diagramme ci-dessous, où les requêtes et les réponses sont représentées par une flèche, et les éléments de données qui les accompagnent sont indiqués entre parenthèses.

Paramètres de requête de la balise Google Match

Paramètre Description
google_gid ID utilisateur Google Pour les utilisateurs qui ne résident pas dans un État américain soumis à des restrictions de confidentialité, cela sera toujours spécifié dans la balise de correspondance de Google.
google_cver Version du cookie. Ce paramètre est toujours spécifié dans la balise de correspondance de Google.
google_push Indique que cette requête lance le workflow de mise en correspondance des pixels. La valeur doit être renvoyée via le paramètre correspondant dans la réponse de redirection de l'enchérisseur.
gdpr_consent Une chaîne TC qui représente le consentement de l'utilisateur final. Pour en savoir plus, consultez les [exigences concernant le consentement des utilisateurs dans l'UE](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) ci-dessous ou la section **Comment la chaîne TC sera-t-elle transmise ?** dans la [documentation sur la version 2.0 du TCF de l'IAB pour Authorized Buyers](//support.google.com/authorizedbuyers/answer/9789378).

Paramètres de redirection de la mise en correspondance des pixels de l'enchérisseur

Paramètre Description
google_nid ID de réseau (NID) du compte d'enchérisseur. Cet ID peut être récupéré via la ressource Enchères.
google_push Indique que cette redirection termine le workflow de mise en correspondance des pixels. La valeur de la balise de correspondance Google correspondante doit être spécifiée ici.
google_hm

Contient les données que l'enchérisseur souhaite stocker dans une table de correspondance hébergée par Google.

google_ula Chaîne utilisée pour ajouter l'utilisateur à une liste d'utilisateurs existante. Le format attendu pour cette valeur est userlistid[,timestamp] :
  • userlistid: un seul ID numérique de liste d'utilisateurs.
  • timestamp: code temporel facultatif au format POSIX, indique quand l'utilisateur a été ajouté à la liste des utilisateurs.

Ce paramètre d'URL peut être répété pour ajouter l'utilisateur à plusieurs listes.

gdpr_consent Chaîne TC représentant le consentement de l'utilisateur final. Pour en savoir plus, consultez [Exigences concernant le consentement des utilisateurs dans l'UE](/authorized-buyers/rtb/cookie-guide#eu-user-consent-requirements) ci-dessous ou la section **Comment la chaîne TC sera-t-elle transmise ?** dans la [documentation sur la version 2.0 du TCF de l'IAB pour Authorized Buyers](//support.google.com/authorizedbuyers/answer/9789378).

Initiée par Google: mise en correspondance unidirectionnelle des pixels

La mise en correspondance de pixels unidirectionnelle diffère du workflow bidirectionnel dans la mesure où la balise de correspondance de Google n'inclut pas de paramètre spécifiant l'ID utilisateur Google, mais continue à remplir une table des correspondances hébergée par Google. Cette option peut être utilisée lorsque l'enchérisseur n'est pas autorisé à héberger des ID utilisateur Google dans sa propre table de correspondance. Un exemple simple du workflow révisé est résumé dans les étapes ci-dessous.

Étape 1: Google place une balise de correspondance

Google place une balise de correspondance pour un enchérisseur sélectionné par algorithme. La balise de correspondance inclut le paramètre google_push. Exemple :

<img src="https://ad.network.com/pixel?google_push=PUSH_DATA" />

Étape 2: Le navigateur de l'utilisateur demande un pixel à l'URL Cooking Matching de l'enchérisseur

Le navigateur de l'utilisateur demande un pixel à partir de l'URL de mise en correspondance des cookies de l'enchérisseur, y compris le cookie de l'enchérisseur dans les en-têtes HTTP.

Le point de terminaison de la mise aux enchères par correspondance des cookies doit rediriger vers le service de correspondance des cookies de Google, y compris le paramètre google_hm renseigné avec ses données de cookie encodées en base64 adaptées au Web. L'URL de redirection peut se présenter comme suit:

https://cm.g.doubleclick.net/pixel?google_nid=BIDDER_ACCOUNT_NID&google_hm=HOSTED_MATCH_DATA&google_push=PUSH_DATA

Google recevra une redirection contenant les paramètres que vous avez spécifiés, en plus du cookie de Google dans les en-têtes HTTP. Si l'opération a réussi, les impressions de cet utilisateur dans les demandes d'enchères suivantes incluront les données de ciblage hébergées de l'enchérisseur dans BidRequest.user.buyeruid pour OpenRTB ou BidRequest.hosted_match_data pour le protocole Google RTB obsolète. Les enchérisseurs peuvent également renseigner des listes d'utilisateurs à l'aide des données de correspondance hébergées qu'ils ont spécifiées.

Enfin, Google renvoie un pixel transparent de 1 x 1 pixel au navigateur de l'utilisateur.

Open Bidding permet aux places de marché d'utiliser des workflows de mise en correspondance des cookies initiés par l'enchérisseur et initiés par Google pour mettre en correspondance un ID utilisateur Google avec son cookie. Cookie Match Assist (CMA) est une fonctionnalité supplémentaire pour les places de marché qui leur permet de créer des tables de correspondance avec leurs propres enchérisseurs.

  1. Lorsque vous placez une annonce, Google sélectionne de manière algorithmique une place de marché participante et place une balise Cookie Match Assist dont la structure est la suivante:

    <img src="https://ob.exchange.com/pixel?google_gid=GOOGLE_GID&google_cver=1"/>
  2. La balise de correspondance CMA de Google entraîne la réception d'une demande de pixel par l'URL de mise en correspondance des cookies de la place de marché.

  3. Le point de terminaison de la mise en correspondance des cookies de la place de marché reçoit la requête, où son propre service de mise en correspondance des cookies est chargé de faire correspondre l'ID utilisateur à l'un de ses enchérisseurs. Dans le schéma ci-dessous, le service de mise en correspondance des cookies de la place de marché répond au navigateur de l'utilisateur par une redirection vers l'un des points de terminaison de son enchérisseur.
  4. L'enchérisseur reçoit la requête, ainsi que les paramètres spécifiés par la place de marché pour faire correspondre l'ID utilisateur à son cookie.

Restrictions

Limiter la fréquence des requêtes de correspondances récentes

Les enchérisseurs sont tenus de limiter le nombre d'appels au service de cookie matching pour les utilisateurs qui ont une entrée récente dans la table de correspondance hébergée par Google. Une entrée de la table de correspondances hébergée peut être considérée comme expirée au bout de 14 jours, après quoi elle peut être actualisée.

Répondre à toutes les demandes de mise en correspondance de pixels

Les enchérisseurs qui utilisent le workflow de mise en correspondance des pixels doivent répondre à toutes les requêtes entrantes de mise en correspondance des pixels avec une réponse incluant le paramètre google_push. Cela permet à Google d'appliquer les règles en surveillant l'utilisation. Si le taux de réponse d'un enchérisseur passe sous 90%, Google limite le nombre de requêtes Pixel Match envoyées à son compte.

Utiliser des points de terminaison HTTPS

Les points de terminaison utilisés dans tous les workflows de lecture des cookies doivent utiliser le protocole HTTPS.

Lorsque vous répondez à une requête Pixel Match qui vous est envoyée via HTTPS, vous devez rediriger vers le service de mise en correspondance des cookies via HTTPS. De même, un point de terminaison Cookie Match Assist qui redirige vers des enchérisseurs doit également utiliser HTTPS. Si vous envoyez des requêtes à Google via HTTP plus d'une fois toutes les deux minutes, le nombre de requêtes de correspondance envoyées à votre compte sera limité.

Les demandes de mise en correspondance des cookies soumises aux Règles de Google relatives au consentement de l'utilisateur dans l'UE doivent indiquer le consentement de l'utilisateur final. Ces requêtes doivent indiquer que le consentement a été recueilli de l'une des manières suivantes:

Exemples

Les exemples ci-dessous montrent comment utiliser le service de mise en correspondance des cookies pour atteindre des objectifs spécifiques. Sauf indication contraire, nous partons du principe que l'utilisateur concerné ne réside pas dans un État américain soumis à des restrictions de confidentialité.

Remplir un tableau de correspondance hébergé par l'enchérisseur

Un enchérisseur peut utiliser le workflow de mise en correspondance des cookies pour renseigner sa propre table de correspondance en ne fournissant que les paramètres google_nid et google_cm dans sa balise de correspondance. Cela peut se présenter comme suit :

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_cm" />

Si l'URL de mise en correspondance des cookies de l'enchérisseur est définie sur https://ad.network.com/pixel?id=1 et que l'opération de mise en correspondance des cookies aboutit, la redirection que Google envoie en réponse à la balise de mise en correspondance de l'enchérisseur peut se présenter comme suit:

https://ad.network.com/pixel?id=1&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1

Si l'opération de mise en correspondance des cookies échoue, car l'utilisateur ne dispose pas de cookie Google, la réponse est la suivante:

https://ad.network.com/pixel?id=1&google_error=3

Le code d'erreur dépend de la cause sous-jacente de l'erreur. Pour en savoir plus sur les codes d'erreur possibles pour le workflow de lecture des cookies, consultez les paramètres d'URL de redirection.

Ajouter à la liste d'un seul utilisateur

Le paramètre google_ula peut être spécifié dans la balise de correspondance d'un enchérisseur pour ajouter l'utilisateur à une liste d'utilisateurs avec l'ID donné. Si la table de correspondance Google ou hébergée par l'enchérisseur contient une nouvelle entrée pour l'utilisateur, l'enchérisseur peut placer une balise de correspondance incluant les paramètres google_nid et google_ula pour ajouter l'utilisateur à la liste spécifiée sans lancer le workflow complet de mise en correspondance des cookies. Pour en savoir plus, consultez les restrictions concernant l'appel du service de mise en correspondance des cookies. La balise de correspondance correspondante peut se présenter comme suit:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345" />

Pour une réponse positive, lorsque l'URL de mise en correspondance des cookies de l'enchérisseur est https://ad.network.com/pixel, l'URL de redirection de Google est la suivante:

https://ad.network.com/pixel?google_ula=12345,0

En cas d'erreur globale (par exemple, s'il n'y a pas de cookie Google pour l'utilisateur), l'URL de redirection inclut le paramètre google_error:

  • https://ad.network.com/pixel?google_error=3

Si une erreur concerne spécifiquement l'ajout de l'utilisateur à la liste, vous recevrez google_ula dans la redirection. Contrairement au paramètre de balise de correspondance correspondant, celui-ci remplace le code temporel par un code d'état pour indiquer la réussite de l'opération. Par exemple, si la requête a échoué parce que le compte de l'enchérisseur n'avait pas accès à la liste d'utilisateurs spécifiée, l'URL de redirection est la suivante:

https://ad.network.com/pixel?google_ula=12345,2

Ajouter à plusieurs listes d'utilisateurs

Les enchérisseurs peuvent spécifier qu'un utilisateur doit être ajouté à plusieurs listes d'utilisateurs en incluant plusieurs paramètres google_ula dans la balise de correspondance. En pratique, cela peut se présenter comme suit:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345,7654321&google_ula=45678" />

L'état de l'opération pour chaque liste d'utilisateurs est également signalé via des paramètres google_ula distincts dans la redirection:

https://ad.network.com/pixel?google_ula=12345,2&google_ula=45678,0

Dans la redirection ci-dessus, nous pouvons voir que l'opération a réussi pour la liste d'utilisateurs avec l'ID 45678, mais a échoué pour l'ID de liste d'utilisateurs 12345, car l'enchérisseur n'était pas autorisé à y accéder.

Pour effectuer la mise en correspondance des cookies et ajouter l'utilisateur à une liste d'utilisateurs en une seule requête, la balise de correspondance d'un enchérisseur doit inclure google_cm et google_ula:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=ad_network_xyz&google_ula=12345&google_cm" />

L'URL de redirection spécifiée par Google doit inclure google_gid, google_cver et google_ula. Cela peut se présenter comme suit:

https://ad.network.com/pixel?id=&google_gid=dGhpcyBpcyBhbiBleGFtGxl&google_cver=1&google_ula=12345,0

Stocker une correspondance dans une table des correspondances hébergée par Google

Si un enchérisseur souhaite stocker ses données de cookie dans une table de correspondance hébergée par Google et qu'il n'a pas l'intention de stocker la correspondance avec l'ID utilisateur Google dans sa propre table de correspondance, sa balise de correspondance doit inclure le paramètre google_hm, dont la valeur doit être une chaîne encodée en base64 adaptée au Web. Pour un utilisateur dont les données de cookie non encodées du demandeur sont Cookie number 1!, la valeur encodée est Q29va2llIG51bWJlciAxIQ==, qui sera utilisée dans une balise de correspondance comme celle-ci:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D" />

Pour une réponse positive, lorsque l'URL de mise en correspondance des cookies de l'enchérisseur est https://cookie-monster.com/pixel, l'URL de redirection de Google est la suivante:

https://cookie-monster.com/pixel

Le paramètre google_gid ne figure pas dans la redirection, car la balise de correspondance n'incluait pas google_cm, et google_hm n'est pas inclus dans les réponses réussies. Dans les futures demandes d'enchères pour les impressions de cet utilisateur, l'enchérisseur recevra ses données de ciblage hébergées dans BidRequest.user.buyeruid pour OpenRTB ou BidRequest.hosted_match_data pour le protocole Google RTB obsolète.

Si l'enchérisseur a utilisé une balise de correspondance dans laquelle la valeur de google_hm n'était pas encodée en base64 (par exemple, chocolate_chunk!), l'URL de redirection pourrait se présenter comme suit:

https://cookie-monster.com/pixel?google_hm=2

L'URL de redirection ci-dessus inclut une valeur google_hm de 2, ce qui suggère que l'opération a échoué, car la valeur n'a pas pu être décodée.

Tables de correspondance de l'enchérisseur et hébergées par Google avec des listes d'utilisateurs

Si un enchérisseur héberge sa propre liste d'utilisateurs en plus d'une liste d'utilisateurs hébergée par Google, et souhaite qu'une seule balise de correspondance corresponde aux deux tables et ajoute l'utilisateur à une liste d'utilisateurs donnée, sa balise de correspondance doit inclure les paramètres google_cm, google_hm et google_ula. Si les données de cookie de l'enchérisseur sont Cookie number 1!, la valeur encodée sera Q29va2llIG51bWJlciAxIQ==, ce qui produira une balise de correspondance comme suit:

<img src="https://cm.g.doubleclick.net/pixel?google_nid=cookie-monster&google_hm=Q29va2llIG51bWJlciAxIQ%3D%3D&google_cm&google_ula=12345" />

Pour une réponse positive, où l'URL de mise en correspondance des cookies de l'enchérisseur est https://cookie-monster.com/pixel, l'URL de redirection de Google doit se présenter comme suit:

https://cookie-monster.com/pixel?google_gid=ABCDETC&google_cver=1&google_ula=12345,0

À la réception de la redirection, l'enchérisseur peut faire correspondre l'ID utilisateur Google spécifié dans google_gid avec les données de ses cookies dans sa table des correspondances. De plus, il peut déterminer que les opérations de table de correspondance et de liste d'utilisateurs hébergées par Google ont bien été effectuées. Par conséquent, tout préciblage de l'enchérisseur configuré pour cibler l'ID de la liste d'utilisateurs spécifié entraînera désormais la réception de demandes d'enchères pour les impressions de l'utilisateur. De même, dans ces demandes d'enchères, l'enchérisseur recevra ses données de ciblage hébergées dans BidRequest.user.buyeruid pour OpenRTB ou BidRequest.hosted_match_data pour le protocole RTB Google obsolète.