GTM Server-Side est une architecture avec des composants distincts qui nécessitent chacun une configuration séparée. Le guide complet se trouve dans le guide d’architecture et de configuration complète GTM Server-Side. Ces notes décomposent ce guide en éléments navigables.
Par où commencer
GTM Server-Side : Architecture et quatre blocs constitutifs — Comment l’architecture fonctionne : le flux de requêtes navigateur-vers-serveur-vers-vendeur, le multiplexage et les quatre types de composants (Clients, Tags, Déclencheurs, Variables/Transformations). Lisez ceci en premier.
GTM Server-Side sur Cloud Run : Déploiement et configuration — Déploiement du conteneur serveur sur Google Cloud Run : provisionnement automatique vs manuel, configuration de production (allocation CPU, comptages d’instances, l’exigence du serveur de preview), configuration de domaine personnalisé et architecture multi-région.
Intégrations vendeurs
Cookies server-side et contournement de Safari ITP — Le mécanisme FPID qui définit les cookies first-party via l’en-tête HTTP, la vérification d’adresse IP de Safari 16.4 qui brise de nombreux déploiements basés sur CNAME, et trois approches qui le résolvent (First Party Mode, reverse proxy, Stape Cookie Keeper).
Meta CAPI : Configuration server-side — Déduplication des événements avec event_id partagé, scoring Event Match Quality et mapping des données utilisateur, transmission des cookies _fbp et _fbc, et application du consentement pour les tags vendeurs non-Google.
Google Ads Enhanced Conversions Server-Side — Le tag Conversion Linker et le cookie FPGCLAW, la configuration des données utilisateur Enhanced Conversions, et à quoi ressemble une uplift de conversion réaliste.
Opérations
GTM Server-Side : Coûts d’hébergement en auto-hébergé vs managé — Tarification Cloud Run par niveau de trafic, le piège des coûts Cloud Logging (souvent plus cher que le compute), et une comparaison des alternatives managées : Stape.io, Addingwell et Cloudflare Zaraz.
GTM Server-Side : Cadre de décision pour l’hébergement — Comment choisir entre Cloud Run, AWS ECS Fargate, Azure App Service et les providers managés selon votre infrastructure existante, votre capacité opérationnelle et votre volume de trafic.
GTM Server-Side sur AWS — Architecture ECS Fargate et ventilation des coûts, pourquoi la NAT Gateway rend AWS plus cher qu’il n’y paraît, où les Savings Plans font basculer l’économie, et pourquoi Lambda est incompatible.
GTM Server-Side sur Azure — Niveaux App Service et configuration SSL, Container Apps comme alternative proche de Cloud Run, et pourquoi Azure Functions ne fonctionnera pas.
Providers d’hébergement GTM Server-Side managés — Stape (incluant Cookie Keeper et Custom Loader), Addingwell, TAGGRS et Cloudflare Zaraz — ce que chacun inclut, où chacun est le bon choix.
GTM Server-Side : Dix échecs d’implémentation et comment les éviter — Dix erreurs d’implémentation sur l’ensemble de la stack : domaines personnalisés manquants, signaux de consentement qui ne circulent pas, le piège du nom de Client sensible à la casse dans les déclencheurs, déduplication Meta manquante, mismatch IP compromettant les cookies FPID, et implémentations de tags dupliqués.
Contexte associé
Ces notes fournissent le contexte pour comprendre pourquoi le tracking server-side est important :
- Restrictions des cookies navigateur en 2026 — Pourquoi le tracking client-side manque 20 à 40 % des visiteurs
- Propagation du Consent Mode dans GTM Server-Side — Comment les signaux de consentement voyagent via les paramètres
gcs/gcdet pourquoi les tags non-Google nécessitent une application manuelle du consentement - Résolution d’identité pour la mesure publicitaire — Ce que le tracking server-side ne résout pas (cross-device, suppression des cookies) et ce qui comble le manque