Retour au blog

Blog

Pourquoi SignalHost : ce que perdent les balises dans le navigateur, et ce que votre propre serveur de tagging récupère

Publié · 7 min de lecture

Chaque chiffre dans GA4, Google Ads et Meta commence par une requête envoyée depuis le navigateur d’un visiteur vers une adresse qui appartient à Google ou à Meta. Une part croissante des navigateurs est conçue pour arrêter précisément ces requêtes, et rien ne vous prévient quand cela se produit : le rapport affiche simplement moins. SignalHost déplace ce trafic sur votre propre domaine et sur un serveur de tagging à vous, construit et exploité pour vous. Voici ce qui plaide en sa faveur, dans l’ordre où les problèmes vous atteignent — et, pour finir, la liste honnête de ce qu’il ne fait pas et de qui n’en a pas besoin.

Ce que vos rapports ne vous montrent jamais

Avec des balises dans le navigateur, chaque mesure est une requête vers le domaine de quelqu’un d’autre : le script Tag Manager depuis googletagmanager.com, chaque hit GA4 vers google-analytics.com, chaque événement Meta vers facebook.com. Les bloqueurs de publicité, les extensions de confidentialité, les navigateurs dotés d’un blocage des traqueurs intégré et les filtres DNS des réseaux de bureau et domestiques reconnaissent ces noms d’hôte et ces chemins, et écartent la requête. La page se charge normalement. La visite, elle, n’arrive jamais.

Vous ne pouvez pas voir cette perte dans GA4, parce que GA4 ne montre que ce qui est arrivé. Son ampleur dépend de votre audience — bien plus grande pour un public technique, jeune ou soucieux de sa vie privée que pour un public général — et elle touche tous les rapports à la fois : moins d’utilisateurs, moins de sessions, moins de conversions, et des campagnes qui paraissent moins bonnes qu’elles ne le sont.

Le blocage est l’une des quatre raisons pour lesquelles GA4 affiche moins de conversions que votre boutique : pourquoi GA4 compte trop peu, et ce qui peut être récupéré.

Là où cela coûte le plus : les conversions et les plateformes publicitaires

Une page vue perdue est un désagrément. Une conversion perdue vous coûte deux fois. Google Ads, Meta et TikTok décident où va votre budget en apprenant des conversions qu’ils reçoivent : chaque achat qu’un bloqueur avale est un achat dont les enchères n’apprennent jamais rien, et chaque campagne affiche un rendement inférieur à celui qu’elle a réellement obtenu.

La seconde perte est le clic sur l’annonce lui-même. Une conversion ne compte pour une campagne que si elle peut être rattachée au clic qui l’a provoquée, et ce lien est un ID de clic — gclid pour Google, fbclid pour Meta, ttclid pour TikTok — qui figure dans l’adresse de la page de destination et en disparaît au clic suivant du visiteur. Il faut quelque chose pour le conserver jusqu’à l’achat, et ce quelque chose est un cookie. S’il est posé depuis l’adresse d’un autre site, Safari le refuse purement et simplement, et l’achat, trois pages plus loin, arrive sans aucun clic rattaché.

Ce que SignalHost change

  • Vos balises se chargent et transmettent depuis votre propre domaine. Avec metrics.votresite.com comme adresse de tagging, chaque requête va, pour le navigateur, vers votre propre site, et aucune liste visant les noms d’hôte de Google ne la repère.
  • Plus rien à reconnaître. Les listes de filtres cherchent aussi gtm.js, /g/collect et les ID de mesure sur n’importe quel domaine. SignalHost encode chaque requête dans un seul chemin opaque, différemment pour chaque client, si bien que le nom de fichier, le nom de l’événement, votre ID de mesure et l’adresse de la page ne sont plus en clair.
  • Les conversions parviennent aux plateformes publicitaires depuis votre serveur. Google Ads, Meta, TikTok, Reddit, Pinterest, Snapchat et LinkedIn reçoivent vos événements par leurs propres interfaces serveur — la Conversions API de Meta, l’Events API de TikTok et les autres — au lieu d’un pixel dans le navigateur. Gardez aussi un pixel si vous le souhaitez : envoyez le même event_id aux deux, et chaque plateforme compte l’événement une seule fois.
  • Le clic survit jusqu’à l’achat. Votre conteneur serveur conserve l’ID de clic dans un cookie sur votre propre domaine — FPGCLAW pour Google Ads, _fbc pour Meta —, si bien qu’un achat effectué plusieurs pages ou plusieurs jours plus tard parvient encore à la plateforme avec le clic dont il provient.
  • Un événement, toutes les destinations. Les événements que votre site envoie déjà à GA4 alimentent aussi chaque plateforme que vous connectez, traduits dans les noms propres à chacune, si bien que vous configurez un événement une fois au lieu d’une fois par plateforme.

Ce que vous auriez sinon à construire et à faire tourner vous-même

