Le server side déplace une partie du traitement et peut donner davantage de contrôle. Il ne remplace ni une définition fiable des événements ni les obligations applicables.
Comprendre le trajet des données
Dans un dispositif de tracking server side, un serveur reçoit et traite certains événements avant leur éventuelle transmission aux outils de mesure. Il peut les vérifier, les transformer et choisir leurs destinations. Des informations peuvent toujours provenir du navigateur : le passage côté serveur ne signifie pas que le site n’envoie plus rien.
Google Tag Manager propose notamment un conteneur serveur utilisant des balises, déclencheurs et variables. Cette architecture se distingue du conteneur web exécuté dans le navigateur. L’article Google Tag Manager présente ce vocabulaire, utile pour comprendre un schéma de collecte proposé par un prestataire.
Identifier un besoin avant de choisir l’architecture
Le projet peut chercher à mieux contrôler les destinations, normaliser les données ou simplifier certains traitements. Le bénéfice dépend du dispositif existant. Un serveur ne répare pas automatiquement un événement mal défini ni une valeur commerciale absente du système source.
Commencez par cartographier les événements, les paramètres, les outils destinataires et les personnes responsables. Un audit tracking peut révéler qu’une correction du plan de mesure suffit pour un premier périmètre. La migration doit répondre à un besoin documenté, avec un critère de réussite observable.
Préserver les choix de consentement
Le server side ne supprime pas les règles applicables aux traceurs et aux données personnelles. Les choix exprimés sur le site doivent être pris en compte dans le dispositif retenu. Une technique de collecte ne constitue pas à elle seule une exemption ou une preuve de conformité.
Examinez les données reçues, les journaux et les transmissions, avec les responsables concernés. Limitez les informations aux usages définis. N’envoyez pas des champs libres ou des URL contenant des informations personnelles simplement parce qu’un connecteur les accepte. La page consentement et tracking décrit l’importance des contrôles de comportement.
Tester les doublons et les situations d’échec
Exemple fictif : une commande est envoyée depuis le navigateur et depuis un système de vente. Sans règle de déduplication adaptée aux outils destinataires, elle peut être comptée deux fois. Le plan de marquage doit préciser l’identifiant, les événements et le traitement attendu des remboursements.
Testez aussi un envoi retardé, une valeur absente et une indisponibilité temporaire. Conservez des preuves de recette avec des données de test. La continuité du service doit inclure un moyen de repérer les erreurs et de décider si une transmission peut être rejouée sans créer une seconde conversion.
Chiffrer l’exploitation après l’installation
L’hébergement, la configuration, la surveillance et la maintenance font partie du coût. Définissez qui contrôle les alertes, met à jour les composants et suit les dépenses. Le projet doit prévoir un retour arrière et une documentation permettant à une autre personne de reprendre le dispositif.
Comparez ensuite des périodes et des définitions compatibles. Une variation du nombre d’événements après migration peut signaler un changement de mesure, pas une hausse réelle des ventes. L’implémentation du tracking doit inclure cette vérification et laisser visibles les limites restantes dans les rapports.