Mise en correspondance des cookies

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

La mise en correspondance des cookies vous permet de faire correspondre votre cookie (par exemple, l'identifiant d'un utilisateur qui a consulté votre site Web) à un ID utilisateur Google spécifique à l'enchérisseur et de créer des listes d'utilisateurs qui vous aident à prendre des décisions d'enchères plus efficaces. Ce guide décrit les concepts liés à la mise en correspondance des cookies, ainsi que les différents workflows de mise en correspondance des cookies. Il décrit également les variantes possibles pour certains cas d'utilisation.

Concepts

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

Dans le contexte de la publicité numérique, Google identifie les utilisateurs avec des 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 pour lesquels ils souhaitent diffuser des annonces. La mise en correspondance des cookies permet à l'enchérisseur de faire correspondre ses cookies à ceux de Google afin de 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 spécifique à 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. Il permet également de renseigner les listes d'utilisateurs.

Tableaux de correspondance

Un tableau de correspondance permet de mapper un ID ou d'autres données d'un domaine à un autre. Les enchérisseurs peuvent utiliser le service de mise en correspondance des cookies pour renseigner leurs propres tableaux de correspondance en mappant leur cookie pour un utilisateur donné à l'ID utilisateur Google de l'utilisateur ou pour remplir un tableau de correspondance hébergé par Google. Les tableaux de correspondance sont nécessaires pour que l'application d'enchères d'un enchérisseur puisse accéder aux données des cookies de l'utilisateur qui voit l'impression.

Tableaux de correspondance hébergés par Google

Pour faciliter la maintenance, améliorer la latence et mettre en correspondance les données des 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 encodée en base64 adaptée au Web (ci-après dénommée "données de correspondance hébergées") qui sera mappée à l'ID utilisateur Google pour un utilisateur donné. Une fois qu'une correspondance a été établie, elle peut être utilisée comme suit:

  • 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 correspondant à son ID utilisateur Google. Si votre point de terminaison d'enchères est configuré pour utiliser le protocole RTB de Google, vous le recevrez en tant qu'octets décodés via le champ BidRequest.hosted_match_data. Dans l'implémentation OpenRTB de Google, BidRequest.user.buyeruid renvoie ces données sous la forme d'une chaîne au format base64 adaptée au Web.

  • Listes d'utilisateurs: les listes d'utilisateurs peuvent contenir 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. Cela permet d'éliminer les impressions moins pertinentes pour les utilisateurs situés 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 avec les 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 pour la mise en correspondance des cookies : ID de chaîne qui identifie de manière unique un compte d'enchérisseur pour la mise en correspondance des cookies et les autres opérations associées.
  • URL de mise en correspondance des cookies : URL de base d'un point de terminaison qui acceptera et traitera les requêtes entrantes dans les workflows de mise en correspondance des cookies. Les enchérisseurs peuvent intégrer des macros dans cette URL afin de contrôler l'ordre des paramètres qui lui sont transmis dans les workflows de mise en correspondance des cookies.
  • Balise de correspondance : balise que vous devez placer dans le navigateur de l'utilisateur pour le processus de mise en correspondance des cookies initié par l'enchérisseur. Elle peut être diffusée à côté d'annonces, ou être placée sur des propriétés Web en dehors de celles-ci.
  • URL de rapport de mise en correspondance des cookies (facultatif): dans le workflow unidirectionnel de mise en correspondance des cookies, vous pouvez fournir cette URL pour spécifier un point de terminaison qui recevra les détails des erreurs en cas d'échec de la mise en correspondance des cookies via une redirection HTTP 302. Par défaut, les réponses ne sont envoyées à cette URL qu'en cas d'erreur lors de la mise en correspondance des cookies. Toutefois, les enchérisseurs peuvent demander que la redirection soit toujours envoyée.
  • URL de mise en correspondance des cookies: pour les places de marché qui mettent en œuvre le workflow de mise en correspondance des cookies, il s'agit de l'URL de base du point de terminaison destiné à répondre aux requêtes entrantes.
  • Quota d'assistance à la mise en correspondance des cookies: pour les places de marché qui mettent en œuvre le workflow de mise en correspondance des cookies, il s'agit du nombre maximal de demandes que leur URL de mise en correspondance des cookies peut recevoir chaque seconde. Cela permet d'é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, les paramètres d'URL de mise en correspondance des cookies d'un enchérisseur sont généralement ajoutés 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 sous la forme %%GOOGLE_<PARAM_NAME>%% ou %%GOOGLE_<PARAM_NAME>_PAIR%%. Les macros compatibles 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
