Une même commande attribuée à la fois à Meta et à Google Ads fausse vos analyses de performance et gonfle artificiellement le coût d’acquisition affiché. L’écart d’attribution ne vient pas d’une simple différence de modèles : il résulte de méthodes de tracking incompatibles, de fenêtres d’attribution distinctes et du double comptage systématique dès qu’un utilisateur interagit avec plusieurs canaux avant d’acheter. Beaucoup pensent que ces chiffres se recoupent automatiquement ou que les plateformes appliquent les mêmes règles, ce qui est inexact.
Après lecture, vous saurez identifier précisément pourquoi les écarts apparaissent, diagnostiquer les cas de double attribution, comprendre les limites des technologies client-side et server-side. Vous pourrez aussi choisir des méthodes d’analyse ou d’implémentation conformes au RGPD et aux recommandations de la CNIL pour limiter ces écarts et documenter vos rapports.
Pourquoi les écarts d’attribution surviennent entre Meta et Google Ads
Meta et Google Ads utilisent des modèles d’attribution différents par défaut. Google Ads propose principalement les modèles « last click », « data-driven » et quelques variantes (first click, position-based, etc.). Le modèle « last click » attribue la conversion au dernier canal cliqué avant l’achat, ce qui avantage souvent Google Ads dans les parcours multi-sources. Meta privilégie un modèle « last touch » qui prend en compte à la fois les clics et les vues (view-through), ce qui permet à Meta d’attribuer une conversion même si l’utilisateur n’a fait que voir la publicité sans cliquer.
Les fenêtres d’attribution varient aussi : Google Ads permet de configurer la fenêtre de conversion (7, 30, voire 90 jours selon le type de conversion), alors que Meta applique généralement une fenêtre standard de 7 jours post-clic et 1 jour post-view, mais ces paramètres peuvent évoluer ou être personnalisés selon le type de campagne. Cette différence de durée signifie qu’une conversion peut sortir de la fenêtre pour l’une des plateformes et rester comptabilisée sur l’autre.
Le parcours utilisateur implique souvent plusieurs points de contact. Un utilisateur peut voir une annonce Meta sur mobile, puis cliquer sur une annonce Google en desktop avant d’acheter. Chaque plateforme, selon ses propres règles, peut revendiquer la conversion, générant un écart dans les rapports. Les modèles d’attribution data-driven de Google Ads, s’ils sont activés, répartissent la valeur de la conversion sur plusiLe tracking cross-device et cross-browser reste imparfait.tièrement à son canal si ses critères sont remplis.
Le tracking cross-device et cross-browser reste imparfait. Google Ads s’appuie sur les comptes Google connectés et le machine learning pour tenter de réconcilier les sessions entre appareils, mais ce n’est pas systématique. Meta utilise principalement l’identifiant Facebook/Instagram pour relier les sessions, mais ne couvre pas tous les scénarios. Cela crée des divergences, surtout si l’utilisateur n’est pas connecté ou utilise différents navigateurs ou appareils lors de son parcours d’achat.
Pour vérifier si ces écarts proviennent d’un problème de configuration, contrôlez la cohérence des fenêtres d’attribution dans chaque interface et vérifiez que les tags sont bien déclenchés uniquement quand le consentement utilisateur est recueilli, conformément aux recommandations CNIL. Un écart très important, hors logique d’attribution, peut indiquer un problème de déclenchement ou de collecte côté client ou serveur.
Double comptage : comment deux plateformes revendiquent la même vente
Google Ads et Meta attribuent chacun une conversion dès qu’un de leurs signaux d’attribution correspond à une action d’achat sur votre site. Aucun mécanisme natif ne permet à ces plateformes de communiquer entre elles pour dédupliquer les ventes. Chaque plateforme travaille sur ses propres modèles d’attribution, ses propres fenêtres et ses propres identifiants (cookies propriétaires, identifiants publicitaires, signaux serveur).
Le double comptage se produit dès qu’un même achat est attribué à la fois à Meta et à Google Ads. C’est systématique dès lors qu’un utilisateur a interagi avec plusieurs canaux avant de convertir. Par exemple :
- Un utilisateur clique sur une annonce Google Ads, ne convertit pas tout de suite, puis consulte une publicité Meta sur Instagram ou Facebook, sans cliquer, et finalise l’achat dans la même session ou plus tard.
- L’utilisateur clique sur une annonce Meta, puis effectue une recherche Google (naturelle ou payante), clique sur une annonce Google Ads, puis achète.
- Le parcours inclut plusieurs interactions : visionnage de vidéo Meta, clic Google Ads, retargeting Meta, puis conversion.
Dans chacun de ces scénarios, chaque plateforme revendique la conversion si l’événement d’achat tombe dans sa fenêtre d’attribution (par défaut, 7 jours clic et 1 jour vue sur Meta ; 30 jours clic sur Google Ads, sauf modification manuelle). Les modèles d’attribution (last click, data-driven, etc.) accentuent ou réduisent ce phénomène selon leur logique propre, mais ne synchronisent jamais les comptages entre plateformes.
Cette absence de déduplication inter-plateformes gonfle artificiellement le total des conversions rapportées par les canaux payants. Si vous additionnez les conversions rapportées par chaque plateforme, vous obtenez un volume supérieur à la réalité mesurée sur votre back-office ou votre outil d’analytics central. Cela fausse le calcul du coût d’acquisition, du ROI par canal et la répartition budgétaire.
Les arbitrages budgétaires fondés sur ces chiffres conduisent à surévaluer l’efficacité réelle de chaque plateforme, et à sous-estimer la part d’interactions multi-canaux dans les parcours clients.
Pour détecter le double comptage, comparez le nombre total de ventes attribuées (additionnez les conversions Google Ads et Meta) au nombre de ventes effectives sur votre back-office ou dans votre outil analytics (Google Analytics, Matomo, etc.). Un écart significatif, hors problèmes de tracking ou de consentement, indique la présence de double comptage. Ce phénomène n’est pas un bug, mais une conséquence structurelle de l’attribution multi-plateformes.
Limites techniques du tracking côté client et côté serveur
Les navigateurs limitent la durée de vie des cookies tiers et restreignent certaines méthodes de stockage. Safari applique l’Intelligent Tracking Prevention (ITP) qui réduit la durée de vie des cookies en JavaScript à 7 jours, voire 24h dans certains cas. Firefox utilise Enhanced Tracking Protection (ETP) pour bloquer de nombreux scripts tiers. Chrome déploie progressivement des restrictions similaires. La conséquence directe est une perte de fiabilité du tracking client-side sur une partie croissante du trafic, en particulier sur mobile et Safari.
La CNIL impose le recueil du consentement explicite pour tout dépôt de cookies non strictement nécessaires, y compris ceux utilisés par les tags publicitaires. Sans consentement, le tag Google Ads ou Meta Pixel ne peut légalement collecter ni transmettre d’identifiant utilisateur, ni stocker une conversion. La plupart des CMP (Consent Management Platform) désactivent ces scripts tant que l’utilisateur n’a pas consenti, ce qui crée des trous dans la donnée, surtout sur les premières visites.
Le tracking client-side repose sur le navigateur de l’utilisateur : le tag JavaScript collecte les données et les envoie vers les serveurs des plateformes. Ce mode subit toutes les limites évoquées ci-dessus. Le server-side tagging consiste à faire transiter les événements via un serveur intermédiaire contrôlé par l’annonceur, souvent via Google Tag Manager côté serveur. Cela permet de contourner certaines restrictions navigateur, mais pas les exigences de consentement : relayer un événement sans consentement marketing reste interdit selon la CNIL.
Les API de conversion (Meta Conversions API, Google Enhanced Conversions) reçoivent les événements côté serveur, souvent enrichis de données (hash d’email, user agent, etc.). L’intégration via API réduit la perte de signal liée aux navigateurs, mais ne supprime pas les risques d’incohérence. Par exemple, un même événement peut être envoyé deux fois (client puis serveur) si la déduplication n’est pas correctement configurée.
Les paramètres de déduplication varient selon la plateforme : sur Meta CAPI, il faut utiliser un identifiant d’événement unique (event_id) transmis à la fois par le pixel et l’API. Sur Google Enhanced Conversions, vérifiez les logs dans Google Tag Assistant et la section « Statut de la conversion » dans Google Ads pour détecter les doublons ou les erreurs de correspondance.
Des incohérences apparaissent aussi lors de la transmission d’événements. Perte de connexion, script bloqué par un adblocker, ou configuration incorrecte du data layer peuvent empêcher l’envoi ou la bonne association des conversions. Pour vérifier la cohérence, comparez le nombre d’événements envoyés dans les consoles de debug (Meta Event Manager, Google Tag Assistant) et les logs côté serveur. Toute différence significative signale un problème à investiguer.
Comment analyser et expliquer les écarts d’attribution dans vos rapports
Commencez par extraire les données brutes de chaque plateforme. Pour Meta et Google Ads, exportez les logs de conversions attribuées, en incluant l’identifiant de transaction ou l’ID de commande (si transmis), la date de conversion, la source/campagne, et tout paramètre UTM disponible. Sur Google Ads, vérifiez que le champ de référence de conversion correspond bien à votre objectif e-commerce (ex : achat, lead qualifié).
Si votre site utilise un user_id ou un identifiant de commande unique dans le data layer, exploitez-le dans vos exports. Cela permet de croiser les ventes revendiquées par les deux plateformes. Si vous ne retrouvez pas cet identifiant dans les exports, vérifiez la configuration du data layer côté e-commerce et l’intégration du tag ou de l’API côté plateforme.
Le rapprochement passe souvent par les paramètres UTM. Filtrez les ventes dans votre outil de web analytics (ex : GA4) par utm_source et utm_campaign, puis comparez-les aux conversions remontées dans Meta et Google Ads. Attention, certains achats issus de campagnes Meta peuvent présenter une utm_source=facebook mais être attribués à Google Ads dans GA4 selon le modèle d’attribution par défaut (ex : last non-direct click).
Les outils d’attribution multi-touch indépendants (ex : Segment, Attribution App, ou modèles internes via BigQuery) permettent d’analyser les chemins utilisateurs sur plusieurs points de contact. Ces solutions donnent une vision plus granulaire, mais leur fiabilité dépend de la qualité du tracking cross-device et du consentement obtenu.
En France, sous le RGPD et les recommandations de la CNIL, tout suivi d’utilisateur requiert le consentement explicite, sauf exemption pour la mesure d’audience. Vérifiez que votre stack respecte ces obligations, sinon la donnée sera partielle.
N’additionnez jamais les totaux de conversions des deux plateformes : une même vente peut être revendiquée par chacune selon ses propres règles d’attribution. Pour illustrer, créez un tableau de rapprochement simple :
| ID Commande | Attribué Meta | Attribué Google Ads | Source Web Analytics | |-------------|--------------|---------------------|---------------------| | 123456 | Oui | Oui | Google (paid) | | 123457 | Non | Oui | Google (paid) | | 123458 | Oui | Non | Facebook | | 123459 | Non | Non | Direct |
Ce type de tableau permet d’identifier les doublons, les écarts et les ventes non captées par l’une ou l’autre plateforme. Vérifiez toujours la cohérence des identifiants et la correspondance des dates de conversion pour limiter les erreurs d’interprétation.
Pistes techniques pour limiter les écarts et améliorer la transparence
Définir une source de vérité réduit les interprétations contradictoires. Pour la majorité des e-commerçants français, le chiffre d’affaires validé dans le back-office (commande réellement payée, hors annulation et fraude) constitue la référence. Les outils analytics first-party (par exemple, une base de données transactionnelle propriétaire ou un export journalier du CMS) permettent de consolider cette information.
Cette base doit être utilisée pour rapprocher les conversions attribuées par Meta et Google Ads, et pour arbitrer les écarts lors des reportings.
Aligner la configuration des tags évite des divergences inutiles. Les événements de conversion doivent être déclenchés sur les mêmes interactions (par exemple, l’événement purchase au clic sur “Paiement validé” ou à l’affichage de la page de confirmation, selon le parcours utilisateur réel). Les paramètres transmis (montant, devise, identifiant de transaction) doivent être formatés à l’identique sur les deux plateformes. Vérifiez que les noms d’événements et les valeurs respectent les spécifications de chaque plateforme. Un contrôle systématique dans le “Tag Assistant” de Google et le “Gestionnaire d’évènements” Meta permet d’identifier les écarts de déclenchement ou de valeur.
Le consent mode de Google et le server-side tagging réduisent les pertes de données liées au refus de consentement ou au blocage des cookies. En France, toute collecte de données à des fins publicitaires nécessite le consentement explicite (RGPD, recommandations CNIL). Activez le consent mode sur vos tags Google pour adapter la collecte selon le statut du consentement. Pour Meta, le déclenchement des conversions server-side (CAPI) doit aussi respecter le consentement recueilli.
Les traitements doivent intégrer un contrôle du statut de consentement avant envoi des données. Vérifiez régulièrement que les déclencheurs côté serveur ne contournent pas le choix de l’utilisateur, sous peine de non-conformité et d’écarts d’attribution artificiels.
Documenter les choix d’implémentation et les écarts observés permet d’expliquer les différences aux parties prenantes. Tenez à jour une documentation interne qui détaille la logique d’attribution choisie, la configuration des tags, les règles de consentement appliquées, et les écarts constatés sur une période donnée. Un tableau de rapprochement entre ventes back-office, conversions Google Ads et Meta doit être partagé avec les équipes concernées, accompagné d’une explication méthodique des écarts (refus de consentement, double comptage, délais de remontée, etc.).
Questions fréquentes
Peut-on empêcher totalement le double comptage entre Meta et Google Ads ?
Non, il n’existe pas de solution native pour dédupliquer automatiquement les conversions entre plateformes. Seul un rapprochement manuel ou via un outil tiers permet d’estimer la part de double comptage.
Quelle fenêtre d’attribution utiliser pour comparer Meta et Google Ads ?
Il n’existe pas de règle universelle. Il faut vérifier les paramètres d’attribution de chaque plateforme et, si possible, aligner les fenêtres pour faciliter la comparaison.
Le consent mode permet-il de réduire les écarts d’attribution ?
Le consent mode améliore la conformité et réduit la perte de données côté Google, mais n’aligne pas automatiquement les modèles d’attribution entre plateformes.
Pas sûr que votre tracking reflète la réalité ?
Propulse Agency audite les configurations de tracking e-commerce — balisage server-side, Meta CAPI, GA4 et consentement — et corrige ce qui vous coûte discrètement des conversions.
Prioriser vos vérifications avant toute implémentation
Commencez par vérifier la cohérence de vos paramètres d’attribution sur chaque plateforme. Assurez-vous que les fenêtres d’attribution configurées dans Meta et Google Ads correspondent, ou que vous comprenez précisément leurs différences. Une discordance ici fausse toute tentative de réconciliation des données.
Avant d’ajuster vos tags ou d’installer une solution server-side, cartographiez vos flux de consentement. Vérifiez que votre CMP applique bien les règles CNIL sur le déclenchement des tags et la transmission des identifiants. Beaucoup d’écarts naissent d’un consent mode mal configuré ou d’un data layer incomplet au moment du clic ou de la conversion.
