Comment splitter GA4 avec server_container

Je route certains événements GA4 vers SGTM et je laisse les autres partir directement vers Google avec server_container_url. L’intérêt est simple : moins de coût, plus de résilience, et un meilleur contrôle. Le vrai sujet, c’est de le faire sans casser l’identifiant client.

Pourquoi ne pas tout envoyer en SGTM ?

Je n’envoie pas tout en SGTM parce que tous les événements GA4 n’ont pas la même valeur business, le même besoin de contrôle, ni le même impact coût.

Dans un tracking GA4 classique, Google Tag Manager côté client déclenche les événements depuis le navigateur. Avec un conteneur server-side GTM, une partie des hits ne part plus directement vers Google Analytics. Elle passe d’abord par votre serveur de tracking, souvent via le paramètre server_container_url, puis le serveur relaie vers GA4.

C’est très utile quand l’événement mérite d’être sécurisé, enrichi ou contrôlé. Un achat, un lead, une inscription, une demande de démo, ça a une vraie valeur business. Là, je veux pouvoir nettoyer les données, ajouter des infos serveur, mieux gérer le consentement, filtrer le spam, réduire certaines pertes liées aux bloqueurs, ou garder une logique de tracking plus maîtrisée.

Mais pour un scroll à 25 %, un clic secondaire, une ouverture d’accordéon ou une interaction qui sert juste à lire le comportement utilisateur, je ne vais pas forcément mobiliser toute l’infrastructure SGTM. Ça marche, oui. Mais ce n’est pas toujours utile.

Formez-vous à Google Tag Manager !

Apprenez grâce à nos formations Google Tag Manager une compétence précieuse pour tout professionnel du web. Cet outil permet de simplifier la gestion des balises, de gagner du temps, d'améliorer la précision des données et de personnaliser le suivi des événements. En maîtrisant GTM, vous pouvez optimiser vos campagnes marketing, améliorer les performances de votre site et prendre des décisions basées sur des données fiables et précises.

Il y a aussi un sujet simple à ne pas oublier : SGTM a un coût. Le conteneur serveur tourne sur une infrastructure cloud. Chaque requête reçue, traitée, puis renvoyée vers GA4 consomme des ressources. Le network egress, c’est le trafic sortant depuis votre infrastructure vers l’extérieur, et lui aussi peut peser selon les volumes. Je ne dramatise pas, mais sur des sites avec beaucoup de trafic, envoyer tous les micro-événements côté serveur peut vite devenir un choix discutable.

Je garde aussi une voie directe vers les endpoints Google quand c’est pertinent. Si le conteneur serveur est indisponible, mal configuré ou temporairement en erreur, certains événements moins sensibles peuvent continuer à partir côté client. Ça évite de mettre tout le tracking derrière un seul point de passage.

Concrètement, je peux faire ce tri :

Achats, leads, inscriptions : Je les envoie via SGTM, parce qu’ils sont critiques et méritent plus de contrôle.
Scrolls, clics mineurs, interactions secondaires : Je peux les laisser partir côté client, surtout s’ils servent surtout à l’analyse UX.

La logique est simple. Je fais passer par SGTM ce qui a de la valeur, ce qui doit être fiable, enrichi ou mieux gouverné. Je laisse en direct ce qui est moins sensible, moins stratégique, ou trop volumineux pour justifier le coût et la complexité.

Comment définir le routage par défaut ?

Je définis le routage par défaut avec le paramètre server_container_url dans la configuration du Google Tag, idéalement via une Event Settings Variable. C’est le réglage le plus propre quand je veux que GA4 passe par un conteneur serveur SGTM sans devoir modifier chaque événement un par un.

Quand server_container_url contient l’URL de votre conteneur SGTM, les événements GA4 ne partent plus directement vers les endpoints Google classiques. Ils sont envoyés vers votre conteneur serveur. Le conteneur serveur reçoit l’événement, peut le contrôler, l’enrichir, le filtrer si besoin, puis le transmettre à GA4. C’est ça le principe du server-side tagging avec GA4.

