Un guide pratique de suivi de l'attribution

En pratique, le suivi des attributions devient confus quand un utilisateur passe de www.example.com à app.example.com, docs.example.com, checkout.example.com, ou à un microsite marketing distinct. La personne voit une seule marque. Votre pile analytique peut voir plusieurs visites déconnectées.

Cette rupture peut faire paraître la recherche organique faible, faire paraître les campagnes payantes meilleures ou pires qu'elles ne le sont réellement, et faire apparaître l'activation produit comme sans lien avec la page d'atterrissage qui l'a pourtant déclenchée.

L'objectif est de préserver le contexte de la source tout au long du parcours sans transformer l'attribution en pistage intrusif.

Problèmes courants entre sous-domaines

Les sous-domaines créent des lacunes d'attribution de façon prévisible :

• Le site marketing et l'application utilisent des propriétés analytiques différentes.
• Un formulaire d'inscription redirige via un fournisseur d'authentification.
• Les paramètres UTM sont perdus avant l'événement de conversion.
• Les exclusions de référents sont mal configurées.
• Les cookies sont limités à un seul hôte au lieu du domaine parent.
• Une application monopage change de route sans enregistrer les pages vues.
• L'application produit enregistre l'activation, mais le site marketing enregistre l'acquisition.

Le résultat est généralement un rapport où les conversions apparaissent comme du trafic direct, des auto-référencements, des référencements d'authentification, ou « inconnu ».

Définir le parcours avant de configurer les outils

Commencez par le parcours réel de l'utilisateur. Pour une entreprise SaaS, ce parcours ressemble à ceci :

1. Le visiteur arrive sur www.example.com/blog/... depuis la recherche organique.
2. Le visiteur clique sur « Démarrer l'essai gratuit ».
3. Le navigateur ouvre app.example.com/signup.
4. L'utilisateur vérifie son e-mail via un service d'authentification.
5. L'utilisateur crée un espace de travail.
6. L'utilisateur connecte une intégration.

Il reste à décider quels événements comptent :

• Vue de la page d'atterrissage
• Inscription démarrée
• Inscription terminée
• Espace de travail créé
• Première intégration connectée
• Premier rapport consulté

Chaque événement doit avoir un seul propriétaire et une seule définition. Si « inscription » signifie début du formulaire dans un outil et compte vérifié dans un autre, les rapports d'attribution seront peu fiables.

Utiliser les UTM de façon cohérente

Les UTM restent le moyen le plus simple de préserver le contexte des campagnes. Utilisez-les pour les publicités payantes, l'e-mail, les partenariats, les publications sur les réseaux sociaux, les liens d'affiliation et les codes QR hors ligne. Gardez les valeurs en minuscules, prévisibles, et sans donnée personnelle.

Bon exemple :

?utm_source=linkedin&utm_medium=paid-social&utm_campaign=q2-demo

Mauvais exemple :

?utm_source=linkedin&utm_campaign=jane.smith@example.com-demo

La documentation UTM de Google reste une référence utile pour comprendre le sens des paramètres, même si vous utilisez un autre outil d'analytique (Aide Google Analytics).

Garder l'attribution first-party autant que possible

Pour les parcours entre sous-domaines, la mesure first-party suffit. Vous pouvez utiliser le même script analytique et le même projet sur les sous-domaines liés, puis ne stocker que le contexte de source minimal nécessaire pour les rapports agrégés.

Dans une implémentation axée sur la protection de la vie privée :

• Ne stockez pas les adresses IP complètes.
• Ne construisez pas de profils cross-site entre des domaines sans lien.
• Évitez le fingerprinting comme solution de contournement aux limites des cookies.
• Ne transmettez pas d'e-mails ou d'identifiants clients dans les URL.
• Retirez les paramètres de requête sensibles avant la collecte analytique.
• Utilisez une courte durée de rétention pour les données d'événements brutes.

Si vous utilisez des cookies, portez attention au consentement et à la portée du cookie. Un cookie limité à .example.com peut être lu par les sous-domaines, mais reste une technologie de pistage et peut nécessiter un consentement selon la finalité et la juridiction. Les directives de l'ICO britannique sont claires : les cookies non essentiels et les technologies similaires nécessitent le contrôle de l'utilisateur (ICO).

Gérer l'authentification et les redirections de paiement

