Source Attribution in HubSpot aufbauen

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

Direktantwort: Source Attribution in HubSpot ordnet jedem Kontakt und jedem Deal die Quelle zu, aus der er wirklich kam. Die Standardangabe „Original Source“ hält dabei nur den ersten bekannten Touchpoint fest. Spätere Interaktionen, Offline-Kontakte und die Quelle, die der Lead selbst nennt, sieht sie nicht.

HubSpot setzt Original Source und die beiden Drilldown-Ebenen automatisch, und von Hand überschreiben lassen sich diese Properties nicht. Gespeichert wird, über welchen Kanal ein Kontakt zum ersten Mal bekannt wurde, dazu Details wie der Suchbegriff oder die Kampagne. Für eine erste Einordnung reicht das. Für eine Budgetentscheidung nicht. An genau dieser Stelle 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.

Am besten lässt sich das Problem mit einem Bild erklären, das sich in Projekten eingebürgert hat: dem Attribution-Eisberg. Über der Wasserlinie siehst du die Original Source. Darunter liegen die Ebenen, die HubSpot nicht von selbst erfasst: die Quelle, die der Lead selbst angibt (Self-Reported Attribution), Multi-Touch-Daten sowie die Zuordnung von Offline- und Partnerkontakten. Genau dort geht in vielen B2B-Teams das Vertrauen ins Reporting verloren.

Über der Wasserlinie stehen also nur zwei Properties: Original Source und ihre Drilldown-Ebene. Darunter liegen mindestens fünf weitere Datenpunkte. HubSpot bietet sie technisch an, befüllt sie aber nicht automatisch. Da ist zuerst die Quelle, die der Lead selbst nennt (Self-Reported Attribution). Dazu kommen Multi-Touch-Daten über den gesamten Funnel und die Zuordnung von Offline- und Partnerkontakten. Dann die Engagement-Daten eines Leads, etwa welchen Content er liest und welche Whitepaper er herunterlädt. Und schließlich UTM-Parameter, die ein Cookie über mehrere Seitenwechsel hinweg festhält.

Eine Grenze gehört gleich an den Anfang: Source Attribution ersetzt weder dein Lead-Scoring-Modell noch die Qualifizierung. Attribution sagt dir, woher ein Kontakt kam. Ob er kaufbereit ist oder zu deinem ICP passt, sagt sie nicht. Wer beide Fragen vermischt, baut ein Reporting, dem am Ende weder Marketing noch Sales eine Entscheidung anvertraut.

Wer den Eisberg ignoriert, verwechselt schnell zwei Fragen: „Woher kam der erste Klick?“ und „Welcher Kanal hat den Umsatz gebracht?“. In HubSpot haben beide verschiedene Antworten. Nur eine davon steht ohne Zusatzarbeit im CRM.

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

Direktantwort: Welches Modell du wählst, entscheidet darüber, welcher Kanal in deinem Report gut aussieht. HubSpot bietet acht Attributionsmodelle, von First Interaction über Linear und U-Shaped bis Full Path. Die Contact-Attribution läuft schon ab Marketing Hub Professional. Deal- und Revenue-Attribution gibt es ausschließlich in Marketing Hub Enterprise.

Im Alltag wird das gern auf drei Familien verkürzt: First-Touch, Last-Touch und Multi-Touch. Als Einstiegsbild taugt das. Um einen Report zu konfigurieren, reicht es nicht. Innerhalb von Multi-Touch unterscheidet HubSpot noch einmal fünf Verteilungslogiken, und jede beantwortet eine andere Frage.

So definiert die HubSpot Knowledge Base die Attributionsmodelle. Für deine Report-Auswahl zählt vor allem eines: Contact-Create-Reports laufen ab Professional, Deal-Create- und Revenue-Attribution ausschließlich in Enterprise. So steht es auch in der HubSpot-Dokumentation zum Erstellen von Attribution-Reports.

