Le tracking server-side fait passer des événements de mesure par une infrastructure que la boutique contrôle avant de les transmettre aux outils choisis. Google Tag Manager Server est une façon de le faire : un conteneur serveur reçoit des requêtes, les transforme en événements et les route. Le guide du tracking e-commerce explique d'abord quels achats et étapes mesurer.
Dessiner le trajet de chaque donnée
Schématisez la source (navigateur, checkout, système de commande), le point de collecte, les transformations et chaque destination. N'envoyez que les champs nécessaires. Définissez qui a accès au serveur, comment les erreurs sont journalisées et combien coûte l'hébergement. Google documente des déploiements Cloud Run et d'autres infrastructures ; le dimensionnement dépend du trafic et de la disponibilité visée.
Faire défiler le tableau →
| Étape | Question de contrôle |
|---|---|
| Source | L'événement décrit-il une action réellement terminée ? |
| Collecte | Valeur, devise et identifiant sont-ils intacts ? |
| Routage | La destination reçoit-elle seulement les données prévues ? |
| Rapport | La commande apparaît-elle une seule fois ? |
Ne pas confondre transport et qualité
Un achat fictif ou doublé reste faux, même transmis par serveur. Vérifiez le parcours de paiement, les retours de page de confirmation, les commandes annulées et les différences de devise. Pour les événements venant de deux chemins, utilisez les identifiants de déduplication prévus par chaque destination. Le suivi e-commerce enrichi dans GA4 aide à définir les paramètres utiles.
Le server-side peut réduire certains scripts dans le navigateur et donner plus de contrôle sur les données envoyées. Il ne garantit ni une mesure complète, ni un gain de performance, ni une meilleure attribution. Mesurez ces effets sur votre configuration réelle.
Respecter les choix et sécuriser le système
Le passage par un domaine de collecte de première partie ne permet pas d'ignorer le consentement. Faites appliquer les choix des visiteurs avant l'envoi aux destinations concernées et documentez les règles de traitement. Limitez les accès, surveillez les coûts et prévoyez une alerte si le serveur cesse de recevoir des achats. Une panne de mesure peut laisser les campagnes apprendre sur des données incomplètes.
Basculer progressivement
Sur un échantillon, comparez achats et revenus remontés par l'ancien et le nouveau chemin à la source de vérité e-commerce. Validez les cas limites : paiement refusé, remboursement, double clic, reprise mobile et changement de devise. Documentez les écarts avant d'étendre. Une période de coexistence ne signifie pas qu'il faut compter deux fois les conversions dans les plateformes.
Questions fréquentes
Le tracking server-side supprime-t-il le besoin de tags navigateur ?
Pas toujours. Le serveur a besoin de recevoir les événements depuis le navigateur, l'application ou le système e-commerce. L'architecture dépend des données et des destinations choisies.
Permet-il de contourner le refus de consentement ?
Non. Le passage par un serveur ne change pas les choix des visiteurs ni les obligations applicables à la collecte et à la transmission des données.
Pourquoi dédupliquer les achats ?
Le même achat peut être transmis par navigateur et serveur. Un identifiant de commande ou d'événement cohérent évite qu'une plateforme le compte deux fois, selon son mécanisme de déduplication.
Faut-il choisir Google Tag Manager Server ?
C'est une option documentée par Google, pas la seule. Comparez hébergement, contrôle des données, maintenance et intégration avec vos plateformes.
On regarde vos chiffres ensemble ?
45 minutes, vos données sous les yeux, et une lecture de là où se cache la marge dans votre acquisition.
Réserver un appel