Construire l'épine dorsale d'attribution : un aperçu technique

19 janvier 202610 min read

Construire la colonne vertébrale d'attribution : présentation technique

L'attribution est l'endroit où les données de revenus se transforment en dispute. Le marketing revendique le pipeline, les ventes revendiquent la signature, l'équipe partenaires revendique l'introduction, et la finance se méfie tranquillement des trois camps parce que rien ne se réconcilie. La réaction habituelle est de débattre des modèles : premier contact, multi-contact, un mélange pondéré. Mais le modèle est le dernier des problèmes. Le premier problème, c'est que la plupart des organisations n'ont pas de colonne vertébrale d'attribution, c'est-à-dire pas de structure de données sous-jacente qui enregistre qui a touché quoi, quand, et dans quel contexte, sous une forme sur laquelle n'importe quel modèle peut être calculé.

Ceci est le complément technique de l'article conceptuel sur la colonne vertébrale d'attribution : le modèle de données, les problèmes d'identité et d'horodatage, et le pipeline qui transforme un flux désordonné de points de contact en quelque chose d'interrogeable et indépendant du modèle. Dans l'architecture de référence d'une plateforme de revenus moderne, c'est le composant le plus exigeant de la couche d'intelligence, car l'attribution révèle toutes les faiblesses de vos données.

C'est un modèle de données, pas un rapport

L'erreur fondamentale consiste à traiter l'attribution comme un problème de reporting, un tableau de bord que l'on configure. C'est un problème de modélisation de données que l'on résout une fois, après quoi les rapports deviennent faciles. La colonne vertébrale repose sur trois primitives.

Les points de contact sont des enregistrements atomiques et immuables d'une interaction : un webinaire suivi, une réponse à un e-mail, une réunion apportée par un partenaire, une inscription au produit. Chacun possède un sujet (qui), un type (quoi), un horodatage (quand) et un système source (d'où cela vient).

Les entités sont les comptes et contacts auxquels les points de contact se rattachent, résolus en identifiants canoniques afin qu'un point de contact issu de l'automatisation marketing et un autre issu du CRM atterrissent sur le même compte.

Les événements de revenus sont les résultats auxquels le crédit est attribué : pipeline créé, opportunité avancée, deal signé, expansion réservée.

Ces trois éléments en place, n'importe quel modèle d'attribution, qu'il soit premier contact, dernier contact, linéaire, à décroissance temporelle, en U, ou une pondération apprise, n'est qu'une fonction appliquée aux points de contact entre la première interaction d'une entité et un événement de revenu. On arrête de se disputer sur quel rapport est correct et on commence à calculer différentes vues sur les mêmes données immuables. Cette séparation est tout l'enjeu.

Les deux choses qui font vraiment échouer les projets

Plus de projets d'attribution meurent sur ces deux points que sur n'importe quel désaccord de modélisation.

La résolution d'identité. Un point de contact ne vaut rien si vous ne pouvez pas le rattacher à la bonne entité. Le même humain apparaît sous forme d'identifiant de cookie, d'e-mail de formulaire, de contact CRM et d'identifiant utilisateur produit, et si ces identités ne sont pas reliées entre elles, leurs points de contact se dispersent sur des entités fantômes. Il faut un rapprochement déterministe là où vous disposez de clés partagées (e-mail, domaine) et un rapprochement probabiliste prudent là où ce n'est pas le cas. C'est pourquoi l'attribution sanctionne si durement une mauvaise hygiène des données RevOps. Chaque identité non résolue est un trou dans la colonne vertébrale, et ces trous ne se répartissent pas aléatoirement. Ils se concentrent précisément dans les canaux les moins bien instrumentés, ce qui biaise l'ensemble du modèle.

