Suivi GA4 côté serveur via le palier de redirection

Le tagging GA4 côté client via gtag.js ou GTM est la base d'attribution que la plupart des équipes adoptent par défaut. Il fonctionne bien dans des conditions idéales : un utilisateur Chrome desktop sur une connexion rapide, sans bloqueur de publicités, une session Safari qui n'a pas déclenché le plafond de durée de cookie de script de 24 heures de l'ITP. Les conditions idéales couvrent peut-être 65 à 75 % du trafic UE en 2026.

Le reste - les utilisateurs d'uBlock Origin, le blocage intégré de Brave, l'Intelligent Tracking Prevention de Safari sur iOS, la cohorte croissante de bloqueurs au niveau réseau comme NextDNS et Pi-hole - envoie des événements qui soit n'arrivent pas à www.google-analytics.com, soit y parviennent sans identifiant client utilisable parce que le cookie _ga a été supprimé. L'écart typique sur des audiences à forte densité UE est de 25 à 35 % des événements de conversion. Pour certaines industries - fintech, outils de confidentialité, outils de développement - il est plus élevé parce que la démographie utilisateur est corrélée à l'adoption des bloqueurs.

Le Measurement Protocol de GA4 est le chemin côté serveur qui contourne tout cela. Votre serveur dialogue directement avec le point de terminaison de collecte de Google. L'état du navigateur est sans importance. Cet article couvre la configuration exacte : identifiants, forme du payload, rattachement du client_id, validation et le pattern de déduplication pour les équipes qui font tourner gtag en parallèle du chemin côté serveur.

L'architecture sous-jacente de transmission des conversions - pourquoi le côté serveur gagne et comment fonctionne la diffusion vers plusieurs plateformes - est couverte dans l'aperçu du suivi de conversion côté serveur. La version Meta CAPI de ce tutoriel est sur transmettre les conversions à Meta CAPI ; le pattern de configuration est de la même forme, avec ici les paramètres spécifiques à GA4.

TL;DR#

• GA4 gtag.js perd 25-35 % des événements de conversion sur le trafic UE typique à cause des bloqueurs (uBlock, Brave) et de l'ITP (plafonds de durée de cookie Safari) ; le Measurement Protocol contourne tout cela parce que la requête provient de votre serveur.
• Il vous faut deux identifiants : le Measurement ID (G-XXXXXXXX) de votre flux de données, et un secret API généré dans Admin → Flux de données → Secrets de l'API Measurement Protocol. Les deux se collent dans les paramètres workspace d'Elido en moins de deux minutes.
• Le client_id est ce qui lie un événement côté serveur à une session GA4 ; Elido définit un cookie UUID propriétaire lors de la redirection du lien court et l'inclut dans chaque transmission de conversion, donc vous n'avez pas à lire le cookie _ga depuis le navigateur.
• La validation prend environ dix minutes : la DebugView de GA4 montre les événements Measurement Protocol arriver en environ dix secondes ; les rapports standard se remplissent en 24 à 48 heures.

Les deux identifiants dont vous avez besoin#

GA4 Measurement Protocol nécessite deux informations, toutes deux issues de la console d'administration GA4.

Measurement ID. L'identifiant du flux de données, formaté G-XXXXXXXX. Trouvez-le sous Admin → Flux de données → votre flux web → le panneau des détails du flux. C'est le même ID que vous passez à gtag('config', 'G-XXXXXXXX') dans votre configuration côté client - ce n'est pas un secret ; il apparaît dans le source de votre page.

Secret API. C'est l'identifiant qui autorise les écritures côté serveur sur le point de terminaison de collecte. Naviguez vers Admin → Flux de données → votre flux web → Secrets de l'API Measurement Protocol → Créer. Le secret est une courte chaîne alphanumérique. Traitez-le comme une clé de compte de service : stockez-le comme un secret d'espace de travail, faites-le tourner avec d'autres identifiants de service, ne le committez pas dans le code source.

Dans Elido, ces valeurs se collent dans les paramètres de l'espace de travail sous Intégrations → GA4. Une fois enregistrés, Elido valide la paire contre le point de terminaison de débogage GA4 et confirme la connectivité. La validation est immédiate ; un 4xx à cette étape signifie que le Measurement ID ou le secret API est erroné.

