Pourquoi le suivi côté serveur peut encore perdre des données (et comment le Enhanced Tracking Script y remédie)

Principaux enseignements

• Le suivi côté serveur ne protège pas à lui seul contre les bloqueurs de publicité qui interceptent la requête navigateur-serveur avant que n'atteigne le conteneur de votre serveur.
• Les scripts de suivi standard disponibles sur le marché ne résolvent pas le manque de données au niveau du script.
• Le script de suivi amélioré TAGGS crypte l'intégralité de la demande d'événement (et pas seulement l'URL du script GTM), ce qui la rend méconnaissable pour tout filtre de blocage.
• Sur les audiences à fort taux de blocage (développeurs, spécialistes du marketing, professionnels de l'analyse), l'augmentation générée par le script TAGGRS atteint près de 30 % de requêtes mesurées en plus.

Le suivi côté serveur résout un véritable problème de mesure. Il éloigne la collecte de données du navigateur et donne à votre installation un point de terminaison serveur de première partie. Pour de nombreuses équipes, c'est le plus grand pas vers une meilleure attribution.

Mais il y a une couche qui passe souvent inaperçue.

Avant qu'un événement n'atteigne le conteneur de votre serveur, le navigateur doit encore charger le script de suivi et envoyer la demande d'événement. Si l'une de ces parties est bloquée, votre installation côté serveur n'a pas la possibilité de faire son travail.

Le tableau de bord peut encore sembler sain. Les événements continuent d'arriver. Votre conteneur de serveur fonctionne. Mais une partie des données peut fuir avant même que la première requête côté serveur ne soit effectuée.

Pour les agences et les spécialistes du suivi, cette lacune est importante. Vous pouvez construire la bonne architecture côté serveur et perdre quand même des données au niveau de la couche de script.

Le script de suivi amélioré TAGGRS comble cette lacune. Il remplace votre snippet GTM standard par un script qui crypte l'intégralité de la requête navigateur-serveur, la rendant méconnaissable pour les filtres de blocage. Cet article explique où commence l'écart entre les données, pourquoi le cryptage est plus performant que l'encodage au niveau du script et quelle amélioration mesurable les agences peuvent attendre.

Le suivi côté serveur ne démarre pas sur le serveur

La plupart des équipes considèrent le suivi côté serveur comme un problème de conteneur de serveur. Elles vérifient que le serveur de balisage est actif, que le GA4 reçoit des événements et que les balises de conversion se déclenchent.

Ces contrôles sont utiles, mais ils commencent trop tard.

Une configuration typique dépend toujours d'un script de suivi côté navigateur - généralement Google Tag Manager. GTM se charge dans le navigateur, démarre le conteneur et envoie des requêtes au point de terminaison côté serveur. Pour la plupart des configurations, le chargement du script est déjà résolu. Le script GTM est masqué et se charge donc sans problème.

Le point faible vient ensuite.

Comment le script GTM crée un angle mort

Une fois le script chargé, il doit encore envoyer des événements au conteneur côté serveur. Même lorsque ces demandes sont adressées à un domaine de première partie, le chemin de la demande peut encore contenir des marqueurs reconnaissables tels que /collect, /g/collect ou d'autres modèles d'analyse. Les bloqueurs de publicité peuvent détecter ces modèles et bloquer l'événement avant qu'il n'atteigne le conteneur du serveur.

Cela crée un mode de défaillance difficile à repérer :

• le script GTM se charge
• le point de terminaison côté serveur est de première partie
• le chemin d'accès à la demande révèle toujours la nature de la demande
• Le GA4 et les plateformes publicitaires reçoivent moins d'événements
• les rapports de campagne continuent à être mis à jour, mais avec moins de données qu'ils ne le devraient

Rien ne semble complètement cassé. Vous voyez les données, mais pas toutes.

Il en résulte un angle mort au niveau des mesures. Le suivi côté serveur améliore le chemin après que la demande a atteint le serveur de marquage, mais il ne peut pas traiter un événement qui a été bloqué dans le navigateur parce que la demande ressemblait encore à du suivi.

C'est là que l'amélioration devient visible. Si la couche de script et le chemin de requête deviennent plus difficiles à reconnaître, davantage d'événements atteignent le conteneur du serveur.

La preuve : 0,8 % à 9,1 % de pages vues en plus.

TAGGRS a conçu le script de suivi amélioré pour supprimer la couche visible la plus faible du suivi moderne : la requête qui ressemble encore à une analyse avant qu'elle n'atteigne le conteneur côté serveur.

L'objectif est simple. Si un utilisateur donne son consentement et qu'un événement est censé être mesuré, ces données doivent pouvoir être transmises au conteneur côté serveur au lieu d'être arrêtées par un script reconnaissable ou un chemin de requête.

En pratique, cela fait du script de suivi amélioré l'un des scripts de suivi les plus résistants du marché. TAGGRS l'a testé auprès de 30 partenaires pionniers et sur le site web que vous êtes en train de lire. La différence était évidente.

L'indice de référence TAGGRS (Enhanced Tracking Script uplift)

Mise en place	Augmentation du nombre de pages vues
Suivi standard côté client	Base de référence
Masquage des scripts GTM + domaine de première partie	+0.8%
Script de suivi amélioré TAGGRS	+9.1%
Publics très bloquants (développeurs, spécialistes du marketing)	Jusqu'à ~30%

Avec le masquage standard gtm.js et un domaine de première partie, TAGGRS a mesuré une augmentation de 0,8 % des pages vues par rapport au suivi classique côté client. Cette configuration résolvait déjà une partie du problème : le script GTM pouvait se charger à partir d'un chemin moins reconnaissable.

Après la mise en œuvre du nouveau script de suivi amélioré, l'augmentation est passée à 9,1 % des pages vues mesurées. La différence provient du masquage de l'ensemble de la requête, et pas seulement du chargement du script GTM. Au lieu d'envoyer des événements par des chemins reconnaissables, le script a rendu la requête complète du navigateur au serveur plus difficile à identifier pour les bloqueurs.

L'effet a été le même pour les partenaires qui ont été les premiers à se lancer. Dans les cas les plus forts, l'augmentation a atteint près de 30 % d'événements mesurés en plus.

Une augmentation de 9,1 % n'est pas une amélioration cosmétique des rapports. Sur un compte à dépenses élevées, elle peut modifier la qualité du signal renvoyé à Google Ads, Meta, GA4 ou d'autres plateformes.

Un meilleur signal ne permet pas seulement d'améliorer les rapports. Il donne également aux algorithmes publicitaires un retour d'information plus complet. Les campagnes sont optimisées en fonction des événements qui survivent à la chaîne de suivi. Si une partie de cette chaîne est bloquée au niveau du script, l'algorithme apprend à partir d'une image incomplète.

L'importance du profil de l'audience

Le profil de l'audience a un effet important sur l'ampleur de l'augmentation :

• Les sites web destinés aux consommateurs pourraient bénéficier d'une légère augmentation.
• Les produits utilisés par les développeurs, les spécialistes du marketing, les équipes d'analyse ou les acheteurs de technologie ont tendance à afficher un pourcentage plus élevé. Ces visiteurs sont plus susceptibles d'utiliser des bloqueurs de publicité ou des paramètres de navigateur plus stricts.

Pour les agences qui mettent en place des dispositifs de suivi pour des clients axés sur la performance, l'effet est toujours très fort.

Pourquoi les trajectoires de suivi standard sont-elles faciles à détecter ?

Les bloqueurs de publicité n'ont pas besoin de comprendre l'ensemble de votre configuration de suivi. Ils recherchent des modèles.

Ces modèles peuvent être des domaines, des chemins d'accès, des noms de fichiers, des formes de demande ou des points de terminaison analytiques connus. Une requête de suivi standard offre aux bloqueurs de nombreuses possibilités de travail. Le chemin d'accès est familier. La structure de la requête est familière. Le comportement du réseau est familier.

Le suivi côté serveur modifie la destination de nombreuses requêtes, mais le chemin d'accès peut encore révéler ce qui se passe. Une demande adressée à un domaine de première partie peut toujours contenir un chemin d'accès en forme de suivi.

C'est le point faible.

Pensez-y comme à un code propre par rapport à un code fragile. Le code fragile fonctionne tant que l'environnement est favorable. Si vous changez une hypothèse, il se casse la figure. Le code propre est construit avec moins de modèles fragiles, il résiste donc mieux lorsque l'environnement change.

Le suivi présente le même problème. Une configuration peut fonctionner parfaitement dans un test de navigateur propre et perdre quand même des données lorsqu'un visiteur utilise uBlock Origin, Ghostery, un navigateur strict en matière de confidentialité ou une liste de filtres qui cible des chemins d'accès communs comme /collect.

La résilience ne consiste pas à dissimuler un comportement douteux. Il s'agit de rendre les mesures consenties moins fragiles.

Pourquoi d'autres n'ont pas résolu le problème de la couche d'écriture

De nombreuses configurations de suivi s'arrêtent au routage côté serveur. Elles déplacent les requêtes du GA4 ou de la plateforme publicitaire vers un point de terminaison de première partie, puis supposent que le problème est résolu.

Cette solution est utile, mais elle ne protège pas totalement la requête après le chargement du script.

Certains outils de suivi côté serveur reconnaissent déjà ce problème. Leur documentation explique que les requêtes GA4 utilisent des motifs reconnaissables comme /g/collect, et que les bloqueurs de publicité peuvent bloquer les requêtes correspondantes même lorsque la configuration utilise le suivi côté serveur. La solution habituelle consiste à coder les requêtes avant qu'elles n'atteignent le conteneur GTM côté serveur, puis à les décoder avant la prévisualisation/débogage.

C'est le bon problème à résoudre. Mais dans nos premiers tests, le masquage semblait faible parce que la structure de la requête pouvait encore être décodée et comprise trop facilement. Si la protection est principalement une couche de codage lisible, comme le masquage de type base64, il est plus difficile de la considérer comme une résilience à long terme. Les listes de filtres peuvent s'adapter une fois que le modèle est connu.

L'approche la plus rigoureuse ne consiste pas simplement à cacher le mot " collecter". La requête côté navigateur doit éviter les modèles stables que les bloqueurs de publicité pourront reproduire le mois prochain.

Ce que le script de suivi amélioré TAGGRS change

Le script de suivi amélioré adopte une approche plus rigoureuse : il crypte la demande au lieu de se contenter de l'encoder.

Cette différence est importante. Le codage est comparable à la traduction d'une phrase de l'anglais à l'espagnol. La phrase est différente, mais quiconque connaît la méthode peut la retraduire. Il s'agit toujours du même message dans un format différent.

Le cryptage fonctionne différemment. La demande est transformée avec une clé, de sorte que le chemin côté navigateur n'expose plus de marqueurs de suivi lisibles comme /collect ou /g/collect. Avant que la demande n'atteigne le conteneur côté serveur, TAGGRS peut la décrypter et l'acheminer correctement.

Le script de suivi amélioré est toujours un remplacement direct du script standard de Google Tag Manager. Au lieu de placer le snippet GTM normal sur le site web, vous ajoutez le Enhanced Tracking Script à partir de votre tableau de bord TAGGRS. Il fonctionne toujours avec votre conteneur web GTM, mais le flux de requêtes change.

À un niveau élevé, le script fait 4 choses :

1. remplace le modèle de chargement standard du GTM par un modèle plus résistant.
2. crypte l'intégralité de la requête navigateur-serveur, et pas seulement l'URL du script.
3. déchiffre et achemine la requête avant qu'elle n'atteigne le conteneur côté serveur.
4. permet de garder plus d'événements disponibles pour GA4 et les plateformes publicitaires lorsque des bloqueurs ou des restrictions de navigateur sont actifs.

L'essentiel est de savoir où il agit. Il ne remplace pas le suivi côté serveur. Il protège l 'étape précédant la réception de l'événement par le suivi côté serveur, où de nombreuses configurations exposent encore des voies d'analyse reconnaissables.

Vous vous demandez comment configurer le script ?

Est-ce légal et éthique ?

Oui, si elles sont utilisées à bon escient et avec les contrôles de confidentialité adéquats.

L'objectif est de combler les lacunes en matière de mesure, et non de suivre secrètement les utilisateurs contre leur gré. Les équipes d'analyse doivent néanmoins être transparentes dans leur politique de confidentialité, respecter les choix de consentement et donner aux utilisateurs le contrôle sur la collecte des données, comme l'exige la loi.

Il en va de même pour la qualité des données. Davantage de données ne sont utiles que si elles sont collectées de manière responsable. Les spécialistes du suivi doivent toujours appliquer des techniques d'anonymisation, éviter d'envoyer des IPI et vérifier que les demandes des utilisateurs équipés de bloqueurs de publicité ne contiennent pas de marqueurs de données personnelles qui ne devraient pas s'y trouver.

Le script de suivi amélioré est un outil. Il rend le parcours de suivi plus résistant, mais il ne supprime pas la responsabilité d'utiliser un traitement approprié du consentement, des contrôles de la vie privée et une bonne gouvernance des données.

Il existe également un second problème lié au consentement qui mérite son propre article. Certains bloqueurs de publicité peuvent bloquer ou interrompre les bannières de consentement elles-mêmes. Avec la bonne configuration du conteneur côté serveur, l'Enhanced Tracking Script peut contribuer à rendre le flux de consentement plus résistant. Ce sujet nécessite une explication plus approfondie, mais le principe est le même : les mesures doivent être fiables sans priver l'utilisateur de son choix.

Voyez l'amélioration dans votre propre tableau de bord

L'aspect le plus intéressant de ce dispositif est que l'impact est visible.

Dans le tableau de bord de TAGGRS Analytics, le graphique des demandes peut afficher des catégories de demandes. L'une de ces catégories est Enhanced Tracking Script (script de suivi amélioré). Elle montre les demandes déclenchées par le script, ce qui vous permet de savoir si le nouveau script est actif et quel est le volume de trafic qu'il gère.

C'est important pour la confiance.

La plupart des améliorations en matière de suivi sont difficiles à prouver. Un spécialiste modifie la configuration, les données semblent un peu meilleures et tout le monde doit déduire ce qui s'est passé. Le script de suivi amélioré offre aux agences un point de preuve plus clair. Vous pouvez montrer au compte ce qui a changé et où l'activité mesurée supplémentaire apparaît.

Le tableau de bord facilite également la validation après le déploiement :

• Utilisez la vue des dernières 24 heures pour vérifier l'effet peu de temps après la mise en œuvre.
• Utilisez les catégories de demandes pour confirmer l'arrivée des demandes de script de suivi amélioré.
• Comparez les données côté serveur et côté client pour voir combien de données supplémentaires votre configuration côté serveur capture.
• Surveillez les baisses inhabituelles après les changements de CMS, les modifications de GTM ou les mises à jour des filtres de blocage des publicités.

Pour les agences, cela est utile dans les conversations avec les clients. Au lieu de dire "nous avons rendu la configuration plus robuste", vous pouvez montrer la catégorie dans le tableau de bord et expliquer la couche récupérée.

La configuration du tableau de bord est expliquée dans la documentation du tableau de bord de suivi côté serveur TAGGRS.

Un commutateur, pas un autre projet d'infrastructure

La plupart des agences savent déjà à quel point les projets de suivi peuvent être lourds.

Il y a généralement un développeur de site web, un spécialiste du GTM, un spécialiste du marquage côté serveur, une limitation du CMS et un client qui veut un résultat pour hier. Même de petites modifications de suivi peuvent se transformer en un long fil de mise en œuvre.

Le script de suivi amélioré est conçu pour éviter cela.

Dans le tableau de bord TAGGRS, vous configurez la fonctionnalité sous Fonctionnalités → Optimiser → Script de suivi amélioré. Ajoutez l'ID du conteneur web GTM, activez l'option Maximiser vos performances, enregistrez les paramètres et remplacez l'ancien extrait GTM par le code généré.

Telle est la valeur pratique. Pas de nouveau serveur de marquage. Pas de projet de proxy personnalisé. Pas de travail d'infrastructure séparé pour l'agence.

Vous devez toujours avoir accès au code du site web ou au CMS, car le script doit remplacer le snippet GTM existant. Mais pour la plupart des équipes, il s'agit d'un changement moins important que la reconstruction de la configuration du suivi.

Pour les agences qui gèrent de nombreux comptes, la différence est encore plus grande. Une fonction qui peut être activée et validée dans le tableau de bord est plus facile à vendre, plus facile à déployer et plus facile à expliquer.

Comment s'insérer dans un dispositif de suivi des résiliences ?

Le script de suivi amélioré ne remplace pas une stratégie de suivi appropriée.

Vous avez toujours besoin d'une bonne gestion des consentements. Vous avez toujours besoin d'un conteneur de serveur fonctionnel. Vous avez encore besoin de noms d'événements propres, de déduplication, d'un mappage de conversion correct et d'intégrations de plateformes fiables.

Mais le script résout un point faible spécifique qui échappe à de nombreuses équipes : le premier chargement de la couche de suivi.

Une installation résiliente comporte plusieurs couches :

• Le script du site web se charge de manière fiable.
• Les événements sont envoyés à un point de terminaison du serveur de première partie.
• Le conteneur serveur enrichit, contrôle et transmet les données.
• Les cookies et les identifiants sont traités dans le respect de la vie privée.
• Le tableau de bord indique si l'installation produit réellement plus de données utilisables.

Si la première couche se brise, le reste du dispositif ne peut rien y faire. Le script de suivi amélioré renforce cette première couche.

Pour un diagnostic plus complet, téléchargez le guide " Quelle est la résilience de votre système de suivi ? Il vous aide à déterminer où se produit la perte de signal et ce qu'il faut réparer en premier.

FAQ

Le script de suivi amélioré est-il identique au suivi côté serveur ?

Le suivi côté serveur déplace le traitement des données vers un conteneur serveur. Le script de suivi amélioré améliore le script côté navigateur qui lance le flux de suivi.

Ils fonctionnent ensemble. Le suivi côté serveur gère le chemin d'accès au serveur. Le script de suivi amélioré permet à un plus grand nombre de requêtes d'atteindre ce chemin.

Cela remplace-t-il mon script Google Tag Manager actuel ?

Oui, le script de suivi amélioré est conçu pour remplacer le script GTM standard. N'exécutez pas les deux en même temps. Des scripts en double peuvent créer des événements en double et des rapports inexacts.

Cela permettra-t-il de combler toutes les lacunes en matière de suivi ?

Non. Il résout une lacune importante : la perte au niveau du script avant que le conteneur du serveur ne reçoive la requête.

D'autres problèmes peuvent encore affecter la qualité des données, notamment les paramètres de consentement, les balises cassées, les événements en double, les clients de conteneur de serveur manquants, les mauvaises correspondances d'événements et les limites d'attribution du côté de la plateforme.

Pourquoi un script de suivi de site web est-il important si j'utilise déjà le suivi côté serveur ?

Parce que la première requête commence toujours dans le navigateur. Si le script de suivi du site web est bloqué, le conteneur du serveur peut ne jamais recevoir l'événement.

Le suivi côté serveur améliore ce qui se passe après que la demande a été faite. Le script de suivi amélioré améliore les chances que la demande soit faite en premier lieu.

Puis-je voir l'impact à l'intérieur de TAGGRS ?

Oui. Le tableau de bord analytique comprend des catégories de demandes, y compris le script de suivi amélioré. Cela vous permet de vérifier si le script est actif et de voir comment il contribue au volume des demandes.

Pour une analyse plus approfondie, comparez les données côté serveur et côté client dans le tableau de bord sur une plage de dates cohérente.

Cela rend-il les publicités visibles pour les utilisateurs qui utilisent des bloqueurs de publicité ?

Non. Le Enhanced Tracking Script ne débloque pas les publicités, les bannières, les pop-ups ou les placements publicitaires sur votre site web.

Il est axé sur la mesure. Si un utilisateur équipé d'un bloqueur de publicité visite votre site et donne son accord, le script aide la demande de suivi à atteindre votre conteneur côté serveur. Il ne modifie pas ce que le visiteur voit sur la page.

Ainsi, les utilisateurs qui bloquent les publicités bloqueront toujours les publicités. La différence est que les signaux d'analyse et de conversion consentis ont une meilleure chance d'atteindre votre dispositif de mesure.