Balisage côté serveur : souveraineté des données dans un monde axé sur la confidentialité
Les pixels côté client meurent. Server-Side GTM (SGTM) est la solution. Une plongée approfondie dans Facebook CAPI, la déduplication d'événements et la victoire sur Safari ITP.
L’âge d’or du marketing numérique est révolu. Pendant une décennie, les spécialistes du marketing ont pu copier-coller un pixel Facebook dans l’en-tête et tout suivre comme par magie. Puis est arrivé le RGPD. Ensuite, Safari ITP (Intelligent Tracking Prevention). Puis iOS 14.5 (Transparence du suivi des applications). Ensuite, l’adoption d’AdBlock a atteint 30 %. Et enfin, Chrome Phase 3 tue le cookie tiers.
Si vous utilisez toujours des pixels JavaScript côté client, vous perdez 20 à 30 % de vos données. Vous dépensez un budget pour des publicités qui génèrent des ventes, mais l’algorithme pense que ce n’est pas le cas et arrête donc de diffuser la publicité. C’est la crise de la « perte de signal ».
Chez Maison Code Paris, nous migrons les marques à 8 chiffres vers le Server-Side Tagging (SGTM). Il ne s’agit pas seulement d’« Analytics » ; c’est « l’infrastructure de données ». Il déplace la logique de suivi du navigateur de l’utilisateur (environnement non approuvé et bloqué) vers votre serveur (environnement approuvé et non bloqué).
Pourquoi Maison Code en parle
Chez Maison Code Paris, nous agissons comme la conscience architecturale de nos clients. Nous héritons souvent de stacks “modernes” construites sans compréhension fondamentale de l’échelle.
Nous abordons ce sujet car il représente un point de pivot critique dans la maturité de l’ingénierie. Une mise en œuvre correcte différencie un MVP fragile d’une plateforme résiliente de niveau entreprise.
Pourquoi Maison Code centralise les données
Nous ne faisons plus confiance au navigateur. Il s’agit d’un environnement hostile à l’exactitude des données. Entre ITP, AdBlockers et GDPR, le suivi côté client est interrompu. Nous mettons en œuvre SGTM pour récupérer la Souveraineté des données pour nos clients :
- Contrôle : vous décidez quelles données sont envoyées à Facebook (hachage des e-mails, suppression des informations personnelles). * Précision : nous constatons généralement une augmentation de 20 % des revenus attribués après le passage au CAPI côté serveur.
- Conformité : nous appliquons automatiquement le « Mode consentement » au niveau du serveur, garantissant ainsi l’absence de fuite de données si l’utilisateur se désinscrit.
Les avantages : Pourquoi passer au côté serveur ?
1. Contourner les AdBlockers (contexte propriétaire)
Les AdBlockers recherchent les requêtes adressées à « facebook.com » ou « google-analytics.com ». Dans SGTM, le navigateur envoie des données à « analytics.yourbrand.com ». Puisqu’il s’agit d’un sous-domaine de votre site principal, il s’agit d’une demande de première partie. Les AdBlockers (généralement) ne le bloquent pas, car le blocage des requêtes propriétaires interrompt le site Web. Résultat : Vous récupérez environ 15 % des événements perdus.
2. Extension de cookies (battre l’ITP)
Safari supprime les cookies côté client (définis par JS) après 7 jours (ou 24 heures s’ils proviennent d’un lien publicitaire).
Si un utilisateur clique sur une annonce lundi, navigue et revient 8 jours plus tard pour acheter, Facebook le considère comme un « nouvel utilisateur ». L’attribution est perdue.
Les cookies définis sur le serveur (en-tête Set-Cookie) sont fiables. Ils durent jusqu’à 2 ans.
SGTM vous permet d’actualiser les cookies marketing (_fbp, _ga) du serveur, en gardant la fenêtre d’attribution ouverte.
3. Performances des pages (Core Web Vitals)
Un site de luxe typique possède : Facebook, TikTok, Pinterest, Snapchat, LinkedIn, GA4, Hotjar, Criteo. Cela représente 8 bibliothèques JavaScript lourdes analysant le DOM sur le thread principal. Avec SGTM, vous les supprimez tous. Vous chargez le script One (GTM). Il envoie Un flux de données à votre serveur. Votre serveur le diffuse ensuite vers les 8 fournisseurs API à API. Résultat : TBT (Temps de blocage total) 300 ms plus rapide.
Guide d’intégration : l’approche hybride
Nous ne recommandons pas de passer immédiatement au « 100 % côté serveur ». Nous utilisons une approche hybride avec Déduplication.
Pour des événements comme « PageView » ou « ViewContent », le navigateur est le meilleur (il capture l’agent utilisateur, des tailles de fenêtre spécifiques). Pour des événements comme « Achat », le serveur est le meilleur (précision).
Pour une configuration robuste, nous envoyons DEUX.
- Le navigateur envoie « Achat » à Facebook Pixel.
- Le serveur envoie « Achat » à Facebook CAPI.
- Facebook reçoit 2 événements. Il doit savoir qu’il s’agit de la même transaction.
La clé : l’ID de l’événement
Vous devez générer un event_id unique et l’envoyer avec les deux flux.
//utils/analytics.ts
fonction d'exportation generateEventId() {
return crypto.randomUUID(); // "a4b5c6..."
}
// Côté client
const eventId = generateEventId();
fbq('track', 'Achat', { valeur : 100 }, { eventID : eventId });
dataLayer.push({ event : 'achat', event_id : eventId });
Lorsque Facebook voit deux événements avec l’ID « a4b5c6 » dans les 48 heures, il en supprime un (déduplication). Si l’événement Navigateur a été bloqué par AdBlock, Facebook utilise l’événement Serveur. Si les deux arrivent, Facebook utilise l’événement Browser (généralement des données plus riches) mais le confirme avec l’événement Server. Cela maximise la qualité de correspondance d’événement (EMQ).
Architecture : Google Cloud Run
Nous hébergeons le conteneur du serveur GTM sur Google Cloud Run. Pourquoi Cloud Run ? Mise à l’échelle automatique. Lors du Black Friday, vous pourriez avoir 10 000 requêtes/seconde. Cloud Run fait tourner 50 conteneurs. Le mardi à 3 heures du matin, il descend à 0 ou 1. Vous payez ce que vous utilisez.
Configuration :
- URL de transport : Pointez votre Web GTM vers
https://analytics.maisoncode.paris. - En-tête d’aperçu : connectez le conteneur de serveur au conteneur Web.
- Clients : le « Client GA4 » dans SGTM revendique la requête entrante et la transforme en objet de données d’événement.
Confidentialité : rédaction des données
Il s’agit d’une victoire massive en matière de conformité. Lorsque le navigateur parle directement à Facebook, Facebook voit tout (IP utilisateur, en-têtes, référent). Lorsque vous effectuez un proxy via SGTM, Vous contrôlez les données. Vous pouvez :
- Supprimez l’adresse IP.
- Hachez l’adresse e-mail (
sha256(email)). - Supprimez les paramètres d’URL spécifiques (par exemple, réinitialisez les jetons).
- Bloquez entièrement l’événement si l’utilisateur a consenti à “Analytics” mais pas à “Marketing”.
Nous implémentons un filtre Consent Mode dans SGTM. Si l’en-tête « x-consent-marketing : refusé » est présent, la balise CAPI Facebook ne se déclenche pas.
Ingénierie des coûts
SGTM coûte de l’argent (utilisation du serveur + bande passante).
Un site à fort trafic peut coûter entre 200 et 500 €/mois.
Optimisation : Filtrez les événements inutiles.
N’envoyez pas d’événements scroll à votre conteneur de serveur si vous n’en avez pas besoin pour CAPI.
Configurez la balise de configuration GA4 pour exclure les événements à volume élevé et de faible valeur du flux du serveur.
Modèle avancé : le “Client de données”
Au lieu d’utiliser le protocole GA4, nous assistons à une transition vers des connecteurs JSON génériques.
Nous construisons un point de terminaison personnalisé /api/collect.
Le frontend POST une charge utile JSON propre :
{
"event": "order_placed",
"charge utile": { "id": "123", "total": 500 },
"contexte": { "id_utilisateur": "u_999" }
}
Le « client JSON » SGTM l’ingère. Cela dissocie votre couche de données complète des particularités de Google Analytics.
10. Persistance des données : piste d’audit Firestore
Le Standard GTM est éphémère. Les données circulent et disparaissent.
Que faire si vous souhaitez auditer « Chaque ajout au panier » pour des raisons juridiques ?
Dans SGTM, nous ajoutons une balise Firestore Writer.
Chaque événement valide est écrit dans une collection analytics_logs/{date}/{eventId}.
Cela nous donne une piste d’audit permanente et interrogeable (BigQuery) de chaque point de données envoyé à Facebook.
Si Facebook prétend « Aucune conversion », nous pouvons interroger nos propres journaux pour prouver qu’ils ont tort.
11. Stratégies de contrôle des coûts (le problème de 500 €)
Cloud Run peut coûter cher si un botnet vous frappe.
Nous implémentons le Bot Filtering at Ingress.
Dans app.yaml, nous bloquons les agents utilisateurs correspondant à des modèles de robots connus avant qu’ils ne lancent même une instance de conteneur.
Nous utilisons également Memory Limit (512 Mo) pour éviter qu’une fuite de mémoire dans un modèle personnalisé ne fasse planter la facture.
SGTM devrait coûter 1 % de vos dépenses médias. Si c’est plus, vous êtes surapprovisionné.
13. La passerelle CAPI vs Full SGTM
Facebook propose une « CAPI Gateway » (image AWS). Il s’agit d’une version simplifiée et automatisée de SGTM.
- Avantages : configuration en 1 clic. Aucun entretien.
- Inconvénients : Boîte noire. Vous ne pouvez pas filtrer les données. Vous ne pouvez pas l’empêcher d’envoyer des informations personnelles. Pour la conformité d’entreprise (RGPD), nous ne pouvons pas utiliser CAPI Gateway. Nous devons posséder l’infrastructure (Full SGTM sur Cloud Run) pour garantir que nous ne divulguons pas de données utilisateur.
14. Améliorer le ROAS avec les conversions hors ligne
Toutes les ventes ne se font pas en ligne. L’utilisateur clique sur Annonce -> Parcours -> Appels l’équipe commerciale -> Achats par téléphone. Facebook pense que la publicité a échoué. Nous utilisons SGTM pour canaliser les Conversions hors ligne. Le Sales CRM (Salesforce) transmet l’événement « Fermé gagné » à notre point de terminaison SGTM avec le « fbp » (ID du navigateur Facebook) capturé lors de la navigation initiale. Facebook attribue rétroactivement la vente à l’annonce cliquée il y a 3 jours. Cela améliore la visibilité du ROAS de 20 % pour les articles coûteux.
15. Conclusion
Le Server-Side Tagging est la table « Adulte » du marketing numérique. Cela nécessite des ressources d’ingénierie. Ce n’est pas gratuit. Mais c’est le seul moyen de créer un pipeline de données durable et respectueux de la confidentialité, qui survivra à la guerre des navigateurs.
Chez Maison Code, nous pensons que les First Party Data sont l’atout le plus précieux qu’une marque possède. SGTM vous aide à le protéger.
Incohérence des données ?
Shopify indique-t-il 100 commandes, mais Facebook en dit 60 ?