Die Lead-Source, der Sie nicht trauen können: warum eine einzelne HubSpot-Lead-Source-Property über Forms, Paid und Inbound bricht

Wenn ein Marketing-Team frustriert über seine Attributions-Zahlen zu uns kommt, zeigen sie uns meist ein Dashboard, in dem zwei Charts auf derselben Seite uneins sind. Paid Search ist die Top-Quelle auf einer Card und die dritte Quelle auf einer anderen. Das Team hat den Vormittag damit verbracht, zu streiten, welcher Chart richtig ist. Der Chart ist nicht das Problem. Die einzelne Lead-Source-Property, die beide Charts speist, ist das Problem, und Report-Level-Fummelei wird das nicht fixen. Die Lösung lebt eine Schicht tiefer, in der Property-Architektur am Contact-Record.

Warum das jetzt wichtig ist

B2B-Buyer-Journeys werden länger und rauschiger, Paid-Touches stapeln sich auf Organic, Chat überlappt mit Form-Fills, und ein einzelner Contact akkumuliert Dutzende Interaktionen, bevor der SDR überhaupt aufnimmt. Last-Click-Attribution war die einfache Antwort, aber Last-Click „repräsentiert falsch, wie die heutige komplexe Kombination von Marketing-Bemühungen Kaufentscheidungen beeinflusst", wie die Harvard Business Review in ihrem Beitrag dazu, warum Marketing-Metriken sich nicht addieren, formulierte. (hbr.org) Der Instinkt ist, den Report zu fixen. Die tatsächliche Lösung ist, eine Property nicht mehr das Gewicht von drei verschiedenen Fragen tragen zu lassen.

Warum eine einzelne Lead-Source-Property immer verliert

Eine einzelne Lead-Source-Property wird täglich gefragt, mindestens drei verschiedene Fragen zu beantworten: welcher Kanal hat diesen Contact bei uns eingeführt; welcher Kanal hat ihn zuletzt vor der heutigen Aktivität berührt; und welcher Kanal war aktiv, als er die Hand hob. Das sind drei Jobs. Eine einzelne Property kann nur einen Wert auf einmal halten, also hält sie das, was die letzte Race Condition gewann, meist der letzte Form-Fill oder der letzte Paid-Click, der überschreibt, was vorher da war.

Ein Beispiel, Ein Contact entdeckt Sie über einen Organic-Blog-Post, kommt zwei Wochen später über eine Paid-Social-Anzeige zurück und konvertiert schließlich auf einem Webinar-Formular. Die einzelne Lead-Source-Property liest „Webinar", oder „Paid Social", je nachdem, welcher Workflow zuletzt feuerte. Das Content-Team denkt, der Blog ist tot. Das Paid-Team nimmt die Credits. Beide Teams haben unrecht, weil die Property nie Raum hatte, die ganze Geschichte zu erzählen.

First-Touch, Last-Touch, Converting-Touch, drei Properties, drei Jobs

Die Lösung ist, Lead-Source nicht mehr als eine Property zu behandeln, sondern als drei. Jede hat einen klar definierten Job, eine klar definierte Schreibregel und einen klar definierten Konsumenten.

First-Touch, write-once, gesetzt bei Contact-Create

Die First-Touch-Property beantwortet: welcher Kanal hat diesen Contact bei uns eingeführt. Sie wird im Moment der Contact-Record-Erstellung gesetzt und nie überschrieben: nicht durch einen Workflow, nicht durch eine Integration, nicht durch ein Formular. Die Schreibregel ist hart, nur bei Create setzbar, danach gesperrt. Das ist das Feld, das die Content- und SEO-Teams ansehen sollten, weil es das einzige ist, das den vollen Lifecycle des Contacts überlebt, ohne dass Paid- oder Last-Mile-Aktivität die History umschreibt.

Last-Touch, letzte nicht-direkte Interaktion, aktualisierbar