La forme de l'événement#

La référence du Measurement Protocol GA4 (consultée le 12/05/2026) spécifie le format de requête. Le point de terminaison est :

POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=<secret>

Le corps porte un client_id, un user_id optionnel et un tableau events. Voici le payload pour un événement d'achat :

{
  "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "user_id": "user-shop-12847",
  "events": [
    {
      "name": "purchase",
      "params": {
        "transaction_id": "ord_98231",
        "value": 89.5,
        "currency": "EUR",
        "engagement_time_msec": 1,
        "items": [
          {
            "item_id": "sku-spring-jeans-32-blue",
            "item_name": "Spring Jeans 32 Blue",
            "quantity": 1,
            "price": 89.5
          }
        ]
      }
    }
  ]
}

Quelques points faciles à rater dans ce payload :

event_name doit être en snake_case minuscule. La référence des événements GA4 (consultée le 12/05/2026) liste les noms d'événements recommandés : purchase, sign_up, generate_lead, add_to_cart. Envoyer Purchase (avec un P majuscule) produira un événement distinct dans les rapports GA4 plutôt que de fusionner avec vos événements purchase déclenchés par gtag. La plateforme ne vous avertit pas ; l'événement atterrit simplement comme un événement personnalisé au nom étrange.

engagement_time_msec doit être présent et défini à un entier positif. Sans lui, GA4 compte l'événement mais ne crédite pas l'engagement de session, et certains modèles d'attribution excluent les événements sans temps d'engagement. Définir 1 suffit à satisfaire l'exigence.

event_params est limité à 25 paramètres par événement. Le Measurement Protocol rejettera les payloads qui dépassent cette limite. Le rejet est silencieux par défaut - la requête renvoie 204 sans corps que l'événement ait été accepté ou non. Utilisez le point de terminaison de débogage (couvert dans la section validation) pour détecter les débordements.

user_id est optionnel mais précieux. Si vous avez un identifiant utilisateur persistant côté serveur - un ID client dans votre table de commandes, un ID d'abonné dans votre CRM - envoyez-le. GA4 l'utilise pour l'attribution cross-device, et il améliore la correspondance entre les événements côté serveur et côté client.

Rattachement du client_id : pourquoi c'est important et comment Elido le gère#

Le client_id est le champ que GA4 utilise pour lier un événement côté serveur à une session navigateur. Quand gtag.js s'exécute sur une page, il lit le cookie _ga et utilise son UUID comme client_id pour tous les événements qu'il déclenche. Si votre événement côté serveur porte le même client_id, GA4 peut rattacher ces événements au même parcours utilisateur et à la même session.

Le défi est d'obtenir cet UUID côté serveur. Le cookie _ga est un cookie propriétaire sur votre domaine, donc votre serveur peut le lire au moment du checkout et l'inclure dans le payload de conversion. Mais cela ne fonctionne que si le navigateur de l'utilisateur a _ga défini, ce qui est précisément la population que vous perdez à l'ITP et aux bloqueurs.

Elido résout cela au palier de redirection. Quand un utilisateur clique sur un lien court, le handler edge d'Elido génère un UUID et le définit comme un cookie propriétaire _elido_cid sur la réponse de redirection - avant que l'utilisateur n'atteigne votre site. L'UUID est aussi ajouté à l'URL de destination comme ?elido_click=<uuid> (configurable par workspace). Le flux :

Votre landing page ou tag manager lit elido_click depuis l'URL et l'écrit dans les attributs personnalisés de la commande. Au moment de la conversion, votre webhook de commande porte l'UUID. Elido le recherche, construit le payload Measurement Protocol avec client_id défini à cet UUID, et transmet à GA4.

C'est plus fiable que de lire _ga depuis le navigateur parce que l'UUID est capturé au moment du clic, avant que la session du navigateur ne détermine si les cookies sont acceptés. Même si l'ITP supprime le cookie _ga dans les 24 heures, le cookie _elido_cid d'Elido persiste comme cookie propriétaire sous votre domaine de lien court - et l'attribut de commande persiste dans votre base de données quoi qu'il en soit.

Le guide d'envoi d'événements GA4 (consulté le 12/05/2026) décrit comment fonctionne client_id à travers les chemins client et serveur.