ASSOCIATION_GOOGLE_PUSH &google_push=PIXEL_MATCH_DATA
PARAMÈTRES 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. Sa mise en œuvre nécessite la réinitialisation des paramètres 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 doit définir son URL de mise en correspondance des cookies comme suit:

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 demande de mise en correspondance à cet enchérisseur, celle-ci sera remplacée par la suivante:

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 mise en correspondance des cookies de Google accepte actuellement trois flux de travail pour différents cas d'utilisation décrits ci-dessous.

La mise en correspondance des cookies bidirectionnel fait référence à un flux de travail initié par l'enchérisseur, qui consiste à placer une balise de correspondance dans le navigateur de l'utilisateur qui la redirige vers Google. Ce processus permet à Google et à l'enchérisseur de renseigner des tableaux de correspondance. Vous trouverez ci-dessous un exemple simple de ce workflow.

Étape 1: Insérez la balise de correspondance

Pour lancer ce processus, 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 l'ID utilisateur Google qu'à 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 des paramètres supplémentaires dans la balise de correspondance pour répondre à différents cas d'utilisation. Pour en savoir plus sur ces paramètres, consultez Faire correspondre les paramètres d'URL du tag.

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

La balise de lecture des cookies enverra une requête du service de mise en correspondance des cookies de Google au navigateur de l'utilisateur, qui enverra une redirection HTTP 302 à 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 pour la balise de correspondance simple, comme ci-dessus, pourrait 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. Nous recommandons aux enchérisseurs qui hébergent un tableau de correspondance de stocker la chaîne exacte renvoyée par le service de mise en correspondance des cookies. Dans les requêtes d'enchères suivantes, il s'agira des valeurs spécifiées via BidRequest.google_user_id dans le protocole RTB de Google ou par BidRequest.user.id dans l'implémentation OpenRTB de Google.

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é est rarement modifié, après quoi il est incrémenté.

Si Google rencontre une erreur lors du traitement de votre requête de correspondance, un paramètre google_error est spécifié.

Étape 3: L'enchérisseur traite les redirections et y 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 que Google a fournis à la deuxième étape. En outre, ils reçoivent leur cookie dans les en-têtes HTTP. Si l'opération a abouti, un enchérisseur hébergeant son propre tableau de correspondance peut faire correspondre son cookie à l'ID utilisateur Google inclus dans la réponse. Il est recommandé aux enchérisseurs de stocker la chaîne exacte renvoyée par le service de mise en correspondance des cookies.

Si l'opération échoue, l'enchérisseur recevra 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 vous recevez un message d'erreur, vous pouvez tenter d'établir une nouvelle correspondance pour cet utilisateur en associant une nouvelle balise de correspondance.

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

Ce workflow est illustré par le diagramme 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 répertoriés entre parenthèses.

Correspondance avec les paramètres d'URL de la balise

Paramètre Description
google_nid ID de réseau (NID) du compte de l'enchérisseur. Cet ID peut être récupéré dans le champ cookieMatchingNid des comptes de l'API REST pour acheteur.
google_cm Indique au service de mise en correspondance des cookies de Google qu'il doit effectuer la 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 si aucun cookie n'est présent. La valeur du paramètre est ignorée et peut être omise. Si ce paramètre n'est pas défini, une erreur se produit en l'absence de cookie.
google_no_sc Ce paramètre est obsolète. Cela indique au service de lecture des cookies que Google ne doit pas définir de cookie pour l'utilisateur si aucun cookie n'est présent. La valeur du paramètre est ignorée et peut être omise.
google_hm