L'intégrité temporelle. L'attribution répartit le crédit sur une séquence, elle a donc besoin d'horodatages fiables et cohérents en fuseau horaire sur chaque point de contact et chaque événement de revenu. Les échecs courants : des systèmes qui enregistrent l'heure d'ingestion plutôt que l'heure de l'événement, des incohérences de fuseau horaire entre les sources, des enregistrements rétroactifs qui arrivent dans le désordre. Un point de contact horodaté après le deal qu'il était censé influencer n'est pas une erreur mineure. Il corrompt silencieusement les modèles à décroissance temporelle et fondés sur la position. Traitez l'heure de l'événement comme un contrat de justesse, un thème que nous approfondissons dans Temps réel contre traitement par lots : quand la fraîcheur des données de revenus compte.

Le pipeline

Une colonne vertébrale fonctionnelle est un pipeline avec des étapes distinctes, chacune testable séparément.

  1. Collecte. Ingérer les points de contact depuis chaque source : automatisation marketing, activités CRM, analytique produit, systèmes partenaires, plateformes publicitaires. Conserver la charge utile brute. Ne jamais jeter une fidélité de source dont vous pourriez avoir besoin plus tard.
  2. Normalisation. Faire correspondre les événements hétérogènes au schéma commun de point de contact, avec un ensemble cohérent de types, de sujets et d'horodatages en temps d'événement.
  3. Résolution d'identité. Relier les points de contact à des entités canoniques en utilisant la logique de rapprochement décrite ci-dessus.
  4. Assemblage. Ordonner les points de contact de chaque entité en une chronologie et les associer aux événements de revenus pertinents. Cela produit les parcours que les modèles consomment.
  5. Calcul du modèle. Appliquer un ou plusieurs modèles sur les parcours assemblés. Comme la colonne vertébrale est indépendante du modèle, cette étape est peu coûteuse à modifier et peu coûteuse à exécuter avec plusieurs modèles en parallèle pour comparaison.

La discipline consiste à garder les étapes séparées. Dès que la logique de normalisation s'infiltre dans le calcul du modèle, on ne peut plus changer de modèle sans risquer les données sous-jacentes, et tout le bénéfice disparaît.

Le rendre crédible

Une colonne vertébrale gagne la confiance par l'explicabilité. Pour chaque dollar crédité, vous devriez pouvoir remonter exactement aux points de contact et à la pondération exacte qui l'ont produit. Stockez le résultat du modèle à côté du parcours à partir duquel il a été calculé, afin que l'attribution soit auditable plutôt qu'une boîte noire qui produit des chiffres.

La même structure rend praticables les cas véritablement difficiles, en particulier l'attribution de co-vente et de partenaires, où un deal implique votre équipe, un partenaire, et des points de contact qui se chevauchent. Parce que la colonne vertébrale enregistre nativement le système source et le type de point de contact, les touches sourcées par un partenaire et influencées par un partenaire deviennent des lignes de premier ordre plutôt que des notes de bas de page manuelles. Les résultats ne deviennent utiles, cependant, qu'une fois renvoyés dans les systèmes où les gens travaillent réellement. C'est le rôle de la couche de réécriture, qui pousse le crédit attribué dans les champs CRM et les tableaux de bord où les commerciaux et les dirigeants le verront réellement.

Points clés à retenir

  • Résolvez l'attribution comme un modèle de données. Une fois la colonne vertébrale en place, chaque modèle n'est qu'une requête sur celle-ci.
  • Trois primitives : points de contact immuables, entités canoniques, événements de revenus.
  • L'identité et les horodatages font échouer plus de projets que les débats de modélisation ne le feront jamais, et les dégâts sont silencieux.
  • Gardez collecte, normalisation, résolution, assemblage et calcul comme des étapes séparées pour pouvoir changer de modèle sans toucher aux données.
  • Stockez le résultat à côté du parcours dont il provient. C'est ce qui rend le chiffre défendable quand le CFO pose la question.

Une colonne vertébrale bien construite transforme une dispute de crédit sans fin en une fondation interrogeable et auditable, exactement le type de couche de données dont dépend une plateforme d'orchestration des revenus comme Revnewo. Si vos débats d'attribution tournent toujours autour du modèle, la vraie solution se trouve généralement une couche plus bas.

See revenue orchestration in action

Unify your revenue data, signals, and plays on one AI-native platform.