Suivi cross-domaine GA4 cassé ? Réparez les sessions (2026)

Environ 30 pour cent des propriétés GA4 couvrant deux domaines en 2026 scindent silencieusement un parcours d'acheteur unique en deux sessions — perdant la source Google ou payante d'origine au moment du saut — pourtant la plupart des équipes ne le remarquent que lorsque leur propre domaine apparaît comme une référence majeure. Un parcours qui traverse des domaines n'est pas du trafic cassé ; c'est du trafic non rattaché, et le correctif n'est jamais de tout re-baliser par réflexe. C'est de trouver le seul endroit où le lien entre domaines se rompt.

Ce guide suit un visiteur en avant sur deux domaines à travers sept points de contrôle — perte de source, le linker _gl, la configuration dans Admin, sous-domaines contre domaines distincts, paniers tiers, exclusions de référence et vérification — pour que vous corrigiez la cause, pas le symptôme. Pour vérifier automatiquement votre configuration face aux fuites inter-domaines les plus courantes, lancez notre audit de suivi gratuit à 5 axes.

Mis à jour le 2026-05-17 avec le comportement actuel de la mesure inter-domaines, du linker _gl et des références indésirables observé sur des comptes américains, britanniques et européens.

TL;DR — pourquoi un parcours devient deux sessions :

Un saut de domaine réinitialise la session sauf si la mesure inter-domaines relie les deux domaines — 1 acheteur devient 2 utilisateurs. 2. Le linker _gl transporte le client ID entre domaines et doit survivre dans l'URL de destination. 3. Configurez vos domaines dans Admin sous le flux de données Web, et mettez la balise sur chaque domaine. 4. Les sous-domaines n'ont besoin de rien — seuls les vrais domaines distincts se configurent. 5. Les paniers tiers retirent le linker — listez-les et ajoutez des exclusions de référence pour garder la source.

Pourquoi un parcours devient-il deux sessions ?

La perte de source est la première chose à comprendre car elle explique tous les symptômes en dessous. GA4 identifie un visiteur par un client ID stocké dans un cookie propriétaire limité à un domaine. Dès qu'un visiteur passe à un second domaine, ce cookie est illisible, donc le second domaine crée un nouveau client ID et recommence à compter à zéro.

Nouveau client ID — Parce que le domaine de destination ne peut pas lire le cookie du domaine d'origine, GA4 traite l'arrivée comme un tout nouvel utilisateur. Une personne qui a cliqué sur une annonce Google, parcouru votre site marketing et sauté au paiement est désormais enregistrée comme deux utilisateurs en deux sessions.

Source perdue — Pire que le double comptage, la seconde session enregistre le premier domaine comme référent. La source payante ou organique d'origine qui a gagné le clic est écrasée, donc les revenus sur le domaine de paiement semblent venir de votre propre site.

Auto-référence — Cet écrasement est exactement le motif d'auto-référence : votre propre domaine qui grimpe dans le rapport d'acquisition de trafic. C'est le signal le plus bruyant qu'un saut de domaine n'est pas rattaché. Pour la méthode dédiée afin de l'éliminer, voyez notre guide d'exclusion des auto-références GA4.

L'objectif est simple : un parcours doit rester une session avec sa source d'origine intacte, peu importe le nombre de domaines qu'il touche.

Qu'est-ce que le linker _gl et comment doit-il passer ?

Une fois que vous acceptez que le cookie ne peut pas suivre le visiteur, le mécanisme qui le fait est le linker. Le paramètre _gl est la façon dont GA4 transmet le client ID d'un domaine au suivant sans dépendre d'un cookie partagé.

Le paramètre linker — Quand la mesure inter-domaines est configurée, la balise Google ajoute _gl à chaque lien et formulaire sortant qui pointe vers un domaine listé. Il encode le client ID et le contexte de session sous forme d'une chaîne éphémère dans l'URL.

Survivre au saut — Le domaine de destination lit _gl à l'arrivée et adopte le même client ID au lieu d'en créer un nouveau. Vous pouvez le confirmer visuellement : cliquez et la barre d'adresse affiche une longue chaîne ?_gl=1*... pendant un instant. Pas de _gl sur la destination signifie pas de rattachement.

Ce qui le casse — Tout ce qui réécrit l'URL de destination avant que GA4 la lise — une redirection qui retire les paramètres d'URL, un panier qui assainit l'URL ou un lien manuel qui contourne la balise — tue le linker. Ne bloquez ni ne retirez jamais _gl dans une règle de pare-feu ou un CDN.