Données que l'enchérisseur souhaite stocker dans un tableau de correspondance hébergé par Google.

La valeur est une chaîne au format base64 adaptée au Web (remplissage facultatif). Les données brutes ne doivent pas dépasser 40 octets. Par exemple, Q29va2llIHRoYXQgaXMgdW5kZXIgNDAgdG90YWwgYnl0ZXMuLi4u.

google_redir Chaîne encodée au format URL qu'un enchérisseur peut indiquer s'il veut que Google envoie la redirection HTTP 302 vers l'URL encodée pour cette balise de correspondance. Cela permet à Google d'être placé au début d'un appel enchaîné avec les partenaires. Cette erreur entraîne une erreur si elle est spécifiée sans google_hm ou avec google_cm.
google_ula Chaîne permettant d'ajouter l'utilisateur à une liste d'utilisateurs existante. Le format attendu est userlistid[,timestamp] :
  • userlistid : un ID numérique de liste d'utilisateurs unique.
  • timestamp : horodatage facultatif au format POSIX qui indique à quel moment l'utilisateur a été ajouté à la liste d'utilisateurs.

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

En plus des paramètres ci-dessus, les enchérisseurs peuvent spécifier les leurs, lesquels seront ajoutés à l'URL de redirection en tant que paramètres. 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 ultérieur. La conservation des paramètres n'est pas garantie. Voici à quoi peut ressembler une balise de correspondance incluant des paramètres définis par l'enchérisseur:

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

Paramètres de l'URL de redirection

L'URL de redirection est créée à partir de l'URL de base de 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 qu'elle a abouti.
google_cver Version du cookie. Défini si google_cm est spécifié dans la requête et qu'elle a abouti.
google_error

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

  • 1: l'utilisateur possède un cookie Google, mais a désactivé tout suivi au moyen de ce cookie.
  • 2 : aucune opération valide n'a été spécifiée. Par exemple, une requête no-op a été reçue.
  • 3: l'utilisateur ne possède pas de cookie Google. Google ne définira pas le cookie via le service de mise en correspondance des cookies.
  • 4: opérations spécifiées en conflit. Vous n'êtes pas autorisé à spécifier les options google_push et google_cm dans la même requête, car leurs objectifs sont 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 Pixel Match bidirectionnelle. Votre redirection doit définir google_push sur la même valeur que celle 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 trouvé.
  • 9: aucun cookie trouvé. Une tentative de définition d'un cookie de test a été effectuée.
  • 10: le paramètre google_redir a été utilisé sans google_hm spécifié, ou en plus de google_cm.
  • 15 : la requête provient d'une région où Google exige que le tableau de correspondance soit hébergé par Google. Par conséquent, cette réponse ne contient pas d'ID utilisateur Google. Cette fonctionnalité n'est actuellement disponible que pour un petit pourcentage du trafic, mais devrait être complètement opérationnelle en juin 2020.
google_hm

S'affiche uniquement si la tentative d'écriture dans le tableau de correspondance hébergé 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 pour pouvoir écrire des entrées de tableau de correspondance 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: la 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 - Ralentissement: cette écriture n'a pas été traitée en raison d'une limitation.
google_ula

État de l'opération d'ajout à 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

Par exemple : 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 d'utilisateurs.
  • 2 : autorisation refusée. Vous n'êtes pas autorisé à ajouter des utilisateurs à la liste d'utilisateurs indiquée.
  • 5 : ID de liste d'utilisateurs incorrect. L'ID de liste d'utilisateurs fourni n'est pas valide.
  • 6 : attribut fermé. L'ID de liste d'utilisateurs fourni est fermé.
  • 10 : erreur interne. Le service de mise en correspondance des cookies a rencontré une erreur interne. Vous pouvez essayer d'associer à nouveau l'utilisateur.

Les scénarios suivants décrivent la mise en correspondance des cookies pour un utilisateur type parcourant une page Web.

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

