Les échecs GTM Server-Side sont fréquemment invisibles : les données cessent de circuler, l’attribution se casse ou les coûts s’envolent sans aucune indication dans l’interface GTM. Voici les erreurs d’implémentation les plus courantes dans les déploiements GTM Server-Side.
1. Aucun domaine personnalisé configuré
L’échec le plus basique, et celui qui rend tout le reste inutile.
Sans domaine personnalisé (par exemple gtm.yourdomain.com), votre conteneur serveur reçoit des requêtes depuis un contexte d’URL tiers. Les cookies définis depuis ce contexte sont des cookies tiers. Ils sont soumis aux mêmes restrictions de navigateur que vous essayiez d’éviter. Tout l’intérêt du paramétrage des cookies first-party server-side est que votre serveur partage un domaine avec votre site.
Diagnostic : Vérifiez que le server_container_url dans votre configuration Google Tag correspond à votre sous-domaine personnalisé, et non à une URL *.run.app. Vérifiez avec curl https://gtm.yourdomain.com/healthy — doit retourner « OK ».
2. Les signaux de consentement n’atteignent pas le conteneur serveur
GTM server-side n’a pas de Consent Mode intégré. Le consentement doit être configuré dans le conteneur web et encodé dans les paramètres HTTP (gcs et gcd) que le conteneur web envoie avec chaque requête à votre conteneur serveur.
Si les signaux de consentement sont supprimés en transit — par un CDN, un reverse proxy qui modifie les query strings, ou une règle Cloudflare mal configurée — votre conteneur serveur fonctionne sans information de consentement. Les tags Google ajustent leur comportement automatiquement, mais les tags non-Google (Meta CAPI, TikTok, LinkedIn) se déclenchent inconditionnellement. Les utilisateurs ayant refusé le consentement voient leurs données envoyées aux plateformes publicitaires.
Diagnostic : Dans le mode Preview de GTM server-side, inspectez les données d’événement entrantes pour les champs x-ga-gcs et gcd. S’ils sont absents, les signaux de consentement sont supprimés avant d’atteindre le serveur.
3. Nom de client sensible à la casse dans les déclencheurs
Celui-ci cause plus de maux de tête de débogage que n’importe quel autre problème.
Dans les conditions de déclencheur GTM server-side, le champ Client Name est sensible à la casse. Si votre Client GA4 s’appelle « GA4 » et que votre condition de déclencheur vérifie « ga4 », le déclencheur ne se déclenche jamais. Aucune erreur. Aucun avertissement. Le tag ne se déclenche simplement pas.
Le conteneur s’exécute, le Client réclame les requêtes, les données d’événement sont correctement parsées — et puis chaque tag qui dépend de cette condition de déclencheur ne produit rien.
Diagnostic : Ouvrez chaque déclencheur qui utilise Client Name equals [valeur]. Comparez la chaîne exacte — y compris la capitalisation — au nom réel du Client dans votre configuration Clients. Ils doivent correspondre caractère par caractère.
4. Déduplication d’événements Meta manquante
Si vous exécutez à la fois le Meta Pixel dans le navigateur et Meta CAPI dans le conteneur serveur (ce que Meta recommande), vous devez implémenter la [[fr/configuration-serveur-meta-capi|déduplication d’événements via event_id partagé]].
Sans cela, chaque conversion est comptée deux fois : une fois par le Pixel et une fois par CAPI. Meta ne signalera pas cela automatiquement. Events Manager affiche un nombre sain d’événements provenant de deux sources, et cela semble correct. Vous ne découvrez le doublement que lorsque vous comparez avec les vrais chiffres de conversion et constatez que le total déclaré est environ le double de ce que vous attendez.
Diagnostic : Dans Events Manager, recherchez les conversions affichant « de 2 sources ». Si elles montrent 1 événement provenant de 2 sources, la déduplication fonctionne. Si elles apparaissent comme des événements séparés, l’event_id n’est pas partagé ou ne correspond pas.
5. Cloud Logging laissé aux paramètres par défaut
La configuration de journalisation par défaut de Cloud Run enregistre chaque requête dans Cloud Logging à 0,50 $/Go. Pour un serveur de tracking recevant des milliers de petites requêtes par heure, c’est catastrophiquement cher.
Le coût de compute pour 2 instances always-on est d’environ 90 $/mois. La journalisation par défaut à un trafic modéré ajoute 100 à 220 $/mois en plus — souvent plus que le coût du compute lui-même. La ventilation complète est couverte dans GTM Server-Side : Coûts d’hébergement.
Diagnostic : Consultez la ventilation de facturation de votre Google Cloud Console. Si les postes Cloud Logging sont significatifs, vous sur-journalisez. Correctif : limitez la journalisation Cloud Run aux erreurs et aux requêtes par échantillonnage dans les paramètres Cloud Logging.
6. Throttling CPU activé sur Cloud Run
Sans le flag --no-cpu-throttling (« CPU always allocated »), Cloud Run throttle le CPU à zéro entre les requêtes. Pour un serveur web stateless servant des chargements de pages occasionnels, c’est acceptable. Pour un serveur de tracking qui doit recevoir une requête, la parser, effectuer 2 à 4 appels HTTP sortants vers des API vendeurs et répondre rapidement — le throttling provoque des timeouts et des pertes de données sous tout trafic réel.
Le symptôme est sporadique : la plupart des requêtes se terminent correctement, un pourcentage expire et perd des données. Le taux d’échec est proportionnel à la fréquence à laquelle le conteneur se refroidit entre les bursts de trafic.
Diagnostic : Vérifiez votre configuration Cloud Run — « CPU is always allocated » doit être activé, pas « CPU is only allocated during request processing ».
7. Serveur de preview scalé au-delà d’1 instance
Le mode debug/preview de GTM maintient l’état de session entre plusieurs requêtes. Le serveur de preview utilise l’état en mémoire pour suivre quels événements se sont déclenchés, quels tags ont été exécutés et dans quel ordre. Si vous scalez le serveur de preview au-delà d’1 instance, les requêtes de la même session de debug atteignent des instances différentes. Chaque instance n’a qu’un état partiel. Le mode debug affiche des informations incomplètes ou contradictoires.
Cela n’affecte pas le tracking de production — cela rend seulement le débogage peu fiable, ce qui est son propre problème.
Diagnostic : Vérifiez Cloud Run pour votre service de preview. Les instances min et max doivent toutes deux être définies à 1.
8. Cookies FPID compromis par un mismatch d’IP
La configuration du cookie FPID semble correcte dans GTM et le cookie semble être défini — mais les utilisateurs Safari affichent toujours des fenêtres d’attribution de 7 jours. C’est la vérification d’adresse IP de Safari 16.4.
Si votre CNAME gtm.yourdomain.com pointe vers l’infrastructure Cloud Run, l’adresse IP résolue est sur le réseau de Google, pas sur le réseau de votre hébergeur. Safari compare les IP et traite le cookie comme un cookie tiers malgré le nom de domaine correspondant. La limite de 7 jours s’applique.
Diagnostic : Ouvrez le Web Inspector de Safari lors d’une visite depuis votre site. Vérifiez l’onglet Réseau pour la réponse qui définit le cookie FPID. Regardez l’expiration du cookie — si c’est 7 jours à partir de maintenant plutôt que 90+ jours, Safari l’a classifié comme tiers. Comparez l’IP de gtm.yourdomain.com avec l’IP de yourdomain.com en utilisant dig ou un outil de lookup DNS.
Trois solutions existent : First Party Mode, reverse proxy, ou Stape Cookie Keeper.
9. Consentement spécifique par région non configuré
Le Consent Mode a deux modes d’échec du côté de la configuration du consentement :
- Refus global — refuser le consentement pour tous les utilisateurs mondialement fait perdre des données des utilisateurs dans les régions où le consentement n’est pas légalement requis (la plupart des États-Unis, par exemple). Votre mesure devient beaucoup plus bruitée que nécessaire.
- Accord global — accorder le consentement globalement pour tous les utilisateurs viole le RGPD pour les utilisateurs EEE qui n’ont pas explicitement consenti.
La configuration correcte utilise des défauts de consentement spécifiques par région : refus par défaut pour les utilisateurs EEE/UK (où l’opt-in est requis), accord par défaut pour les utilisateurs américains dans les États sans exigences d’opt-in, et exceptions au niveau des États pour la Californie, le Colorado, etc.
Diagnostic : Dans la configuration du Consent Mode de votre conteneur web, vérifiez si des paramètres de région sont définis. Un défaut global sans exceptions régionales est presque certainement incorrect.
10. Implémentations de tags dupliqués
Des tags GA4 ou Google Ads apparaissant à deux endroits : codés en dur dans le HTML <head> du site et également gérés via GTM.
Le tag codé en dur n’a pas accès à la gestion de l’état de consentement de GTM. Il se déclenche inconditionnellement, indépendamment de ce que l’utilisateur a sélectionné dans la bannière de consentement. Le tag géré par GTM respecte correctement le consentement. Résultat : des données sont collectées pour les utilisateurs qui ont refusé le consentement via le tag codé en dur, et le même utilisateur génère des événements dupliqués — un depuis le tag codé en dur, un depuis GTM.
C’est simultanément un problème de qualité des données et un problème de conformité.
Diagnostic : Inspectez le code source de votre page et l’onglet Réseau. Si vous voyez gtag.js chargé directement depuis https://www.googletagmanager.com/gtag/js?id=G-XXXXXX dans votre HTML et des événements GA4 se déclenchant via GTM, vous avez des implémentations dupliquées. La solution est de supprimer le tag codé en dur et de laisser GTM être le mécanisme de chargement unique.