Le linker est tout le mécanisme porteur ici, donc l'essentiel du débogage inter-domaines est en réalité du débogage de linker. Si vous passez à une configuration côté serveur, notre guide GTM côté serveur explique comment le transfert change.

Comment configurer la mesure inter-domaines dans Admin ?

Le mécanisme compris, la configuration est courte — et c'est là que la plupart des correctifs atterrissent vraiment. La mesure inter-domaines se règle par flux de données, pas par propriété, donc vous la configurez sur le flux Web qui sert les deux domaines.

Le chemin exact — Ouvrez Admin, choisissez la propriété, sélectionnez Flux de données, cliquez sur votre flux de données Web, puis Configurer les paramètres de balise et Configurer vos domaines. C'est l'unique écran qui contrôle tout le comportement.

Ajouter des domaines — Listez chaque domaine du parcours avec un type de correspondance : contient, égal ou commence par. example.com et examplecart.com doivent tous deux apparaître. Un domaine manquant est la raison la plus fréquente pour laquelle une balise correctement installée scinde encore les sessions.

L'exigence de balise — La configuration est nécessaire mais pas suffisante : la balise Google doit être active sur chaque domaine listé. Si le domaine de destination n'a pas de balise, rien ne lit le paramètre _gl à l'arrivée, donc le rattachement échoue en silence.

Enregistrez, puis republiez ou attendez le rafraîchissement de la balise avant de tester. Si votre tunnel se termine par une conversion Google Ads, alignez cela avec notre guide de configuration de l'import de conversions GA4 pour que la session rattachée soit rapportée correctement en aval.

Sous-domaines ou domaines distincts : lequel se configure ?

Une large part de l'effort gaspillé vient du fait de configurer la mauvaise chose. La question décisive est de savoir si le saut traverse le domaine enregistrable ou simplement un sous-domaine de celui-ci.

Les sous-domaines se rattachent gratuitement — shop.example.com et www.example.com partagent la même racine, la même portée de cookie propriétaire et donc le même client ID. GA4 les garde dans une seule session automatiquement, sans aucune configuration. Les ajouter à la liste des domaines est inoffensif mais inutile.

Les domaines distincts se configurent — La session ne se casse que lorsque le domaine enregistrable change, par exemple example.com vers examplecart.com, ou un hôte de réservation sur son propre domaine. C'est le saut qui a besoin de la mesure inter-domaines et du linker _gl.

Diagnostiquez avant de configurer — Lisez les deux URL du parcours et comparez le domaine racine. Si la racine est identique, la scission n'est pas un problème inter-domaines et vous devriez plutôt regarder les filtres, le consentement ou la duplication de balise.

Bien comprendre cette distinction fait gagner des heures : vous cessez d'ajouter des sous-domaines qui n'en avaient jamais besoin et commencez à lister le domaine vraiment distinct qui casse réellement la session.

Pourquoi les paniers tiers perdent-ils le linker ?

Même avec une configuration Admin parfaite, un panier ou un paiement hébergé peut quand même casser la chaîne car vous ne contrôlez pas entièrement la façon dont il traite l'URL entrante. C'est le point de défaillance réel le plus courant.

Retrait de paramètres — De nombreux paniers hébergés, moteurs de réservation et pages de paiement assainissent ou réécrivent l'URL entrante par sécurité, retirant le paramètre _gl avant que GA4 sur cette page puisse le lire. Le linker arrive mais est jeté, donc une nouvelle session démarre.

L'auto-référence qu'il crée — Parce que la source est perdue, le domaine de paiement enregistre votre propre site comme référent. Le clic payant d'origine disparaît et les revenus sont mal attribués au trafic interne.

Le correctif en deux parties — D'abord, listez le domaine du panier dans la mesure inter-domaines pour que le linker soit attendu des deux côtés. Ensuite, ajoutez l'hôte du panier ou du paiement à la liste des références indésirables pour que GA4 refuse de le créditer comme source même si un saut perdu se glisse.

Si la plateforme retire les paramètres de force et n'offre aucun réglage GA4 natif, un transfert côté serveur ou le connecteur propre de la plateforme est généralement requis — il n'y a pas de contournement côté client quand l'URL est réécrite côté serveur. Pour la réconciliation des revenus à travers cet écart, voyez notre guide des écarts GA4 et Google Ads.

Comment les exclusions de référence interagissent-elles ?

La mesure inter-domaines et les exclusions de référence résolvent deux moitiés différentes du même problème, et un suivi multi-domaines propre a généralement besoin des deux fonctionnant ensemble.