Le vrai intérêt, c’est de placer ce paramètre au niveau global. Si je le mets directement dans la configuration du Google Tag, ou mieux dans une Event Settings Variable utilisée par ce tag, j’évite de répéter server_container_url dans chaque tag GA4 Event. Votre tracking devient plus lisible, plus stable, et surtout plus cohérent. Tous les événements suivent le même comportement par défaut.

Une Event Settings Variable, c’est simplement une variable GTM qui centralise les paramètres d’événement. Au lieu d’avoir les mêmes réglages dispersés partout, je les mets à un seul endroit. C’est bête, mais sur des comptes avec 30 ou 40 événements GA4, ça change tout. J’ai déjà vu des setups où certains événements partaient en server-side, d’autres en direct vers Google, juste parce qu’un paramètre avait été oublié. C’est exactement le genre de bug silencieux qu’on veut éviter.

Ce routage par défaut prépare aussi les exceptions. Une fois que tout passe par SGTM par défaut, je peux décider événement par événement si certains doivent suivre un autre chemin. On garde une base propre, puis on ajuste uniquement là où c’est nécessaire.

Les événements qui méritent souvent le passage server-side sont ceux qui ont de la valeur business, ou qui demandent plus de contrôle :

purchase
generate_lead
sign_up
begin_checkout
Événements enrichis ou sensibles

Mon approche simple, c’est donc celle-ci : je mets server_container_url dans le réglage global, je centralise avec une Event Settings Variable, puis je gère les cas particuliers seulement quand ils existent vraiment.

Comment forcer un envoi côté client ?

Je force l’envoi côté client en redéfinissant server_container_url au niveau du tag d’événement GA4 avec une valeur vide ou null. Ça dit à GA4 : pour cet événement précis, n’utilise pas le serveur SGTM, envoie directement à Google.

Le point important, c’est la priorité. Le paramètre défini dans le tag d’événement GA4 écrase celui défini plus haut, que ce soit dans le Google Tag ou dans l’Event Settings Variable. Donc si votre configuration globale pointe vers votre server container, vous pouvez quand même faire sortir un événement du tunnel serveur, juste en surchargeant ce paramètre au niveau du tag concerné.

Concrètement, sur l’événement que je veux envoyer directement à Google, j’ajoute un paramètre dans le tag GA4 :

Nom du paramètre : server_container_url
Valeur : une chaîne vide, donc rien du tout

Visuellement, ça peut paraître bizarre parce qu’on ajoute un champ pour le laisser vide. Mais c’est justement ça qui réinitialise le comportement. Je l’utilise parfois pour des événements de debug, ou pour isoler un souci quand un client me dit “l’événement part bien côté navigateur mais je ne le vois pas côté serveur”. Là, je coupe le détour SGTM sur un seul event, et je vois tout de suite si le problème vient du serveur ou du tracking client.

Si vous voulez rendre l’intention plus claire, vous pouvez aussi passer par une variable Custom JavaScript. Elle retourne explicitement une chaîne vide ou null. C’est plus lisible dans une configuration maintenue par plusieurs personnes.

function() {
  return "";
}

Ou avec null :

function() {
  return null;
}

La nuance à ne pas rater, c’est la différence entre null, une chaîne vide et undefined. Une chaîne vide ou null réinitialise le comportement. undefined, lui, veut plutôt dire “ignore ce champ”, donc la valeur définie plus haut peut continuer à s’appliquer.

Valeur vide	Réinitialise server_container_url et force l’envoi direct côté client.
null	Réinitialise aussi le paramètre et permet de bypasser SGTM pour cet événement.
undefined	Le champ est ignoré, donc la configuration héritée peut rester active.

Comment éviter les erreurs humaines ?

J’évite les erreurs en rendant l’exception visible, nommée clairement, et impossible à confondre avec un champ oublié.

