Source Attribution in HubSpot aufbauen

1. Was Source Attribution in HubSpot ist – und was die Original Source nicht zeigt

Direktantwort: Source Attribution in HubSpot ordnet jedem Kontakt und Deal die tatsächliche Lead-Quelle zu. Die Standard-Property „Original Source" erfasst dabei nur den ersten bekannten Touchpoint – sie zeigt weder spätere Interaktionen noch Offline-Kontakte noch die vom Lead selbst genannte Quelle.

Original Source und die beiden Drilldown-Ebenen sind automatisch gesetzte Properties, die sich nicht manuell überschreiben lassen: Sie speichern, über welchen Kanal ein Kontakt zum ersten Mal bekannt wurde, plus Details wie den genutzten Suchbegriff oder die Kampagne. Für die erste Einordnung reicht das. Für eine Budgetentscheidung nicht. Genau an diesem Punkt setzt jedes HubSpot-Setup an, das wir aufbauen – Attribution ist selten der erste Baustein, aber fast immer der, an dem sich zeigt, ob das Datenmodell trägt.

Das Problem zeigt sich am deutlichsten an einem Bild, das sich in Projekten eingebürgert hat: dem Attribution-Eisberg. Sichtbar über der Wasserlinie steht die Original Source. Darunter liegen die Ebenen, die HubSpot nicht automatisch erfasst – Self-Reported Attribution, Multi-Touch-Daten, Offline- und Partner-Zuordnung. Genau dort verschwindet in vielen B2B-Teams das Vertrauen ins Reporting.

Über der Wasserlinie liegen zwei Properties: Original Source und ihre Drilldown-Ebene. Darunter liegen mindestens fünf weitere Datenpunkte, die HubSpot technisch anbietet, aber nicht automatisch befüllt: Self-Reported Attribution (die vom Lead selbst genannte Quelle), Multi-Touch-Daten über den gesamten Funnel, Offline- und Partner-Zuordnung, Lead-Engagement-Daten wie Content-Konsum und Whitepaper-Downloads, und UTM-Parameter, die per Cookie über mehrere Seitenwechsel hinweg gespeichert bleiben.

Source Attribution ersetzt dabei kein Lead-Scoring-Modell und keine Qualifizierung. Sie beantwortet nur, woher ein Kontakt kam – nicht, ob er kaufbereit ist oder zum ICP passt. Wer beide Fragen vermischt, baut am Ende ein Reporting, das weder Marketing noch Sales als Entscheidungsgrundlage akzeptiert.

Wer das ignoriert, verwechselt schnell zwei unterschiedliche Fragen: „Woher kam der erste Klick" und „Welcher Kanal hat den Umsatz mitgebracht". Beide haben in HubSpot unterschiedliche Antworten. Nur eine davon steht ohne Zusatzarbeit im CRM.

2. Welche Attributionsmodelle bietet HubSpot – und wann passt welches?

Direktantwort: HubSpot bietet acht Attributionsmodelle, von First Interaction über Linear und U-Shaped bis Full Path. Contact-Attribution läuft bereits ab Marketing Hub Professional, Deal- und Revenue-Attribution ausschließlich in Marketing Hub Enterprise.

Die Praxis vereinfacht das gern auf drei Familien: First-Touch, Last-Touch, Multi-Touch. Als Einstiegsbild funktioniert das. Für die Report-Konfiguration reicht es nicht – HubSpot unterscheidet innerhalb von Multi-Touch noch einmal in fünf verschiedene Verteilungslogiken, und jede beantwortet eine andere Frage.

So beschreibt es die HubSpot Knowledge Base in ihrer Definition der Attributionsmodelle. Für die Report-Auswahl entscheidend: Contact-Create-Reports laufen ab Professional, Deal-Create- und Revenue-Attribution ausschließlich in Enterprise – das steht so auch in der HubSpot-Dokumentation zum Erstellen von Attribution-Reports.

Für die meisten B2B-SaaS-Teams ist der pragmatische Startpunkt nicht ein einzelnes Modell, sondern zwei parallel: Last Interaction für die schnelle operative Frage „was hat gerade konvertiert", und W-Shaped oder Linear für die langfristige Budget-Diskussion. HubSpot erlaubt, mehrere Modelle im selben Report nebeneinander anzuzeigen – genau dafür gedacht, dass ein einzelnes Modell selten die ganze Geschichte erzählt.

3. Welche Attribution-Properties liegen auf Contact-Ebene, welche auf Deal-Ebene?

Direktantwort: Contact-Ebene trägt die automatisch erfassten Werte – Original Source und ihre zwei Drilldown-Stufen. Deal-Ebene trägt die Werte, die ein Team bewusst ergänzt: Record Source, Self-Reported Source Cluster, Sales-Reported Source und die Initial/Latest-Source-Felder über den gesamten Verlauf.

