Comment récupérer les conversions que les bloqueurs de publicités cachent
Une grande part de vos acheteurs bloque l'analyse avant qu'elle n'atteigne Google ou Meta. Voici comment la perte survient et comment le côté serveur la récupère.
Entre un quart et la moitié de vos conversions pourraient ne jamais atteindre votre analyse — non pas parce que les ventes n'ont pas eu lieu, mais parce que le navigateur du client a refusé de les signaler. Les bloqueurs de publicités, les extensions de confidentialité et les restrictions de suivi d'Apple annulent silencieusement les requêtes qui portent vos événements de tracking.
Le plus frustrant est à quel point c'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 la récupérer.
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é tiennent des listes de blocage de domaines d'analyse et de publicité, et ils annulent toute requête se dirigeant 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. Des taux de blocage d'environ 30 % sont courants sur les audiences générales, et ils grimpent 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 les campagnes et segments qui paraissent 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. L'ITP plafonne la durée de vie des cookies posés par le JavaScript côté client — parfois à seulement 24 heures ou 7 jours.
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é, donc il ressemble à un visiteur tout nouveau et 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 cela en coupant les signaux inter-applications et inter-sites, touchant Meta particulièrement durement. Notre glossaire définit l'ITP, l'ATT et le reste de ces termes en langage clair.
Pourquoi le tracking côté serveur les contourne
Le tracking côté serveur change l'endroit où l'événement prend naissance. Au lieu de demander au navigateur de signaler une conversion à Google ou Meta, le serveur de votre boutique envoie l'événement directement, de serveur à serveur, via un conteneur sGTM auto-hébergé.
Les bloqueurs de publicités et les extensions de confidentialité vivent dans le navigateur. Ils ne peuvent annuler que les requêtes qui quittent le navigateur — ils n'ont aucune portée sur un appel serveur à serveur que votre back-end effectue. L'ITP régit les cookies du navigateur, donc une conversion envoyée depuis votre serveur, ancrée à la commande elle-même plutôt qu'à un cookie fragile, n'est pas affectée.
C'est la raison structurelle pour laquelle le tracking côté serveur récupère ce que le côté client perd : il déplace les événements les plus importants hors du seul endroit — le navigateur — où ils sont le plus susceptibles d'être bloqués. 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, la récupération typique se situe dans la fourchette de 30 à 50 % des conversions précédemment manquantes — parfois davantage 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 30 à 50 % récupérés 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.
Questions rapides
Combien de conversions les bloqueurs de publicités cachent-ils réellement ?+
Cela varie selon l'audience, mais des taux de blocage autour de 30 % sont courants et plus élevés chez les acheteurs techniques ou soucieux de leur vie privée. Combinée à l'ITP, la perte totale atteint souvent 30 à 50 %.
Les bloqueurs de publicités peuvent-ils aussi bloquer les événements côté serveur ?+
Non. Les bloqueurs de publicités opèrent à l'intérieur du navigateur et ne peuvent annuler que les requêtes qui le quittent. Un événement serveur à serveur envoyé depuis votre back-end ne passe jamais par le navigateur pour être bloqué.
L'ITP affecte-t-il le tracking côté serveur ?+
Pas de la même façon. L'ITP plafonne les cookies posés par le navigateur. Les événements côté serveur sont ancrés à la commande plutôt qu'à un fragile cookie côté client, donc les règles d'expiration de l'ITP ne les effacent pas.
Récupérer les conversions bloquées est-il légal ?+
Oui, quand c'est bien fait. Cela récupère des conversions consenties que le navigateur a laissées tomber pour des raisons techniques. Le consentement est toujours respecté et les données personnelles sont hachées avant de quitter votre boutique.
À quelle récupération dois-je m'attendre ?+
Généralement 30 à 50 % des conversions précédemment manquantes, parfois davantage pour les audiences très iOS ou utilisatrices de bloqueurs. Le chiffre exact dépend de votre trafic et de votre configuration actuelle.