Dispatch hybride client/serveur dans GTM : splitter vos événements GA4 avec la tête, pas au hasard

Tout envoyer côté serveur, c’est la tentation. C’est aussi la meilleure façon de faire exploser votre facture Cloud Run et de perdre la finesse des signaux comportementaux que seul le navigateur peut capturer. La vraie question n’est pas « client ou serveur ? », c’est « quel événement mérite quel chemin ? »

Le principe du split : un seul paramètre, deux destins

Vous pouvez manipuler le paramètre server_container_url dans vos tags GA4 côté client pour déterminer si le tag doit dispatcher vers le sGTM ou directement vers les serveurs de Google. C’est le levier central de toute l’architecture hybride.

Simo Ahava recommande de toujours définir ce paramètre dans les settings du Google Tag pour pointer vers votre endpoint sGTM, ce qui fait du dispatch serveur le comportement par défaut. La seule exception : si vous voulez que sGTM reste l’exception et ne traite qu’une poignée d’événements clés — dans ce cas, ne mettez pas server_container_url dans le Google Tag.

Concrètement, ça donne deux configurations possibles. Soit le serveur est le flux principal et vous redirigez quelques événements légers directement vers Google. Soit le client reste le flux principal et vous montez côté serveur uniquement les événements qui le méritent.

Ce que ça change vraiment : le schéma du flux

Voici comment les données circulent dans une architecture hybride e-commerce :

[Navigateur]
    │
    ├─ page_view, scroll, video_progress
    │       └──► [Google Analytics directement]  ← client-side, rapide, pas de coût sGTM
    │
    ├─ add_to_cart, begin_checkout, purchase
    │       └──► [sGTM endpoint : tags.monsite.com]
    │                   │
    │                   ├─ Filtrage bot (user-agent + IP score)
    │                   ├─ Enrichissement (marge réelle, tier CRM)
    │                   ├─ Déduplication transaction_id
    │                   └──► [GA4] + [Meta CAPI] + [Google Ads]
    │
    └─ _ga cookie écrit en first-party (durée 13 mois)

Les événements de conversion qui alimentent l’optimisation des campagnes paid — Demo Booked, Trial Started, Purchase — sont ceux que les plateformes utilisent pour apprendre votre audience. En perdre 30% à cause des adblockers, c’est entraîner vos algorithmes sur un échantillon non représentatif. Montez les conversions côté serveur en priorité. Les pages vues et les micro-interactions d’engagement peuvent rester côté client.

Le piège du cookie : JavaScript Managed, pas Server Managed

Si vous splittez vos événements GA4 et utilisez sGTM pour en forwarder une partie vers Google Analytics, vous devez configurer le GA4 Client dans sGTM en mode « JavaScript Managed identity ». Si vous utilisez « Server Managed » à la place, vos événements sGTM et vos événements client-side utiliseront des valeurs de cookies différentes pour l’identifiant client — et finiront dans des enregistrements utilisateur distincts.

Ça paraît anodin. En pratique, ça casse votre attribution cross-session complètement. Un utilisateur qui browse en client-side puis convertit via sGTM devient deux utilisateurs différents dans GA4. Vérifiez ce paramètre avant de passer en prod.

Filtrer les bots côté serveur : là où ça compte vraiment

Avec le tracking server-side, les événements identifiés comme spam sont filtrés immédiatement avant d’être forwardés vers GA4. La donnée n’atteint même pas Google Analytics. C’est fondamentalement différent de ce que vous pouvez faire côté client.

GA4 rate les bots sophistiqués parce qu’il fonctionne sur liste noire, pas sur détection active. La liste IAB/ABC attrape les user-agents qui se déclarent volontairement comme bots. Tout le reste passe. Au lieu que le navigateur envoie les données directement à Google — facilement contournable — le navigateur envoie vers votre container serveur. Sur le serveur, vous pouvez assainir la donnée avant qu’elle n’atteigne GA4, l’enrichir avec des scores de fraude internes.

Le cas e-commerce : enrichir sans exposer

Imaginez un scénario où côté client vous collectez uniquement un événement purchase avec un transaction_id. Dans sGTM, vous utilisez ce transaction_id pour aller chercher le reste des données e-commerce depuis votre moteur de vente via des appels HTTP API ou depuis Firestore. Vous pouvez même remplacer la valeur collectée côté client par le profit réel et l’envoyer à vos vendors. Vous n’exposeriez jamais vos marges dans le client — côté serveur, c’est parfaitement faisable.

Prompt IA pour automatiser la logique de dispatch

Voici un prompt directement utilisable dans ChatGPT ou Claude pour générer votre matrice de routage événements :

Tu es un expert GTM server-side. 
J'ai un site e-commerce avec les événements GA4 suivants : 
[liste tes événements].

Pour chaque événement, indique :
1. Dispatch recommandé : client-side direct / sGTM / les deux (dual-tagging)
2. Justification : coût réseau, sensibilité de la donnée, 
   besoin d'enrichissement, risque bot
3. Paramètres à enrichir côté serveur si applicable
4. Risque de duplication à gérer (oui/non + méthode)

Format : tableau markdown avec colonnes 
Événement | Dispatch | Justification | Enrichissement | Anti-dupe

Ce prompt vous sort en 30 secondes une matrice que vous auriez mis deux heures à construire manuellement. Ajustez la liste d’événements, itérez.

Ce que le merge Google Tag + GTM change à cette logique

Selon Simo Ahava, « un container GTM sera désormais un Google Tag pleinement opérationnel en lui-même, et tout Google Tag supplémentaire ajouté comme destination bénéficiera d’un chargement optimisé, de settings partagés et d’un modèle de permissions mutuels. »

Il est donc conseillé d’inclure server_container_url et les autres paramètres critiques dans des Event Settings Variables. Si vous déclenchez un Google Tag avec server_container_url spécifié, suivi d’un Google Tag avec le même Tag ID sans server_container_url, ce deuxième hit n’ira pas vers votre serveur. Dans une architecture hybride, ce comportement peut silencieusement casser votre routage.

La conformité n’est pas une option de confort

Les sanctions CNIL 2024-2025 montrent que de nombreux sites continuaient à lire des cookies — y compris des cookies first-party — après un retrait de consentement, caractérisant un manquement à l’obligation d’effectivité du retrait. La CNIL rappelle qu’après le retrait du consentement, toute lecture ou écriture de traceurs doit cesser, y compris ceux générés automatiquement.

Les plateformes publicitaires priorisent de plus en plus la qualité du signal first-party plutôt que le volume brut d’événements. Le server-side devient le point de normalisation, d’enrichissement et de fiabilisation de ces signaux avant activation.

Votre prochaine action concrète : ouvrez votre plan de marquage, listez vos événements, et appliquez ce critère simple pour chaque ligne — est-ce que cet événement contient une donnée sensible, alimente une conversion paid, ou nécessite un enrichissement CRM ? Si oui à l’un des trois, il va côté serveur. Sinon, laissez-le respirer dans le navigateur.