Dans GTM, un champ vide, c’est rarement neutre pour un humain. Techniquement, vous savez pourquoi il est vide. Mais la personne qui repasse derrière dans trois mois peut le lire comme un oubli, une dette, ou un paramètre cassé.

Je l’ai vu plusieurs fois sur des comptes clients. Un champ vide reste en place, puis quelqu’un arrive avec une bonne intention, “corrige” le paramètre, remet le server_container_url, publie, et c’est là que le tracking casse. Pas par incompétence. Juste parce que l’intention n’était pas lisible.

Pour éviter ça, je préfère utiliser une variable explicite au lieu de laisser une valeur vide directement dans le tag. Par exemple une Custom JavaScript Variable ou un Custom Variable Template avec un nom qui dit clairement ce qu’elle fait.

{{JS - Force envoi client-side - server_container_url vide}}

Le nom est presque plus important que la technique ici. Il doit éviter toute ambiguïté. Quelqu’un doit comprendre en lisant le tag que ce n’est pas un champ oublié, c’est une exception volontaire.

Les bonnes pratiques que j’applique sont simples :

Nommer l’intention, pas seulement le contenu technique.
Éviter les noms vagues comme “empty”, “null”, “test” ou “fix”.
Indiquer le comportement attendu, par exemple “force envoi client-side”.
Garder la convention visible dans le conteneur GTM, avec une note ou une documentation interne.
Utiliser le même format partout, pour que l’équipe reconnaisse vite les exceptions volontaires.

Je documente aussi la convention de nommage dans GTM. Pas besoin d’un roman. Une note claire suffit, du type : “Les variables nommées Force envoi client-side servent à rendre volontairement vide le server_container_url sur certains tags GA4.”

La lisibilité ne suffit pas, il faut aussi vérifier l’impact sur l’identifiant client.

Quels réglages surveiller avant de splitter ?

Je surveille surtout deux choses avant de splitter, la valeur réellement envoyée dans server_container_url et la gestion de l’identifiant client dans SGTM.

Le premier piège, il est bête mais je l’ai déjà vu plusieurs fois chez des clients : on croit désactiver l’envoi vers le conteneur server-side, alors qu’on envoie juste une valeur ambiguë. Si vous voulez réinitialiser server_container_url, utilisez une chaîne vide « » ou null. Ça dit clairement à GA4 : “je n’utilise plus cette URL server-side”.

Undefined, je l’évite dans ce cas précis. Si votre objectif est de forcer le retour à l’envoi direct vers Google, undefined peut laisser le comportement précédent en place selon le contexte d’exécution, le tag, ou la façon dont la variable est résolue. Et là, vous pensez splitter proprement, mais certains événements continuent à partir vers SGTM sans que ce soit évident au premier coup d’œil.

Le deuxième point, c’est le GA4 Client dans le conteneur server-side. Quand vous mélangez des événements envoyés côté navigateur et d’autres envoyés via SGTM, il faut que l’identifiant client reste cohérent. Sinon GA4 peut croire qu’un même utilisateur est plusieurs personnes, ou qu’une session est coupée en deux.

Dans le client GA4 du conteneur server-side, je mets la gestion de l’identifiant en JavaScript Managed. Ça veut dire que l’identifiant client est piloté de façon compatible avec ce qui se passe côté navigateur. C’est important quand une partie du tracking passe en client-side et une autre en server-side.

Si ce réglage est mal géré, les effets peuvent être assez pénibles :

Des sessions coupées ou recréées artificiellement.
Des utilisateurs moins bien reconnus entre deux événements.
Des parcours qui deviennent plus difficiles à analyser.
Des rapports GA4 moins fiables, surtout sur l’attribution et les conversions.

Je ne splitte pas pour faire joli. Je le fais selon l’importance business de l’événement et le coût de traitement côté server-side. Un achat, un lead, une création de compte, ça mérite souvent SGTM. Un scroll à 25 %, pas toujours.

Famille d’événements	Exemples	Destination conseillée
Critiques	Achat, lead, inscription, ajout au panier stratégique	SGTM
Utiles mais non critiques	Recherche interne, vue produit, clic important	SGTM si la donnée sert vraiment, sinon client-side
Bruit analytique	Scroll, clics secondaires, micro-interactions	Client-side