Jeanne vide le cache de tous les cookies. Ils accèdent ensuite à la page d'accueil d'ExampleNews.com.

Conséquences :

  1. ExampleNews.com s'affiche et appelle les annonces de Google (Ad Manager).
  2. Étant donné que 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ères de FinestDSP reçoit et traite la demande d'enchère, puis envoie sa réponse.
  4. Google reçoit des réponses aux enchères de la part des enchérisseurs, y compris la réponse de FinestDSP qui spécifie une annonce avec une balise de correspondance (pixel).
  5. FinestDSP remporte la mise aux enchères. Google diffuse l'annonce FinestDSP et associe la balise à Jeanne.
  6. La balise de correspondance appelle le service de lecture des cookies de Google, en spécifiant les paramètres google_nid et google_cm.
  7. Le service de lecture des cookies lit les cookies Google de Jeanne et envoie une redirection au navigateur de Jeanne vers l'URL de mise en correspondance des cookies de FinestDSP avec les paramètres google_user_id et google_cver définis.
  8. Le navigateur de Jeanne charge la redirection vers l'URL de lecture des cookies de FinestDSP.
  9. FinestDSP traite les requêtes de redirection, qui incluent les paramètres d'URL définis par Google et leur cookie pour Jeanne dans les en-têtes HTTP. FinestDSP peut désormais stocker le mappage de son cookie sur google_user_id dans le tableau de correspondance.
  10. FinestDSP répond à la redirection avec un pixel invisible "1x1".
Scénario 2: Utilisateur avec mappage existant

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

  1. La page Web s'affiche. Google (Ad Manager) demande donc les annonces qui seront diffusées sur la page.
  2. Lors de la mise aux enchères, Google envoie une demande d'enchère aux enchérisseurs concernés, y compris FinestDSP.
  3. FinestDSP reçoit la demande d'enchère, y compris des signaux tels que google_user_id.
  4. FinestDSP recherche le google_user_id dans son tableau de correspondance et trouve le cookie associé à Jeanne qui a été créé une semaine plus tôt (scénario 1).
  5. En fonction des informations associées au cookie, la logique d'enchères de FinestDSP définit une enchère sur l'impression et remporte la mise aux enchères.
  6. Jeanne peut voir une annonce adaptée à ses centres d'intérêt, selon les informations détenues par FinestDSP.

La mise en correspondance des cookies unidirectionnel est semblable au workflow bidirectionnel, si ce n'est qu'elle est modifiée de sorte que seul Google héberge et remplit un tableau de correspondance. Cela peut être utilisé dans les cas où l'enchérisseur n'est pas autorisé à héberger des ID utilisateur Google dans son propre tableau de correspondance. Pour utiliser ce flux, les enchérisseurs doivent autoriser Google à héberger le tableau de correspondance, ne peuvent plus spécifier google_cm dans les requêtes envoyées au service de mise en correspondance des cookies de Google et ne reçoivent donc pas google_gid pour remplir leur propre tableau de correspondance. Une fois que Google a établi une correspondance pour un utilisateur, les enchérisseurs peuvent l'ajouter aux listes d'utilisateurs à l'aide de leurs propres données sur les cookies. De même, les demandes d'enchères pour ces utilisateurs excluent le User-ID Google, mais incluent les données de correspondance hébergées. Un exemple simple de workflow révisé est résumé ci-dessous.

Pour lancer ce processus, un enchérisseur doit placer une balise de correspondance de sorte qu'il s'affiche dans le navigateur de l'utilisateur. Contrairement au flux de travail pour les utilisateurs situés en dehors de la Californie, la balise de correspondance doit rediriger le navigateur des utilisateurs vers votre URL de lecture des cookies. Par exemple, avec une URL de mise en correspondance des cookies configurée en tant que 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, celui-ci 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 devra ê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 contenant ses données de cookies encodées en base64 et 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 un pixel en cas de réussite ou de redirection 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 de mise en correspondance des cookies n'a été spécifiée pour le compte du système d'enchères, Google diffuse un pixel transparent de 1 x 1 par défaut. Le workflow s'arrête ici. Les impressions pour cet utilisateur dans les demandes d'enchères ultérieures incluront les données de correspondance hébergées par l'enchérisseur dans BidRequest.hosted_match_data pour le protocole Google ou BidRequest.user.buyeruid pour l'implémentation OpenRTB de Google. 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.