Die Last-Touch-Property beantwortet: welcher Kanal hat diesen Contact zuletzt berührt, bevor er das tat, was er gerade tut. Sie aktualisiert sich, wann immer eine nicht-direkte Interaktion landet, ein Paid-Click, ein Campaign-Tag, ein Referral. Direct Traffic überschreibt sie nicht (sonst würde jede getippte URL das tatsächliche Marketing-Signal löschen). Das ist das Feld, das das Paid-Team ansehen sollte, weil es spät im Zyklus reflektiert, ob das Budget seinen Job tut.

Converting-Touch, gesperrt im Moment der Konversion

Die Converting-Touch-Property beantwortet: welcher Kanal war aktiv, als dieser Contact tatsächlich konvertierte, das Demo-Formular einreichte, MQL traf, die Hand hob. Sie wird beim Konversions-Event gesetzt und, wie First-Touch, danach nie überschrieben. Das ist das Feld, das Sales-Handoff und SDR-Routing ansehen sollten, weil es den Kanal der Intent erfasst statt des Kanals der Awareness oder der letzten Campaign-Exposure.

Die Schreibregeln, welches System welche Property berühren darf

Drei Properties funktionieren nur, wenn die Schreibregeln wasserdicht sind, durchgesetzt über Forms, Workflows und Integrations-Sync. Forms setzen First-Touch bei Create und Converting-Touch bei Submit, Punkt, sie schreiben nie Last-Touch. Workflows aktualisieren Last-Touch, wenn eine Campaign-Attributions-Regel feuert, dürfen aber First-Touch oder Converting-Touch nach dem Setzen nicht berühren. Native Ad-Integrationen und Reverse-ETL-Feeds bekommen nur Schreibzugriff auf Last-Touch. Wenn die Schreib-Oberfläche einer Property nicht eingeschränkt ist, kollabiert die Architektur innerhalb eines Quartals zurück in das Eine-Property-Chaos.

Ein praktisches Detail: Sperren Sie die First-Touch- und Converting-Touch-Felder mit „Set-once"-Logik in Workflows, die prüfen, ob das Feld leer ist, bevor sie schreiben. Die Plattform setzt Write-once nicht nativ durch, also lebt die Disziplin in der Workflow-Schicht. Das muss mit Vorsicht genossen werden: keine Durchsetzung ist perfekt, besonders wenn jemand eine CSV importiert, , aber das Muster hält, wenn die Workflows konsistent benannt und quartalsweise reviewt werden.

Die Reporting-Schicht, eine Property pro Report wählen, nie mitteln

Drei Properties bedeuten drei Reports, nicht einen Report, der über sie mittelt. Das Content-Attributions-Dashboard liest nur First-Touch. Das Paid-Effizienz-Dashboard liest nur Last-Touch. Das MQL-zu-SQL-Handoff-Dashboard liest nur Converting-Touch. Jeder Report nennt das Feld in Titel und Chart-Untertitel, sodass jeder, der zu ihm kommt, versteht, welche Frage er beantwortet. Die Versuchung, einen einzigen „Lead Source"-Report zu bauen, der zwischen den drei Feldern auf einem Dropdown wechselt, ist real, und ihr sollte widerstanden werden, jedes Team, das den Dropdown nutzt, wird vergessen, welcher gerade ausgewählt ist, und über das Ergebnis streiten.

Ein verwandtes Problem, das es zu flaggen lohnt: Sobald ein Contact bekannt ist, werden UTMs auf folgenden Sessions vom Standard-Tracking nicht mehr erfasst, ein separater Failure Mode von dem, um den es in diesem Beitrag geht. Die Property-Architektur hier setzt voraus, dass die Inputs sauber sind. Wenn UTM-Stitching upstream gebrochen ist, zeichnet das Drei-Property-Modell treu drei Geschmacksrichtungen schlechter Daten auf.

Muster aus der Praxis