Diese Trennung ist keine technische Spitzfindigkeit. Ein Kontakt bringt seine Quelle mit, sobald er zum ersten Mal im System auftaucht – reine Historie, die sich nicht mehr ändert. Ein Deal dagegen entsteht oft Wochen oder Monate später, mit eigenen, teils widersprüchlichen Signalen: Der Kontakt kam ursprünglich über Organic Search, der konkrete Deal entstand aber aus einem Demo-Formular nach einer Partner-Empfehlung. Beide Wahrheiten gleichzeitig abzubilden, braucht getrennte Property-Ebenen.

Die Reihenfolge, in der diese Werte einander überschreiben dürfen, ist wichtiger als die Zahl der Properties selbst. Ohne eine explizit gesetzte Priorität – Self-Reported Source Cluster typischerweise vor allen automatisch erfassten Werten – gewinnt am Ende zufällig die Property, die technisch zuerst geschrieben wurde, nicht die, die inhaltlich am verlässlichsten ist.

4. Was du vor dem Aufbau klären musst

Direktantwort: Vier Dinge stehen vor dem ersten Property-Umbau: eine dokumentierte UTM-Konvention, ein Formular-Inventar nach Einbettungsart, eine vollständige Liste aller Attribution-relevanten Properties auf Contact- und Deal-Ebene, und eine geklärte Zuständigkeit zwischen Marketing und Sales.

Die Reihenfolge ist kein Zufall. Wer zuerst neue Properties anlegt und erst danach über UTM-Konventionen spricht, baut Felder, die niemand konsistent befüllt. Wer zuerst die Zuständigkeit klärt, spart sich die Diskussion, warum plötzlich zwei Teams unterschiedliche Werte in dasselbe Feld schreiben.

• UTM-Konvention dokumentiert: feste Werte für utm_source, utm_medium, utm_campaign – nicht pro Kampagne neu erfunden, sondern in einer geteilten Tabelle, auf die auch neue Teammitglieder ohne Rückfrage zugreifen können.
• Formular-Inventar nach Einbettungsart: HTML-eingebettete Formulare gegenüber iFrame-eingebetteten getrennt aufgelistet, denn nur bei ersteren lassen sich Cookie-Werte zuverlässig in versteckte Felder übertragen. Landingpage-Formulare, Popup-Formulare und in externe Tools eingebettete Formulare gehören in drei getrennte Spalten dieser Liste.
• Property-Liste je Objekt: welche Contact- und Deal-Properties Attribution überhaupt betreffen, bevor neue Custom Properties dazukommen. Ohne diese Liste entstehen erfahrungsgemäß doppelte Properties mit fast identischem Namen, die niemand mehr auseinanderhält.
• Zuständigkeit zwischen Marketing und Sales: wer pflegt Self-Reported- und Sales-Reported-Werte, und was passiert, wenn beide widersprechen. Ein einzelner Property-Owner pro Feld verhindert, dass zwei Teams denselben Wert in gutem Glauben unterschiedlich befüllen.
• Bereits vorhandene ICP- und Scoring-Properties im Blick, etwa aus einem ABM-Scoring-Setup – Attribution baut auf denselben Datensätzen auf, nicht auf einer separaten Property-Welt.

Fehlt eine dieser vier Grundlagen, wird jeder folgende Schritt zur Nacharbeit. Property-Governance über mehrere Teams oder Länder hinweg ist noch einmal ein eigenes Kapitel – dazu mehr im Abschnitt zu Group-wide CRM. Ein Symptom taucht dabei zuverlässig auf: Zwei Regionalteams nennen denselben Kanal unterschiedlich, und das Reporting zeigt am Ende drei „LinkedIn"-Zeilen statt einer.

5. Wie du Source Attribution in HubSpot Schritt für Schritt aufbaust

Direktantwort: Der Aufbau läuft in fünf Schritten: UTM- und Cookie-Setup, erweiterte Properties auf Contact- und Deal-Ebene, Trennung von Demand Capture und Demand Creation, Offline- und Partner-Attribution, und zuletzt eine Reporting-Struktur, die alles zusammenführt.

