Attribution e-commerce : pourquoi vos régies revendiquent plus de ventes que vous n’en réalisez, et ce que le suivi côté serveur peut réellement changer

En résumé

La somme des conversions revendiquées par vos régies ne mesure pas vos ventes. Chaque plateforme compte selon ses propres fenêtres et ses propres modèles. Leur total peut dépasser vos ventes réelles, ou rester en dessous, sans jamais correspondre à votre comptabilité.
Cinq grandeurs ne doivent jamais être mélangées. Le nombre de conversions déclarées, la valeur que la régie leur attribue, le chiffre d’affaires hors taxes commandé, les commandes réellement conservées après annulations et retours, et les versements nets de votre prestataire de paiement.
Un serveur de suivi ne dispense pas du consentement. Lire ou écrire une information sur l’appareil d’un visiteur à des fins publicitaires exige son accord préalable, même si l’opération passe par un sous-domaine de votre boutique. L’envoi d’une donnée de commande de serveur à serveur reste, lui, soumis au RGPD.
Le suivi côté serveur fiabilise un envoi, il ne règle pas l’attribution. Il réduit les pertes au moment du paiement chez les visiteurs qui ont consenti. Il n’empêche pas deux régies de revendiquer la même vente, et Safari limite toujours la durée de vie de nombreux cookies.
Avant de signer un devis, calculez son point mort sur votre marge. Additionnez l’hébergement, l’intégration, la recette et la maintenance, puis rapportez ce coût à la marge d’une commande conservée. Le résultat est un seuil comptable. Il ne prouve pas que l’outil générera ces commandes.

Des rapports qui ne tombent jamais juste

Prenons un exemple purement illustratif, sur un mois complet. À la clôture d’octobre, votre boutique enregistre 100 000 euros hors taxes de commandes validées. Sur la même période, Google Ads affiche 65 000 euros de valeur de conversion, Meta Ads 55 000 euros et Microsoft Advertising 15 000 euros. Le total des régies atteint 135 000 euros, pour 100 000 euros vendus.

L’inverse existe aussi. Chez un marchand dont une grande partie des visiteurs refuse les traceurs, la somme des régies peut rester bien en dessous des ventes réelles, sans que le dirigeant sache quelle campagne est rentable.

Face à ces écarts, une proposition revient souvent : « Votre suivi par navigateur perd trop de données. Passez au suivi côté serveur, vous retrouverez vos conversions et votre rentabilité publicitaire s’améliorera. » Pour décider, il faut comprendre comment les régies comptent, ce que la loi autorise, ce que les navigateurs font réellement, et ce que l’opération coûte au complet.

Pourquoi les chiffres des régies divergent de votre comptabilité

Chaque régie compte dans son propre périmètre

Une plateforme publicitaire répartit le crédit d’une vente entre les annonces qu’elle a elle-même diffusées. Cette répartition s’arrête à sa frontière. Quand un acheteur voit une publicité sur un réseau social, puis clique sur une annonce de recherche avant de commander, les deux régies peuvent chacune revendiquer la commande, selon la fenêtre d’attribution réglée dans chaque compte.

Ce chevauchement ne touche pas toutes les commandes. Il suffit pourtant à interdire d’additionner les rapports de plusieurs régies comme s’il s’agissait de ventes distinctes.

Les pertes de signal et les conversions modélisées

En sens inverse, quand un visiteur refuse les traceurs ou que son navigateur bloque le suivi, la régie perd la trace directe de l’achat. Certaines plateformes compensent par une modélisation statistique : elles ajoutent à leurs rapports des conversions estimées. Le total affiché dépend alors du taux de refus, de la largeur des fenêtres et du poids de cette modélisation.

Les retours et les annulations

La balise de conversion enregistre la commande au moment où elle est passée. Si la commande est ensuite annulée ou remboursée, la régie continue de la compter, sauf si vous lui transmettez la correction. Les enchères automatiques s’appuient alors sur une valeur surévaluée.

Google Ads documente deux corrections (Aide Google Ads, « À propos des ajustements de conversions ») :

la rétractation retire la conversion : sa valeur passe à zéro et elle sort du décompte ;
la réévaluation modifie la valeur de la conversion sans changer le décompte, par exemple après un retour partiel.

Pour une conversion en ligne, Google demande l’identifiant de commande transmis avec la conversion d’origine. Pour une conversion importée sans identifiant de commande, l’identifiant de clic et l’heure de la conversion peuvent servir à la place, avec des exceptions décrites dans la même page. Une conversion rétractée ne peut plus être ajustée ensuite.

Deux précisions évitent des erreurs courantes. La page d’aide ne fixe pas de délai général en jours pour ces ajustements : les délais de 7 et 55 jours qu’elle mentionne concernent les annonces d’hôtels, pas le commerce en ligne. Et l’envoi d’un ajustement ne demande pas de louer un serveur de suivi : un import de fichier ou un appel à l’interface de programmation de Google Ads depuis votre outil de gestion suffit (Aide Google Ads, « Ajuster vos conversions »).

Retenez la condition pratique : sans identifiant de commande stable transmis dès la conversion d’origine, la correction devient difficile.

