Généralement, quand une équipe marketing vient nous voir frustrée par ses chiffres d'attribution, elle nous montre un dashboard où deux graphiques sur la même page sont en désaccord. Paid search est la première source sur une carte et la troisième sur une autre. L'équipe a passé la matinée à débattre de quel graphique est juste. Le graphique n'est pas le problème. La seule propriété lead source qui alimente les deux graphiques est le problème, et le bricolage au niveau rapport ne le réparera pas. Le correctif vit une couche en dessous, dans l'architecture de propriétés sur l'enregistrement Contact.
Pourquoi cela compte maintenant
Les parcours d'achat B2B continuent de s'allonger et devenir plus bruyants, les touches paid s'empilent sur l'organique, le chat chevauche le form fill, et un seul Contact accumule des dizaines d'interactions avant que le SDR ne décroche. Le last-click était la réponse facile, mais le last-click « représente mal la façon dont la combinaison complexe d'efforts marketing d'aujourd'hui influence les outcomes d'achat », comme le formulait Harvard Business Review dans son article sur pourquoi les métriques marketing ne s'additionnent pas. (hbr.org) L'instinct, c'est de réparer le rapport. Le vrai correctif, c'est d'arrêter de laisser une propriété porter le poids de trois questions différentes.
Pourquoi une seule propriété lead source perd toujours
Une seule propriété lead source est sollicitée, chaque jour, pour répondre à au moins trois questions différentes , quel canal a introduit ce Contact chez nous ; quel canal l'a touché en dernier avant l'activité d'aujourd'hui ; et quel canal était actif au moment où il a levé la main. Ce sont trois jobs. Une propriété ne peut tenir qu'une valeur à la fois, donc elle finit par tenir le signal qui a gagné la dernière race condition, généralement le dernier form fill ou le dernier paid click écrasant ce qui était là.
Par exemple : un Contact vous découvre via un post de blog organique, revient deux semaines plus tard via une pub paid social, et finit par convertir sur un form webinar. La seule propriété lead source lit « webinar », ou « paid social », selon quel workflow s'est déclenché en dernier. L'équipe contenu pense que le blog est mort. L'équipe paid prend le crédit. Aucune des deux n'a raison, parce que la propriété n'a jamais eu la place de raconter toute l'histoire.
First-touch, last-touch, converting-touch , trois propriétés, trois jobs
Le correctif, c'est d'arrêter de traiter le lead source comme une propriété et de commencer à le traiter comme trois. Chacune a un job clairement défini, une règle d'écriture clairement définie, et un consommateur clairement défini.
First-touch, write-once, défini à la création du Contact
La propriété first-touch répond à : quel canal a introduit ce Contact chez nous. Elle est définie au moment où l'enregistrement Contact est créé et n'est jamais écrasée: pas par un workflow, pas par une intégration, pas par un form. La règle d'écriture est dure , settable seulement à la création, verrouillée ensuite. C'est le champ que les équipes contenu et SEO devraient regarder, parce que c'est le seul qui survit au cycle complet du Contact sans que l'activité paid ou last-mile ne réécrive l'histoire.
Last-touch, dernière interaction non directe, mise à jour
La propriété last-touch répond à : quel canal a touché ce Contact en dernier avant ce qu'il fait en ce moment. Elle se met à jour quand une interaction non directe atterrit, un paid click, un tag campaign, un referral. Le trafic direct ne l'écrase pas (sinon chaque URL tapée efface le vrai signal marketing). C'est le champ que l'équipe paid devrait regarder, parce qu'il reflète si le budget fait encore son job tard dans le cycle.
Converting-touch, verrouillé au moment de la conversion
La propriété converting-touch répond à : quel canal était actif au moment où ce Contact a effectivement converti, soumis le form démo, atteint MQL, levé la main. Elle est définie à l'événement de conversion et, comme first-touch, n'est jamais écrasée ensuite. C'est le champ que le sales handoff et le routage SDR devraient regarder, parce qu'il capte le canal d'intention plutôt que le canal d'awareness ou le canal de dernière exposition campaign.
Les règles d'écriture , quelle propriété chaque système peut toucher
Trois propriétés ne marchent que si les règles d'écriture sont étanches, appliquées à travers forms, workflows et synchro intégration. Les forms définissent first-touch à la création et converting-touch à la soumission, point, ils n'écrivent jamais last-touch. Les workflows mettent à jour last-touch quand une règle d'attribution campaign se déclenche, mais sont interdits de toucher first-touch ou converting-touch après leur définition. Les intégrations natives ad et les feeds reverse-ETL obtiennent un accès en écriture à last-touch seulement. Si la surface d'écriture d'une propriété n'est pas contrainte, l'architecture s'effondre dans le désordre une-propriété en un trimestre.
Un détail pratique : verrouillez les champs first-touch et converting-touch en utilisant la logique « set once » dans des workflows qui vérifient si le champ est vide avant d'écrire. La plateforme n'applique pas le write-once nativement, donc la discipline vit dans la couche workflow. Ça doit être pris avec un grain de sel, aucune application n'est parfaite, surtout quand quelqu'un importe un CSV, mais le pattern tient si les workflows sont nommés cohéremment et revus chaque trimestre.
La couche reporting , choisissez une propriété par rapport, ne les moyennez jamais
Trois propriétés veut dire trois rapports, pas un rapport qui moyenne sur les trois. Le dashboard d'attribution contenu lit first-touch seulement. Le dashboard d'efficacité paid lit last-touch seulement. Le dashboard MQL-vers-SQL handoff lit converting-touch seulement. Chaque rapport nomme le champ dans son titre et dans le sous-titre du graphique, pour que quiconque s'en approchant comprenne quelle question il répond. La tentation de construire un rapport « lead source » unique qui switche entre les trois champs sur un dropdown est réelle, et il faut y résister, chaque équipe qui utilise le dropdown oubliera lequel est sélectionné et débattra du résultat.
Un problème frère à flagger , une fois qu'un Contact est connu, les UTMs sur les sessions suivantes ne sont plus captés par le tracking par défaut, un mode d'échec séparé de celui dont parle ce post. L'architecture de propriétés ici suppose que les inputs sont propres. Si le UTM stitching est cassé en amont, le modèle à trois propriétés enregistre fidèlement trois saveurs de mauvaise donnée.
Cas observé sur le terrain
Une équipe marketing B2B SaaS DACH au stade late-Series-A est venue nous voir avec exactement cette contradiction de dashboard. Leur seul champ « original source » était écrasé par un workflow paid social chaque fois qu'un Contact ré-engagé cliquait sur une pub, donc le rapport mensuel de leur équipe contenu s'effondrait à mesure que les Contacts originalement sourcés depuis le blog étaient ré-attribués au paid des mois plus tard. Le CFO a demandé, raisonnablement, pourquoi le budget contenu existait. Nous avons scindé la propriété en trois en un build de deux semaines , first-touch comme nouveau champ backfillé depuis le snapshot historique de création d'enregistrement, last-touch câblé au workflow paid existant avec la règle d'écriture rétrécie, converting-touch défini à la soumission de form et verrouillé. En un mois, la contribution de l'équipe contenu a cessé de disparaître, l'équipe paid a gardé son crédit last-touch là où le budget ré-engageait effectivement un Contact, et le sales handoff avait un canal d'intention stable sur lequel router. Aucun des trois chiffres n'a beaucoup bougé ; c'était la même activité, enfin séparée.
Résolution , un playbook pour installer le modèle à trois propriétés
- Auditez la propriété lead source existante. Listez chaque workflow, intégration et form qui y écrit. Vous cherchez les race conditions, les endroits où deux systèmes s'écrasent l'un l'autre. Cette liste surprend généralement l'équipe.
- Créez trois nouvelles propriétés. Un champ first-touch channel, un last-touch channel, un converting-touch channel. Ne réutilisez pas le champ lead source existant au premier passage, laissez-le en place pour que les rapports historiques continuent de fonctionner.
- Définissez les valeurs de picklist une fois, partagées sur les trois. Mêmes valeurs, même casse, même ordre. Les rapports s'effondrent dès qu'un champ a « paid social » et un autre a « paid - social ».
- Câblez les règles d'écriture. Les forms définissent first-touch (seulement si vide) et converting-touch à la soumission. Les intégrations paid écrivent last-touch seulement. Chaque workflow touchant ces champs obtient un préfixe de nom qui flagge quelle propriété il porte.
- Backfillez first-touch depuis les timestamps de création d'enregistrement. Pour les Contacts existants, utilisez la donnée original-source que la plateforme retient déjà là où elle survit, et acceptez un known-unknown pour le reste. Documentez la date de cutoff.
- Reconstruisez les rapports contre les nouveaux champs. Un rapport par propriété. Titrez chacun avec le nom de la propriété. Retirez l'ancien rapport source unique ou marquez-le déprécié pour que personne n'y fasse confiance.
- Revoyez l'inventaire de workflows chaque trimestre. L'architecture ne reste propre que si quelqu'un porte la revue. Ajoutez ça à l'agenda standing marketing ops.
Là où Checkpoint intervient
L'architecture de propriétés est le travail sans gloire derrière chaque dashboard HubSpot auquel quelqu'un fait réellement confiance. C'est l'essentiel de ce que nous faisons côté marketing operations chez Checkpoint. Si votre dashboard lead source se contredit, ou si contenu, paid et sales ont cessé de s'accorder sur ce que « source » veut dire, le correctif est presque toujours une couche en dessous du dashboard. Parlez-nous avant que la prochaine revue trimestrielle ne force une autre dispute sur quel graphique est juste.
Sources
- Lindsay. « Why Your Marketing Metrics Don't Add Up. » Harvard Business Review, 9 septembre 2014. hbr.org
- Hossain. « A Simple Framework for Unlocking Full-Funnel Marketing Attribution Intelligence. » OpenView Labs. openviewpartners.com
Noah Charak