Mise en correspondance des cookies

De manière générale, la mise en correspondance des cookies consiste, pour un annonceur ou un fournisseur, à associer des cookies de son domaine à ceux du domaine de Google. La mise en correspondance de ces cookies vous permet d'associer vos données first party à des données publicitaires Google (suivies via Display & Video 360 et Campaign Manager 360) des utilisateurs, ce qui vous permet d'intégrer des données CRM et de mieux comprendre le comportement des utilisateurs. En combinant ces données via des jointures axées sur la confidentialité, vous pouvez :

  • cibler des audiences en fonction d'éléments spécifiques abandonnés dans le panier, si les utilisateurs ont interagi avec vos annonces et votre domaine ;
  • déterminer quelles annonces entraînent des sessions plus longues sur votre domaine ;
  • analyser l'historique des achats par rapport aux données post-campagne.

Limites et confidentialité des utilisateurs finaux

Bien qu'efficace, la mise en correspondance des cookies présente certaines limites :

  • Il est interdit de joindre les tables *_match et non-*_match.
  • La procédure nécessite de mobiliser vos ingénieurs et ceux de Google.
  • Il est peu probable que vous puissiez faire correspondre toutes les données de vos annonces Google. Les taux de correspondance dépendent de plusieurs facteurs et varient selon le cas d'utilisation et la configuration côté client. Les taux de correspondance sont souvent inférieurs à ceux auxquels s'attendent les utilisateurs. La mise en correspondance des cookies ne fonctionne que si les utilisateurs ont interagi avec votre domaine et vos annonces.
  • Google commence à renseigner vos tables des correspondances une fois qu'elles sont configurées. Selon la fréquence à laquelle les utilisateurs consultent votre site et reçoivent votre pixel correspondant, plusieurs mois peuvent s'écouler avant que vos tables des correspondances ne contiennent des données globales et stables sur vos visiteurs.
  • Vous ne pourrez pas associer des utilisateurs individuels à plusieurs appareils, sauf si vous disposez d'un moyen de les connecter sur plusieurs appareils.
  • Vous ne pouvez pas mettre en correspondance un utilisateur avec plusieurs cookies, comme c'est le cas lorsqu'un utilisateur supprime ses cookies.
  • Les tâches exécutées sur des tables des correspondances sont soumises aux mêmes exigences d'agrégation que les autres tâches dans Ads Data Hub. Si vous avez un faible taux de correspondance et que votre domaine enregistre peu de visites, il peut être difficile d'obtenir des données. Cela s'explique par l'effet combiné des taux de correspondance et des exigences d'agrégation1.
  • Conformément aux règles de Google sur la confidentialité des utilisateurs finaux, vous ne pouvez pas :
    • faire correspondre les données de connexion et de déconnexion d'un utilisateur donné ;
    • faire correspondre des données avec les utilisateurs ayant désactivé la personnalisation des annonces.
  • Pour les événements iOS, vous ne pouvez mettre en correspondance que les données issues d'applications sur iOS version 14.5 ou ultérieure et provenant d'utilisateurs ayant accordé leur autorisation en vertu du framework App Tracking Transparency d'Apple.

Pour vous assurer de pouvoir utiliser vos données first party dans Ads Data Hub, vous devez confirmer avoir obtenu le consentement approprié pour transmettre à Google les données des utilisateurs finaux dans l'EEE conformément aux Règles relatives au consentement de l'utilisateur dans l'UE et aux Règles Ads Data Hub. Ces exigences s'appliquent à chaque compte Ads Data Hub et vous devez les respecter chaque fois que vous importez de nouvelles données first party. Tout utilisateur peut effectuer cette confirmation au nom de l'intégralité du compte.

Notez que les règles de requête des services Google qui s'appliquent aux requêtes d'analyse s'appliquent aussi aux requêtes de mise en correspondance des cookies. Par exemple, vous ne pouvez pas exécuter de requêtes multiservices sur des utilisateurs dans l'EEE lorsque vous créez une table des correspondances.

Pour découvrir comment confirmer l'obtention du consentement dans Ads Data Hub, consultez Exigences de consentement pour l'Espace économique européen.

Pour que Google remplisse vos tables des correspondances, vous devez insérer une balise de correspondance sur chaque page de votre domaine sur laquelle vous souhaitez mettre en correspondance des données publicitaires. L'emplacement du pixel dépend de vos objectifs publicitaires. Par exemple, vous pouvez essayer d'établir une correspondance avec tous les utilisateurs qui consultent votre domaine (nécessite un pixel sur presque toutes les pages) ou avec les utilisateurs ayant réalisé une conversion (nécessite un pixel sur une page de conversion). En général, plus le pixel est généralisé, plus les taux de correspondance sont élevés.

La balise de lecture des cookies est un pixel 1x1 transparent. Elle contient votre ID de profil de mise en correspondances des cookies et un ID d'utilisateur ou de cookie encodé :

<img src="https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm=Q29va2llIG51bWJlciAxIQ" />

C'est cette balise qui initie la communication entre vous et les services de mise en correspondance des cookies Google.