Cinq grandeurs à ne jamais mélanger

Toute comparaison doit porter sur une période identique et séparer cinq grandeurs qui n’ont ni la même unité ni le même sens :

Le nombre de conversions attribuées. Un volume d’événements, parfois fractionné selon le modèle d’attribution.
La valeur de conversion déclarée par la régie. Un montant, brut des retours tant qu’aucun ajustement n’est transmis.
Le chiffre d’affaires hors taxes commandé, lu dans votre outil de gestion.
Les commandes réellement conservées, en nombre et en valeur, nettes des annulations, des retours et des remboursements.
Les versements nets de votre prestataire de paiement. Ils arrivent décalés dans le temps et amputés des commissions. Ce n’est pas votre chiffre d’affaires.

Ce que la loi autorise

Certains prestataires laissent entendre qu’un serveur de suivi installé sur un sous-domaine de la boutique rendrait la collecte « interne » et dispenserait du consentement. C’est faux. Le droit distingue deux situations, selon ce qui se passe techniquement.

Lecture ou écriture sur l’appareil du visiteur

Dès qu’un système dépose ou lit une information sur le téléphone ou l’ordinateur d’un visiteur (un cookie, un stockage local, un identifiant publicitaire), l’article 82 de la loi Informatique et Libertés s’applique. Ce texte vise l’opération elle-même. Il ne distingue pas selon que le serveur appartient à une régie ou à votre boutique (CNIL, lignes directrices du 17 septembre 2020 sur les cookies et autres traceurs).

Le consentement préalable est requis dès que le traceur n’est pas strictement nécessaire au service demandé. La CNIL range parmi les traceurs exemptés ceux du panier d’achat, de l’authentification ou de la mémorisation du choix exprimé, ainsi que certains traceurs de mesure d’audience sous conditions. Les traceurs de publicité personnalisée n’en font pas partie (CNIL, « Cookies et traceurs : que dit la loi ? »).

Conséquence directe : si un visiteur a refusé les traceurs publicitaires dans votre bandeau, votre serveur de suivi n’a pas à relayer ces traceurs aux régies.

Transmission de serveur à serveur à partir d’une commande enregistrée

La situation diffère quand l’envoi part uniquement de votre base de commandes, sans rien lire ni écrire sur l’appareil de l’acheteur. Par exemple, la transmission d’un montant et d’une adresse électronique hachée pour un ajustement de conversion. Cette opération ne relève pas, en tant que telle, de l’article 82.

Elle n’échappe pas pour autant aux règles de protection des données :

une adresse électronique ou un numéro de téléphone haché reste une donnée personnelle, pseudonymisée et non anonyme, soumise au RGPD ;
sa transmission à une plateforme publicitaire suppose une information claire de l’acheteur et une base légale valable, en pratique le consentement dans la plupart des usages publicitaires ;
les très grandes plateformes désignées « contrôleurs d’accès » doivent elles-mêmes obtenir le consentement de l’utilisateur pour exploiter à des fins publicitaires les données personnelles que leur transmettent des tiers (règlement européen sur les marchés numériques, article 5, paragraphe 2). C’est pourquoi elles vous demandent de leur transmettre le choix de l’acheteur.

Ce guide décrit le cadre. Il ne remplace pas l’avis de votre délégué à la protection des données ou de votre conseil.

Ce que le suivi côté serveur change techniquement

Safari : des règles précises, pas une règle unique

Une part importante du trafic mobile passe par l’iPhone. Safari et les navigateurs fondés sur son moteur, WebKit, appliquent plusieurs protections contre le suivi. Elles ne se résument pas à une durée unique.

Situation	Effet dans Safari
Cookie créé par un script dans la page	Expiration plafonnée à 7 jours
Stockage accessible aux scripts, sans interaction du visiteur avec le site pendant 7 jours d’utilisation du navigateur	Données supprimées
Arrivée depuis un domaine classé comme traceur, avec une adresse portant des paramètres	Cookies créés par script plafonnés à 24 heures
Cookie posé par la réponse du serveur de votre propre domaine	Pas de plafond de ce type
Cookie posé par un sous-domaine qui renvoie, par un enregistrement CNAME, vers un domaine tiers	Expiration plafonnée à 7 jours, depuis Safari 14
Cookie posé par un sous-domaine dont l’adresse IP est jugée étrangère à celle du site	Expiration plafonnée à 7 jours, depuis Safari 16.4

Le plafond lié au CNAME est décrit par l’équipe WebKit elle-même, qui précise qu’il s’aligne sur celui des cookies créés par script (WebKit, « CNAME Cloaking and Bounce Tracking Defense », 12 novembre 2020). Le plafond lié à l’adresse IP et sa date sont rapportés par la presse spécialisée, WebKit n’ayant pas publié de billet équivalent (PPC Land, synthèse sur la prévention du suivi dans Safari).

Ces règles bougent. Fin octobre 2026, la même presse a rapporté que Safari 27.2 corrigeait un plafonnement appliqué par erreur à des sites eux-mêmes hébergés derrière un CNAME (PPC Land, 2026).