Sinon, si une erreur s'est produite, Google envoie une redirection à l'URL du rapport sur la mise en correspondance des cookies de l'enchérisseur et la cause de l'erreur spécifiée 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 redirigera 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 sur le navigateur de l'utilisateur.

Le workflow par défaut pour les utilisateurs de Californie est illustré par le schéma 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 de l'enchérisseur. Cet ID peut être récupéré dans le champ cookieMatchingNid des comptes de l'API REST pour acheteur.
google_sc Ce paramètre est obsolète. Définit le cookie de Google pour l'utilisateur si aucun cookie n'est présent. La valeur du paramètre est ignorée et peut être omise. Si ce paramètre n'est pas défini, une erreur se produit en l'absence de cookie.
google_no_sc Ce paramètre est obsolète. Cela indique au service de lecture des cookies que Google ne doit pas définir de cookie pour l'utilisateur si aucun cookie n'est présent. 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 un tableau de correspondance hébergé par Google.

google_redir URL codée à laquelle Google doit envoyer 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 permettant d'ajouter l'utilisateur à une liste d'utilisateurs existante. Le format attendu est userlistid[,timestamp] :
  • userlistid : un ID numérique de liste d'utilisateurs unique.
  • timestamp: horodatage facultatif au format POSIX qui indique à quel moment l'utilisateur a été ajouté à la liste d'utilisateurs.

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

Paramètre Description
google_error

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

  • 1 : l'utilisateur possède un cookie Google, mais a désactivé tout suivi au moyen de ce cookie.
  • 2 : aucune opération valide n'a été spécifiée. Par exemple, une requête no-op a été reçue.
  • 3: l'utilisateur ne possède pas de cookie Google. Google ne définira pas le cookie via le service de mise en correspondance des cookies.
  • 4: opérations spécifiées en conflit. Vous n'êtes pas autorisé à spécifier les options google_push et google_cm dans la même requête, car leurs objectifs sont 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 Pixel Match bidirectionnelle. Votre redirection doit définir google_push sur la même valeur que celle 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 trouvé.
  • 9 : aucun cookie trouvé. Une tentative de définition d'un cookie de test a été effectuée.
  • 10: le paramètre google_redir a été utilisé sans google_hm spécifié, ou en plus de google_cm.
  • 15: la requête provient d'une région où Google exige que le tableau de correspondance soit hébergé par Google. Par conséquent, cette réponse ne contient pas d'ID utilisateur Google. Cette fonctionnalité n'est actuellement disponible que pour un petit pourcentage du trafic, mais devrait être complètement opérationnelle en juin 2020.

Déclenchement par Google: mise en correspondance des pixels bidirectionnelle

La mise en correspondance des pixels bidirectionnelle est un processus pour le service de mise en correspondance des cookies de Google, dans lequel Google tente de faire correspondre un ID utilisateur Google à un enchérisseur sélectionné par un algorithme autre que le vainqueur des enchères en temps réel. Lorsqu'une annonce est placée, Google insère une balise de correspondance qui redirige le navigateur de l'utilisateur afin qu'il charge un pixel transparent à partir de l'URL de mise en correspondance des cookies choisie par l'enchérisseur. Google et l'enchérisseur peuvent ainsi remplir un tableau de correspondance avec un utilisateur donné. Vous trouverez ci-dessous un exemple simple de ce workflow.

Étape 1: Google insère une balise de correspondance