Présentation détaillée

  1. Un utilisateur consulte une page contenant une balise de correspondance.
  2. La balise de correspondance lance une série de redirections vers les services de correspondance de Google Marketing Platform, Google Ads et YouTube. Les requêtes contiennent l'ID de l'utilisateur ou le cookie de votre site Web, ainsi que le cookie Google de chacun des espaces d'ID du service correspondant.
  3. Un pixel transparent 1x1 est renvoyé au navigateur pour confirmer que la requête a été traitée.

Ce processus est représenté dans le schéma suivant :

Image illustrant une série de redirections entre le navigateur et les services correspondants

Configuration

Pour configurer la lecture des cookies dans Ads Data Hub, procédez comme suit :

  1. Contactez votre responsable de compte pour lui faire part de votre intérêt pour la mise en correspondance des cookies. Il échangera avec vous au sujet de vos objectifs et vous donnera plus d'informations sur le déploiement du pixel de suivi sur votre domaine.
  2. Les spécialistes Ads Data Hub lanceront une nouvelle conversation pour discuter des exigences techniques et des cas d'utilisation.
  3. Lorsque vous déployez le pixel de suivi et le point de terminaison de l'erreur, Google crée vos tables des correspondances.

Une fois ces étapes terminées, aucune action immédiate n'est requise de votre part. Google remplira vos tables des correspondances quotidiennement2. Vous devrez donc patienter suffisamment de temps pour que votre table contienne assez de données permettant de fournir des correspondances pertinentes et répondre aux exigences d'agrégation. Ce délai dépend de la fréquence à laquelle les utilisateurs consultent votre site : s'ils le consultent une fois par jour, il sera beaucoup plus court que s'ils ne le consultent qu'une fois par mois. Lorsque le nombre de nouvelles correspondances ralentit, cela signifie que vos tables des correspondances contiennent des données plus complètes.

Interroger les tables des correspondances

Lorsque vos tables de correspondance contiennent suffisamment de données pour satisfaire aux contrôles de confidentialité, vous êtes prêt à exécuter des requêtes sur les tables.

Chaque table du schéma Ads Data Hub contenant un champ user_id est accompagnée d'une table *_match. Par exemple, pour la table adh.google_ads_impressions, Ads Data Hub génère également une table des correspondances appelée adh.google_ads_impressions_match, qui contient vos ID utilisateur. Des tables des correspondances distinctes sont créées pour les tables isolées conformément au règlement. Par exemple, pour la table adh.google_ads_impressions_policy_isolated_youtube, Ads Data Hub génère également une table des correspondances appelée adh.google_ads_impressions_policy_isolated_youtube_match qui contient vos ID utilisateur.

Ces tables incluent un sous-ensemble des utilisateurs disponibles dans les tables d'origine, où il existe une correspondance avec le user_id. Par exemple, si la table d'origine contient des données pour les utilisateurs A et B, mais que seul l'utilisateur A correspond, l'utilisateur B ne figurera pas dans la table des correspondances.

Les tables des correspondances contiennent une colonne supplémentaire appelée external_cookie, qui stocke votre cookie sous la forme d'OCTETS.

Il est important de prendre en compte le type de champ lorsque vous rédigez vos requêtes. Les opérateurs de comparaison SQL s'attendent à ce que les littéraux que vous comparez soient du même type. Selon la manière dont le user_id est stocké dans votre table de données first party, vous devrez peut-être encoder les valeurs dans la table avant de faire correspondre les données. Vous devez caster votre clé de jointure en OCTETS pour que la mise en correspondance fonctionne :

JOIN ON
  adh.google_ads_impressions_match.external_cookie = CAST(my_data.user_id AS BYTES)

De plus, les comparaisons de chaînes en SQL sont sensibles à la casse. Par conséquent, vous devrez peut-être encoder les chaînes des deux côtés pour pouvoir les comparer avec précision.

Encoder les ID utilisateur

Encoder les ID utilisateur côté client

Pour sécuriser la transmission des différents formats d'ID via des URL, tous les ID doivent être encodés en Base64 adapté aux URL avant d'être envoyés. L'ID décodé en Base64 adapté pour les URL sera disponible dans le champ external_cookie d'Ads Data Hub. Vous devez donc annuler toutes les transformations que vous avez appliquées avant de l'encoder pour obtenir votre ID d'origine.

Si votre ID contient systématiquement 24 caractères (ou octets) ou moins, vous pouvez inclure l'ID encodé en base64 adaptée aux URL dans un pixel, comme illustré dans l'exemple 1. Si votre ID dépasse 24 caractères (ou octets), vous devez le transformer en une représentation de 24 octets maximum. Dans certains cas (comme le GUID dans l'exemple 2), il s'agit de convertir la représentation en octets. Dans d'autres cas, vous devrez peut-être envoyer à Google un sous-ensemble ou un hachage de votre identifiant. Notez que, dans tous les cas, vous devez vérifier que vous pouvez écrire une jointure SQL JOIN qui convertit l'ID de votre table propriétaire de la même manière.

Exemple 1

La valeur de votre ID utilisateur ne dépasse jamais 24 octets. Ads Data Hub vous recommande d'envoyer votre ID utilisateur directement à ADH (après l'avoir encodé au format Base64 adapté aux URL pour le transport des URL).