1. UTM- und Cookie-Setup. Ein Skript speichert UTM-Parameter oder den Referrer als First-Party-Cookie – alternativ in Local oder Session Storage. Ein zweites Skript überträgt den gespeicherten Wert in versteckte Felder eingebetteter HubSpot-Formulare. Funktioniert zuverlässig bei HTML-eingebetteten Formularen. Bei iFrames lässt sich das Cookie oft nicht injizieren – das ist keine Fehlkonfiguration, sondern eine technische Grenze der Einbettungsart.
2. Erweiterte Properties auf Contact- und Deal-Ebene anlegen. Original Source und Drilldown reichen auf Contact-Ebene nicht aus. Ergänzt werden in der Praxis Properties für Record Source, Self-Reported Source und – mit klar definierter Priorität vor allen automatisch erfassten Werten – ein Self-Reported Source Cluster. Nach eigener Projekterfahrung von SalesPlaybook, aus 50+ Implementierungs- und Optimierungsprojekten in HubSpot, Salesforce und Pipedrive (Stand: internes Team-Deck 05/2026), ist genau dieser Schritt der häufigste Bruchpunkt: Teams legen die neuen Properties an, vergessen aber, ihnen in der Workflow-Logik tatsächlich Vorrang vor der automatischen Original Source zu geben. Das Ergebnis sieht auf den ersten Blick nach funktionierender Attribution aus – neue Felder sind befüllt, das Dashboard zeigt Werte, niemand beschwert sich. Erst Wochen später, wenn ein Kontakt mit widersprüchlichen Quellenangaben auftaucht, zeigt sich der Fehler: Die ältere, automatische Property gewinnt gegen die bewusst gepflegte, weil die Priorisierung in der Workflow-Reihenfolge fehlt. In den meisten dieser Projekte fiel das nicht der Technik auf, sondern einem Sales-Mitarbeiter, dem die im CRM angezeigte Quelle offensichtlich falsch vorkam – ein Warnsignal, das ernst genommen werden sollte, statt es als Einzelfall abzutun.
3. Demand Capture von Demand Creation trennen. Demand Creation beantwortet „Wie hat der Lead überhaupt von uns erfahren" (LinkedIn-Post, Podcast, Empfehlung). Demand Capture beantwortet „Über welchen Kanal ist er konkret eingestiegen" (Google Ads, Website-Formular). HubSpot trennt beides nicht automatisch – ohne eigene Property-Logik verschmelzen beide Fragen zu einer unscharfen Antwort, und Marketing kann am Ende nicht mehr zeigen, ob eine Kampagne Nachfrage geweckt oder nur eine bereits vorhandene Nachfrage abgegriffen hat.
4. Offline- und Partner-Attribution ermöglichen. Messen, Netzwerke und Sales-Empfehlungen laufen nicht über UTM-Parameter. Ein Sales-Reported-Source-Feld, das im Deal-Erstellungsprozess verpflichtend befüllt wird, holt diese Quellen ins Reporting – sonst bleiben sie für immer „Direct Traffic" oder unbekannt. In der Praxis reicht dafür eine kurze, fest im Deal-Prozess verankerte Liste von Quellkategorien, etwa: Cold aktive Kundenansprache, Customer Success, Events, Google, LinkedIn, Organic, Network/Referral, Partner, Press. Weniger Kategorien als gedacht reichen meist aus – zu viele Optionen führen nur dazu, dass Sales beim Ausfüllen die naheliegendste statt der richtigen wählt.
5. Reporting-Struktur aufsetzen. Erst wenn die Properties stehen, lohnt sich der Report-Bau: ein Lead-Source-Report auf Contact-Ebene, eine Kanalverteilung, und ein Touchpoint-Report, der First- und Last-Touch nebeneinander zeigt statt nur einen davon. Wer diese Reihenfolge umdreht und zuerst Reports baut, baut sie auf Properties, die zwei Wochen später ohnehin nochmal umgezogen werden.

6. Woran Source-Attribution-Setups in der Praxis scheitern

Direktantwort: Die drei häufigsten Fehlerklassen sind iFrame-eingebettete Formulare, die UTM-Cookies nicht übernehmen, uneinheitliche UTM-Konventionen zwischen Kampagnen, und ein alleiniger Verlass auf Original Source, ohne Self-Reported- oder Offline-Daten zu ergänzen.

Auffällig: Drei der vier Fehlerklassen sind kein Software-Problem. Sie sind eine Frage der Reihenfolge – welche Property zuerst gesetzt wird, welcher Workflow zuerst läuft, welche Konvention zuerst dokumentiert ist. Das ist auch die gute Nachricht: Diese Fehler lassen sich ohne neue Tools beheben, nur mit einer anderen Ausführungsreihenfolge.

7. Was tun, wenn eine neue Property-Struktur bestehende Reports zerschießt?

Direktantwort: Neue Attribution-Properties laufen mindestens einen vollen Reporting-Zyklus parallel zu den bestehenden, bevor alte Reports umgestellt werden. Original Source bleibt dabei durchgehend die unveränderte Fallback-Quelle, nie ersetzt, nur ergänzt.

