Même avec les cookies server-side qui prolongent leur durée de vie, les cookies seuls ne résolvent pas le tracking cross-device ni l’attribution après qu’un utilisateur a effacé ses données de navigation. Les cookies trackent des appareils, pas des personnes. Un utilisateur qui effectue ses recherches sur iPhone et convertit sur desktop est invisible pour l’attribution basée sur les cookies — deux identités d’appareil distinctes sans aucune connexion.
Les approches de résolution d’identité qui comblent ce manque pour la mesure publicitaire fonctionnent de manière fondamentalement différente du tracking par cookies. Au lieu de persister un identifiant d’appareil entre les sessions, elles associent les actions des utilisateurs à des identités connues en utilisant des signaux qui survivent aux restrictions des navigateurs : les données first-party collectées avec consentement, l’identité Google ou email en session authentifiée, et des datasets collaboratifs respectueux de la vie privée.
Ces approches ne remplacent pas le tracking server-side. Elles étendent sa portée aux scénarios où les cookies ne peuvent pas opérer.
Enhanced Conversions
Les Enhanced Conversions de Google capturent des données first-party au moment de la conversion — adresse email, numéro de téléphone, adresse physique, nom — les hashent en SHA-256, et envoient les valeurs hashées avec l’événement de conversion. Côté Google, le hash est associé aux comptes Google connectés pour attribuer la conversion même lorsque les cookies ont été supprimés ou n’ont jamais été définis.
L’implémentation appartient à un tag GTM server-side plutôt qu’en client-side, pour deux raisons. Premièrement, hasher des données sensibles côté client les expose à l’inspection du navigateur et à tout JavaScript s’exécutant sur la page. Deuxièmement, un tag server-side peut enrichir les données de conversion avant de les transmettre — en ajoutant des signaux first-party supplémentaires que l’événement client-side n’aurait peut-être pas inclus.
L’exigence de consentement est non négociable : ad_user_data doit être accordé dans le Consent Mode v2 avant que les données Enhanced Conversions soient utilisées. Le système de Google ignore silencieusement les données enrichies lorsque ce paramètre n’est pas accordé — le tag de conversion semble se déclencher normalement en mode prévisualisation, mais l’association d’identité n’a pas lieu. C’est l’une des défaillances silencieuses les plus fréquentes dans les implémentations Google Ads.
Uplift réaliste : les annonceurs rapportent 5 à 25 % de conversions attribuées en plus après l’implémentation des Enhanced Conversions. Les meilleurs résultats surviennent lorsque plus de la moitié des événements de conversion incluent des données enrichies. Si seulement 10 % des conversions portent des adresses email, l’uplift est minimal car il y a peu à associer. Cela signifie que la valeur des Enhanced Conversions est proportionnelle à votre capacité à collecter des données first-party aux points de conversion — ce qui est autant un problème de produit et d’UX qu’un problème technique.
Unified ID 2.0 (UID2) et EUID
Unified ID 2.0, créé par The Trade Desk, utilise des adresses email hashées comme identifiant cross-site. Lorsqu’un utilisateur s’authentifie ou fournit son email sur le site d’un éditeur, celui-ci génère un token UID2 à partir de l’email hashé. Ce token circule dans l’écosystème publicitaire programmatique — DSP, SSP, côté acheteur et vendeur — où il permet le ciblage et l’attribution sans cookies tiers.
Le modèle de consentement est explicite : UID2 exige que les utilisateurs aient consenti à l’utilisation de leur email à des fins publicitaires. Le consentement est distinct du consentement au marketing par email ; il couvre l’utilisation de l’identifiant pour le ciblage publicitaire sur différents sites. Les éditeurs doivent présenter cela clairement et l’enregistrer.
La variante européenne, EUID, est conçue spécifiquement pour la conformité RGPD et TCF. La génération du token se produit dans une infrastructure européenne, et le cadre de consentement s’intègre avec TCF v2.2 afin que les signaux circulent correctement dans la chaîne de consentement standard que les éditeurs européens utilisent déjà.
Les principaux SSP supportant UID2 incluent Index Exchange, Magnite, PubMatic et OpenX. Côté acheteur, The Trade Desk lui-même et un nombre croissant de DSP ont adopté la solution. Pour les éditeurs dans la publicité programmatique, UID2/EUID représente un graphe d’identité post-cookies qui ne dépend pas des cookies définis par le navigateur pour la reconnaissance.
La limitation pratique : UID2 ne fonctionne que lorsque les utilisateurs s’authentifient ou fournissent un email. Les visites non authentifiées ne produisent aucun token UID2 et restent non résolvables. La couverture varie considérablement selon le type de site — les sites média et e-commerce où les utilisateurs se connectent ont une couverture élevée ; les sites de contenu sans authentification ont une couverture quasi nulle.
Data Clean Rooms
Les data clean rooms sont des environnements de calcul où deux ou plusieurs parties peuvent exécuter des analyses sur des datasets joints sans qu’aucune partie puisse voir les données brutes de l’autre. La garantie de confidentialité provient du modèle de calcul : les requêtes s’exécutent dans un environnement contrôlé, et seuls des résultats agrégés et statistiquement sûrs en sortent.
Pour la mesure publicitaire, le cas d’usage courant est d’associer le fichier clients d’un annonceur au graphe utilisateur d’une plateforme pour mesurer les performances de campagne, sans que l’annonceur voie les données individuelles des utilisateurs de la plateforme ni que la plateforme voie l’intégralité des enregistrements clients de l’annonceur.
Clean rooms spécifiques aux plateformes :
- Google Ads Data Hub : associe les données Google Ads aux données first-party. Permet l’attribution cross-canal, l’analyse de fréquence et l’analyse du chevauchement d’audiences qui ne sont pas disponibles via l’interface Google Ads standard.
- Meta Advanced Analytics : capacité équivalente dans l’écosystème Meta.
- Amazon Marketing Cloud : analyse d’attribution pour les campagnes sur l’inventaire publicitaire d’Amazon.
Les clean rooms cloud-native permettent la collaboration multi-parties sans être liées à l’écosystème d’une seule plateforme :
- Snowflake Data Sharing + Clean Rooms : les requêtes SQL s’exécutent sur des datasets partagés avec des contrôles de confidentialité intégrés dans l’accord de partage.
- AWS Clean Rooms : modèle similaire dans l’infrastructure AWS.
- BigQuery Analytics Hub : l’offre de Google pour le partage de datasets avec sécurité au niveau des lignes et des colonnes.
Les clean rooms sont désormais une infrastructure standard pour les grands annonceurs qui dépensent significativement sur plusieurs canaux et ont besoin de réconcilier l’attribution sans donner à chaque plateforme accès au dataset cross-plateforme complet. Elles sont excessives pour la plupart des implémentations small et mid-market, mais deviennent nécessaires à grande échelle — notamment lorsque l’on cherche à mesurer la vraie incrémentalité entre des canaux qui revendiquent chacun le crédit pour les mêmes conversions.
Comment ces approches s’articulent
Ces approches ne sont pas des alternatives les unes aux autres ni au tracking server-side. Elles forment une pile :
- Les cookies server-side prolongent la durée de vie des cookies pour les utilisateurs où les cookies fonctionnent (résolvant le problème Safari ITP)
- Les Enhanced Conversions récupèrent l’attribution pour les utilisateurs convertissants qui ont effacé leurs cookies ou utilisé un autre appareil
- UID2/EUID active le ciblage et l’attribution pour les utilisateurs authentifiés dans l’écosystème programmatique
- Les data clean rooms fournissent une mesure cross-plateforme à grande échelle, là où aucune plateforme ne peut voir l’image complète
Chaque couche gère un mode de défaillance différent. La base qui améliore toutes ces approches est une implémentation du consentement solide — car les Enhanced Conversions requièrent ad_user_data accordé, UID2 nécessite un consentement authentifié, et les clean rooms ne contiennent que des données légalement collectées.
Le problème de résolution d’identité analytique (lier les identifiants de cookies GA4 aux enregistrements CRM) est adjacent mais distinct. Il s’agit de construire une image complète du parcours d’un client dans votre warehouse. Le problème d’identité pour la mesure publicitaire ici concerne l’attribution des dépenses publicitaires aux résultats — les techniques sous-jacentes (hashage, association, gating du consentement) se chevauchent, mais l’infrastructure et l’objectif métier diffèrent.