var userId = 'abcdef123456789';
// Encode the string (or number) in normal base64.
var userIdBase64 = btoa(userId);

// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_')
    .replace(/=+$/, '');

// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
    'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
    + userIdBase64;
document.body.appendChild(imgElement);
Exemple 2

Vous attribuez une valeur d'identifiant unique universel (UUID) en tant qu'ID utilisateur, par exemple : 123e4567-e89b-12d3-a456-426655440000.

Ads Data Hub recommande les transformations suivantes lors de la mise en correspondance :

  1. L'UUID est formaté en une chaîne de 36 caractères.
  2. Décodez l'UUID en hexadécimal.
  3. L'UUID est formaté en octets.
  4. Encodez les octets en Base64 adaptée aux URL.
  5. L'UUID formaté en une chaîne.

Pour l'implémenter, exécutez le code suivant :

JavaScript

var userId = '123e4567-e89b-12d3-a456-426655440000';

// A helper function for converting a hex string to a byte array.
function strToBytes(str) {
        for (var bytes = [], i = 0; i < str.length; i += 2) {
          bytes.push(parseInt(str.substr(i, 2), 16));
        }
        return bytes;
}

// Remove the formatting dashes from the UUID.
userId = userId.replace(/-/g, '');

// Encode the hex string as a byte array.
var userIdBytes = strToBytes(userId);

// Encode the byte array in normal base64.
var userIdBase64 = btoa(String.fromCharCode(...new Uint8Array(userIdBytes)));

// Ensure that the uploaded user IDs use web-safe Base64 encoding.
userIdBase64 = userIdBase64.replace(/\+/g, '-').replace(/\//g, '_').replace(
    /=+$/, '');

// After encoding the UUID correctly, you can create the request tag and
// insert it into the DOM.
var imgElement = Document.createElement('img');
imgElement.src =
    'https://cm.g.doubleclick.net/pixel?google_nid=adh_customername&google_hm='
    + userIdBase64;
document.body.appendChild(imgElement);

Python

import base64

user_id = '123e4567-e89b-12d3-a456-426655440000'
user_id_as_bytes = bytes.fromhex(user_id.replace('-', ''))
base64.urlsafe_b64encode(user_id_as_bytes)

En cas de correspondance avec un ID utilisateur Google, le champ external_cookie contient votre ID sous forme de valeur d'octet. Pour reconstruire votre ID d'origine, la transformation suivante est requise :

  1. external_cookie est formaté en octets.
  2. Encodez external_cookie en hexadécimal.
  3. external_cookie est formaté en une chaîne.

Encoder des ID utilisateur dans Ads Data Hub

Si vous stockez la chaîne UUID dans un champ de vos données first party, vous devrez la convertir en octets (comme dans l'exemple ci-dessus) afin de joindre correctement vos données.

L'exemple suivant montre comment encoder votre UUID et le joindre dans le champ du cookie externe :

JOIN my_data ON imp.external_cookie = FROM_HEX(REPLACE(my_data.uuid, '-', ''))

Notez que vous ne pouvez pas convertir un entier en octets. Si votre ID utilisateur est un entier (comme dans l'exemple 1 ci-dessus), vous devez d'abord le convertir en une chaîne :

JOIN my_data ON imp.external_cookie = CAST(CAST(my_data.user_id AS STRING) AS BYTES)

N'oubliez pas que l'encodage requis pour faire correspondre vos données dépend de la manière dont vous les stockez et comment vous les avez encodées avant de les envoyer à Ads Data Hub.

En savoir plus sur les fonctions de chaîne dans BigQuery SQL

Exemple de requête

L'exemple suivant joint les données first party à google_ads_impressions_match, puis joint les résultats à adh_google_ads_impressions dans une deuxième requête.

SELECT
  imp.campaign_id as campaign_id,
  sum(my_data.recent_orders) as orders,
  average(my_data.lifetime_value) as ltv
FROM
  adh.google_ads_impressions_match as imp
LEFT JOIN
  my_data ON imp.external_cookie = my_data.company_guest_id_bytes
GROUP BY
  campaign_id

Les résultats de la requête précédente étant enregistrés sous previous_results, vous pouvez désormais joindre google_ads_impressions. Les données des campagnes n'ayant généré aucune impression sont ainsi ajoutées à vos résultats.

SELECT
  campaign_id,
  COALESCE(orders, 0) as orders,
  COALESCE(ltv, 0) as ltv,
FROM (SELECT DISTINCT campaign_id
   FROM adh.google_ads_impressions)
LEFT JOIN previous_results USING (campaign_id)

  1. Par exemple, un taux de correspondance de 20 % signifie que vous avez besoin de 250 utilisateurs par ligne pour atteindre le seuil d'agrégation de 50 utilisateurs (soit 50/0,2 = 250). 

  2. Il peut s'écouler jusqu'à 48 heures avant que les correspondances ne s'affichent dans vos tables.