Customer Match ne repose plus seulement sur un fichier d’emails ou de téléphones correctement formaté. Google demande progressivement de mieux qualifier la façon dont la donnée a été obtenue, surtout lorsqu’un tiers prépare et charge les audiences pour plusieurs annonceurs.
Search Engine Land a signalé le 25 septembre 2026 l’ajout d’exigences d’adresse IP et d’horodatage pour les imports Customer Match réalisés par des partenaires. Le guide Customer Match de l’API Google Ads confirme que le consentement doit être transmis avec les données utilisateur et que Google fait évoluer les contrôles applicables aux tiers.
1. Ce qui change réellement en octobre 2026
Le point important est le rôle du chargeur. L’exigence annoncée cible les partenaires qui téléversent des données Customer Match pour le compte d’annonceurs via les interfaces programmatiques. L’adresse IP et la date de collecte servent à documenter la provenance de l’enregistrement et à appliquer les règles de traitement appropriées.
Ne transformez donc pas le titre de l’actualité en règle universelle. Un fichier chargé directement par l’annonceur, un connecteur CRM opéré par un éditeur et un prestataire membre du programme partenaire ne suivent pas nécessairement le même circuit. La première tâche est d’identifier la responsabilité réelle, pas d’ajouter deux colonnes au hasard.
À retenir
IP et horodatage ne sont pas de nouveaux critères de ciblage. Ce sont des éléments de provenance et de conformité destinés à encadrer l’usage des données confiées à un tiers.
2. Cartographiez chaque chemin vers Customer Match
Listez toutes les audiences actives, puis remontez leur chaîne : formulaire, application, caisse ou CRM ; stockage ; CMP ou registre de consentement ; transformation ; connecteur ; compte Google Ads ; campagne qui consomme la liste. Un même segment peut avoir plusieurs chemins si l’agence, le CRM et l’équipe interne disposent chacun d’un import.
Pour chaque flux, notez le propriétaire du traitement, le mode d’envoi, la fréquence, les champs transmis et la durée de conservation. Vérifiez aussi si les données sont hachées au bon moment : le hachage protège certains identifiants pendant le transfert, mais il ne remplace ni la base légale, ni la preuve de consentement, ni la gouvernance des accès.
3. Le consentement doit voyager avec la donnée
Dans l’API Google Ads, le statut ad_user_data indique si les données peuvent être utilisées à des fins publicitaires. Google précise que seuls les utilisateurs dont le consentement est accordé sont ajoutés à la liste. Laisser le statut non défini n’est donc pas un raccourci fiable, surtout dans un environnement où le connecteur doit interpréter plusieurs sources.
Alignez la CMP, le CRM et l’outil d’activation sur une règle commune. Le consentement doit rester attaché au bon individu, à la bonne finalité et à la date pertinente. Une synchronisation quotidienne ne doit pas réactiver un utilisateur qui s’est opposé après son premier achat.
Erreurs à éviter
- Déduire le consentement de la seule présence d’un email dans le CRM.
- Réutiliser une liste historique sans connaître la date et le contexte de collecte.
- Appliquer un statut unique à tout un fichier malgré des sources différentes.
- Confondre hachage technique et autorisation d’usage publicitaire.
- Laisser plusieurs prestataires charger la même audience sans registre commun.
4. Ne forcez pas IP et horodatage dans les zones exemptées
La règle comporte des limites géographiques. Les informations de provenance ne doivent pas être fabriquées ou reconstituées lorsque Google ne les accepte pas pour certains utilisateurs, notamment dans les zones européennes mentionnées par la plateforme. Le connecteur doit être capable de distinguer les enregistrements concernés plutôt que d’envoyer une valeur générique.
Cette séparation doit venir d’une logique documentée : pays de l’utilisateur ou du compte, source de collecte et comportement attendu de l’API. Une adresse IP de serveur, de proxy ou du siège de l’entreprise n’est pas une approximation acceptable de l’adresse observée au moment de la collecte.
5. Demandez des preuves au prestataire, pas une promesse
Si une agence, un CDP ou un intégrateur charge les listes, exigez une fiche de flux avant octobre : endpoints utilisés, champs obligatoires, règles régionales, gestion du consentement, journal des rejets et procédure de suppression. Demandez aussi comment seront traités les anciens enregistrements dont la provenance est incomplète.
Surveillez ensuite les indicateurs qui révèlent une dégradation : volume de membres, taux de correspondance, lignes rejetées, délais de synchronisation et campagnes dépendantes de la liste. Une chute n’est pas forcément un problème d’audience ; elle peut signaler qu’un contrôle de consentement ou de provenance fonctionne enfin.
6. Plan d’action en 48 heures
Plan d’action 24/48 h
- Exportez la liste des segments Customer Match, leurs propriétaires et les campagnes qui les utilisent.
- Identifiez pour chaque segment le point de collecte, le statut de consentement, le canal d’import et le prestataire responsable.
- Demandez au fournisseur si l’exigence d’octobre 2026 s’applique à son flux et comment il gère les exceptions géographiques.
- Testez un petit lot : consentement accordé, refusé, non défini et enregistrement exempté, puis consignez les réponses de l’API.
- Créez une alerte sur les rejets, le volume de membres et le taux de correspondance avant que la liste n’affecte les enchères.
Le changement Customer Match ne doit pas conduire à collecter davantage de données sans discernement. Il doit au contraire rendre la chaîne plus explicable : une provenance vérifiable, un consentement transporté correctement, un responsable identifié et un contrôle des exceptions. C’est cette gouvernance — plus que deux nouveaux champs — qui protège la performance et la confiance.