Ein B2B-SaaS-Marketing-Team in DACH in der späten Series-A-Phase kam mit genau diesem Dashboard-Widerspruch zu uns. Ihr einzelnes „Original Source"-Feld wurde von einem Paid-Social-Workflow überschrieben, jedes Mal wenn ein re-engagter Contact eine Anzeige klickte: also kollabierte der Monatsreport ihres Content-Teams immer wieder, als ursprünglich vom Blog gesourcte Contacts Monate später Paid neu zugeordnet wurden. Der CFO fragte berechtigt, warum das Content-Budget existiere. Wir splitten die Property in zwei Wochen in drei, First-Touch als neues Feld, aus dem historischen Record-Create-Snapshot rückwirkend gefüllt, Last-Touch an den bestehenden Paid-Workflow mit verschmälerter Schreibregel verdrahtet, Converting-Touch bei Form-Submit gesetzt und gesperrt. Innerhalb eines Monats verschwand der Beitrag des Content-Teams nicht mehr, das Paid-Team behielt seine Last-Touch-Credits dort, wo das Budget tatsächlich einen Contact re-engagte, und Sales-Handoff hatte einen stabilen Channel of Intent, auf den geroutet werden konnte. Keine der drei Zahlen bewegte sich viel; es war dieselbe Aktivität, endlich getrennt.

Auflösung, ein Playbook für die Installation des Drei-Property-Modells

1. Auditieren Sie die bestehende Lead-Source-Property. Listen Sie jeden Workflow, jede Integration und jedes Formular, das in sie schreibt. Sie suchen nach den Race Conditions: den Stellen, an denen zwei Systeme einander überschreiben. Diese Liste überrascht das Team meist.
2. Erstellen Sie drei neue Properties. Ein First-Touch-Channel-Feld, ein Last-Touch-Channel-Feld, ein Converting-Touch-Channel-Feld. Repurposen Sie das bestehende Lead-Source-Feld im ersten Pass nicht: lassen Sie es an Ort und Stelle, damit historische Reports weiter funktionieren.
3. Definieren Sie die Picklist-Werte einmal, geteilt über alle drei. Gleiche Werte, gleiche Schreibweise, gleiche Reihenfolge. Reports kollabieren in dem Moment, in dem ein Feld „paid social" und ein anderes „paid - social" hat.
4. Verdrahten Sie die Schreibregeln. Forms setzen First-Touch (nur wenn leer) und Converting-Touch bei Submit. Paid-Integrationen schreiben nur Last-Touch. Jeder Workflow, der diese Felder berührt, bekommt ein Namens-Präfix, das flaggt, welche Property er besitzt.
5. Backfillen Sie First-Touch aus Record-Create-Timestamps. Für bestehende Contacts nutzen Sie die Original-Source-Daten, die die Plattform bereits behält, wo sie überleben, und akzeptieren ein known-unknown für den Rest. Dokumentieren Sie das Cutoff-Datum.
6. Bauen Sie Reports gegen die neuen Felder neu. Ein Report pro Property. Titulieren Sie jeden mit dem Property-Namen. Retiren Sie den alten Single-Source-Report oder markieren Sie ihn als deprecated, damit niemand ihm mehr traut.
7. Reviewen Sie das Workflow-Inventar quartalsweise. Die Architektur bleibt nur sauber, wenn jemand das Review besitzt. Fügen Sie es der Marketing-Ops-Standing-Agenda hinzu.

Wo Checkpoint ins Spiel kommt

Property-Architektur ist die unglamouröse Arbeit hinter jedem HubSpot-Dashboard, dem irgendjemand tatsächlich vertraut. Es ist der Großteil dessen, was wir auf der Marketing-Operations-Seite bei Checkpoint machen. Wenn Ihr Lead-Source-Dashboard sich selbst widerspricht, oder wenn Content, Paid und Sales aufgehört haben, sich zu einigen, was „Source" bedeutet, ist die Lösung fast immer eine Schicht unter dem Dashboard. Sprechen Sie mit uns, bevor das nächste quartalsweise Review einen weiteren Streit darüber erzwingt, welcher Chart richtig ist.

Quellen

• Lindsay. „Why Your Marketing Metrics Don't Add Up." Harvard Business Review, 9. September 2014. hbr.org
• Hossain. „A Simple Framework for Unlocking Full-Funnel Marketing Attribution Intelligence." OpenView Labs. openviewpartners.com