Ein Property-Umbau, der bestehende Dashboards live überschreibt, ist der teuerste Fehler in diesem Prozess – nicht wegen der Technik, sondern weil Sales und Finance dann für ein Quartal auf zwei unterschiedliche Zahlen schauen, ohne zu wissen, welche gilt. Deshalb: neue Properties zuerst in einem separaten Test-Report validieren, erst danach in die produktiven Reports übernehmen. Bei mehreren Business Units oder Ländern in derselben Instanz gilt dieselbe Vorsicht auch für die Property-Governance selbst, siehe Group-wide CRM.

Ein realistischer Zeitrahmen für diesen Parallelbetrieb: vier bis sechs Wochen, oder ein voller monatlicher Reporting-Zyklus plus Puffer. Kürzer reicht selten, weil sich Auffälligkeiten erst zeigen, wenn genug neue Kontakte und Deals durch den kompletten Prozess gelaufen sind – nicht nur durch die ersten paar Testfälle.

8. Wie du prüfst, ob die neue Zuordnung stimmt

Direktantwort: Eine Stichprobe von 20 bis 30 Kontakten mit bekannter, händisch verifizierter Quelle wird gegen die neuen Properties abgeglichen. Stimmen weniger als 90 % überein, liegt der Fehler fast immer in der Workflow-Priorität, nicht in der Property-Definition selbst.

1. Stichprobe ziehen: Kontakte, deren echte Quelle das Team ohnehin kennt (z. B. aus persönlichen Sales-Gesprächen).
2. Neue Properties gegen diese Stichprobe prüfen – nicht gegen die alte Original Source, die genau das Problem war.
3. Abweichungen einzeln nachverfolgen: meist ein Workflow, der in falscher Reihenfolge läuft, seltener ein technisches Tracking-Problem.
4. Nach zwei bis drei Wochen erneut prüfen, sobald genug neue Kontakte durch den vollständigen Prozess gelaufen sind.

Diese Stichprobe ersetzt kein automatisiertes Monitoring, aber sie deckt genau den Fehler auf, den kein Dashboard von selbst zeigt: eine Property, die technisch korrekt befüllt ist, aber die falsche Priorität hat. Ohne den händischen Abgleich sieht ein solches Setup monatelang unauffällig aus – bis jemand eine Budgetentscheidung darauf stützt.

9. Wie du das Reporting liest, ohne den größten Kanal mit dem besten zu verwechseln

Direktantwort: Ein Kanal mit dem größten Kontaktvolumen ist nicht automatisch der beste Kanal – erst ein Blick auf Lead-Qualität, Touchpoint-Kombination und tatsächlichen Deal-Anteil zeigt, wo Budget wirklich wirkt.

Drei Lesefehler wiederholen sich in fast jedem Attribution-Report:

• Der leere Lead-Source-Report. Ein großer Anteil der Kontakte zeigt keine zugewiesene Quelle – das verhindert jede Budgetentscheidung, die auf dem Report basieren soll. Ursache ist fast immer ein hybrides Modell, das nicht konsequent genug umgesetzt wurde.
• Die Kanalverteilung als Kuchendiagramm. Der größte Kreissegment-Anteil ist nicht der wertvollste Kanal. Erst die Kombination mit einem klar definierten „Lead Source Cluster" zeigt, welcher Kanal tatsächlich zu Deals führt, nicht nur zu Kontakten.
• Der Touchpoint-Report mit nur einer Spalte. First Touch (z. B. ein Social-Klick) und Last Touch (z. B. ein Sales-Meeting) tragen beide zum Umsatz bei. Ein Report, der nur eine Seite zeigt, unterschätzt systematisch die andere.

Wer diese drei Lesefehler kennt, liest jedes künftige Attribution-Dashboard anders – nicht als Bestätigung der bisherigen Budgetverteilung, sondern als Grundlage, sie zu korrigieren. Und genau darin liegt die eigentliche Verbindung zwischen Attribution-Reporting und Aufbau neuer Verkaufschancen: Ohne belastbare Quellendaten lässt sich keine Kanalentscheidung rechtfertigen, die mehr kostet als eine Bauchgefühl-Vermutung.

Für den laufenden Betrieb bleiben fünf Punkte handlungsleitend, unabhängig davon, wie weit der Aufbau schon ist:

• UTM-Konventionen bleiben schriftlich fixiert, nicht im Kopf einer einzelnen Person.
• Software-Tracking und Self-Reported Attribution laufen kombiniert, nie als Ersatz füreinander.
• Transparenz zwischen Marketing und Sales ist ein Property-Zugriff, keine monatliche Slide.
• Die gesamte Buyer Journey zählt, nicht nur der erste oder letzte Klick.
• Attribution steuert tatsächlich Budget – ein Report, der niemandes Entscheidung ändert, war die Mühe nicht wert.

Wo genau ein Team auf dieser Liste steht, lässt sich in einem einzigen Reporting-Zyklus ehrlich beantworten. Der nächste ist selten mehr als vier Wochen entfernt.