Une limite s’impose à tout diagnostic fait de l’extérieur. Examiner vos enregistrements DNS ou comparer des adresses IP donne un signal de risque. Cela ne dit jamais quelle durée de vie vos cookies ont réellement. Seule une vérification dans l’inspecteur web de Safari, sur les cookies effectivement posés, permet de conclure.

L’apport réel : la commande qui ne se perd plus au paiement

Chez les visiteurs qui ont consenti, l’intérêt d’un envoi par le serveur tient au moment du paiement. Quand un client valide son achat dans son application bancaire et referme son téléphone avant que la page de confirmation ne s’affiche, la balise du navigateur ne se déclenche pas. Un envoi déclenché par votre outil de gestion transmet la commande malgré tout.

Les annulations et les remboursements peuvent suivre le même chemin, par les ajustements décrits plus haut. Aucun de ces deux usages n’exige, à lui seul, un serveur de suivi loué à part.

Ce que le suivi côté serveur ne garantit pas

Aucun lien mécanique avec vos ventes. Envoyer davantage de signaux modifie les conversions attribuées et le pilotage des enchères. Cela ne garantit ni plus de ventes ni une meilleure rentabilité.
Aucune récupération de « toutes les commandes manquantes ». L’envoi reste limité aux acheteurs pour lesquels vous disposez d’une base légale et d’un identifiant exploitable. Sur le plan technique, un envoi par le serveur perd des événements s’il ne gère pas les erreurs, les nouvelles tentatives et les doublons. Un identifiant d’événement commun au navigateur et au serveur est indispensable pour qu’une même vente ne soit pas comptée deux fois.
Aucune amélioration automatique de la vitesse du site. Le téléphone du visiteur n’est allégé que si vous retirez réellement les scripts tiers du navigateur, y compris les restes d’applications désinstallées.
Aucune suppression des doubles revendications. Un serveur qui envoie proprement la même vente à deux régies n’empêche pas chacune de se l’attribuer.

Le coût complet

L’abonnement affiché n’est qu’une partie du coût. À partir du devis réellement remis à votre boutique, additionnez :

l’hébergement du serveur et ses paliers de dépassement, qui dépendent du nombre de requêtes et montent lors des pics de novembre et décembre ;
l’intégration initiale, le raccordement au bandeau de consentement et la recette des identifiants de commande et d’événement ;
la maintenance : après chaque refonte du thème, changement de moyen de paiement ou mise à jour d’application, quelqu’un doit vérifier que les envois et les identifiants fonctionnent encore.

Ce guide ne cite aucun tarif d’hébergeur. Ils changent souvent et dépendent du volume : demandez un devis daté, avec le prix des dépassements.

Comment décider

Appuyez-vous sur vos chiffres comptables, hors taxes, sur une période identique.

L’efficacité publicitaire globale. Divisez votre chiffre d’affaires hors taxes encaissé par vos dépenses publicitaires totales hors taxes. Ce ratio ne dépend d’aucune régie.

La marge par commande avant publicité. Partez du panier moyen hors taxes et retirez tous les coûts qu’une commande entraîne : achat des marchandises, logistique, retours et remboursements, frais de paiement.

La contribution après publicité. Multipliez le nombre de commandes conservées par cette marge, puis retirez vos dépenses publicitaires totales. Ce qui reste couvre vos charges fixes.

Le point mort du devis. Calculez le coût mensuel complet du dispositif : abonnement, installation amortie, temps de maintenance. Deux cas se présentent :

à budget publicitaire inchangé, divisez ce coût mensuel par la marge par commande ;
si chaque commande supplémentaire demande une dépense publicitaire, divisez ce coût par la marge diminuée de cette dépense.

Le second calcul n’a de sens que si la marge reste supérieure à la dépense publicitaire par commande. Sinon, aucun volume de commandes ne rembourse l’outil.

Exemple illustratif. Une boutique dégage 35 euros de marge par commande conservée, avant publicité. Le projet revient à 350 euros hors taxes par mois, tout compris. Il faut 10 commandes supplémentaires par mois, à budget publicitaire constant, pour couvrir ce coût. Si chacune demande 17,50 euros de publicité en plus, il en faut 20.

Ce seuil est un repère comptable. Il dit combien de commandes rembourseraient le dispositif, pas que le dispositif les apportera. Seul un test mené dans la durée, en comparant des périodes ou des zones avec et sans le changement, renseigne sur l’effet réel.

Ce que ce guide ne fait pas

Il ne recommande aucun prestataire et ne classe aucune solution. Il ne mesure pas le chevauchement exact entre vos régies : un écart entre leurs rapports et votre comptabilité ne dit pas quelle part des ventes la publicité a réellement causée. Il ne vaut pas avis juridique.

Sources principales

Textes et autorités :

Documentation des éditeurs, pour leurs propres produits :

WebKit, « CNAME Cloaking and Bounce Tracking Defense », consultée le 12 novembre 2026.
Aide Google Ads, « À propos des ajustements de conversions », consultée le 12 novembre 2026.
Aide Google Ads, « Ajuster vos conversions ».

Presse spécialisée, pour les points que WebKit ne documente pas lui-même :