Pour suivre la source des demandes de renseignements sur un site e-commerce B2B destiné à l’export, l’enjeu n’est pas simplement de compter la provenance des visiteurs, mais de relier une demande qualifiée à l’historique de navigation du visiteur. Les outils SaaS d’analyse de données identifient généralement les visites à l’aide des paramètres marketing présents dans les URL, des informations sur la page référente et des identifiants du navigateur. Lorsqu’un formulaire est envoyé ou qu’un autre événement de conversion se produit, ils enregistrent les informations de source correspondantes.
Mais une « source » n’a pas toujours une réponse unique : un client peut d’abord arriver par la recherche naturelle, revenir quelques jours plus tard en cliquant sur une publicité, puis accéder directement au site pour envoyer une demande de renseignements. Le canal auquel le système attribue cette demande dépend de sa capacité à relier les identités et de ses règles d’attribution, et pas seulement de l’installation d’un code de suivi.
Lorsqu’un visiteur arrive sur un site indépendant, le script de suivi lit généralement l’URL de la page de destination, l’adresse de la page référente, ainsi que des informations telles que l’heure de la visite et le chemin de navigation. Des paramètres UTM peuvent être ajoutés à l’avance aux liens publicitaires ou publiés sur les réseaux sociaux, par exemple utm_source, utm_medium et utm_campaign, qui indiquent respectivement la source du trafic, le support et la campagne. Les identifiants de clic des plateformes publicitaires peuvent également servir à relier les conversions ultérieures, mais leur disponibilité dépend des règles de la plateforme, des autorisations et du mode d’intégration.
En l’absence de paramètres marketing, le système peut s’appuyer sur le HTTP Referrer, c’est-à-dire l’adresse de la page référente, pour déterminer si le visiteur provient d’un moteur de recherche, d’un réseau social ou d’un autre site externe. Le Referrer ne contient pas le détail des recherches ou des publicités et peut être absent en raison des règles du navigateur, des paramètres de confidentialité, des redirections ou d’un accès depuis une application. Par conséquent, un trafic classé comme « accès direct » ne signifie pas nécessairement que le client a saisi l’adresse du site manuellement.
Pour relier une demande de renseignements ultérieure aux visites précédentes, l’outil utilise des cookies, le stockage local ou d’autres méthodes autorisées afin d’enregistrer l’identifiant du visiteur et les informations de source. Lorsqu’un utilisateur envoie un formulaire, le site peut transmettre l’identifiant et les champs de source avec le formulaire sous forme de champs masqués, ou les récupérer côté serveur à partir de l’identifiant de session et les enregistrer dans la fiche de demande. Le parcours complet comprend généralement : la collecte des informations de visite, l’enregistrement de l’identifiant et de la source, le suivi des conversions effectives et le rattachement des conversions aux prospects.

