Une stratégie de données propriétaires commence par distinguer le cadre RGPD, ePrivacy et les règles Google. Le DMA vise les contrôleurs d’accès ; il ne donne pas à l’annonceur une base légale. Collecte, conservation, rapprochement, mesure, personnalisation et envoi à Google sont des opérations distinctes. Chacune exige sa finalité, son droit d’usage et ses preuves.
Privacy Sandbox : pourquoi le calendrier ne suffit plus
Le 22 juillet 2024, Google a proposé de remplacer la suppression programmée des cookies tiers dans Chrome par une approche donnant davantage de choix à l’utilisateur. Le 22 avril 2025, le groupe a précisé qu’il conserverait les réglages actuels et ne déploierait pas de nouvelle fenêtre autonome. Les cookies tiers n’ont donc pas disparu de Chrome à une date unique.
Le 17 octobre 2025, Google a notamment annoncé la suppression progressive d’Attribution Reporting pour l’attribution, de Protected Audience pour les audiences protégées, de Topics pour les centres d’intérêt, de Private Aggregation pour l’agrégation privée et de Shared Storage pour le stockage partagé. D’autres technologies peu adoptées figurent dans l’annonce. Cela ne signifie pas que toute la Privacy Sandbox disparaît. La page de statut maintient notamment CHIPS, pour les cookies partitionnés par site, et FedCM, l’API de gestion fédérée des identités. La conclusion que j’en tire : aucun remplaçant universel ne s’est imposé.
Pour Google Ads, la difficulté ne se résume pas au navigateur. Les écarts avec GA4 viennent aussi des dates d’événement, modèles et fenêtres d’attribution, délais de remontée, identifiants disponibles, environnements Web ou applicatifs, actions configurées et périmètres de rapport. L’érosion des signaux y contribue. Elle n’explique pas tout.
Le bon diagnostic n’est donc pas « le Web est sans cookies ». Il est plus précis : la capacité à relier une interaction publicitaire à un résultat s’érode différemment selon le navigateur, le choix de l’utilisateur, la balise, le bloqueur et la région. L’incrémentalité et les ventes dédupliquées deviennent alors des repères complémentaires.
Données propriétaires, déclarées et tierces : de quoi parle-t-on ?
Les présentations commerciales transforment souvent ces mots en trois cases étanches. Mauvaise grille. « Zero-party data » est un terme marketing non normalisé qui désigne généralement des préférences ou intentions fournies dans une relation directe. Ces informations peuvent donc appartenir aux données propriétaires.
Comparer sans fabriquer de hiérarchie
| Critère | Données tierces (third-party) | Données propriétaires (first-party) | Données déclarées (zero-party) |
|---|---|---|---|
| Origine | Achetées, licenciées ou mises à disposition par un acteur tiers | Observées ou fournies sur un site, une application, en magasin, au téléphone ou dans l’outil de gestion de la relation client (CRM) de l’entreprise | Préférence ou intention fournie volontairement dans cette relation directe |
| Exemples | Segment externe, étude de marché, signal issu d’un cookie tiers | Achat, demande de devis, appel qualifié, identifiant de compte, événement applicatif ou cookie propriétaire | Budget déclaré, préférence de produit, horizon de projet ou fréquence de communication choisie |
| Dépendance technique | Variable selon la source, le droit d’usage et la technique ; un cookie tiers n’est pas toute la donnée tierce | Variable : une donnée CRM, un événement d’application et un cookie navigateur n’ont ni la même durée ni les mêmes limites | Dépend du stockage, de la fraîcheur de la préférence, de sa finalité et d’un éventuel retrait |
| Usage dans Google Ads | Segments proposés par Google ou ciblage contextuel selon le produit ; pas de téléversement libre de fichiers achetés | Seulement les événements et champs admis, sous politiques Google, consentements applicables et éligibilité du compte | La préférence reste dans vos outils ; seul un identifiant ou événement pris en charge peut être transmis pour un usage documenté |
| Lecture qualité | Couverture parfois large, pertinence et preuve d’origine à contrôler | Qualité liée à la collecte, au rapprochement, à la fraîcheur et aux droits conservés | Intention explicite, mais possible biais de réponse ou préférence devenue obsolète |
Les données déclarées ne sont pas un passe-droit
Une préférence stockée dans le CRM dépend moins de la session qu’un comportement observé dans le navigateur. Son rattachement publicitaire reste pourtant soumis aux identifiants disponibles, au choix de l’utilisateur et aux règles du produit. Déclaré ne veut pas dire éternel, exact ni automatiquement activable.
Les conversions améliorées utilisent des données fournies par l’utilisateur, comme l’adresse électronique, le téléphone, le nom ou l’adresse, associées à une conversion admissible. Elles n’ingèrent pas un budget déclaré ou une préférence arbitraire. De même, un import d’aval doit représenter un événement métier qualifié, horodaté, attribuable et dédupliqué.
Une réponse de quiz ne crée pas seule une audience prédictive GA4. La propriété doit instrumenter les événements requis et rester éligible aux métriques prédictives. L’information déclarée peut enrichir votre propre segmentation. Ce n’est pas une promesse d’activation automatique chez Google.
Quiz, configurateur et compte obligatoire sont des hypothèses à tester, pas des points de collecte « sans friction ». Demandez une adresse seulement si elle sert le résultat ou une finalité expliquée. Le hachage SHA-256 pseudonymise ; il n’anonymise pas et ne remplace ni base légale, ni information, ni consentement requis, ni politique Google.
Unifier les données dispersées sans fusionner les droits
Commencez par inventorier la matière réellement disponible : commandes, appels, formulaires, statuts commerciaux, retours et préférences. Cartographiez chaque source, son responsable, sa finalité, sa qualité, sa durée de conservation et le droit d’usage associé. Une colonne remplie n’est pas encore une donnée activable.
Un dossier peut être fragmenté entre CRM, boutique et service client. C’est un exemple, pas une règle de trois. Lors du rapprochement, conservez la source, la finalité, la version, la date, la portée et la preuve des choix. Ne fusionnez jamais deux états en gardant celui qui autorise le plus.
La clé maîtresse doit être un identifiant client interne stable. L’adresse électronique reste un attribut susceptible de changer, d’avoir des alias ou d’être partagée. Normaliser les espaces et les minuscules est légitime ; supprimer des points, suffixes ou domaines ne l’est que si le fournisseur le prévoit et si l’identité est démontrée. Pour Customer Match, les champs privés sont hachés selon les règles Google, tandis que le pays et le code postal restent en clair.
Dédupliquez les personnes et les conversions séparément. Une commande ou transaction exige son propre identifiant et un journal des rapprochements. Puis mesurez : lignes valides, couverture, erreurs, taux de correspondance et événements répétés. Un taux faible peut aussi venir d’utilisateurs sans compte Google, d’identifiants différents, de la fraîcheur ou du consentement. Le ciblage par liste de clients, nommé Customer Match par Google, ajoute encore des conditions de conformité et de paiement ; certaines fonctions exigent 90 jours d’historique et 50 000 dollars américains de dépenses cumulées. Une liste doit conserver au moins 100 membres ajoutés ou actualisés sur 540 jours.
Les cinq briques à mettre en cohérence
La stratégie n’est pas un nouvel outil à acheter. C’est une chaîne de décisions. Elle peut commencer par une plateforme de données clients (CDP) dans une grande organisation, ou par un simple inventaire contrôlé ailleurs. Dans les deux cas, le câblage arrive après la finalité.
- Gouvernance et choix. Le RGPD prévoit six bases légales. Une plateforme de gestion du consentement (CMP) recueille ou transmet certains choix ; elle ne crée pas la base légale. Le mode de consentement Google (Consent Mode) transmet des états aux produits Google lorsqu’il est requis, notamment dans l’Espace économique européen, au Royaume-Uni et en Suisse.
- Couche de données et mesure de base. La couche de données de Google Tag Manager, appelée dataLayer, structure les informations disponibles dans la page. Elle ne collecte ni n’envoie rien seule. Les balises doivent être déclenchées selon la finalité et les choix applicables.
- Conversions améliorées. C’est une utilisation possible des données fournies au moment d’une conversion Web admissible. La balise reste nécessaire. Depuis juin 2026, Google unifie les réglages Web et prospects, mais les sources et diagnostics restent à contrôler.
- Résultats hors ligne. N’envoyez pas « le CRM ». Envoyez un résultat qualifié et les champs admis : identifiant de clic ou donnée fournie, date, action, valeur, identifiant de transaction et états de consentement. Depuis le 15 juin 2026, les nouveaux flux concernés sont orientés vers Data Manager API, l’interface de gestion des données de Google Ads ; les anciens jetons ne suivent pas tous le même régime.
- Marquage côté serveur. Le navigateur ou l’application envoie encore l’événement initial. Le traitement et les envois partenaires passent ensuite par le serveur. Les bénéfices sur les cookies exigent un contexte propriétaire, idéalement de même origine ; le domaine par défaut du conteneur ne suffit pas.
À ces cinq briques s’ajoutent la qualité CRM, la conservation, les responsabilités, Customer Match lorsque le compte est éligible et une mesure d’impact. La cohérence ne consiste pas à tout envoyer. Elle consiste à savoir quel événement sert quelle décision et pourquoi vous avez le droit de l’utiliser.
Testez aussi le versant organisationnel : qui possède le dictionnaire d’événements, si le statut « vente » garde le même sens selon l’équipe et si un retrait est propagé. Le problème peut être organisationnel, technique ou les deux. Il faut le qualifier avant de choisir son coupable.
Collecter seulement ce qui sert
Certaines informations sont nécessaires au service ou au contrat. D’autres servent une personnalisation ou une mesure publicitaire additionnelle. Ne les mélangez pas. Un numéro donné pour livrer une commande n’est pas automatiquement autorisé pour personnaliser une publicité.
Une adresse électronique peut être nécessaire pour envoyer un suivi, utile pour ouvrir un compte ou facultative pour recevoir un résultat. La contrepartie ne doit jamais devenir un prétexte pour conditionner abusivement l’accès. Soyons clairs : plus de champs ne signifie pas plus de stratégie.
Un achat invité, un formulaire ou un appel peuvent fournir un identifiant sans création de compte. L’objectif n’est pas d’identifier tout le monde. Il est de mesurer les événements qui comptent avec le minimum de données nécessaire.
La question d’inventaire reste redoutablement simple : à quel moment cette information améliore-t-elle réellement le service, la mesure ou la décision ? Si la réponse tient uniquement à une future audience hypothétique, ne collectez pas encore.
Chaque point doit être relié à un usage compatible. Une préférence CRM n’est pas absorbée par l’attribution basée sur les données : ce modèle répartit le crédit entre interactions à partir des conversions admissibles. Une préférence libre reste dans vos outils tant qu’aucune fonction documentée ne la prend en charge.
Une case vide peut donc être saine. Elle peut signaler qu’aucune donnée supplémentaire n’est nécessaire. Le chantier commence seulement lorsque l’information améliore une décision, que sa collecte est proportionnée et que son usage est démontrable.
| Point de collecte | Condition à vérifier | Usage publicitaire possible |
|---|---|---|
| Achat ou inscription Web | Conversion mesurée et identifiant fourni au même moment | Conversions améliorées si l’action et le champ sont admissibles |
| Demande de devis | Identifiant d’attribution, issue commerciale, date et déduplication | Résultat qualifié envoyé par Data Manager, pas formulaire brut répété |
| Programme de fidélité | Finalité de personnalisation, choix applicable, compte éligible et liste assez récente | Customer Match sur les surfaces autorisées |
| Quiz ou configurateur | Préférence utile au résultat ; adresse demandée seulement si nécessaire | Segmentation interne ; aucun envoi automatique de la préférence |
| Compte après achat | Nouvel achat ou événement réel avec identifiant de transaction | Nouvelle conversion admissible, jamais conversion « récurrente » sans événement |
Ce tableau n’est pas une liste de cases à remplir. C’est un filtre. Besoin métier, minimisation, transparence, compatibilité produit, puis valeur mesurée. Dans cet ordre.
Mesurer l’impact sans inventer de causalité
Il n’existe pas de gain universel. Le point de départ, le volume, la qualité des identifiants, la campagne et la fenêtre de conversion changent le résultat. Une hausse avant/après reste exposée à la saisonnalité, au budget, aux enchères, à l’attribution et aux modifications du compte.
Définissez d’abord l’état de référence : part des événements admissibles portant une donnée fournie, erreurs de format, délai de remontée, taux de correspondance, part de résultats qualifiés, doublons et couverture par action. Sans cela, « signal récupéré » ne veut rien dire.
Conversions améliorées. Le diagnostic Google distingue couverture, niveau de correspondance, alertes et hausse de conversions rapportée. La couverture peut apparaître rapidement, le niveau de correspondance évolue sous délai, et l’indicateur de hausse n’est visible que pendant une fenêtre limitée avec assez de volume. Ne soustrayez pas deux périodes pour fabriquer cet impact.
Résultats hors ligne. Contrôlez le taux d’acceptation, les erreurs, les transactions répétées et le délai entre clic et vente. Comparez ensuite conversions rapportées et ventes dédupliquées. Le nombre de conversions qui « reposaient sur un cookie » n’est pas une métrique disponible.
Performance. Une meilleure observabilité peut modifier les conversions rapportées et l’apprentissage des enchères. Elle ne garantit ni baisse du CPA cible ni hausse du ROAS cible. Pour isoler un effet réel, comparez des périodes matures à périmètre constant ou utilisez une expérience lorsque le volume le permet.
Enfin, méfiez-vous du biais de sélection. Les entreprises mieux équipées peuvent aussi avoir davantage de transactions, un modèle connecté ou une maturité numérique supérieure. Votre cible doit être définie par la couverture, la qualité, le coût et la décision gagnée. Pas par la moyenne d’un portefeuille qui ne vous ressemble pas.
Lorsque la couverture reste faible : alternatives et compléments
Le ciblage contextuel et Ads Data Hub sont deux compléments présentés ici. Ce ne sont pas les seuls : mesure modélisée, expérimentation, données d’éditeur et signaux non personnalisés peuvent aussi répondre à un besoin précis. Aucun ne dispense de réparer la mesure de base.
Ciblage contextuel : choisir un contenu, pas un profil
Le critère porte sur le contenu consulté plutôt que sur un profil individuel. La diffusion, la fréquence et la mesure peuvent toutefois encore mobiliser des identifiants selon la configuration et le choix de l’utilisateur. « Contextuel » ne signifie pas techniquement indépendant de toute donnée.
Sur le Réseau de Recherche, la requête contribue à la mise en correspondance avec les mots clés et d’autres signaux, dont le lieu, l’appareil, l’enchère ou certaines audiences. Sur le Réseau Display et YouTube, le thème, le mot clé de contenu ou le placement peuvent devenir des critères explicites.
Ce ciblage fonctionne avec ou sans audience propriétaire. Il n’enrichit pas automatiquement le CRM, mais les enseignements sur les créations, requêtes et placements restent exploitables. C’est un mode d’acquisition complémentaire, pas une solution provisoire réservée aux bases trop petites.
Ads Data Hub : analyser sous contrôles de confidentialité
Ads Data Hub est l’environnement Google qui relie des comptes publicitaires à l’entrepôt de données BigQuery pour analyser des données d’événements avec vos données propriétaires admises. Les données Google sous-jacentes ne sont pas inspectables individuellement. Les sorties sont agrégées, filtrées ou bruitées selon le mode de confidentialité.
Les seuils portent sur chaque ligne de résultat : environ 20 utilisateurs uniques avec ajout de bruit, 50 avec les contrôles différentiels historiques et 10 pour des requêtes limitées aux clics et conversions. Une ligne peut être filtrée ; l’ensemble ne revient pas nécessairement vide. La maturité exige aussi SQL, BigQuery, comptes liés, reconnaissance du consentement, gouvernance et un cas d’usage rentable. Pour activer une audience, il faut encore un compte destinataire éligible, des événements autorisés et une taille active suffisante. La documentation indique notamment 100 utilisateurs actifs sur 30 jours pour les listes concernées.
- Chrome n’a pas supprimé les cookies tiers à une date unique, mais l’érosion des identifiants varie déjà selon le navigateur et le choix utilisateur.
- Aucune hiérarchie universelle ne place les données déclarées au-dessus des données observées ou tierces : jugez pertinence, fraîcheur, preuve, droit d’usage, couverture et dépendance technique.
- Une préférence déclarée peut être précieuse et obsolète ; un comportement récent peut être plus prédictif.
- Une base dupliquée peut gonfler les fichiers et répéter les événements. Elle ne dégrade pas mécaniquement chaque taux de correspondance.
- La stratégie réunit gouvernance, qualité, finalités, droits, instrumentation, CRM, activation autorisée, responsabilités et mesure d’impact.
La décision pratique
Le chantier ne commence pas par le remplacement d’un cookie. Il commence par une décision à améliorer, le droit d’utiliser la donnée, sa couverture et la méthode choisie pour mesurer son apport. Si l’une de ces quatre réponses manque, ajoutez d’abord de la gouvernance, pas une nouvelle base.
Questions fréquentes
Qu’appelle-t-on données propriétaires dans Google Ads ?
Chrome a-t-il supprimé les cookies tiers ?
Quelle différence entre un cookie propriétaire et une donnée propriétaire ?
Par où commencer lorsque rien n’est documenté ?
Le marquage côté serveur est-il indispensable ?
Les conversions améliorées compensent-elles toute l’érosion du signal ?
Sources Google officielles vérifiées le 22 juillet 2026. Les premières références couvrent la voie annoncée en juillet 2024, la décision Chrome d’avril 2025, les retraits annoncés en octobre 2025 et le statut des technologies. La documentation Google couvre ensuite les politiques relatives aux données client, les règles Customer Match, la correspondance des données, les réglages 2026 des conversions améliorées, le diagnostic des conversions améliorées, les imports hors ligne et Data Manager, les audiences prédictives GA4 et le domaine du marquage serveur. Les autres références portent sur les contrôles Ads Data Hub, l’activation des audiences, l’évolution du mode de consentement, la correspondance des mots clés et le ciblage des annonces.
Cadre juridique et navigateurs vérifiés le 22 juillet 2026. CNIL : six bases légales, règles applicables aux traceurs et hachage et pseudonymisation. Navigateurs : blocage Safari daté de mars 2020, protections WebKit actuelles, protection Firefox par défaut en septembre 2019, isolation totale des cookies et réglages Firefox actuels.