Unsere Empfehlung für die meisten B2B-SaaS-Teams: Fang nicht mit einem Modell an, sondern mit zwei. Last Interaction beantwortet die schnelle operative Frage, was gerade konvertiert hat. W-Shaped oder Linear trägt die langfristige Budgetdiskussion. HubSpot kann mehrere Modelle im selben Report nebeneinander zeigen, und genau dafür ist die Funktion gedacht. Ein einzelnes Modell erzählt selten die ganze Geschichte.

3. Welche Attribution-Properties liegen auf dem Kontakt, welche auf dem Deal?

Direktantwort: Ein Kontakt und ein Deal können aus verschiedenen Quellen stammen, und dein Reporting muss beides festhalten. Deshalb liegen die automatisch erfassten Werte auf dem Kontakt: Original Source und ihre zwei Drilldown-Stufen. Auf dem Deal liegen die Werte, die dein Team bewusst ergänzt: Record Source, der Self-Reported Source Cluster, die Sales-Reported Source sowie die Initial- und Latest-Source-Felder.

Das ist keine technische Spitzfindigkeit. Ein Kontakt bringt seine Quelle mit, sobald er zum ersten Mal im System auftaucht. Das ist reine Historie, und die ändert sich nicht mehr. Ein Deal entsteht dagegen oft Wochen oder Monate später und bringt eigene, teils widersprüchliche Signale mit. Ein typischer Fall: Der Kontakt kam ursprünglich über Organic Search, der konkrete Deal entstand aber aus einem Demo-Formular nach einer Partner-Empfehlung. Beides stimmt. Abbilden kannst du es nur mit getrennten Property-Ebenen.

Wichtiger als die Zahl der Properties ist die Reihenfolge, in der sie einander überschreiben dürfen. Typischerweise steht der Self-Reported Source Cluster vor allen automatisch erfassten Werten. Legst du diese Priorität nicht ausdrücklich fest, entscheidet der Zufall. Dann gewinnt die Property, die technisch zuerst geschrieben wurde, und nicht die, die inhaltlich am verlässlichsten ist.

4. Was du vor dem Aufbau klären musst

Direktantwort: Bevor du die erste Property umbaust, müssen vier Grundlagen stehen. Zwei davon betreffen das Tracking: eine dokumentierte UTM-Konvention und ein Formular-Inventar nach Einbettungsart. Die anderen zwei betreffen dein Datenmodell und dein Team: eine vollständige Liste aller Properties, die Attribution auf Kontakt und Deal berühren, und eine geklärte Zuständigkeit zwischen Marketing und Sales.

Die Reihenfolge ist kein Zufall. Legst du zuerst neue Properties an und sprichst erst danach über UTM-Konventionen, baust du Felder, die niemand konsistent befüllt. Klärst du zuerst die Zuständigkeit, sparst du dir später die Diskussion, warum plötzlich zwei Teams verschiedene Werte in dasselbe Feld schreiben.

• Eine dokumentierte UTM-Konvention: Leg verbindliche Werte für utm_source, utm_medium und utm_campaign fest. Diese Werte werden nicht pro Kampagne neu erfunden. Du legst sie in einer geteilten Tabelle ab, die auch neue Teammitglieder ohne Rückfrage finden.
• Ein Formular-Inventar nach Einbettungsart: Liste HTML-eingebettete und iFrame-eingebettete Formulare getrennt auf. Nur bei den HTML-Formularen lassen sich Cookie-Werte zuverlässig in versteckte Felder übertragen. Formulare auf Landingpages, Pop-up-Formulare und Formulare in externen Tools gehören in drei getrennte Spalten dieser Liste.
• Eine Property-Liste je Objekt: Schreib auf, welche Contact- und Deal-Properties Attribution überhaupt betreffen, bevor neue Custom Properties dazukommen. Ohne diese Liste entstehen erfahrungsgemäß doppelte Properties mit fast gleichem Namen, die niemand mehr auseinanderhält.
• Eine klare Zuständigkeit zwischen Marketing und Sales: Leg fest, wer die Self-Reported- und die Sales-Reported-Werte pflegt und was gilt, wenn sich beide widersprechen. Ein einziger Property-Owner pro Feld verhindert, dass zwei Teams denselben Wert in gutem Glauben unterschiedlich befüllen.
• Behalte außerdem die ICP- und Scoring-Properties im Blick, die du schon hast, etwa aus einem ABM-Scoring-Setup. Attribution baut auf denselben Datensätzen auf, nicht auf einer eigenen Property-Welt.

