Shopify et Vercel reconstruisent Hydrogen comme une base ouverte et agnostique au runtime. Hydrogen …
Server-side tracking bien fait : la mesure appartient au schéma de composant
Server-side tracking bien fait : la mesure appartient au schéma de composant
Ouvre l'onglet réseau sur la plupart des storefronts et tu retrouves partout la même histoire : 25 à 40 tags tiers chargés dans le <head>, chacun étant un script qui s'exécute avant même que le client ne voie un produit. Analytics, deux pixels publicitaires, un outil de heatmap, une couche de consentement, un enregistreur de session, trois snippets "growth" que plus personne ne se souvient d'avoir ajoutés. Chaque tag est une requête, un parsing et un blocage du thread principal. La stack de mesure est devenue, en silence, l'une des charges de performance les plus lourdes de la page, et les données qu'elle produit s'amincissent à mesure que les navigateurs durcissent leurs règles sur les cookies et les scripts.
Il existe un modèle plus propre, et il repose sur deux mouvements. D'abord, la mesure s'exécute sur le serveur, pas dans 30 scripts navigateur. Ensuite, le tracking est déclaré dans le schéma de composant, juste à côté du composant qui émet l'événement, au lieu d'être câblé comme un projet de tags séparé. Les deux mouvements comptent. Le server-side, c'est le transport, le schéma de composant, c'est là où les événements prennent leur sens.
Ce que coûte vraiment la prolifération de tags client
La gestion de tags côté client semblait un progrès il y a dix ans : le marketing pouvait ajouter un tag sans déploiement. La facture est arrivée plus tard. Chaque tag client a trois coûts récurrents.
- Performance. Les scripts tiers rivalisent avec ton propre JavaScript pour le thread principal. Un seul conteneur de tag manager tirant une douzaine de fournisseurs ajoute régulièrement 300 à 700 ms au Time to Interactive sur mobile de milieu de gamme.
- Qualité des données. Les bloqueurs de publicité, l'ITP et le gating de consentement écartent une part significative des événements client avant même qu'ils ne quittent le navigateur. Tu ne mesures pas la réalité, tu mesures le sous-ensemble d'utilisateurs qui ne t'ont pas bloqué.
- Dérive de gouvernance. Les tags s'accumulent. Personne ne possède la liste complète. Le conteneur devient l'endroit où les vieux pixels ne meurent jamais et où une fuite de données personnelles n'est qu'à une variable mal configurée.
Rien de tout cela n'est un problème de fournisseur. C'est structurel : mettre la mesure dans le navigateur sous forme de scripts épars.
Ce que le server-side déplace réellement
Le server-side tagging déplace la collecte et la redistribution des événements du navigateur vers un point de terminaison serveur que tu contrôles. Le navigateur envoie une requête first-party à ton propre domaine, le serveur l'enrichit et transmet des événements propres aux destinations qui en ont besoin : Google Analytics, une plateforme publicitaire, un entrepôt de données.
Le paysage ici est réel et mérite d'être nommé honnêtement. Google propose Google Tag Manager côté serveur (server-side tagging, "SST"). Cloudflare Zaraz exécute les outils tiers au edge, hors du thread principal du navigateur. Les deux sont des moyens légitimes de réduire la charge client. Ce qu'aucun des deux ne résout à lui seul, c'est la seconde moitié du problème : d'où viennent les événements, et qui les garde cohérents quand le storefront change ? C'est une question de composant, pas une question de transport.
Pourquoi la mesure appartient au schéma de composant
Dans un frontend composable headless, le storefront est construit à partir de composants dotés de schémas typés. Une product card, un bouton d'ajout au panier, un filtre, une étape de checkout : chacun est un composant avec un contrat défini. Ce contrat est précisément le bon endroit pour déclarer ce que le composant mesure.
Au lieu d'un projet de tagging séparé qui devine des sélecteurs DOM, l'événement vit à côté du composant qui l'émet :
defineBlock('ProductCard', {
props: { productId: string, position: number },
tracking: {
view: { event: 'product_view', server: true },
click: { event: 'product_select', server: true,
payload: { productId: 'props.productId',
listPosition: 'props.position' } },
},
})Quand le composant s'affiche ou reçoit une interaction, la plateforme émet un événement structuré vers le point de terminaison serveur, pas vers un tag navigateur. Comme le payload est typé et lié aux props, il ne peut pas dériver silencieusement quand un designer déplace la card dans une nouvelle section. Le schéma d'événement fait partie du contrat de composant, versionné avec lui, revu avec lui. Voilà ce que signifie l'analytics de schéma de composant en pratique : le schéma est la source unique de vérité, à la fois pour le rendu et pour la mesure.
La forme de l'événement server-side
Sur le serveur, chaque composant émet la même forme normalisée, quel que soit le backend ou la destination qui se trouve derrière :
{
"event": "product_select",
"occurred_at": "2026-07-29T09:14:22Z",
"session_id": "s_9f2c...",
"source": { "component": "ProductCard", "schema_version": "2.3.0" },
"context": { "locale": "fr-FR", "channel": "web", "consent": ["analytics"] },
"payload": { "productId": "SKU-4471", "listPosition": 3 }
}Parce que la collecte est first-party et côté serveur, cet événement survit aux bloqueurs de publicité et au gating de consentement au niveau des scripts (tu respectes toujours le consentement, il est porté dans context). Il arrive une fois, propre, et peut être redistribué vers n'importe quelle destination sans nouveau tag navigateur.
Où se placent Zaraz, Google SST et les données first-party
Les deux modèles ne sont pas un choix exclusif. Le schéma de composant décide du *quoi* et du *quand*, la couche serveur décide du *vers où*.
| Couche | Rôle | Responsable | Mode d'échec si sautée |
|---|---|---|---|
| Schéma de composant | Définir les événements, lier des payloads typés | Engineering, dans le contrat de composant | Devinette de sélecteurs DOM, dérive au redesign |
| Point de terminaison serveur (first-party) | Collecter une requête propre par événement | Plateforme | Bloqueurs et ITP mangent tes données |
| Server tagging (Google SST / Zaraz) | Enrichir et redistribuer vers les destinations | Plateforme / edge | Le thread principal client reste lourd |
| Stockage de données first-party | Conserver les événements qui t'appartiennent, modéliser plus tard | Équipe data | Dépendance fournisseur sur tes propres données de comportement |
Le gain, ce sont des données first-party qui t'appartiennent vraiment : collectées depuis ton propre domaine, définies par tes propres composants, et portables vers la destination ou le modèle que tu choisiras ensuite.
Le trafic des agents devient enfin mesurable
Il y a une raison propre à 2026 pour laquelle cela compte. Une part croissante du trafic storefront n'est pas un humain avec un navigateur qui exécute tes tags. C'est un agent, un assistant d'achat, une session Claude ou ChatGPT qui interroge tes points de terminaison pour le compte d'un utilisateur. Les tags côté client ne se déclenchent pas du tout pour ces visiteurs, donc dans un monde de tags navigateur, le trafic des agents est tout simplement invisible. Quand la mesure vit dans le schéma de composant et émet côté serveur, l'événement se déclenche, qu'un navigateur ait exécuté un script ou non. Tu vois les vues et sélections de produits pilotées par agent comme un canal à part entière, au lieu d'un trou dans le funnel.
Une courte checklist de migration
- Inventorie le
<head>: liste chaque tag client et son responsable réel. - Mets en place un point de terminaison serveur first-party sur ton propre domaine.
- Déplace les destinations analytics et publicitaires derrière le server tagging (Google SST ou Zaraz comme transport edge).
- Déclare les événements dans les schémas de composant, typés et liés aux props, pas via des sélecteurs DOM.
- Porte le consentement dans le
contextde l'événement, applique-le côté serveur. - Supprime les tags client que tu viens de remplacer. Ne les laisse pas tourner "au cas où".
À retenir
Le server-side tracking, ce n'est pas seulement déplacer un tag manager sur un serveur. Bien fait, ce sont deux décisions : la mesure s'exécute sur le serveur, et les événements sont déclarés dans le schéma de composant, où ils sont versionnés, revus et impossibles à casser en silence. Le résultat : un <head> plus léger, des données first-party qui t'appartiennent, un consentement que tu peux vraiment appliquer, et un trafic d'agents que tu vois enfin. Si tu cherches le chemin le plus court vers cette configuration sur un backend existant, c'est exactement ce pour quoi la Frontend Management Platform de Laioutr est conçue, et la page produit Tracking et Analytics montre comment elle s'intègre à un storefront composable. Pour le contexte plus large sur la direction que prend le composable cette année, vois Tendances du commerce composable 2026.