Lorsqu'une page d'un éditeur participant se charge dans le navigateur de l'utilisateur et qu'un espace publicitaire de cette page est rempli par Google, une balise de correspondance peut être placée et demande un pixel à un enchérisseur sélectionné à l'aide d'un algorithme. La balise de mise en correspondance des pixels placée par Google associe l'URL de mise en correspondance des cookies de l'enchérisseur à 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 par 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 demandes 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 à l'URL utilisée dans la balise de correspondance du workflow de mise en correspondance des cookies initié par l'enchérisseur. Dans Pixel Matching, le paramètre google_cm est remplacé par le paramètre google_push, et sa valeur doit être identique à 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 répondre à des cas d'utilisation supplémentaires.

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

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

Schéma du workflow Pixel Matching

Ce workflow est illustré par le diagramme 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 répertoriés entre parenthèses.

Paramètres de demande de balise Google Match

Paramètre Description
google_gid ID utilisateur Google. Pour les utilisateurs situés hors de Californie, cela sera toujours spécifié dans la balise de correspondance de Google.
google_cver Version du cookie. Ceci sera 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.

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 de l'enchérisseur. Cet ID peut être récupéré dans le champ cookieMatchingNid des comptes de l'API REST pour acheteur.
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 un tableau de correspondance hébergé par Google.

google_ula Chaîne permettant d'ajouter l'utilisateur à une liste d'utilisateurs existante. Le format attendu est userlistid[,timestamp] :
  • userlistid : un ID numérique de liste d'utilisateurs unique.
  • timestamp: horodatage facultatif au format POSIX qui indique à quel moment l'utilisateur a été ajouté à la liste d'utilisateurs.

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

Déclenchement par Google: mise en correspondance unidirectionnelle des pixels

La 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 le User-ID Google, mais elle continuera à renseigner un tableau de correspondance hébergé par Google. Cela peut être utilisé dans les cas où l'enchérisseur n'est pas autorisé à héberger des ID utilisateur Google dans son propre tableau de correspondance. Un exemple simple de workflow révisé est résumé ci-dessous.

Étape 1: Google insère une balise de correspondance

Google place une balise de correspondance pour un enchérisseur sélectionné via un 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 le pixel auprès de l'enchérisseur

Le navigateur de l'utilisateur demande un pixel 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 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 contenant ses données de cookies encodées en base64 et 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. Si l'opération a réussi, les impressions pour cet utilisateur dans les demandes d'enchères ultérieures incluront les données de correspondance hébergées de l'enchérisseur dans BidRequest.hosted_match_data pour le protocole Google, ou BidRequest.user.buyeruid pour l'implémentation OpenRTB de Google. 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 au navigateur de l'internaute.

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

  1. Lorsqu'une annonce est diffusée, Google sélectionne de manière algorithmique une place de marché participante et insère une balise de lecture des cookies 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 pour l'URL de lecture des cookies de la place de marché.

  3. Le point de terminaison de mise en correspondance des cookies de la place de marché reçoit la demande, dans laquelle son propre service de mise en correspondance des cookies est responsable de la mise en correspondance de l'ID utilisateur avec l'un de ses enchérisseurs. Dans le diagramme ci-dessous, le service de mise en correspondance des cookies de l'échange répond au navigateur de l'utilisateur avec une redirection vers l'un des points de terminaison de son enchérisseur.
  4. L'enchérisseur reçoit la demande, ainsi que tous les paramètres spécifiés par la place de marché pour faire correspondre l'ID utilisateur avec son cookie.

Restrictions

Limiter la fréquence des requêtes pour les nouvelles correspondances

Les enchérisseurs sont chargés de limiter le nombre d'appels au service de mise en correspondance des cookies pour les utilisateurs qui ont une nouvelle entrée dans le tableau de correspondance hébergé par Google. Une entrée du tableau de correspondance hébergé peut être considérée comme arrivée à expiration dans 14 jours. Passé ce délai, elle peut être actualisée.

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