Fehlt eine dieser vier Grundlagen, wird jeder folgende Schritt zur Nacharbeit. Arbeiten mehrere Teams oder Länder in derselben Instanz, kommt die Property-Governance als eigenes Kapitel dazu. Mehr dazu findest du 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. So baust du Source Attribution in HubSpot Schritt für Schritt auf

Direktantwort: Reports, die vor dem Datenmodell entstehen, baust du zweimal. Deshalb läuft der Aufbau von unten nach oben, in fünf Schritten. Zuerst kommen das UTM- und Cookie-Setup und die erweiterten Properties auf Kontakt und Deal. Dann trennst du Demand Capture von Demand Creation und holst Offline- und Partnerquellen ins System. Erst zum Schluss baust du die Reporting-Struktur.

1. UTM- und Cookie-Setup. Ohne diesen Schritt geht die Kampagneninformation spätestens beim Seitenwechsel verloren. Ein Skript speichert UTM-Parameter oder den Referrer als First-Party-Cookie, alternativ im Local oder Session Storage. Ein zweites Skript schreibt den gespeicherten Wert in versteckte Felder deiner eingebetteten HubSpot-Formulare. Bei HTML-eingebetteten Formularen funktioniert das zuverlässig. In einen iFrame lässt sich das Cookie dagegen oft nicht injizieren. Das ist keine Fehlkonfiguration, sondern eine technische Grenze dieser Einbettungsart.
2. Erweiterte Properties auf Contact- und Deal-Ebene anlegen. Original Source und Drilldown reichen auf dem Kontakt nicht aus. In der Praxis ergänzt du Properties für Record Source und Self-Reported Source. Dazu kommt ein Self-Reported Source Cluster, der klar definierten Vorrang vor allen automatisch erfassten Werten bekommt. Genau hier liegt der häufigste Bruchpunkt. So zeigt es die eigene Projekterfahrung von SalesPlaybook aus 50+ Implementierungs- und Optimierungsprojekten in HubSpot, Salesforce und Pipedrive (Stand: internes Team-Deck 05/2026). Teams legen die neuen Properties an, vergessen aber, ihnen in der Workflow-Logik auch Vorrang vor der automatischen Original Source zu geben. Auf den ersten Blick sieht das nach funktionierender Attribution aus. Die neuen Felder sind befüllt, das Dashboard zeigt Werte, niemand beschwert sich. Der Fehler zeigt sich erst Wochen später, wenn ein Kontakt mit widersprüchlichen Quellenangaben auftaucht. Dann gewinnt die ältere, automatische Property gegen die bewusst gepflegte, weil in der Workflow-Reihenfolge die Priorisierung fehlt. In den meisten dieser Projekte fiel das nicht der Technik auf. Es fiel einem Sales-Mitarbeiter auf, dem die Quelle im CRM offensichtlich falsch vorkam. Nimm so ein Warnsignal ernst, statt es als Einzelfall abzutun.
3. Demand Capture von Demand Creation trennen. Hier geht es um die Frage, ob dein Marketing Nachfrage erzeugt oder nur einsammelt. Demand Creation beantwortet, wie der Lead überhaupt von deinem Unternehmen erfahren hat, etwa über einen LinkedIn-Post, einen Podcast oder eine Empfehlung. Demand Capture beantwortet, über welchen Kanal er konkret eingestiegen ist, zum Beispiel über Google Ads oder ein Website-Formular. HubSpot trennt beides nicht von selbst. Ohne eigene Property-Logik verschmelzen die zwei Fragen zu einer unscharfen Antwort. Dann kann Marketing nicht mehr zeigen, ob eine Kampagne Nachfrage geweckt oder nur vorhandene Nachfrage abgegriffen hat.
4. Offline- und Partner-Attribution ermöglichen. Messen, Netzwerke und Empfehlungen aus dem Vertrieb laufen nicht über UTM-Parameter. Ins Reporting holst du diese Quellen über ein Feld „Sales-Reported Source“, das beim Anlegen eines Deals Pflicht ist. Sonst bleiben sie für immer „Direct Traffic“ oder unbekannt. In der Praxis reicht dafür eine kurze Liste von Quellkategorien, die fest im Deal-Prozess verankert ist. Zwei davon decken den direkten Vertrieb ab: Cold Outbound und Customer Success. Drei decken digitale Kanäle ab: Google, LinkedIn und Organic. Die übrigen sammeln, was über Menschen und Anlässe kommt: Events, Network/Referral, Partner und Press. Weniger Kategorien als gedacht reichen meist aus. Bei zu vielen Optionen wählt Sales beim Ausfüllen die naheliegendste statt der richtigen.
5. Reporting-Struktur aufsetzen. Reports lohnen sich erst, wenn die Properties stehen. Du brauchst drei davon. Ein Lead-Source-Report auf Contact-Ebene zeigt die Herkunft, eine Kanalverteilung zeigt die Gewichte. Ein Touchpoint-Report stellt First- und Last-Touch nebeneinander, statt nur einen davon zu zeigen. Wer die Reihenfolge umdreht und mit den Reports anfängt, baut sie auf Properties, die zwei Wochen später ohnehin noch einmal umziehen.

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