Ce que fait le rattachement — Configurer vos domaines relie les sessions et, comme effet secondaire, traite ces domaines listés comme internes pour qu'ils soient exclus de la source de référence. C'est le remplacement automatisé par GA4 de l'ancienne liste manuelle d'exclusion de référence.

Ce que font les références indésirables — Pour les domaines que vous ne contrôlez pas — une passerelle de paiement, un hôte SSO, un service de redirection — vous les ajoutez à la liste des références internes et indésirables sous le flux de données. Cela empêche un intermédiaire connu d'écraser la source d'origine même s'il ne fait pas partie de votre parcours rattaché.

Pourquoi vous avez besoin des deux — Le rattachement garde la session entière ; les références indésirables gardent le crédit sur la vraie source. Configurez les domaines que vous possédez pour le rattachement et excluez les hôtes tiers qui ne devraient jamais être crédités.

Clarifiez bien les deux rôles et la source survit de bout en bout. Le tutoriel d'exclusion des auto-références qui l'accompagne couvre les entrées de liste exactes pour les passerelles courantes.

Le tableau de diagnostic inter-domaines

Travaillez ce tableau de haut en bas — il est classé selon la rapidité de confirmation de chaque cause et la fréquence à laquelle elle est la vraie raison d'une scission de parcours sur les domaines.

Ne re-balisez pas tout avant de vérifier le linker :

Quand les sessions se scindent, le réflexe est d'arracher et de réinstaller la balise Google sur les deux domaines. Cela aide rarement et introduit souvent des balises en double qui comptent deux fois. Dans 9 cas sur 10, la balise va bien et le vrai écart est un domaine manquant dans la configuration ou un paramètre _gl retiré au moment du saut. Confirmez d'abord le linker, corrigez ensuite la configuration, et ne touchez la balise que si elle ne se déclenche vraiment pas sur un domaine.

Comment vérifier et prioriser le correctif

Vous trouverez généralement plus d'un écart. L'erreur est de changer plusieurs choses à la fois de sorte que vous ne pouvez pas dire ce qui a fonctionné. Vérifiez dans un ordre fixe et corrigez par impact multiplié par facilité.

Vérifiez d'abord le linker — Parcourez le tunnel et lisez la barre d'adresse de destination. Une chaîne _gl=1*... signifie que le linker s'est déclenché ; son absence est la confirmation la plus rapide et la moins chère que le saut n'est pas rattaché. Cette seule vérification résout la plupart des cas.

Puis regardez le temps réel — Ouvrez le temps réel et confirmez qu'un seul utilisateur traverse les deux domaines sans que le nombre d'utilisateurs augmente. Deux utilisateurs pour un parcours signifie que le client ID ne passe pas et vous devriez revenir au linker.

Puis confirmez dans les rapports — Après 24 à 48 heures, vérifiez que l'acquisition de trafic crédite toujours Google ou votre source payante, pas votre propre domaine. C'est la seule vérification qui prouve l'attribution, pas seulement le rattachement.

Attention aux limites. Le temps réel confirme le rattachement instantanément, mais l'attribution finale et le nettoyage des auto-références ne se stabilisent dans les rapports traités qu'un jour ou deux plus tard, donc ne criez pas victoire sur le seul temps réel. Construisez des balises de source propres avant de passer à l'échelle avec notre générateur d'UTM, et pour faire ressortir automatiquement chaque fuite inter-domaines, lancez l'audit gratuit à 5 axes de SteerAds.

Sources

Sources officielles consultées pour ce guide :

FAQ

Pourquoi mon trafic GA4 se scinde-t-il en deux sessions sur plusieurs domaines ?

Quand un visiteur passe d'un domaine à un autre, GA4 traite le second domaine comme une nouvelle visite, sauf si la mesure inter-domaines les relie. Sans ce lien, le second domaine ouvre une nouvelle session, attribue son propre client ID et enregistre le premier domaine comme source de référence. Un seul acheteur devient donc deux utilisateurs et la source Google ou payante d'origine est perdue. La cause est presque toujours l'une de trois choses : les deux domaines ne sont pas listés dans la configuration inter-domaines, le paramètre linker _gl ne survit pas au saut, ou un panier tiers retire les paramètres d'URL. Environ 30 pour cent des comptes multi-domaines en 2026 perdent ainsi la source. Corrigez d'abord la configuration, puis vérifiez le linker.

À quoi sert le paramètre _gl dans mon URL ?

