Comment récupérer les conversions que les bloqueurs de publicités cachent

Une partie de vos conversions n'atteint jamais vos outils d'analyse — non pas parce que les ventes n'ont pas eu lieu, mais parce que le navigateur du client a refusé de les signaler. Bloqueurs de publicités, extensions de confidentialité et restrictions de suivi d'Apple annulent en silence les requêtes qui portent vos événements de tracking. Personne ne peut vous dire exactement combien vous perdez — aucune moyenne sectorielle vérifiable n'existe — et c'est précisément le problème : de l'intérieur, la perte est invisible.

La commande atterrit dans votre back-office PrestaShop, l'argent arrive sur votre compte, mais GA4, Google Ads et Meta n'en entendent jamais parler. Vous optimisez des campagnes et jugez votre boutique sur des chiffres auxquels il manque une part importante et biaisée de la réalité. Voici exactement comment la perte survient — et comment une conception first-party, côté serveur, la récupère.

Comment les bloqueurs annulent vos événements

Le tracking classique est côté client : un script dans le navigateur de l'acheteur déclenche des événements comme page_view et purchase vers Google ou Meta. Les bloqueurs de publicités et les extensions de confidentialité entretiennent des listes de blocage de domaines d'analyse et de publicité — googletagmanager.com et google-analytics.com y figurent tout en haut — et ils annulent toute requête qui se dirige vers l'un d'eux avant qu'elle ne quitte le navigateur.

De votre côté, c'est complètement silencieux. Pas d'erreur, pas d'avertissement, aucune entrée nulle part — l'événement n'a simplement jamais existé du point de vue de votre analyse. Environ 3 internautes sur 10 utilisent un bloqueur de publicités (GWI, 2025), et l'adoption grimpe plus haut chez les acheteurs plus jeunes, plus techniques et plus soucieux de leur vie privée.

Comme l'adoption penche précisément vers les audiences que beaucoup de boutiques veulent le plus, la perte n'est pas un bruit aléatoire qu'on peut ignorer. C'est un trou systématique et biaisé dans vos données, qui fausse l'image des campagnes et des segments rentables.

L'ITP et le problème d'expiration des cookies

Les bloqueurs de publicités ne sont que la moitié de l'histoire. L'Intelligent Tracking Prevention (ITP) d'Apple, intégrée à Safari et iOS, s'attaque aux cookies dont dépend le tracking. En vertu de la politique WebKit d'Apple elle-même, les cookies posés par le JavaScript côté client sont supprimés après 7 jours sans nouvelle visite — et plafonnés à 24 heures quand le visiteur arrive par un lien décoré de paramètres de tracking (webkit.org).

L'effet est subtil mais corrosif. Un acheteur qui clique sur une publicité aujourd'hui et achète la semaine prochaine revient avec son cookie de tracking déjà expiré : il ressemble à un visiteur tout neuf, non attribué. La vente peut tout de même s'enregistrer, mais dépouillée de la campagne qui l'a générée. Multipliez cela sur une clientèle très mobile et une énorme part de votre attribution s'évapore en silence.

L'App Tracking Transparency aggrave les choses en coupant les signaux inter-applications et inter-sites, ce qui touche Meta particulièrement durement. Notre glossaire définit l'ITP, l'ATT et le reste de ces termes en langage clair.

Pourquoi la conception first-party, côté serveur, survit

Le correctif a deux moitiés, parce que la perte a deux moitiés.

La première moitié, c'est l'argent. Avec PrestaSignal, purchase et remboursement ne dépendent jamais du navigateur : quand PrestaShop confirme une commande, votre back-office rapporte la vente de serveur à serveur, via un serveur de suivi géré que nous opérons pour vous. Les bloqueurs de publicités vivent dans le navigateur et ne peuvent annuler que les requêtes qui en sortent — ils n'ont aucune prise sur un appel effectué par le serveur de votre boutique. La vente est enregistrée exactement une fois, et un remboursement suit avec l'identifiant de transaction correspondant pour que le chiffre d'affaires se reverse correctement.

La seconde moitié, c'est tout le reste — pages vues, vues produit, étapes de panier et de paiement. Ces événements se produisent toujours dans le navigateur, mais ils ne voyagent plus vers un domaine d'analyse tiers. Le module place un petit connecteur sur l'adresse web propre de votre boutique, et le navigateur enregistre les événements à travers lui — le même domaine sur lequel l'acheteur est déjà en train d'acheter — avec les bibliothèques de balises Google servies elles aussi depuis votre domaine. Les bloqueurs fonctionnent à partir de listes de filtres de domaines de tracking connus : les listes actuelles ciblent les domaines de Google, et avec tout ce qui se charge depuis votre propre adresse, il n'y a sur la page aucun domaine d'analyse tiers à leur faire correspondre.

C'est la différence structurelle : les événements du quotidien restent en terrain first-party, là où les listes de filtres actuelles ne visent pas, et les événements qui paient les factures ne touchent jamais le navigateur. Voyez côté serveur vs côté client pour la comparaison complète, ou comment ça marche spécifiquement sur PrestaShop.

À quoi ressemble réellement la récupération

Quand les marchands déplacent le tracking d'achat côté serveur, les conversions que les navigateurs de leurs acheteurs bloquaient redeviennent visibles — surtout pour les audiences très iOS ou utilisatrices de bloqueurs de publicités. Ce n'est pas un gain cosmétique dans un tableau de bord ; ce sont de vraies ventes qui deviennent visibles aux systèmes qui dépensent votre argent.

Les effets en cascade comptent plus que le chiffre en tête d'affiche. Le Smart Bidding de Google et l'optimisation de Meta apprennent tous deux des données de conversion. Nourrissez-les des conversions récupérées et ils voient enfin la vraie valeur de chaque clic et audience, cessent de sous-enchérir sur des campagnes discrètement rentables et réaffectent le budget vers ce qui fonctionne réellement.

Votre reporting revient aussi à la réalité : les taux de conversion cessent de paraître artificiellement bas, le ROAS cesse de paraître artificiellement médiocre, et le chiffre d'affaires GA4 se met à s'aligner sur l'argent en banque.

La récupération n'est pas un contournement

Il vaut la peine d'être clair sur ce qu'est et n'est pas le tracking côté serveur. Ce n'est pas une astuce pour suivre les personnes qui ont refusé le consentement, et ce n'est pas un moyen de contourner la loi sur la vie privée. Les événements respectent toujours les signaux de consentement, et les données personnelles sont normalisées et hachées avec SHA-256 avant de quitter votre boutique.

Ce que le tracking côté serveur corrige, c'est un échec technique de livraison : des conversions légitimes et consenties que le navigateur a laissées tomber pour des raisons qui n'ont rien à voir avec les souhaits du client. Un acheteur dont la commande n'a pas pu être signalée parce que son onglet s'est fermé ou que son réseau a coupé ne s'est désinscrit de rien.

Exploité correctement, avec le consentement respecté et une bannière et une politique en place, le tracking côté serveur est simplement un tuyau plus fiable pour les données que vous êtes déjà en droit de collecter. Si vous voulez mesurer votre propre perte face à de vraies commandes, réservez un audit.