Direktantwort: Drei Fehler begegnen dir in der Praxis am häufigsten. iFrame-eingebettete Formulare übernehmen die UTM-Cookies nicht. Die UTM-Konventionen unterscheiden sich von Kampagne zu Kampagne. Und das Team verlässt sich allein auf Original Source, ohne Self-Reported- oder Offline-Daten zu ergänzen. Ein vierter Fehler kommt dazu, sobald neue Properties angelegt sind: die fehlende Priorität.

Auffällig ist: Drei der vier Fehlerklassen sind kein Software-Problem. Es geht um Reihenfolge. Welche Property wird zuerst gesetzt, welcher Workflow läuft zuerst, welche Konvention ist zuerst dokumentiert? Darin steckt auch die gute Nachricht. Diese Fehler behebst du ohne neue Tools, allein mit einer anderen Reihenfolge.

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

Direktantwort: Bau neben den laufenden Reports, nicht in ihnen. Die neuen Attribution-Properties laufen mindestens einen vollen Reporting-Zyklus parallel zu den bestehenden, bevor du alte Reports umstellst. Original Source bleibt dabei die ganze Zeit unverändert als Rückfallquelle stehen. Du ergänzt sie, aber du ersetzt sie nie.

Der teuerste Fehler in diesem Prozess ist ein Umbau, der bestehende Dashboards live überschreibt. Teuer ist dabei nicht die Technik. Teuer ist, dass Sales und Finance dann ein Quartal lang auf zwei verschiedene Zahlen schauen, ohne zu wissen, welche gilt. Prüf neue Properties deshalb zuerst in einem separaten Test-Report und übernimm sie erst danach in die produktiven Reports. Laufen mehrere Business Units oder Länder in derselben Instanz, gilt dieselbe Vorsicht auch für die Property-Governance selbst, siehe Group-wide CRM.

Wie lange dauert der Parallelbetrieb? Realistisch sind vier bis sechs Wochen, also ein voller monatlicher Reporting-Zyklus plus Puffer. Kürzer reicht selten. Auffälligkeiten zeigen sich erst, wenn genug neue Kontakte und Deals den kompletten Prozess durchlaufen haben, und nicht schon bei den ersten paar Testfällen.

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