Les fournisseurs d'authentification et les processeurs de paiement interrompent l'attribution. Si un utilisateur passe par auth.vendor.com ou checkout.vendor.com, vos analytics traitent son retour comme une nouvelle recommandation.

Utilisez ces précautions :

• Ajoutez les domaines d'authentification et de paiement connus aux exclusions de référencement là où votre outil le permet.
• Enregistrez le contexte de campagne avant la redirection.
• Déclenchez les événements de conversion une fois que l'utilisateur revient sur votre domaine.
• Rapprochez les conversions analytics des registres backend.
• Testez les parcours en navigation privée et avec le consentement refusé.

Pour les conversions à forte valeur, enregistrez aussi la conversion côté serveur. Les analytics côté navigateur sont utiles pour le contexte marketing, mais votre backend doit rester la source de vérité pour les comptes créés, les abonnements payés et les factures.

Attribuer l'activation, pas seulement l'inscription

De nombreuses équipes SaaS s'arrêtent à « essai démarré ». Cela récompense les campagnes qui suscitent la curiosité, pas forcément celles qui créent des clients. De meilleurs rapports relient la source d'acquisition aux jalons d'activation.

Exemples :

• Les visiteurs venus de la recherche organique créent moins de comptes mais s'activent à un taux plus élevé.
• Le social payant génère beaucoup d'inscriptions mais peu de connexions d'intégration.
• Les recommandations de partenaires créent moins d'essais mais plus de passages à un plan payant.
• Le trafic de la documentation convertit lentement mais produit des utilisateurs à forte rétention.

Vous n'avez pas besoin d'une surveillance individuelle pour cela. Des cohortes agrégées par source, campagne, page d'atterrissage et événement d'activation peuvent suffire.

Une checklist d'attribution multi-sous-domaines

Avant de faire confiance aux chiffres, testez le parcours complet :

• Même projet analytics, ou reporting clairement relié entre les sous-domaines.
• Pages vues enregistrées pour les changements de route côté client.
• UTM conservés ou capturés avant les redirections.
• Domaines d'authentification et de paiement traités intentionnellement.
• Événements de conversion définis une seule fois.
• Registres backend rapprochés des comptages analytics.
• Paramètres d'URL sensibles supprimés.
• Comportement de consentement testé dans les marchés réglementés.
• Trafic des bots et interne filtré.

L'attribution entre sous-domaines doit clarifier les décisions, pas créer un graphe d'identité fantôme. Mesurez le chemin de la source jusqu'au résultat, gardez les données first party et minimales, et utilisez la vérité backend pour les événements qui touchent au revenu ou à la conformité.

Vérifications finales d'attribution

Avant de faire confiance à l'attribution multi-sous-domaines, prouvez trois choses : le contexte de campagne survit au parcours, la conversion existe dans votre système backend, et les données d'URL sensibles sont retirées avant que les analytics ne les reçoivent.

Utilisez les analytics pour répondre à des questions opérationnelles telles que quel canal a apporté des visiteurs qualifiés, quelle page d'atterrissage a converti, et où l'entonnoir a perdu des utilisateurs. Gardez les données personnelles hors des paramètres de campagne, évitez le fingerprinting comme raccourci, et rapprochez les résultats à forte valeur des registres first party.

Checklist de validation

Avant de faire confiance à l'attribution multi-sous-domaines, exécutez cinq parcours de bout en bout : visite directe, visite via campagne UTM, inscription blog vers application, redirection d'authentification et redirection de paiement. Vérifiez que la campagne d'origine survit aux redirections légitimes mais ne s'écrase pas elle-même sur les liens internes. Les UTM doivent décrire les liens d'acquisition venant de l'extérieur de la propriété ; les utiliser sur la navigation interne peut corrompre la source de vérité.

