Table des matières
Vos rapports GA4 montrent trop de « nouveaux visiteurs », des ventes attribuées au trafic direct et des campagnes qui semblent ne rien rapporter ? Le problème vient souvent de l'installation standard, dans le navigateur. Bloqueurs, restrictions de Safari et exigences de la LPD fragilisent cette méthode : le server-side via Stape permet de reprendre la main.
En bref
Installé côté navigateur, GA4 perd des visiteurs (bloqueurs) et de la mémoire (cookies limités à 7 jours, voire 24 h, par Safari).
Un conteneur Google Tag Manager server-side hébergé par Stape, sur votre propre sous-domaine, reçoit les données avant Google.
Le serveur permet de filtrer les données personnelles et d'appliquer le consentement avant tout envoi à un tiers.
Un refus reste un refus : le server-side fiabilise la mesure, il ne remplace ni la bannière ni le Consent Mode.
Pourquoi le GA4 standard perd des données
Dans l'installation classique, c'est le navigateur du visiteur qui exécute le script gtag.js et envoie directement les données aux serveurs de Google. Ce modèle se heurte à deux limites techniques et à une question juridique.
1. Safari et l'ITP raccourcissent la mémoire de GA4
Sur Safari (iPhone, iPad, Mac), l'ITP (Intelligent Tracking Prevention) limite les cookies créés en JavaScript. Selon la documentation WebKit, ils sont supprimés après 7 jours sans interaction, et plafonnés à 24 heures si le visiteur arrive par un lien décoré (par exemple avec un gclid Google Ads ou un fbclid Meta).
Conséquence concrète : un prospect clique sur votre annonce le 1er du mois, revient le 10 par une recherche Google et achète. Le cookie _ga a disparu entre-temps. GA4 compte deux utilisateurs au lieu d'un et attribue la vente au référencement naturel, au détriment de la campagne qui l'a déclenchée.
2. Les bloqueurs rendent une partie du trafic invisible
Selon GWI (T2 2025), 30,9 % des internautes suisses utilisent un bloqueur de publicité. Beaucoup de ces extensions, et certains navigateurs comme Brave, bloquent aussi les requêtes vers les domaines de Google Analytics. Ces visites n'apparaissent tout simplement pas dans vos rapports.
3. La question juridique : qui reçoit quoi ?
En client-side, le navigateur de votre visiteur suisse parle directement à Google. Google indique ne pas enregistrer les adresses IP des utilisateurs suisses et européens dans GA4 (aide Google Analytics), mais la requête elle-même, avec l'URL complète, part chez un tiers. Une adresse e-mail glissée par erreur dans une URL de recherche ou de formulaire suffit à transmettre une donnée personnelle. Avec la LPD, vous restez responsable de ce que vos outils envoient.
La solution : GA4 server-side avec Stape
Le principe est simple : au lieu de laisser le navigateur parler à Google, on intercale un serveur que vous contrôlez. C'est le rôle du conteneur Google Tag Manager server-side (sGTM), que nous hébergeons chez Stape, notre plateforme d'hébergement sGTM de référence.
Comment le flux fonctionne
Collecte (GTM web) : le navigateur envoie les événements (pages vues, ajouts au panier, achats) non pas à Google, mais à votre serveur.
Contrôle (sGTM) : le serveur vérifie l'état du consentement, retire les données sensibles et applique vos règles métier.
Distribution (GA4) : une fois validée, la donnée est transmise à GA4, et seulement ce que vous avez décidé d'envoyer.
Google le résume ainsi dans sa documentation du tagging server-side : vous êtes le seul à accéder aux données présentes sur le serveur tant que vous ne choisissez pas de les envoyer ailleurs.
Le sous-domaine personnalisé : la base first-party
Le point central est le Custom Domain, par exemple metrics.votre-site.ch. Les requêtes partent de votre site vers votre propre sous-domaine : on parle de mesure first-party. Elle est plus résiliente aux restrictions techniques des navigateurs, sans rien changer au choix du visiteur. Pour que Safari traite vraiment ce sous-domaine comme le vôtre, il doit être configuré proprement (voir plus bas).
Configurer GA4 server-side selon votre CMS
Le passage au server-side oblige à remettre de l'ordre dans le dataLayer. Le client GA4 du conteneur serveur attend des événements au format GA4 : si la donnée arrive mal structurée, elle est ignorée ou faussée.
WordPress et WooCommerce
Mise en place d'un dataLayer e-commerce standardisé, souvent via le plugin GTM4WP.
Dans le conteneur GTM web, la balise Google (GA4) envoie ses événements vers l'URL de votre serveur, et non plus vers Google.
Côté serveur, le client GA4 reçoit le flux, reconstruit l'événement e-commerce et le transmet à GA4.
Shopify
Architecture plus fermée, surtout sans Shopify Plus : nous utilisons l'application Stape dédiée ou des webhooks.
Les événements clés (begin_checkout, purchase) peuvent être envoyés depuis le back-office de Shopify.
Le bénéfice : une commande n'est plus perdue parce que le client a fermé la page de confirmation trop vite. Le consentement doit bien sûr rester respecté pour ces envois.
Prestashop, Webflow et sites sur mesure
Audit du dataLayer existant et cahier des charges pour vos développeurs.
Événements poussés selon la nomenclature GA4 (item_id, price, currency, etc.), puis pont entre GTM web et sGTM.
Conseil A-Track
Avant de brancher le serveur, comparez une semaine de commandes dans votre back-office avec les achats remontés dans GA4. Cet écart de départ vous servira de référence pour mesurer le gain réel, sans vous fier à des promesses génériques.
Les fonctions Stape utiles pour GA4
Stape ajoute au sGTM des fonctions qui répondent directement aux limites vues plus haut.
Cookie Extender : prolonger la mémoire de GA4
Par défaut, le cookie _ga est écrit en JavaScript, donc soumis à la limite de 7 jours de Safari. Le Cookie Extender de Stape réécrit ce cookie depuis le serveur, dans l'en-tête HTTP de la réponse. Il peut alors conserver sa durée de vie prévue par Google (jusqu'à 2 ans), uniquement si le visiteur a consenti.
Attention au détail qui fait tout : selon WebKit, Safari plafonne aussi à 7 jours les cookies posés par un serveur dont l'adresse IP ne correspond pas à celle du site (« IP address cloaking »). Le sous-domaine de mesure doit donc être servi de façon cohérente avec votre site, par exemple via le même CDN ou un chemin sur votre domaine principal. C'est un réglage à vérifier au cas par cas.
Custom Loader : charger GTM depuis votre domaine
Le Custom Loader de Stape sert le script GTM et GA4 depuis votre propre sous-domaine, avec des chemins personnalisés. Les requêtes restent first-party et sont moins exposées aux listes de blocage génériques. Ce n'est pas un moyen de contourner le choix du visiteur : les balises restent soumises à la bannière et au Consent Mode. Plus de détails dans notre article sur le Custom Loader GTM.
Conformité LPD et RGPD : ce que le serveur change vraiment
Le server-side n'est pas un moyen d'échapper à la loi, c'est un point de contrôle. Le serveur agit comme une douane : rien ne sort sans passer vos règles.
Google Consent Mode v2 : Google l'exige pour ses fonctions publicitaires sur le trafic européen et, depuis le 31 juillet 2024, suisse. Si le visiteur refuse (analytics_storage = denied), aucun cookie GA4 n'est posé. En mode advanced, seuls des signaux sans cookie partent pour la modélisation. Voir notre guide Consent Mode v2.
Nettoyage des données : avant tout envoi à Google, le serveur peut tronquer l'adresse IP, retirer les identifiants inutiles et expurger les URL des données personnelles (PII) comme une adresse e-mail. Notre article sur le nettoyage des données GA4 détaille ces règles.
Localisation du serveur : Stape propose des zones d'hébergement en Europe. La première manipulation de la donnée se fait donc dans un cadre que vous maîtrisez. Les données envoyées ensuite à Google restent un transfert à documenter dans votre politique de confidentialité (Google est certifié au Swiss-U.S. Data Privacy Framework, en vigueur depuis le 15 septembre 2024).
Côté sanctions, rappelons que la LPD révisée, en vigueur depuis le 1er septembre 2023, prévoit des amendes jusqu'à CHF 250'000 contre les personnes responsables en cas de violation intentionnelle (art. 60 à 66). Le cadre complet est dans notre guide de conformité LPD et RGPD.
Les résultats à attendre, sans promesse magique
Un GA4 server-side bien configuré change la qualité de vos analyses. Le gain exact dépend de votre audience (part de Safari, de bloqueurs, taux de consentement) : il se mesure, il ne se promet pas.
Une audience plus complète : une partie des visites auparavant bloquées par des filtres génériques redevient mesurable, pour les visiteurs qui ont accepté la mesure.
Une attribution plus juste : avec des cookies qui durent, le lien entre la première visite publicitaire et l'achat n'est plus coupé après 7 jours. Vos campagnes d'acquisition retrouvent leur vrai poids.
Une traçabilité documentée : vous savez et pouvez montrer quelles données partent vers Google, après quel filtrage et sur quelle base de consentement.
Un navigateur allégé : en déplaçant certaines balises tierces vers le serveur, vous réduisez le code exécuté sur la page.
Pour aller plus loin sur l'impact business, lisez notre guide de la mesure de performance marketing.
Conclusion : par où commencer
Mesurez l'écart actuel entre les commandes réelles et les achats dans GA4.
Vérifiez que votre bannière et le Consent Mode v2 fonctionnent avant toute migration.
Déployez le sGTM sur un sous-domaine correctement configuré, puis contrôlez la durée des cookies dans Safari.
Vos rapports GA4 attribuent-ils les ventes au bon canal ?
A-Track compare vos commandes réelles aux achats GA4, contrôle le Consent Mode v2 et la durée du cookie _ga dans Safari, puis vous dit si le server-side vaut la peine.
En 30 minutes avec un expert, vous savez où vous en êtes.