Table des matières
Vos campagnes semblent sous-performer, et pourtant le trafic direct convertit étonnamment bien ? Si votre paiement, votre réservation ou votre inscription se fait sur le domaine d'un prestataire, la cause est souvent là : le visiteur change de domaine, son identifiant de mesure ne le suit pas, et la vente est attribuée au mauvais canal.
En bref
Un cookie n'existe que pour le domaine qui l'a posé : deux domaines distincts, c'est deux visiteurs distincts, sauf si l'identifiant est transporté.
La configuration inter-domaines de GA4 (paramètre _gl) et le Conversion Linker forment le socle, mais échouent sans clic sur un lien : redirection, POST, iframe, bouton JavaScript.
Le server-side ne fait pas voyager un cookie entre domaines. Il prolonge la durée de vie des identifiants sur chacun de vos domaines face aux limites de Safari.
Relier un visiteur entre plusieurs domaines a des conséquences sous LPD et RGPD : à traiter avant la mise en production.
Cet article s'adresse aux PME suisses, aux agences web et aux agences marketing dont le tunnel de conversion traverse plusieurs domaines. C'est le cas de nombreux sites romands et alémaniques : hôtellerie, formation, billetterie, associations, cabinets médicaux, commerces qui externalisent le paiement.
Pourquoi un parcours à deux domaines casse-t-il la mesure ?
Le mécanisme est simple, et c'est précisément pour cela qu'il passe inaperçu pendant des mois.
Un cookie appartient à un domaine, et à un seul
Quand GA4 s'exécute sur votre-hotel.ch, il écrit un cookie _ga contenant un identifiant client, rattaché à votre-hotel.ch. Lorsque le visiteur clique sur « Réserver » et atterrit sur booking-prestataire.com, le navigateur applique la règle de base du web : un site ne lit pas les cookies d'un autre site. Le script de mesure du domaine de destination ne trouve aucun cookie, en crée un nouveau et attribue au visiteur une nouvelle identité.
Vous n'avez rien cassé ni mal configuré : le navigateur fait exactement ce qu'on lui demande.
Ce que GA4 affiche alors
La conséquence se lit dans vos rapports d'acquisition. La première session se termine sur votre site, sans conversion. Une seconde session démarre sur le domaine du prestataire. Comme le référent est votre propre site, ou qu'il se perd lors d'une redirection, cette seconde session est classée en trafic direct, voire en « referral » depuis votre propre domaine.
Le nombre d'utilisateurs est mécaniquement gonflé : une personne, deux utilisateurs. Le taux de conversion du canal payant s'effondre, celui du direct s'envole. Si votre trafic direct convertit beaucoup mieux que vos campagnes, vous tenez souvent une partie de l'explication.
Ce que voient Google Ads, Meta et LinkedIn
Côté publicitaire, le problème est plus grave, parce qu'il touche l'optimisation des enchères. Un clic sur une annonce Google Ads ajoute un identifiant de clic (gclid, ou wbraid et gbraid sur certains parcours iOS) à l'URL de la page d'arrivée. Cet identifiant doit être stocké sur ce domaine, puis relu au moment de la conversion.
Si la conversion se produit sur un domaine qui n'a jamais vu l'identifiant, elle remonte sans source, ou pas du tout. Les enchères intelligentes apprennent alors sur des données tronquées et réallouent votre budget vers les mauvaises audiences.
Quels parcours sont concernés, et que faut-il vraiment corriger ?
La question n'est pas « ai-je plusieurs domaines », mais « mon tunnel de conversion quitte-t-il mon domaine avant la validation ». Les cas les plus fréquents en Suisse :
Hôtellerie et hébergement : site vitrine en .ch, moteur de réservation hébergé sur le domaine du prestataire.
Billetterie, événements et loisirs : le site présente l'offre, la plateforme de billetterie encaisse.
E-commerce avec page de paiement hébergée : panier sur votre domaine, saisie de carte chez le prestataire de paiement, retour sur votre page de confirmation.
Formation et écoles privées : site institutionnel d'un côté, portail d'inscription ou LMS de l'autre.
Cabinets et cliniques : prise de rendez-vous déléguée à une plateforme externe.
Groupes multi-marques ou multilingues : un domaine .ch et un domaine .fr ou .de, entre lesquels les visiteurs circulent.
B2B et recrutement : site corporate et portail de candidature ou espace client sur un domaine séparé.
Attention : un aller-retour compte double. Dans un parcours de paiement, le visiteur quitte votre domaine puis y revient. Chaque franchissement est une occasion de perdre l'identité, et la page de confirmation est justement celle qui déclenche votre événement d'achat.
Sous-domaine ou domaine distinct ?
Avant d'ouvrir le moindre conteneur, qualifiez la situation. Tous les cas n'appellent pas le même travail, et beaucoup d'équipes corrigent un problème qu'elles n'ont pas.
Même domaine, sous-dossiers (votre-site.ch/fr/ et votre-site.ch/de/) : rien à faire, les cookies sont partagés.
Sous-domaines du même domaine (www.votre-site.ch et shop.votre-site.ch) : pas de configuration inter-domaines, à condition que le cookie soit posé sur le domaine racine. C'est le comportement par défaut de la balise Google et du Conversion Linker. Une configuration inter-domaines appliquée à tort à des sous-domaines peut même créer des problèmes.
Domaines différents, même entité (votre-site.ch et votre-site.fr) : configuration inter-domaines nécessaire, consentement à réfléchir.
Domaine d'un prestataire tiers (paiement, réservation, billetterie) : le cas le plus difficile, car vous ne contrôlez ni le code ni la politique de cookies du domaine de destination. Les solutions dépendent de ce que le prestataire accepte de déployer.
Cette qualification détermine l'essentiel de la charge de travail. En audit, c'est la première question posée, avant même d'ouvrir Google Tag Manager ; elle figure dans notre checklist d'audit de tracking en 15 points.
Paramètre _gl et Conversion Linker : pourquoi la liaison native ne suffit pas
La configuration inter-domaines de GA4
GA4 gère la mesure inter-domaines depuis l'interface : Administration, Flux de données, Configurer les paramètres de la balise, Configurer vos domaines. Selon la documentation officielle de Google, vous pouvez y créer jusqu'à 100 conditions.
Le mécanisme : lorsqu'un visiteur passe vers un domaine déclaré, la balise ajoute à l'URL un paramètre _gl qui transporte l'identifiant client GA4 et les identifiants de clic Google. Le domaine de destination lit ce paramètre et recrée les cookies correspondants. La session se poursuit, l'utilisateur reste le même.
Trois conditions doivent être réunies : tous les domaines utilisent le même identifiant de mesure « G- », la balise Google est présente sur chaque page de chaque domaine, et le passage se fait par un clic sur un lien ou une soumission de formulaire que la balise peut décorer.
Le Conversion Linker, la balise qu'on oublie
Le Conversion Linker est une balise Google Tag Manager distincte de GA4. Selon la documentation Google Tag Manager, elle détecte les informations de clic publicitaire dans l'URL de la page d'arrivée et les stocke dans des cookies propriétaires et dans le stockage local du navigateur (ou dans l'URL pour les pages AMP). Par défaut, elle utilise le domaine de plus haut niveau possible.
Sans cette balise sur le domaine où la conversion se produit, le gclid transporté depuis votre site n'est jamais mémorisé. C'est l'oubli le plus courant que nous rencontrons sur des parcours multi-domaines, y compris chez des annonceurs qui investissent beaucoup en Google Ads.
Les six situations où la décoration de lien échoue
Le paramètre _gl n'est ajouté que si la balise peut intercepter la navigation. Dans les cas suivants, il n'est pas transmis et le parcours se coupe sans bruit :
Redirection côté serveur : votre site renvoie une redirection 302 vers le prestataire. Aucun clic sur un lien, aucune décoration.
Formulaire en POST généré dynamiquement : fréquent dans les tunnels de paiement, où le formulaire est construit ou soumis par un script.
Bouton JavaScript : un bouton qui appelle window.open ou modifie window.location après un traitement asynchrone peut partir avant la décoration.
Iframe : un widget de réservation intégré en iframe est une page d'un autre domaine, où le paramètre ne transite pas par un clic.
Retour depuis le prestataire : le domaine tiers vous renvoie vers votre page de confirmation sans rien décorer. Le visiteur revient comme un inconnu si son cookie d'origine a expiré ou a été supprimé.
Consentement non accordé au moment du clic : si les cookies analytiques sont refusés sur le domaine de départ, il n'y a aucun identifiant à transporter, et c'est normal.
Ces six cas expliquent pourquoi une configuration « faite dans l'interface GA4 » semble en place alors que rien ne passe : le réglage est correct, le parcours réel ne l'est pas.
Que change réellement le tracking server-side ?
Soyons précis, car le sujet est souvent survendu. Le tracking server-side ne permet pas à un cookie de franchir une frontière de domaine. Un serveur de tagging hébergé sur data.votre-site.ch peut poser un cookie pour votre-site.ch, pas pour le domaine d'un prestataire. Aucune architecture ne contourne cette règle du navigateur.
Ce que le server-side résout : la durée de vie des cookies
Le vrai gain se situe ailleurs, et il compte sur un parcours qui s'étale dans le temps, comme une réservation ou un devis B2B.
Depuis février 2019, Safari plafonne à 7 jours les cookies persistants créés en JavaScript, comme l'a annoncé Apple avec Intelligent Tracking Prevention 2.1. Ce plafond descend à 24 heures lorsque le visiteur arrive depuis un domaine classé comme traceur avec une URL décorée (paramètres de requête ou fragment), selon la documentation WebKit sur la prévention du pistage.
Le point est contre-intuitif : la décoration de lien ajoute justement des paramètres à l'URL. Sur un parcours qui passe par un domaine classé, ce mécanisme destiné à sauver l'attribution peut raccourcir la durée de vie du cookie recréé.
Un cookie posé par le serveur dans la réponse HTTP, depuis un sous-domaine qui vous appartient réellement, échappe au plafond des cookies JavaScript. C'est le cœur du gain apporté par le server-side. Avec une limite importante : la même documentation WebKit indique qu'ITP détecte le CNAME cloaking et l'IP cloaking tiers (un sous-domaine qui pointe, par CNAME ou par adresse IP, vers l'infrastructure d'un tiers) et plafonne alors aussi ces cookies à 7 jours. Vérifiez avec votre hébergeur sGTM comment votre sous-domaine de collecte est raccordé.
FPID, FPLC et la limite des vingt heures
Google a prévu un mécanisme spécifique au server-side. Le conteneur serveur peut poser un cookie FPID en HttpOnly, inaccessible à JavaScript, donc plus robuste. Revers : un cookie inaccessible à JavaScript ne peut pas servir à décorer un lien.
Google a donc introduit un second cookie, FPLC, dérivé du FPID et lisible par JavaScript, qui sert de jeton de liaison inter-domaines. Comme l'a documenté Simo Ahava, ce jeton vit 20 heures, et les conteneurs serveur des deux domaines doivent appartenir au même compte Google Tag Manager.
Concrètement, la liaison inter-domaines en server-side fonctionne pour un parcours continu, pas pour un visiteur qui revient trois jours plus tard finaliser sa réservation.
Ce que le server-side règle, et ce qu'il ne règle pas
Règle : la durée de vie des identifiants sur chacun de vos domaines, donc la capacité à relier une conversion tardive au clic d'origine.
Règle : la transmission des conversions aux plateformes par API serveur (Google Ads, Meta, LinkedIn, TikTok), y compris quand des restrictions techniques du navigateur bloquent les appels.
Règle : l'enrichissement de la conversion avec des données de votre back-office, qui compense en partie la perte d'identité entre domaines.
Ne règle pas : le partage d'un cookie entre deux domaines distincts. Cela reste impossible.
Ne règle pas : l'absence de balise sur le domaine du prestataire. Si vous n'y déployez rien, vous n'y mesurez rien.
Ne règle pas : un refus de consentement. Le server-side respecte le choix du visiteur : un refus reste un refus.
Les trois couches de liaison, dans l'ordre
Sur un parcours multi-domaines, la robustesse vient de la superposition de trois couches, pas du choix de l'une d'elles.
Couche 1, la liaison native : configuration inter-domaines GA4 et Conversion Linker déployés sur tous les domaines du parcours, y compris celui du prestataire. C'est le socle, et il ne coûte rien en licences.
Couche 2, le transport explicite : quand la couche 1 ne peut pas s'appliquer (redirection, POST, iframe), on transporte soi-même les identifiants utiles dans l'URL ou les champs du formulaire, puis on les relit à l'arrivée. Ces paramètres sont des données personnelles : finalité, information et durée de conservation doivent être définies.
Couche 3, la réconciliation serveur : la conversion est reconstruite côté serveur à partir de la référence de commande ou de réservation, puis envoyée aux plateformes par API. C'est la couche qui rattrape ce que les deux premières ont laissé passer, et celle qui résiste le mieux aux évolutions des navigateurs.
À retenir : les couches 1 et 2 sauvent la session, la couche 3 sauve la conversion. Les trois nourrissent vos enchères, mais c'est la troisième qui récupère les conversions que les autres ont perdues.
Conseil A-Track
Quand le domaine de destination appartient à un prestataire, ne demandez pas « d'installer le tracking ». Envoyez-lui une demande précise : même identifiant GA4, Conversion Linker, domaines à déclarer, et retour vers votre page de confirmation avec la référence de commande. Les échanges se raccourcissent nettement.
Consentement, LPD et RGPD : ce qu'il faut vérifier
Relier un visiteur entre deux domaines, c'est par définition construire un profil qui dépasse un site unique. Le curseur juridique se déplace.
Premier point, la transparence. La loi fédérale sur la protection des données impose transparence et proportionnalité. Un identifiant partagé entre plusieurs domaines doit être décrit dans la politique de confidentialité de chacun des domaines concernés, avec l'identité du responsable du traitement. Côté cookies, le droit suisse (art. 45c LTC) exige l'information et un droit de refuser ; pour les visiteurs de l'UE, le consentement préalable s'applique (ePrivacy et RGPD).
Deuxième point, la portée du consentement. En règle générale, une bannière posée sur votre-site.ch ne couvre pas domaine-prestataire.com, sauf construction contractuelle explicite entre les deux entités. Le visiteur voit souvent deux bannières successives et peut répondre différemment sur chacune. Votre implémentation doit gérer ce cas : si l'analytique est refusée sur le second domaine, aucun identifiant ne doit y être recréé. Google le rappelle d'ailleurs : Analytics a besoin du consentement pour relier les visiteurs entre domaines via le paramètre _gl.
Troisième point, un signal réglementaire utile. La CNIL considère qu'un traceur de mesure d'audience perd l'exemption de consentement dès qu'il permet un suivi global de la navigation sur différents sites, notamment via un identifiant commun. Autrement dit, la mécanique qui répare l'attribution est aussi celle qui rend le consentement obligatoire côté UE. Ce raisonnement n'est pas directement transposable au droit suisse, mais il concerne toute entreprise suisse qui cible l'Union européenne.
Enfin, le Consent Mode doit être cohérent sur tous les domaines. Des valeurs par défaut différentes d'un domaine à l'autre produisent des écarts de modélisation impossibles à expliquer. Voir notre guide du Google Consent Mode v2 et, pour le cadre complet, notre guide de conformité LPD et RGPD.
Conclusion : diagnostiquer votre parcours en trente minutes
Ce diagnostic ne demande aucun outil payant : un navigateur et de la méthode.
Cartographiez le parcours réel. Listez chaque domaine traversé entre la page d'entrée et la confirmation, dans l'ordre, et le mode de passage à chaque étape : lien, redirection, formulaire, iframe.
Faites un achat ou une réservation test depuis une annonce, ou depuis une URL contenant un paramètre gclid factice, en navigation privée.
À chaque changement de domaine, regardez l'URL. Le paramètre _gl est-il présent ? S'il manque, la couche 1 ne fonctionne pas à cette étape.
Inspectez les cookies du domaine de destination. La valeur de _ga est-elle identique à celle du domaine de départ ? Un cookie _gcl_aw est-il présent ?
Vérifiez la page de confirmation. L'événement de conversion s'y déclenche-t-il, et avec quel identifiant client ?
Comparez trois chiffres sur trente jours : commandes du back-office, conversions GA4, conversions Google Ads. Un écart important et durable sur un parcours multi-domaines a rarement une autre cause.
Refaites le test sur Safari, sur un iPhone, puis sept jours plus tard. C'est ce test qui révèle les problèmes de durée de vie des cookies, invisibles sur Chrome en une seule session.
Si les étapes 3 et 4 échouent, vous avez un problème de liaison. Si elles réussissent mais que l'étape 6 montre un écart, cherchez du côté de la persistance ou du consentement. Dans la plupart des cas que nous voyons, le problème n'est pas dans Google Tag Manager : il est dans une étape du tunnel que personne n'avait identifiée comme un changement de domaine.
Comment A-Track peut vous aider
Nous intervenons sur ces parcours pour des PME suisses et pour des agences qui préfèrent déléguer la mesure : audit pour établir où les conversions se perdent, implémentation des trois couches, puis vérification contradictoire entre votre back-office et vos plateformes. Nos prestations de tracking et conformité couvrent l'implémentation, et notre offre de maintenance annuelle vérifie que le parcours ne se casse pas à la prochaine refonte du tunnel de commande (voir aussi pourquoi un tracking server-side casse après la mise en ligne).
Sources
Google Analytics, configurer la mesure inter-domaines, documentation officielle.
Google Tag Manager, balise Conversion Linker, documentation officielle.
WebKit, Intelligent Tracking Prevention 2.1, Apple, 21 février 2019 ; WebKit, Tracking Prevention.
Simo Ahava, Cross-domain Tracking With Server-side FPID Cookie.
Luc Nugteren, Multi-domain tracking: 5 best practices, Stape, 16 septembre 2026.
Loi fédérale sur la protection des données (LPD, RS 235.1), Fedlex.
Votre paiement externe fausse-t-il l'attribution de vos ventes ?
A-Track suit votre parcours de bout en bout, du site au prestataire de paiement ou de réservation, contrôle _gl, Conversion Linker et consentement, puis corrige les ruptures d'attribution.
Réservez un appel de 30 minutes avec un expert.