Par exemple, un client clique sur un lien vers une page produit contenant utm_source=google et utm_medium=cpc, puis revient trois jours plus tard pour envoyer une demande de renseignements. Si l’identifiant est toujours valide et que l’outil a conservé la première source, la fiche de demande peut garder les informations relatives à cette visite publicitaire ; si l’identifiant a été perdu, le système peut ne connaître que la source de la visite au moment de l’envoi. La durée de conservation doit être définie en fonction de la configuration de l’outil, des restrictions du navigateur et des exigences de confidentialité applicables.
Les demandes de renseignements sur un site peuvent provenir de formulaires produit, de formulaires de contact généraux, de boutons de messagerie instantanée, de liens e-mail ou de liens téléphoniques. La précision du suivi varie selon le canal :
Les sites multilingues, les pages de destination publicitaires indépendantes et les domaines de formulaires tiers peuvent également affecter l’intégrité du parcours. Lors d’une redirection entre domaines, si l’identifiant du visiteur ou les paramètres de source ne sont pas transmis correctement, le système peut reconnaître un même client comme un nouveau visiteur, voire identifier à tort le propre domaine de l’entreprise comme une source de recommandation. Lors de l’évaluation d’un outil, il convient de vérifier la gestion de l’identification interdomaines, l’exclusion des domaines internes et la transmission des formulaires côté serveur.
Les outils SaaS d’analyse de données pour les sites e-commerce B2B destinés à l’export appliquent généralement des règles d’attribution aux données collectées. L’attribution au premier point de contact met l’accent sur le canal par lequel le client a découvert le site. L’attribution au dernier point de contact porte sur la dernière visite avant l’envoi. Certains outils utilisent également l’attribution au dernier point de contact indirect : lorsque la dernière visite est identifiée comme un accès direct, ils remontent à la source indirecte précédente répondant aux critères.
Supposons qu’un client arrive d’abord par la recherche naturelle, clique ensuite sur un contenu publié sur les réseaux sociaux, puis accède directement au site depuis ses favoris et envoie un formulaire : le premier point de contact peut être attribué à la recherche naturelle, le dernier à l’accès direct et le dernier point de contact indirect aux réseaux sociaux. Ces trois résultats reposent sur des règles différentes ; ils ne permettent pas de conclure simplement qu’un canal particulier a, à lui seul, généré la demande.
Pour comparer les rapports, il faut également vérifier la fenêtre d’attribution : la période passée pendant laquelle le système recherche les visites et si cette période est calculée à partir du clic ou de l’envoi. Une fenêtre courte peut empêcher de relier les clients dont le cycle d’achat est long à leurs premiers points de contact. Les différences de fuseau horaire, de classification des canaux, de déduplication et de définition des conversions entre les systèmes peuvent également entraîner des écarts. Le nombre de conversions indiqué par une plateforme publicitaire et le nombre de demandes de renseignements sur un site ne sont pas naturellement équivalents ; ils ne sont comparables qu’après harmonisation des méthodes de mesure.
Il convient de noter qu’un identifiant de navigateur ne correspond pas à l’identité réelle d’un client. Si celui-ci change d’appareil, efface ses données ou utilise un autre navigateur, le parcours de visite existant peut être interrompu. Le rapprochement des identités à partir d’un compte connecté ou d’un système de gestion de la relation client nécessite également des règles de fusion claires et le respect des limites d’autorisation. Les visites qui ne peuvent pas être reliées ne doivent pas être considérées comme un parcours client entièrement reconstitué.
Après le déploiement, vous pouvez accéder au site à l’aide d’un lien de test comportant des paramètres UTM explicites, consulter une page produit, puis envoyer une demande de renseignements identifiée comme test. Vérifiez que la source indiquée dans les événements du site, les enregistrements de formulaire et le système de gestion des prospects concorde, et que les données de test peuvent être exclues des rapports officiels. Testez ensuite séparément les accès sans paramètres, les redirections entre domaines, les envois répétés et les formulaires tiers, afin de vérifier si la source est remplacée, perdue ou comptabilisée plusieurs fois.
Vérifiez également si l’outil peut conserver les champs de source d’origine ainsi que la classification du canal après attribution. Si le système affiche uniquement des catégories agrégées telles que « recherche » ou « publicité », sans permettre de consulter les paramètres, les pages de destination, l’heure de conversion et la version des règles, il sera plus difficile d’analyser les erreurs de classification des canaux. Lorsque le système de formulaire transmet des données à un CRM ou à une plateforme publicitaire, vérifiez également les identifiants d’événement, les mécanismes de nouvelle tentative et de déduplication, afin d’éviter qu’une même demande ne soit comptabilisée plusieurs fois.
La conception du suivi est également soumise aux exigences de confidentialité. Lorsque le RGPD, les règles de l’Union européenne relatives à la vie privée et aux communications électroniques ou les lois d’autres régions s’appliquent, l’utilisation de cookies et de technologies similaires peut nécessiter une information, un consentement ou le respect de conditions d’exception, selon leur finalité et la juridiction concernée. Le système doit permettre de contrôler la collecte et la transmission correspondantes en fonction du statut du consentement, et prévoir des durées de conservation, des droits d’accès et des mécanismes de suppression clairement définis ; le suivi côté serveur ne supprime pas automatiquement ces obligations.
Une solution de suivi des sources efficace ne prétend pas identifier tous les visiteurs. Elle précise plutôt quelles demandes sont enregistrées, comment leur source est reliée, quelles règles d’attribution sont appliquées et dans quels cas l’identification est impossible. Lorsque ces conditions sont clairement définies, les rapports de canaux peuvent servir de base aux décisions concernant les investissements publicitaires et l’optimisation du site.
Articles connexes
Produits connexes