Alors, quels événements doivent vraiment passer par SGTM ?

Le split GA4 avec server_container_url est une solution simple, mais pas anodine. Je garde SGTM comme comportement par défaut pour les événements qui comptent vraiment, puis je force certains tags à repartir côté client avec une valeur vide ou null. Ça permet de réduire la charge serveur, de limiter les coûts et de garder une continuité si SGTM tombe. Le point à ne pas rater, c’est l’identifiant client avec le GA4 Client en JavaScript Managed. Bien fait, vous gardez un tracking plus robuste, plus lisible, et mieux aligné avec vos vrais enjeux business.

FAQ

À quoi sert server_container_url dans GA4 ? server_container_url indique au Google Tag où envoyer les événements GA4. Quand il contient l’URL du conteneur server-side GTM, les hits passent par SGTM. Quand on le réinitialise correctement sur un tag précis, l’événement peut repartir directement vers Google côté client.
Pourquoi splitter les événements entre client-side et server-side ? Je le fais pour éviter d’envoyer inutilement tout le trafic dans SGTM. Les événements critiques peuvent profiter du contrôle server-side, alors que certains événements secondaires peuvent rester côté client. Ça aide à réduire la charge, les coûts et le risque de dépendre uniquement du conteneur serveur.
Comment forcer un événement GA4 à partir directement vers Google ? Il faut redéfinir server_container_url au niveau du tag de l’événement et lui donner une chaîne vide ou une valeur null. Le paramètre du tag écrase celui configuré plus haut dans le Google Tag ou l’Event Settings Variable.
Pourquoi ne pas utiliser undefined pour server_container_url ? undefined ne réinitialise pas vraiment le comportement. Il indique plutôt que le champ doit être ignoré. Pour forcer le retour à l’envoi direct côté client, il faut utiliser une chaîne vide ou null.
Quel réglage SGTM est important si je mélange client-side et server-side ? Le GA4 Client côté serveur doit être configuré en JavaScript Managed si vous mélangez les deux modes d’envoi. L’objectif est de conserver le même identifiant client et de mieux relier les sessions et utilisateurs dans GA4.

A propos de l’auteur

Je suis Franck Scandolera, expert et formateur en tracking avancé server-side, Analytics Engineering, automatisation No/Low Code avec n8n, IA appliquée en entreprise et SEO/GEO. J’accompagne des équipes sur des sujets très concrets : GA4, GTM server-side, qualité de donnée, automatisation et pilotage business. J’ai travaillé avec des références comme Logis Hôtel, Yelloh Village, BazarChic, la Fédération Française de Football ou Texdecor. Je dirige l’agence webAnalyste et l’organisme Formations Analytics. Si vous voulez fiabiliser votre tracking ou industrialiser vos automatisations, contactez-moi.

Franck Scandolera

⭐ Analytics engineer, Data Analyst et Automatisation IA indépendant ⭐

Ref clients : Logis Hôtel, Yelloh Village, BazarChic, Fédération Football Français, Texdecor…

Mon terrain de jeu :

Data Analyst & Analytics engineering : tracking avancé (GA4, Matomo, Piano, GTM server, Tealium, Commander Act, e-commerce, CAPI, RGPD), entrepôt de données (BigQuery, Snowflake, PostgreSQL, ClickHouse), modèles (Airflow, dbt, Dataform), dashboards décisionnels (Looker, Power BI, Metabase, SQL, Python).
Automatisation IA des taches Data, Marketing, RH, compta etc : conception de workflows intelligents robustes (n8n, App Script, scraping) connectés aux API de vos outils et LLM (OpenAI, Mistral, Claude…).
Engineering IA pour créer des applications et agent IA sur mesure : intégration de LLM (OpenAI, Mistral…), RAG, assistants métier, génération de documents complexes, APIs, backends Node.js/Python.