Quand on parle de server-side tracking, on pense tout de suite aux gestionnaires de balises côté serveur comme GTM Server-Side ou Adobe Edge. Mais un TMS n’est pas obligatoire : on peut envoyer des appels HTTP directs du serveur vers l’outil, avec de simples requêtes POST ou GET.
Comparons le fonctionnement sur trois plateformes : Google Analytics 4, Adobe Analytics et Matomo.
Google Analytics 4 : le Measurement Protocol
GA4 propose un point d’entrée dédié pour envoyer des événements directement depuis un serveur.
Le point d’entrée
POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXX&api_secret=YOUR_SECRETLes paramètres
measurement_id: l’identifiant du flux de données (dans l’URL, obligatoire).api_secret: le secret créé dans Admin > Flux de données > Measurement Protocol (dans l’URL, obligatoire).client_id: l’identifiant unique du client, lu dans le cookie_ga.user_id: facultatif, pour les utilisateurs connectés.events: un tableau d’événements, avec nom et paramètres.timestamp_micros: facultatif, heure Unix en microsecondes. Les événements peuvent être antidatés jusqu’à 72 heures.
Le point clé
Lisez le client_id (cookie _ga) et le session_id (gtag('get', …)) dans le navigateur, puis envoyez les deux avec l’événement serveur. Le client_id rattache l’événement à l’utilisateur, le session_id le rattache à la session (référence du Measurement Protocol, cookies GA4).
Les cas d’usage
Transactions côté back-end, e-mails de confirmation, actions purement internes (une mise à jour ERP, par exemple). Google présente le Measurement Protocol comme un complément de gtag, GTM ou Firebase, pas comme un remplaçant : une propriété alimentée uniquement par MP n’obtient qu’un reporting partiel (présentation du Measurement Protocol).
Adobe Analytics : le tracking HTTP direct
Adobe accepte les hits directs via la Data Insertion API (un hit par requête, en query string ou en POST XML). Pour un nouveau projet server-side, Adobe recommande la Bulk Data Insertion API, qui envoie les données par lots de fichiers. Voir la Data Insertion API.
Le point d’entrée
Un GET ou un POST vers :
https://<your-tracking-server>/b/ss/<reportSuiteID>/0/Le serveur de tracking est votre domaine edge, par exemple xxx.data.adobedc.net, ou votre CNAME.
Les principaux paramètres
vid: l’identifiant visiteur, généré à la main ou repris de l’ECID.mid: facultatif, l’Experience Cloud ID (ECID).pageName: le nom de la page ou le libellé du hit.events: la chaîne d’événements, par exemplepurchase.products: la chaîne produits au format Adobe.
Le point clé
La réconciliation des visiteurs chez Adobe repose sur un vid ou un ECID correctement géré. L’idéal est de poser l’ECID côté client puis de le transmettre au back-end.
Les cas d’usage
Les configurations hybrides web + application native, les actions de fidélité, les comportements après connexion suivis côté serveur.
Matomo : la Tracking API, simple et flexible
Matomo fournit une API HTTP très souple, en GET comme en POST.
Le point d’entrée
https://matomo.example.com/matomo.phpLes paramètres
idsite: l’identifiant du site Matomo (obligatoire).rec: doit valoir 1 (obligatoire)._id/cid: l’identifiant visiteur, exactement 16 caractères hexadécimaux (ce n’est pas un UUID). Pour les utilisateurs connectés, préférezuid.uid: facultatif, l’identifiant utilisateur.e_c: la catégorie d’événement (obligatoire pour un événement).e_a: l’action de l’événement (obligatoire pour un événement).e_n: le nom de l’événement.e_v: la valeur de l’événement (facultatif).url: l’URL de la page associée à l’événement.
Source : Matomo Tracking HTTP API.
Le point clé
Comme pour GA4, lisez l’identifiant visiteur (_id, 16 caractères hexadécimaux) dans le navigateur et envoyez-le avec votre hit serveur.
Les cas d’usage
L’analytics auto-hébergé, quand vous gardez les données sur votre propre infrastructure. Les règles de consentement s’appliquent quand même (voir la CNIL).
Bonnes pratiques du server-side tracking natif
- Toujours transmettre un identifiant persistant :
client_idpour GA4,vidoumidpour Adobe,_idouuidpour Matomo. - Synchroniser cet identifiant depuis le front : le lire dans un cookie, dans le localStorage ou via une injection d’en-tête.
- Ajouter des timestamps quand c’est possible : ils préservent l’ordre des événements, surtout quand les actions du back-end sont journalisées de façon asynchrone.
- Journaliser et documenter : gardez une copie de ce que vous envoyez, pour le débogage et pour la conformité.
Quand utiliser le server-side tracking natif ?
- Vous travaillez sur une logique pilotée par le back-end (confirmation de paiement, création de compte).
- Vous voulez un contrôle total sur ce qui est envoyé.
- Vous voulez éviter l’exécution de JavaScript côté client (performance, sécurité), tout en transmettant l’état de consentement de l’utilisateur avec chaque événement.
- Vous construisez des mécanismes de détection de fraude, de réconciliation ou de scoring.
- Vous cherchez une alternative légère à une infrastructure complète de TMS server-side.
Sources
- Google : référence du Measurement Protocol
- Google : présentation du Measurement Protocol
- Google : cookies GA4
- Adobe : Data Insertion API
- Matomo : Tracking HTTP API
- CNIL : cookies et autres traceurs
Pour aller plus loin, lisez la version complète de l’article (en anglais) : Native Server-Side Tracking: GA4 vs Adobe vs Matomo.
Besoin d’aide sur ce sujet ? Commanders Act et server-side.