Elido transmet : le curl réel#

Quand POST /v1/conversions arrive avec un click_id, Elido assemble le payload Measurement Protocol et le transmet. Pour appeler le point de terminaison directement - en contournant Elido et en testant le côté GA4 MP du câblage - le curl est :

curl -X POST \
  "https://www.google-analytics.com/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "client_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
    "user_id": "user-shop-12847",
    "events": [
      {
        "name": "purchase",
        "params": {
          "transaction_id": "ord_98231",
          "value": 89.50,
          "currency": "EUR",
          "engagement_time_msec": 1
        }
      }
    ]
  }'

GA4 renvoie 204 pour les événements valides comme invalides. Vous ne pouvez pas distinguer un événement malformé d'une ingestion réussie par le seul code de statut HTTP. Pour voir si l'événement a vraiment atterri, utilisez le point de terminaison de débogage pendant le développement :

POST https://www.google-analytics.com/debug/mp/collect?measurement_id=G-XXXXXXXX&api_secret=YOUR_SECRET

Le point de terminaison de débogage renvoie un corps JSON qui liste les erreurs de validation pour chaque événement. Un événement avec un nom de paramètre erroné, un payload dépassant 25 paramètres, ou un client_id malformé apparaîtra ici.

En utilisant Elido, la même visibilité de validation est disponible via GET /v1/conversions/{id} - l'enregistrement de conversion montre le statut de transmission GA4 et toute réponse d'erreur du point de terminaison de débogage en mode test.

Validation : DebugView#

DebugView de GA4 est la boucle de feedback la plus rapide pendant la configuration. Pour l'activer pour les événements côté serveur, ajoutez "debug_mode": 1 à l'objet params de l'événement. Les événements avec ce drapeau apparaissent dans DebugView en environ dix secondes ; ils ne comptent pas pour les données de rapport de production.

Dans DebugView (GA4 Admin → DebugView), chaque événement montre son nom, les paramètres qu'il portait, et si des paramètres ont été rejetés. La vue regroupe les événements par client_id, donc vous pouvez tracer la session complète du clic à la conversion.

Ce qu'il faut vérifier avant de supprimer debug_mode :

• Le nom de l'événement apparaît exactement comme attendu dans le flux d'événements DebugView (purchase, pas Purchase ni ecommerce_purchase).
• Le paramètre transaction_id est visible et correspond au format de votre ID de commande.
• Le client_id est une chaîne au format UUID - pas vide, pas une chaîne de repli "unknown".
• La currency est le code ISO 4217 correct (EUR, pas eur, pas Euro).

Les rapports standard GA4 prennent 24 à 48 heures pour refléter les données de conversion côté serveur. N'évaluez pas la précision des rapports le premier jour. DebugView confirme la forme de l'événement ; les rapports confirment l'attribution et les totaux.

Erreurs courantes#

client_id manquant. Les événements sans client_id sont silencieusement abandonnés par le Measurement Protocol. C'est le mode d'échec le plus courant. L'abandon est invisible - la requête renvoie 204, DebugView ne montre rien, la conversion n'apparaît jamais. Vérifiez que le champ client_id est toujours rempli avant que la requête ne parte. Dans la configuration Elido, un client_id manquant signifie que le paramètre elido_click n'a pas été écrit dans la commande au moment de la conversion - vérifiez le tag de landing page ou le handler du webhook.

Format de nom d'événement erroné. Purchase crée un événement personnalisé nommé Purchase à côté des événements purchase existants de gtag. Votre compte total d'achats dans les rapports GA4 se divise sur deux noms d'événements. Le correctif est d'imposer le snake_case minuscule sur tous les noms d'événements envoyés au point de terminaison Measurement Protocol. La référence des événements GA4 (liée plus haut) liste les noms canoniques pour les événements ecommerce.