Rien de tout cela n’est une technologie nouvelle. Google Tag Manager côté serveur est l’outil de Google lui-même, et vous pouvez l’héberger vous-même. Cela suppose un projet Google Cloud avec facturation, un serveur de tagging maintenu en service en production et un second pour l’aperçu, votre propre domaine pointé dessus avec un certificat, une image serveur à tenir à jour, et une facture qui grandit avec votre trafic. Puis les conteneurs : un conteneur web dont la balise Google envoie à votre serveur, une balise pour chaque événement, un conteneur serveur qui les reçoit et les transmet, et pour chaque plateforme publicitaire un modèle, des identifiants et un déclencheur — et chacun de ces éléments peut tomber en panne sans qu’aucune erreur n’apparaisse nulle part.

SignalHost s’occupe de cette partie. Vous connectez votre compte Google une fois — Tag Manager et Analytics en lecture seule, rien d’autre — et il construit et publie les deux conteneurs dans votre propre compte : la balise Google pointée vers votre serveur, des balises pour seize événements standard, des inscriptions et des prospects jusqu’à chaque étape d’un tunnel de paiement, le côté serveur, et chaque plateforme publicitaire que vous ajoutez. Cela prend environ quatre minutes, et vous collez un extrait dans votre site.

Les conteneurs restent à vous. Ils se trouvent dans votre compte Tag Manager, sous votre identifiant : modifiez-les, ajoutez vos propres balises, ou partez en les gardant. Quand une balise doit changer — parce que Google a changé quelque chose, ou parce que nous avons ajouté un événement —, vos conteneurs sont mis à jour sans que vous ayez à cliquer sur quoi que ce soit. Le tout tourne sur une infrastructure européenne, sans projet Google Cloud ni facture cloud à la requête de votre côté.

Ce que vous voyez désormais, et que vous ne pouviez pas voir avant

  • Le nombre de requêtes et d’événements en direct pour chaque conteneur, si bien que « ça marche ? » obtient une réponse en quelques secondes plutôt que dans le rapport du lendemain.
  • Deux chiffres par événement : tout ce qui est arrivé, et la part arrivée avec un consentement analytics — votre taux de consentement, mesuré plutôt qu’estimé.
  • Pages, sources de trafic, pays, navigateurs et appareils, comptés à partir des pages vues que votre serveur a délivrées. Des agrégats uniquement : aucune adresse IP ni aucun identifiant client n’est stocké.
  • Une carte « Dépannage » qui suit vos pages vues depuis votre site, à travers votre serveur, jusqu’au rapport en temps réel de GA4 lui-même, et qui vérifie le chemin vers chaque plateforme publicitaire que vous avez connectée.
  • Avec Growth, Enterprise ou Unlimited, le mode Aperçu de Tag Manager se connecte à votre conteneur serveur comme il le ferait à un conteneur que vous hébergez vous-même.

Ce qu’il ne fait pas

  • Il ne remplace pas le consentement. Une requête vers votre propre domaine exige le même consentement qu’une requête vers celui de Google. Les visiteurs qui refusent restent sur leur refus : les balises de Google n’envoient que ce que Consent Mode autorise, et Meta, TikTok et les autres plateformes ne reçoivent rien pour eux.
  • Il ne fait pas correspondre GA4 à la page de votre conteneur. Analytics exclut les visiteurs qui ont refusé les cookies ; votre serveur compte chaque requête. La différence est votre taux de consentement, pas des données perdues.
  • Il ne peut pas conserver le clic sur l’annonce sans votre propre domaine. Sur le nom d’hôte gratuit sous signalhost.io, vos balises ont déjà quitté les domaines de Google, mais le cookie du clic vient toujours d’un autre site, et Safari le refuse. C’est votre propre domaine, sur une offre payante, qui permet au clic de survivre.
  • Il ne fait pas revenir un visiteur dont le navigateur n’exécute aucun script, ni celui qui part avant que la page ait fini de se charger.

Qui en a besoin, et qui n’en a pas besoin

Vous en avez besoin quand de l’argent dépend des chiffres : vous diffusez des annonces sur Google, Meta, TikTok ou les autres et voulez qu’elles apprennent de chaque vente ; vous vendez en ligne et le nombre de commandes de votre boutique ne concorde pas avec GA4 ; votre audience est technique, jeune ou attentive à sa vie privée ; ou vous rendez des comptes à un client dont le budget suit le tableau de bord.

Vous n’en avez probablement pas besoin si vous ne diffusez pas d’annonces, si votre site reçoit quelques centaines de visites par mois et si personne ne décide quoi que ce soit à partir des chiffres. Analytics côté navigateur suffit quand dix pour cent de plus ou de moins ne changent rien.

Le moyen le plus rapide de savoir dans quel cas vous êtes, c’est de mesurer. L’offre gratuite comprend dix mille requêtes par mois et ne facture jamais rien. Configurez-la, puis comparez une semaine de conversions dans GA4 et dans vos plateformes publicitaires avec la semaine précédente.

Cessez de perdre vos données

Commencez gratuitement. Votre premier conteneur est prêt en quelques minutes.