Généralement, quand un leader marketing vient nous voir frustré au sujet de l'attribution, la conversation commence par les dashboards. Le dashboard Looker dit que l'inbound vient de l'organic. Le dashboard HubSpot dit que l'inbound vient du referral. Les deux sont techniquement corrects à leurs couches respectives, et le fait qu'ils ne soient pas d'accord n'est pas un problème d'outillage, c'est un problème de couture de session. Les UTMs vivent sur des sessions anonymes, les Contacts vivent dans HubSpot, et personne ne possède la jointure entre les deux. C'est ce gap qui fait l'objet de ce post.
Pourquoi cela compte maintenant
Sales et marketing opèrent encore sur des données déconnectées dans la plupart des organisations B2B SaaS, et c'est le mode de défaillance sous presque chaque dispute d'attribution. La pièce de la Harvard Business Review sur le lien sales-marketing l'a posé directement : les entreprises sont inhibées par des données client en silos, et un hub client digital, un identifiant, un record, un parcours, est le correctif structurel (hbr.org). Pour les équipes SaaS qui exploitent un warehouse à côté de HubSpot, la couture session-vers-Contact est le moment où ce hub tient ou cesse silencieusement d'être fiable.
Pourquoi la capture UTM à la soumission ne suffit pas
Le pattern standard consiste à capturer les derniers paramètres UTM à la soumission du formulaire et à les écrire dans des champs cachés sur le Contact : utm_source, utm_medium, utm_campaign. HubSpot fait ça nativement, et ça marche pour le cas le plus simple, un visiteur atterrit sur une URL UTM-taggée, clique un CTA, remplit un formulaire, devient un Contact. Une session, un Contact, un set d'UTMs.
Le cas qui ne tient presque jamais , un visiteur ouvre l'email UTM-taggé jour un, parcourt trois pages, repart. Deux jours plus tard il revient via une recherche Google, lit le pricing, repart. Deux jours après il colle l'URL de la homepage dans un navigateur et remplit le formulaire de démo. La capture UTM à la soumission écrit direct / none sur le Contact. La table de session du warehouse, elle, a les trois sessions et l'UTM email-source qui a réellement piloté le parcours. Deux systèmes, deux vérités, et celle qui gagne est celle dont le CFO ouvre le dashboard en premier.
Le pattern propriété session-token
Le correctif n'est pas un outil d'attribution plus gros. C'est une propriété unique sur le record Contact, appelez-la session_token, qui contient le même identifiant que le front-end écrit dans son log de session. Au premier chargement de page, le front-end génère le token (un UUID, un cookie hashé, n'importe quoi de stable entre sessions), le dépose dans un cookie first-party, et tague chaque événement de page avec. Quand le visiteur remplit un formulaire, le même token écrit dans un champ caché et atterrit sur le Contact.
À partir de là, l'attribution cesse d'être une supposition et devient une jointure. Le Contact a un token ; la table de session a l'historique UTM complet clavé sur ce token, y compris chaque session anonyme antérieure que le même navigateur possédait. Les propriétés UTM au niveau Contact dans HubSpot deviennent le résumé ; la jointure warehouse est la source de vérité.
Ce qui vit où
Sur le Contact , session_token, first_session_utm_source, first_session_utm_medium, first_session_utm_campaign, last_session_utm_source. Ce sont des champs résumés, peuplés par le workflow à la soumission du formulaire, pour que le SDR puisse lire la fiche Contact sans ouvrir le warehouse.
À l'intérieur du warehouse , la table de session complète, clavée par session_token, une ligne par page vue avec contexte UTM complet. Le record Contact pointe vers la table de session ; la table de session n'a pas besoin de connaître le Contact tant que la jointure ne tourne pas.
Workflow de backfill , matcher les sessions anonymes aux Contacts convertis
La soumission du formulaire capture le token de session courant. Elle ne capture pas, à elle seule, les sessions anonymes antérieures du même navigateur. C'est à ça que sert le workflow de backfill.
Le cookie first-party qui porte le token persiste entre sessions, même UUID à chaque visite jusqu'à ce que le cookie expire ou que l'utilisateur le vide. La table de session du warehouse hérite de ce token, donc toutes les sessions anonymes de ce navigateur sont déjà clavées sur un identifiant unique. Le record Contact n'apprend le token qu'au moment de la soumission. Le backfill est le moment où vous remontez ce token à travers la table de session et tirez chaque session antérieure dans la vue d'attribution du Contact.
En pratique, c'est un job planifié, pas un workflow temps-réel. Chaque nuit, une requête Looker trouve les nouveaux Contacts créés dans les dernières 24 heures, joint sur session_token, et écrit les UTMs first-touch et converting-touch consolidés vers HubSpot via l'API. Le temps-réel est un nice-to-have ; le nocturne est la version qui passe en production et y reste.
Le problème des domaines email gratuits
Environ 40 % des Contacts inbound sur la plupart des sites B2B SaaS sur lesquels nous travaillons arrivent sur un domaine email gratuit, gmail, outlook, yahoo. Certains sont de vrais acheteurs utilisant une adresse personnelle ; beaucoup sont du bruit. Dans tous les cas, un Contact sur email personnel est plus difficile à résoudre vers une Company, et le session token n'aide que si le même navigateur-et-cookie était bien celui de l'acheteur. Laptop partagé, cookies vidés, soumission incognito, n'importe lequel casse la chaîne du token et le backfill produit un tableau partiel.
Il n'y a pas de correctif propre au niveau Contact. Ce qui marche est d'accepter la vérité directionnelle , les Contacts sur domaine email gratuit se résolvent proprement environ 60 % du temps, les Contacts sur domaine email pro plus proche de 90 %, et le rapport agrégé reste honnête si vous segmentez par type d'email. Le dashboard qui prétend que chaque Contact a une attribution complète est le dashboard qui ment silencieusement à la CMO.
D'un côté, de l'autre
D'un côté, la jointure session-token donne le crédit à la campagne email qui a réellement piloté le parcours, même quand la soumission convertissante dit direct / none. De l'autre, ceci doit être pris avec un grain de sel au niveau Contact, surtout sur la frange domaine email gratuit. Directionnellement, la jointure est le correctif que le plus gros outil d'attribution était censé être. Au niveau Contact individuel, c'est un signal parmi d'autres. Les deux peuvent être vrais.
Cas observé sur le terrain
Une équipe B2B SaaS en DACH en Series A est venue nous voir le trimestre dernier avec une plainte familière : le dashboard warehouse disait que le paid social était leur meilleur canal inbound, le dashboard Contact-level HubSpot disait que le paid social était à peine présent. L'équipe se disputait sur quel chiffre mettre dans le board deck depuis deux mois. Le vrai problème, c'est que le front-end écrivait un session ID dans le warehouse mais jamais sur le Contact, donc HubSpot ne voyait que les UTMs de la session convertissante: qui, étant donné le parcours acheteur lire-puis-revenir typique, atterrissaient presque toujours sur direct ou organic. Nous avons ajouté une propriété session_token, câblé le formulaire pour la capturer, lancé un backfill nocturne contre l'historique de session existant, et en trois semaines les dashboards ont commencé à raconter la même histoire , le paid social pilotait la discovery, le direct fermait.
Résolution , le playbook de couture de session
- Générez un token de session stable côté front. Un UUID par navigateur, persisté dans un cookie first-party, attaché à chaque événement de page qui flue vers Looker.
- Ajoutez une propriété Contact
session_tokendans HubSpot. Texte single-line, masquée de la fiche Contact si vous voulez, mais peuplée à chaque soumission via un champ caché. - Écrivez le token dans le formulaire. Le champ caché du formulaire lit le cookie au moment de la soumission et écrit le token dans le record Contact. C'est la seule pièce qui doit être en temps réel.
- Construisez la requête de backfill nocturne. Un job Looker qui joint les nouveaux Contacts sur session_token, consolide les UTMs first-touch et converting-touch depuis la table de session, et pousse le résultat vers HubSpot via l'API.
- Segmentez votre reporting par type d'email. Les Contacts sur domaine email gratuit reçoivent un onglet séparé dans le dashboard d'attribution. L'agrégat n'est honnête que si vous laissez le segment bruyant être visiblement bruyant.
- Réconciliez les deux dashboards mensuellement. Looker et HubSpot ne matchent pas exactement, ils résument des choses différentes, mais l'histoire directionnelle doit s'accorder. Quand ce n'est pas le cas, la couture de session est cassée avant que les données ne le soient.
- Documentez la jointure. Une note d'une page sur quelle propriété vit où, quel job tourne quand, et quoi vérifier en premier quand un chiffre paraît faux. Le pattern session-token est le genre de plomberie qui casse silencieusement si personne ne sait qu'il existe.
Là où Checkpoint intervient
L'essentiel du travail d'attribution que nous faisons chez Checkpoint n'est pas la construction d'un nouveau modèle, c'est la réparation de la couture de session que le modèle précédent supposait présente. Si votre équipe marketing operations se bat avec deux dashboards qui ne sont pas d'accord, la jointure est presque toujours la couche cassée, et une propriété plus une requête nocturne est presque toujours le correctif. Nous l'associons au travail plus large de revenue operations sur ce à quoi sert vraiment l'attribution dans votre funnel, et au travail d'implémentation HubSpot qui câble les propriétés, formulaires et workflows pour que la couture survive au prochain changement de portail. C'est pourquoi le bon point de départ n'est pas l'outil d'attribution, c'est le record Contact.
Sources
- Sinha, Shastri, Lorimer, sur le lien sales-marketing à travers les données client en silos, dans Harvard Business Review, novembre–décembre 2024. hbr.org
- Zoltners, Sinha, Lorimer, sur la planification commerciale agile et les cycles d'adaptation continue, dans Harvard Business Review, 27 septembre 2021. hbr.org