Direktantwort: Ob die neue Zuordnung stimmt, prüfst du am besten mit einer kleinen Stichprobe von Hand. Nimm 20 bis 30 Kontakte, deren Quelle du sicher kennst, und gleich sie mit den neuen Properties ab. Stimmen weniger als 90 % überein, liegt der Fehler fast immer in der Workflow-Priorität. An der Definition der Properties selbst liegt es selten.

1. Zieh die Stichprobe: Kontakte, deren echte Quelle dein Team ohnehin kennt, zum Beispiel aus persönlichen Sales-Gesprächen.
2. Prüf die neuen Properties gegen diese Stichprobe. Nicht gegen die alte Original Source, denn die war ja genau das Problem.
3. Verfolge jede Abweichung einzeln. Meist steckt ein Workflow dahinter, der in der falschen Reihenfolge läuft, seltener ein technisches Tracking-Problem.
4. Prüf nach zwei bis drei Wochen noch einmal, sobald genug neue Kontakte den vollständigen Prozess durchlaufen haben.

Die Stichprobe ersetzt kein automatisiertes Monitoring. Dafür findet sie genau den Fehler, den ein Dashboard nie von sich aus meldet: eine Property, die technisch korrekt befüllt ist und trotzdem die falsche Priorität hat. Ohne den Abgleich von Hand sieht so ein Setup monatelang unauffällig aus. Bis jemand eine Budgetentscheidung darauf stützt.

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

Direktantwort: Der Kanal mit den meisten Kontakten ist nicht automatisch der beste. Wo dein Budget wirkt, zeigt erst der Blick auf drei Dinge: die Qualität der Leads, die Kombination der Touchpoints und den Anteil an echten Deals. Wer nur auf das Volumen schaut, schiebt Geld in den lautesten Kanal statt in den wirksamsten.

Drei Lesefehler stecken in fast jedem Attribution-Report:

• Der leere Lead-Source-Report. Bei einem großen Teil der Kontakte steht keine Quelle. Auf so einem Report lässt sich keine Budgetentscheidung aufbauen. Die Ursache ist fast immer ein hybrides Modell, das nicht konsequent genug umgesetzt wurde.
• Die Kanalverteilung als Kuchendiagramm. Das größte Tortenstück ist nicht der wertvollste Kanal. Erst zusammen mit einem klar definierten „Lead Source Cluster“ siehst du, welcher Kanal zu Deals führt und nicht nur zu Kontakten.
• Der Touchpoint-Report mit nur einer Spalte. Der First Touch, etwa ein Klick auf Social Media, und der Last Touch, etwa ein Sales-Meeting, tragen beide zum Umsatz bei. Zeigt der Report nur eine Seite, unterschätzt er die andere systematisch.

Kennst du diese drei Lesefehler, liest du jedes Attribution-Dashboard anders. Es bestätigt dann nicht mehr die bisherige Budgetverteilung, sondern wird zur Grundlage, sie zu korrigieren. Hier liegt auch die eigentliche Verbindung zwischen Attribution-Reporting und Pipeline Generation. Ohne belastbare Quellendaten kannst du keine Kanalentscheidung rechtfertigen, die mehr kostet als ein Bauchgefühl.

Für den laufenden Betrieb gelten fünf Regeln, egal wie weit dein Aufbau schon ist:

• UTM-Konventionen stehen schriftlich fest und nicht im Kopf einer einzelnen Person.
• Software-Tracking und Self-Reported Attribution laufen zusammen, nie als Ersatz füreinander.
• Transparenz zwischen Marketing und Sales heißt Zugriff auf dieselben Properties, nicht eine monatliche Folie.
• Die gesamte Buyer Journey zählt, nicht nur der erste oder der letzte Klick.
• Attribution steuert Budget. Ein Report, der keine einzige Entscheidung ändert, war die Mühe nicht wert.

Für dich heißt das: Nimm dir den nächsten Reporting-Zyklus vor und beantworte ehrlich, wo dein Team auf dieser Liste steht. Lange warten musst du darauf nicht, der nächste Zyklus ist selten mehr als vier Wochen entfernt.