Avec l’adoption croissante du server-side tagging, beaucoup de gens supposent qu’utiliser un domaine personnalisé signifie automatiquement que la donnée est collectée côté serveur. Cela semble logique, mais la réalité est plus nuancée. Il y a deux dimensions indépendantes :
- Où la donnée est collectée : côté client ou côté serveur.
- Quel domaine sert à la collecte : celui de Google, d’Adobe, ou le vôtre.
Cas 1 : Google Analytics 4
Par défaut, GA4 envoie ses hits vers :
https://www.google-analytics.com/g/collectou sa variante régionale :
https://region1.analytics.google.com/g/collectCe sont des endpoints appartenant à Google, utilisés dans toutes les implémentations client-side standard. Le navigateur envoie directement les hits avec gtag.js ou gtm.js, sans aucune intervention d’un serveur de votre côté.
Quand le domaine change
Si vous voyez des requêtes partir vers :
https://analytics.mybrand.com/g/collectou :
https://ga.mybrand.fr/mp/collectun domaine de collecte personnalisé a été configuré. Pour que cela fonctionne, il faut :
- créer un enregistrement DNS (CNAME ou A) qui pointe votre domaine vers un conteneur serveur (en général un conteneur GTM Server-Side hébergé sur App Engine, Stape ou derrière un reverse proxy) ;
- mettre à jour le réglage « Server Container URL » dans votre tag GA4 ;
- configurer un client GA4 dans le conteneur serveur pour recevoir les hits.
Le navigateur envoie alors la donnée à votre propre domaine, et votre conteneur serveur la transmet à Google. C’est l’architecture typique du server-side tagging.
Pourquoi « probable » et non « certain »
Voir un domaine personnalisé est un fort indice d’un dispositif server-side, mais pas une garantie absolue. Plusieurs configurations alternatives imitent le même motif réseau :
| Scénario | Description | Nature |
|---|---|---|
| Reverse proxy simple | Le domaine analytics.mybrand.com redirige simplement les requêtes vers www.google-analytics.com. Aucun traitement, un simple passe-plat. | Pas du vrai server-side |
| Edge function / CDN worker | Les requêtes passent par une edge function Cloudflare ou Akamai. Elle agit comme un relais, pas comme un conteneur de tagging. | Intermédiaire réseau |
| Micro-passerelle interne (Google Gateway, API) | Le domaine reçoit les hits et les transmet à Google via l’API Measurement Protocol. | Server-side partiel |
| Script auto-hébergé + redirection | Hébergement local de gtag.js et proxy des requêtes. | Masquage cosmétique |
Ces solutions ressemblent de l’extérieur à des implémentations server-side, mais n’impliquent ni traitement ni logique de donnée côté serveur. D’où le terme « server-side probable ».
Cas 2 : Adobe Analytics
Adobe propose depuis longtemps des domaines de tracking personnalisés, via les variables :
s.trackingServer = "metrics.mybrand.com";
s.trackingServerSecure = "smetrics.mybrand.com";Ces domaines sont créés par Adobe Customer Care et configurés par des enregistrements CNAME qui pointent vers les serveurs d’Adobe. Ce montage permet aux cookies d’être considérés comme first-party, puisque le domaine appartient à votre site.
La collecte reste pourtant côté client : la bibliothèque AppMeasurement.js s’exécute dans le navigateur et envoie les hits directement. Il n’y a aucun traitement server-side, seulement un masquage de domaine.
Quand le service Experience Cloud ID (ECID) est activé, Adobe utilise le domaine demdex.net pour synchroniser les identifiants d’utilisateur. Le cookie d’ID principal peut être régénéré ou apparié via un master ID (MID), mais tout cela se passe encore dans le navigateur.
Tableau récapitulatif
| Contexte | Domaine d’exemple | Type de collecte | Cookie | Nature |
|---|---|---|---|---|
| GA4 par défaut | www.google-analytics.com | Client-side | 3rd party | Standard |
| GA4 personnalisé (vrai server-side) | analytics.mybrand.com | Server-side | 1st party | Conteneur serveur |
| GA4 personnalisé (proxy/passerelle) | analytics.mybrand.com | Proxy / Edge / transfert par API | 1st party | Intermédiaire |
| Adobe par défaut | metrics.adobedc.net | Client-side | 3rd party | Standard |
| Adobe avec CNAME | metrics.mybrand.com | Client-side | 1st party | Masquage |
| Adobe ECID (demdex) | dpm.demdex.net | Client-side | cross-domain | Master ID |
Conclusion
Voir son propre domaine dans les requêtes réseau est souvent le signe d’un dispositif server-side, mais pas une preuve définitive : proxies, passerelles et workers CDN peuvent imiter le même motif sans vrai traitement côté serveur. À l’inverse, utiliser le domaine par défaut de Google n’interdit pas d’être server-side : votre propre backend peut très bien transmettre la donnée à www.google-analytics.com via le Measurement Protocol.
- Domaine GA4 par défaut : client-side.
- Domaine GA4 personnalisé : server-side probable (sauf proxy ou passerelle).
- Domaine Adobe personnalisé : cookie first-party, pas du server-side.
Changer de domaine agit sur la visibilité et la propriété des cookies. Passer au server-side agit sur le contrôle de la donnée et sa logique de traitement.
Pour aller plus loin, lisez la version complète de l’article (en anglais) : Custom Domain ≠ Server-Side Tagging: What Really Changes for GA4 and Adobe.
Besoin d’aide sur ce sujet ? Commanders Act et server-side.