Les enchérisseurs qui utilisent le workflow Pixel Match doivent répondre à toutes les requêtes Pixel Match entrantes en envoyant une réponse incluant le paramètre google_push. Cela permet à Google d'appliquer des règles en surveillant l'utilisation. Si le taux de réponse d'un enchérisseur passe en dessous de 90%, Google limitera 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 mise en correspondance 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 l'utilisateur vers le service de mise en correspondance des cookies via HTTPS. De même, un point de terminaison Cookie Match Assist qui redirige les enchérisseurs doit également utiliser le protocole HTTPS. Si vous envoyez des requêtes à Google plus souvent toutes les deux minutes via HTTP, le nombre de requêtes de correspondance envoyées à votre compte est limité.

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é se situe en dehors de la Californie.

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 son propre tableau de correspondance en ne fournissant que les paramètres google_nid et google_cm dans sa balise de correspondance. Exemple:

<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 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 parce que l'utilisateur n'a pas de cookie Google, la réponse serait 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 mise en correspondance des cookies, consultez la page sur les paramètres d'URL de redirection.

Ajouter à une seule liste d'utilisateurs

Le paramètre google_ula peut être spécifié dans une balise de correspondance d'un enchérisseur pour ajouter l'utilisateur à une liste d'utilisateurs avec l'ID donné. Si le tableau de correspondance hébergé par Google ou par un enchérisseur comporte une nouvelle entrée pour l'utilisateur, l'enchérisseur peut placer une balise de correspondance comprenant 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 connaître les autres risques, 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, où l'URL de mise en correspondance des cookies de l'enchérisseur est https://ad.network.com/pixel, l'URL de redirection de Google se présentera comme suit:

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 correspondante, il remplace l'horodatage par un code d'état indiquant la réussite de l'opération. Par exemple, si la requête n'a pas abouti parce que le compte de l'enchérisseur n'a pas accès à la liste d'utilisateurs spécifiée, l'URL de redirection se présentera comme suit:

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 associée à l'ID 45678, mais que celle-ci a échoué pour l'ID de liste d'utilisateurs 12345. En effet, 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 dans 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 peut 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 un tableau de correspondance hébergé par Google

Si un enchérisseur souhaite stocker les données de ses cookies dans un tableau de correspondance hébergé par Google et n'a pas l'intention de stocker les correspondances avec l'ID utilisateur Google dans son propre tableau de correspondance, il doit inclure le paramètre google_hm dans lequel sa valeur doit être une chaîne encodée en base64 adaptée au Web. Pour un utilisateur dont les données de cookie non codées sont Cookie number 1!, la valeur encodée serait Q29va2llIG51bWJlciAxIQ==, qui serait 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" />

En cas de 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 se présentera comme suit:

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 positives. Dans les futures demandes d'enchères pour les impressions de cet utilisateur, l'enchérisseur recevra ses données de correspondance hébergées dans BidRequest.hosted_match_data pour le protocole RTB de Google ou dans BidRequest.user.buyeruid pour l'implémentation d'OpenRTB de Google.

Si l'enchérisseur utilisait plutôt une balise de correspondance dont la valeur google_hm n'était pas encodée en base64 (telle que 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 la valeur 2 pour google_hm, ce qui indique que l'opération a échoué, car la valeur n'a pas pu être décodée.

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

Si un enchérisseur héberge sa propre liste d'utilisation en plus d'une liste d'utilisateurs hébergée par Google, et souhaite qu'une seule balise de correspondance corresponde aux deux tableaux 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 du cookie de l'enchérisseur sont Cookie number 1!, la valeur encodée est Q29va2llIG51bWJlciAxIQ==, ce qui génère une balise de correspondance semblable à celle-ci:

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

En cas de 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 se présentera 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 mettre en correspondance l'ID utilisateur Google spécifié dans google_gid avec les données de son cookie dans son tableau de correspondance. En outre, ils peuvent déterminer si les opérations sur les tableaux de correspondance et les listes d'utilisateurs hébergées par Google ont abouti. Par conséquent, tout préciblage configuré par l'enchérisseur pour cibler l'ID de la liste d'utilisateurs spécifiée entraîne désormais la réception par l'enchérisseur des 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 correspondance hébergées dans BidRequest.hosted_match_data pour le protocole RTB de Google ou dans BidRequest.user.buyeruid pour l'implémentation d'OpenRTB de Google.