À quoi ressemble vraiment la récupération de votre tracking.
Imaginez une boutique PrestaShop qui réalise un chiffre d'affaires solide sur les publicités Google et Meta, avec une configuration côté client compétente. Sur le papier, tout va bien — jusqu'à ce qu'on aligne les conversions rapportées dans GA4 et le gestionnaire de publicités sur les commandes réelles du back-office : elles ne correspondent pas. Voici pourquoi cet écart existe, ce que sa fermeture change, et pourquoi c'est le mécanisme — pas un pourcentage — qui se transpose à votre boutique.
Avant : les chiffres ne collent pas
Les outils d'analyse de la boutique affichent systématiquement moins d'achats que sa liste de commandes. La mécanique n'a rien de mystérieux : les bloqueurs de publicités annulent les requêtes vers les domaines d'analyse de Google avant qu'elles ne quittent le navigateur — environ 3 internautes sur 10 en utilisent un (GWI, 2025) — et Safari supprime les cookies posés par script après 7 jours, en vertu de la politique WebKit d'Apple elle-même, si bien que les acheteurs sur iPhone qui reviennent passent pour des inconnus. La sous-estimation est de surcroît biaisée : les ventes manquantes se concentrent précisément dans les audiences riches en iOS et soucieuses de leur vie privée que beaucoup de boutiques valorisent le plus, et le Smart Bidding comme l'optimisation de Meta apprennent à partir de données où elles manquent.
Ce qui change
Rien ne change dans les publicités ni les produits de la boutique. La seule différence, c'est l'endroit où vit le tracking — et la route que chaque événement emprunte.
Le module PrestaSignal s'installe sur la boutique — un ZIP et une clé de licence, aucune modification de thème, aucun sprint de développement. Il provisionne tout, y compris un petit connecteur sur l'adresse web de la boutique elle-même.
Les pages vues, les vues produit et les étapes du panier sont enregistrées via ce connecteur — le propre domaine de la boutique — avec les bibliothèques de balises Google servies depuis la même adresse. Les listes de filtres des bloqueurs actuels ciblent les domaines de Google ; rien sur la page ne leur correspond.
Les achats et les remboursements sont rapportés par le back-office, de serveur à serveur, et comptés exactement une fois — un onglet fermé, un rechargement ou une extension ne peut plus perdre ni doubler une vente.
Les identifiants de clic sont conservés 90 jours dans des cookies first-party conditionnés au consentement, les Enhanced Conversions et la Conversions API transportent des données de correspondance hachées, et des event_id partagés gardent le décompte de chaque plateforme propre.
Le résultat : les plateformes voient enfin ce que le back-office savait
Une fois que les événements navigateur voyagent en first-party et que les ventes se rapportent elles-mêmes côté serveur, les plateformes commencent à voir des conversions auxquelles elles étaient aveugles. Ce n'est pas du chiffre d'affaires nouveau — ce sont les vraies ventes que la boutique réalisait déjà, enfin mesurées. Ce qui est récupéré dépend de l'audience de la boutique : plus le trafic iOS et l'usage de bloqueurs de publicités sont élevés, plus la part cachée est grande. C'est pourquoi cette page montre des proportions plutôt que des pourcentages — aucune moyenne sectorielle vérifiable n'existe, et nous préférons mesurer votre boutique plutôt que lui inventer un chiffre.
Ce qui rend cela reproductible, c'est que la cause est universelle : chaque boutique PrestaShop qui vend à des utilisateurs d'iPhone et à des acheteurs équipés de bloqueurs de publicités perd des conversions de la même façon, pour les mêmes raisons. La taille de l'écart diffère ; le mécanisme — balises navigateur bloquées, cookies posés par script écourtés — est le même partout. C'est pourquoi la même conception first-party, côté serveur, produit la même forme de résultat sur des boutiques très différentes.
À propos de cet exemple.
Est-ce un vrai client nommé ?+
Non — c'est une démonstration illustrative du mécanisme, volontairement sans chiffres inventés. Une étude de cas mesurée sur une boutique réelle, avec un vrai avant-après, est en préparation. En attendant sa publication, nous préférons vous montrer honnêtement le mécanisme plutôt que de déguiser une hypothèse en données — et un audit gratuit vous donne des chiffres propres à votre boutique.
Pourquoi montrer des proportions plutôt que des pourcentages ?+
Parce qu'il n'existe aucune moyenne sectorielle vérifiable de ce que le tracking côté client perd — cela dépend des appareils, des navigateurs et des habitudes de blocage de publicité de votre audience. Ce qui est citable : environ 3 internautes sur 10 utilisent un bloqueur de publicités (GWI, 2025), et Safari supprime les cookies posés par script après 7 jours (la politique WebKit d'Apple elle-même). Le chiffre exact de votre boutique, lui, est mesurable — sur votre boutique, face à vos commandes réelles.
Verrai-je le même résultat ?+
La forme, oui — des achats récupérés, une attribution restaurée, des rapports qui se réconcilient avec votre back-office. L'ampleur dépend de la part de votre trafic sur iOS, du nombre d'acheteurs qui utilisent des bloqueurs et des plateformes que vous exploitez. L'audit gratuit estime votre écart spécifique avant que vous ne vous engagiez à quoi que ce soit.
Vous voulez de vrais chiffres ?
Un audit gratuit mesure l'écart sur votre boutique réelle — vos commandes, votre trafic, vos plateformes — avant que vous ne vous engagiez à quoi que ce soit.