Le paramètre _gl est le linker de GA4. Quand la mesure inter-domaines est configurée, la balise Google ajoute _gl aux liens et formulaires sortants qui pointent vers votre autre domaine listé. Il transporte le client ID et le contexte de session pour que le domaine de destination rattache la visite au même utilisateur au lieu de repartir de zéro. Vous le verrez sous la forme d'une longue chaîne comme ?_gl=1*abcd... dans la barre d'adresse à l'instant du clic. Si _gl est absent de l'URL de destination, le linker ne s'est pas déclenché, le saut n'est pas rattaché et vous obtenez une auto-référence. Ne retirez ni ne bloquez jamais ce paramètre ; c'est le mécanisme qui maintient une session entière.

Les sous-domaines nécessitent-ils une configuration inter-domaines dans GA4 ?

Non, et c'est l'erreur de sur-configuration la plus fréquente. Les sous-domaines d'un même domaine racine — shop.example.com et www.example.com tous deux sous example.com — partagent déjà les cookies et le même client ID, donc GA4 les garde dans une seule session automatiquement, sans réglage. Vous n'avez besoin de la mesure inter-domaines que lorsque le domaine enregistrable lui-même change, par exemple de example.com à examplecart.com ou un hôte de réservation distinct. Listez un vrai domaine distinct dans la configuration de votre flux de données ; laissez tranquilles les sous-domaines de même racine. Ajouter des sous-domaines à la liste ne nuit pas mais ne résout rien, et cela détourne du vrai écart de domaine distinct qui cause la scission.

Pourquoi mon paiement tiers provoque-t-il des auto-références ?

Les paniers hébergés, moteurs de réservation et pages de paiement vivent souvent sur un domaine distinct et retirent ou réécrivent fréquemment les paramètres d'URL entrants, ce qui supprime le linker _gl avant que GA4 puisse le lire. Le résultat est une nouvelle session qui enregistre votre propre site comme référent — une auto-référence — et la source payante d'origine disparaît. Deux correctifs s'appliquent. D'abord, listez le domaine de paiement dans la mesure inter-domaines pour que le linker soit attendu des deux côtés. Ensuite, ajoutez le domaine de paiement aux exclusions de référence ou à la liste des références indésirables pour que GA4 l'ignore comme source. Si la plateforme retire les paramètres de force, un transfert côté serveur ou le connecteur GA4 natif peut être requis.

Comment ajouter un domaine à la mesure inter-domaines ?

Ouvrez Admin dans GA4, sélectionnez la propriété, puis choisissez Flux de données et cliquez sur votre flux de données Web. Sous Configurer les paramètres de balise, ouvrez Configurer vos domaines. Ajoutez chaque domaine appartenant au même parcours avec un type de correspondance — contient, égal, commence par — afin que example.com et examplecart.com soient tous deux listés. Enregistrez, puis republiez ou attendez le rafraîchissement de la balise. La balise Google doit être installée sur chaque domaine listé pour que le linker passe. La configuration seule ne fait rien si le domaine de destination n'a pas de balise. Après enregistrement, parcourez le tunnel et confirmez que le paramètre _gl apparaît sur l'URL de destination.

Que sont les exclusions de référence et existent-elles encore dans GA4 ?

Dans GA4, l'ancienne liste d'exclusion de référence de Universal Analytics est largement automatisée : quand vous configurez la mesure inter-domaines, les domaines listés sont traités comme internes et exclus de la source de référence. Pour les fournisseurs de paiement et autres domaines que vous ne contrôlez pas, GA4 utilise une liste de références indésirables sous la liste des références internes et indésirables du flux de données. Ajoutez-y des domaines comme votre passerelle ou un hôte de redirection pour qu'ils n'écrasent pas la source d'origine. La distinction compte : la mesure inter-domaines rattache la session, tandis que les références indésirables empêchent un intermédiaire connu d'être crédité comme source. Il vous faut généralement les deux pour un tunnel multi-domaines propre.

Comment vérifier que le suivi inter-domaines fonctionne ?

Utilisez trois vérifications dans l'ordre. D'abord, cliquez sur un lien d'un domaine vers l'autre et regardez la barre d'adresse de destination — un paramètre _gl signifie que le linker s'est déclenché. Ensuite, ouvrez les rapports en temps réel de GA4 et confirmez qu'un seul utilisateur traverse les deux domaines sans que le nombre d'utilisateurs augmente. Enfin, après 24 à 48 heures, vérifiez que l'acquisition de trafic crédite toujours Google ou votre source payante plutôt que votre propre domaine en référence. Si le temps réel montre deux utilisateurs pour un parcours, le linker ne passe pas. Souvenez-vous de la limite : le temps réel confirme le rattachement, mais l'attribution finale et le nettoyage des auto-références ne se stabilisent dans les rapports traités qu'un jour ou deux plus tard.