Dépassement de 25 event_params. Le Measurement Protocol rejette silencieusement les payloads avec plus de 25 paramètres par événement. Les équipes transmettant des métadonnées de commande complètes (toutes les lignes d'article, tous les attributs personnalisés) atteignent souvent cette limite sans s'en rendre compte. Utilisez le point de terminaison de débogage pour détecter les débordements en développement. En production, supprimez les paramètres non essentiels et gardez les payloads d'événements légers.

Devise issue de la config de page, pas de la commande. Si votre configuration gtag est par défaut sur USD mais vos commandes sont en EUR, l'événement côté serveur et l'événement côté client portent des valeurs de devise différentes. GA4 les enregistre sous le même nom d'événement mais ne peut pas agréger les valeurs. Tirez la devise de l'enregistrement de commande dans votre backend, pas d'une configuration gtag au niveau de la page.

Déduplication avec gtag côté client#

Si vous faites tourner gtag.js côté client et le Measurement Protocol côté serveur simultanément, vous avez besoin de déduplication. GA4 déduplique les événements en utilisant client_id combiné à une fenêtre temporelle. Le mécanisme est moins explicite que le champ event_id de Meta CAPI mais l'approche pratique est la même : porter un transaction_id cohérent sur les événements d'achat à travers les deux chemins.

Pour les événements d'achat, définissez transaction_id à votre ID de commande. Votre gtag côté navigateur déclenche purchase avec transaction_id: "ord_98231" quand la page de confirmation se charge ; votre événement Measurement Protocol côté serveur porte le même transaction_id: "ord_98231". GA4 déduplique dans la même fenêtre de session. Si la même combinaison client_id + transaction_id arrive deux fois dans la fenêtre de déduplication, la seconde est ignorée.

Pour les événements en amont - generate_lead, sign_up, add_to_cart - il n'y a pas d'ID de commande à utiliser. Le click ID fonctionne ici : définissez event_id à l'UUID elido_click. Le pixel côté navigateur et la transmission côté serveur référencent la même valeur. C'est la même discipline décrite dans le tutoriel de suivi UTM de bout en bout, qui couvre la configuration plus large du tagging de campagne qui rend cet ID disponible à travers le funnel.

La fenêtre de déduplication dans GA4 n'est pas publiquement documentée avec la précision que Meta publie pour CAPI. En pratique, les événements avec une correspondance client_id + transaction_id arrivant dans la même fenêtre de session sont dédupliqués. Faire tourner les deux chemins simultanément est la configuration la plus sûre - elle fournit une couverture de repli pour l'audience à forte adoption de bloqueurs tout en donnant à l'algorithme un signal plus propre depuis le chemin serveur.

Où cela s'inscrit dans le pipeline d'attribution#

Le Measurement Protocol comble l'écart de signal GA4 de la même manière que CAPI comble l'écart de signal Meta. Les mécanismes sont différents - GA4 utilise client_id et transaction_id là où Meta utilise event_id et des clés de correspondance - mais l'architecture est identique : un événement côté serveur qui ne dépend pas de l'état du navigateur.

Pour la vue complète des plateformes vers lesquelles transmettre et de comment fonctionne le fan-out à grande échelle, l'aperçu du suivi de conversion côté serveur couvre GA4, Meta CAPI et TikTok Events côte à côte. Pour les campagnes où le tagging UTM est l'étape amont, suivre les campagnes UTM de bout en bout est la lecture préalable.

La surface produit pour cette configuration : la page conversion tracking features documente l'API /v1/conversions complète, y compris le fan-out multi-plateforme, les événements de remboursement et la sémantique de réessai. La page solutions marketeurs montre comment le pipeline de conversion s'intègre dans un workflow de campagne aux côtés des templates UTM et du routage de smart links.

La configuration elle-même - identifiants dans les paramètres workspace, étape tag manager pour elido_click sur la landing page, plomberie du webhook de commande - prend une demi-journée pour la plupart des équipes. L'étape de validation DebugView ajoute trente minutes supplémentaires. Le résultat est des données de conversion GA4 qui reflètent ce que vos campagnes pilotent réellement, pas seulement les 65-75 % qui survivent au chemin côté navigateur.

Sources

• Google Analytics 4: Measurement Protocol overview. developers.google.com/analytics/devguides/collection/protocol/ga4 (accessed 2026-05-12)
• GA4 Measurement Protocol: Event reference. developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events (accessed 2026-05-12)
• GA4 Measurement Protocol: Sending events. developers.google.com/analytics/devguides/collection/protocol/ga4/sending-events (accessed 2026-05-12)