Inspectez ensuite les charges utiles. Le contexte de campagne doit inclure la source, le support, la campagne, le contenu et parfois utm_id, pas des e-mails, des identifiants de compte ou des jetons utilisateur ponctuels. La documentation du générateur d'URL de Google recommande de définir les paramètres UTM pertinents, en particulier la source, le support, la campagne, l'ID et la plateforme source le cas échéant, ce qui suffit pour la plupart des rapports de campagne (générateur d'URL Google Analytics).

Enfin, rapprochez les totaux de conversion des registres backend. L'attribution explique d'où viennent les conversions ; elle ne doit pas devenir la source de vérité pour savoir si une conversion a eu lieu.

Foire aux questions

Pourquoi le même visiteur apparaît-il comme plusieurs sessions selon les sous-domaines ?

Parce que chaque sous-domaine exécute souvent sa propre propriété analytique ou limite ses cookies à un seul hôte, si bien qu'app.example.com et www.example.com ne partagent jamais le même identifiant de visite. Les paramètres UTM et les données de référence se perdent lors d'une redirection d'inscription ou d'un transfert d'authentification, si bien que la même personne finit par être comptée deux fois, comme trafic direct ou comme auto-référencement.

Quelle est la première étape pour corriger l'attribution entre sous-domaines ?

Notez le parcours utilisateur réel avant de toucher à un quelconque outil, depuis la page d'atterrissage organique jusqu'à l'inscription, la vérification par e-mail, la création de l'espace de travail et la première intégration. Attribuez ensuite un propriétaire et une définition à chaque événement, car une définition mal alignée de « inscription » entre deux outils est ce qui casse le rapport plus tard.

Faut-il mettre des paramètres UTM sur les liens internes entre mes propres sous-domaines ?

Non. Les UTM décrivent un lien d'acquisition qui démarre à l'extérieur de la propriété, et en utiliser sur un lien de www.example.com vers app.example.com écrasera la vraie source par une source interne. Réservez les UTM aux publicités payantes, aux e-mails, aux partenariats, aux publications sur les réseaux sociaux, aux liens d'affiliation et aux codes QR hors ligne.

Ai-je besoin d'un cookie distinct pour chaque sous-domaine ?

Pas si les sous-domaines partagent un même domaine parent. Un cookie limité à .example.com peut être lu aussi bien par www, app, docs que checkout, même s'il reste considéré comme une technologie de suivi et nécessite un consentement selon la finalité et la juridiction.

Comment empêcher les redirections d'authentification de casser l'attribution ?

Ajoutez les domaines d'authentification et de paiement à la liste d'exclusion de référencement de votre outil analytique, puis stockez le contexte de campagne avant le début de la redirection. Déclenchez l'événement de conversion seulement une fois que l'utilisateur revient sur votre domaine. Testez le parcours en navigation privée et avec le consentement refusé pour repérer les cas que la liste d'exclusion ne couvre pas.

Pourquoi la recherche organique semble-t-elle faible dans certains rapports d'attribution ?

Une rupture entre le site marketing et l'application en est une cause fréquente. Les sessions qui démarrent par une recherche organique sur www.example.com sont coupées lors de la redirection d'inscription, si bien qu'app.example.com enregistre l'activation sans source visible, et le rapport sous-estime le trafic organique.

L'attribution doit-elle s'arrêter à l'inscription ou aller plus loin ?

Suivez-la jusqu'à l'activation. L'inscription seule récompense les campagnes qui suscitent de la curiosité plutôt que des clients, alors qu'observer la création de l'espace de travail et la connexion de la première intégration peut montrer que la recherche organique ou le trafic issu de la documentation s'active à un taux plus élevé, même avec moins d'inscriptions brutes.

L'analytique côté navigateur suffit-elle pour les conversions à forte valeur ?

Pas à elle seule. L'analytique côté navigateur est utile pour le contexte marketing, mais les abonnements payants et les factures ont besoin d'un enregistrement backend comme source de vérité, puis d'une étape de réconciliation entre les deux pour que l'attribution ne devienne jamais le facteur décisif quant à l'existence d'une conversion.

Que faut-il retirer d'une URL avant que l'analytique ne la collecte ?

Les e-mails, les identifiants clients et les autres données personnelles n'ont pas leur place dans une chaîne de requête. Retirez les paramètres sensibles avant la collecte, évitez le stockage complet des adresses IP, renoncez au fingerprinting comme contournement des limites des cookies, et gardez une courte durée de conservation des événements bruts.

Comment savoir si une application monopage casse le suivi des pages vues ?

Vérifiez si les changements de route à l'intérieur d'app.example.com déclenchent un événement de page vue, car les SPA qui mettent à jour l'URL côté client omettent souvent l'appel analytique qu'un chargement complet de page déclencherait. L'absence de pages vues pour les changements de route fait partie des problèmes listés liés aux sous-domaines et se traduit par un parcours incomplet entre l'inscription et l'activation.