GTM Server-Side sur Cloud Run : Déploiement et configuration

Cloud Run est la plateforme de déploiement recommandée pour GTM Server-Side depuis octobre 2023, en remplacement d’App Engine. Il exécute l’image Docker officielle du serveur de tagging Google en tant que conteneur serverless entièrement managé — vous ne gérez pas l’infrastructure sous-jacente, mais vous contrôlez la configuration et la région.

Domaine personnalisé : première étape non négociable

Avant de toucher à Cloud Run, vous avez besoin d’un sous-domaine personnalisé pointant vers votre conteneur serveur. Ce n’est pas optionnel. Sans domaine personnalisé, les cookies sont définis dans un contexte tiers et vous perdez tous les avantages des cookies first-party qui rendent le tracking server-side utile.

Deux approches :

Approche par sous-domaine (la plus courante) : Créez un enregistrement CNAME pointant gtm.yourdomain.com vers l’URL de votre service Cloud Run. Google gère le SSL automatiquement via des certificats managés, bien que le provisionnement puisse prendre jusqu’à 24 heures. Cette approche est simple mais présente une limitation : la vérification d’adresse IP de Safari 16.4 signifie que l’approche CNAME seule ne garantit pas le plein rétablissement de la durée de vie des cookies.

Approche same-origin (avancée) : Utilisez un CDN ou un Cloud Load Balancer avec du routage par chemin — par exemple, router /metrics/* vers Cloud Run tandis que le reste du domaine sert votre site normalement. Cela donne le traitement de cookie first-party le plus fort car le serveur partage exactement la même origine que votre site, résolvant complètement le problème d’incompatibilité d’IP. Cette approche nécessite plus de configuration d’infrastructure mais constitue l’architecture long terme correcte pour les sites où l’attribution Safari est importante.

Vérifiez que votre déploiement est opérationnel en appelant https://gtm.yourdomain.com/healthy — il doit retourner « OK ».

Provisionnement automatique vs manuel

GTM propose un flux de provisionnement automatique qui crée les services Cloud Run directement depuis l’interface GTM. C’est plus rapide à configurer mais présente une limitation significative : le provisionnement automatique déploie toujours en US Central (Iowa), indépendamment de l’emplacement de vos utilisateurs.

Le provisionnement manuel est recommandé pour la production. Il vous permet de :

Sélectionner une région plus proche de vos utilisateurs pour une latence plus faible
Conserver les données dans l’infrastructure européenne pour la conformité RGPD lors du service du trafic EU
Contrôler exactement quel projet et quel compte de service est utilisé

Le flux manuel consiste à déployer Cloud Run vous-même avec l’image de conteneur officielle, puis à coller l’URL du service dans les paramètres du conteneur serveur GTM.

Configuration en production

Les paramètres recommandés par Google pour le serveur de tagging :

Min instances: 2     # élimine les cold starts
Max instances: 10    # gère environ 350 req/s
CPU: 1 vCPU, always allocated
Memory: 512 MiB
Request timeout: 60 secondes

Le flag --no-cpu-throttling (CPU always allocated) est critique. Sans lui, Cloud Run throttle le CPU entre les requêtes. Pour un serveur qui doit traiter et transmettre des données rapidement — effectuant souvent plusieurs appels HTTP sortants par requête — le throttling CPU cause une latence inconsistante et peut provoquer des timeouts et des pertes de données sous charge.

Les cold starts comptent davantage pour le tracking que pour la plupart des applications. Un cold start sur une requête vers /g/collect signifie que ce hit est abandonné ou retardé. Un minimum de 2 instances élimine les cold starts en maintenant le conteneur chaud en permanence.

Le serveur de preview (dédié au mode debug GTM) doit fonctionner avec exactement 1 instance. Le scaler au-delà d’1 instance entraîne un comportement imprévisible du mode debug car l’état du debug est stocké en mémoire et plusieurs instances ne le partagent pas.

Architecture multi-région

Pour le trafic mondial, un déploiement Cloud Run dans une seule région introduit de la latence pour les utilisateurs éloignés de la région choisie. Le pattern pour une couverture mondiale :

Déployer des services Cloud Run sur plusieurs régions (par exemple europe-west1, us-east1, asia-east1)
Créer des Serverless Network Endpoint Groups (NEGs) pour chaque service régional
Les placer derrière un External Application Load Balancer unique avec une IP anycast globale
Configurer des règles de routage géographique sur le load balancer

Le load balancer ajoute environ 18 $/mois en coûts de base mais offre deux avantages supplémentaires : la protection DDoS Cloud Armor et le routage du trafic géographique qui dirige les utilisateurs EU vers votre instance EU (pertinent pour les exigences de résidence des données RGPD).

Pour la plupart des configurations avec un public majoritairement européen ou américain plutôt que véritablement mondial, un déploiement régional unique dans la bonne région est suffisant. Déployez sur europe-west1 pour le trafic principalement EU ou us-east1 pour le trafic principalement US et évitez la complexité du load balancer.

Le piège du Cloud Logging

Les paramètres par défaut de Cloud Run enregistrent chaque requête dans Cloud Logging. À 0,50 $/Go ingéré, la journalisation par défaut pour un trafic de tracking modéré ajoute 100 à 220 $/mois — dépassant souvent les coûts de compute.

Désactivez la journalisation détaillée des requêtes après le déploiement. La journalisation des erreurs et la journalisation par échantillonnage des requêtes suffisent pour le débogage ; la journalisation par requête en détail complet n’est pas nécessaire. C’est typiquement le coût inattendu le plus important dans un nouveau déploiement GTM Server-Side.

Serveur de tagging vs serveur de preview

Votre déploiement server-side crée deux services Cloud Run distincts :

Serveur de tagging — gère le trafic de production. Appliquez la configuration de production ci-dessus (min 2 instances, CPU always allocated). C’est ce vers quoi gtm.yourdomain.com pointe.

Serveur de preview — gère les sessions de mode debug/preview GTM. Exécutez-le avec exactement 1 instance. Les sessions de debug se connectent à une instance spécifique du serveur de preview et s’attendent à ce que l’état persiste entre les requêtes de la même session. Plusieurs instances cassent cette attente.

Le serveur de preview n’a pas besoin de la même capacité que le serveur de tagging. Il n’est actif que lorsque quelqu’un a le panneau de preview GTM ouvert, pas pendant le trafic normal des utilisateurs. Gardez-le minimal.

Connexion du conteneur

Une fois Cloud Run déployé, vous le connectez à votre conteneur serveur GTM en :

Dans GTM, accédez aux paramètres de votre conteneur serveur
Définissez la « Tagging Server URL » sur votre domaine personnalisé (par exemple https://gtm.yourdomain.com)
Définissez optionnellement l’URL du serveur de preview si vous l’avez déployé séparément

Dans votre conteneur web, mettez à jour le champ server_container_url de la configuration Google Tag sur votre domaine personnalisé. Cela redirige tous les hits GA4 via votre serveur au lieu de les envoyer directement aux endpoints de collecte de Google. Sans ce changement dans le conteneur web, votre infrastructure serveur reste inactive — le navigateur envoie toujours les hits directement à Google.