Leadquelle im CRM: Was UTM-Parameter erklären und was offenbleibt
UTM-Werte, Anfragequelle und Selbstauskunft auseinanderhalten: ein Datenmodell für nachvollziehbare Quellenberichte.
Ein UTM-Parameter beschreibt einen markierten Zugangsweg. Er beweist nicht, dass dieser Kontaktpunkt den späteren Auftrag verursacht hat. Für brauchbare Leadquellen im CRM werden deshalb technische Beobachtung, konkrete Anfrage und Selbstauskunft getrennt gespeichert.
Der folgende Ablauf ist ein eigener Modellierungsvorschlag mit einem fiktiven Kontakt. Er behandelt die Datenzuordnung, nicht die Einrichtung einer Werbekampagne. Ziel ist ein Report, dessen Aussage auch dann stimmt, wenn ein Teil der Kontaktgeschichte unbekannt bleibt.
Vier verschiedene Fragen hinter dem Wort Quelle
"Woher kommt der Lead?" kann die erste bekannte Websiteinteraktion, den Besuch vor einer Anfrage, den technischen Anlageweg im CRM oder den vom Interessenten genannten Anlass meinen. Diese Informationen müssen nicht übereinstimmen. Ein später importierter Kontakt kann ursprünglich über eine Empfehlung gekommen sein.
HubSpot trennt Original und Latest Traffic Source von der Herkunft der Datensatzerstellung. Die Traffic-Felder beschreiben bekannte Webinteraktionen; die Record Source beschreibt, wie der Datensatz entstanden ist. Ein Import ist damit zunächst eine technische Herkunft und kein vollständiger Marketingkanal.
Eigene UTM-Felder brauchen ebenfalls eindeutige Namen. "Quelle" allein ist zu ungenau. Besser ist eine Definition wie "utm_source des dokumentierten Anfragebesuchs" mit Zeitstempel und Anfrage-ID. Ob der konkrete Erfassungsweg diese Information liefert, wird getestet. Ein Feldname garantiert keine funktionierende Messung.
Eine Kontaktgeschichte mit widersprüchlich wirkenden Angaben
Im fiktiven Beispiel liest eine Person am 3. November einen Beitrag über einen markierten Newsletterlink. Am 7. November öffnet sie die Website erneut, diesmal ohne verwertbare Kampagnenparameter, und stellt eine Anfrage. Im Gespräch nennt sie eine Empfehlung durch einen Kollegen. Am 8. November importiert das Team die Anfrage aus einem bestehenden Formularsystem ins CRM.
| Beobachtung | Gespeicherte Information | Zulässige Aussage |
|---|---|---|
| Markierter Besuch am 3.11. | Quelle newsletter, Kampagne crm-praxis | Ein bekannter Besuch kam über diesen Link |
| Anfrage am 7.11. | Keine Kampagnenparameter erfasst | Für diesen Anfragebesuch fehlt eine UTM-Zuordnung |
| Gespräch | "Ein Kollege hat euch empfohlen" | Genannter Anlass ist eine Empfehlung |
| Import am 8.11. | Technischer Anlageweg Import | So entstand der CRM-Datensatz |
Keine dieser Angaben muss die andere verdrängen. Das Problem beginnt erst, wenn das Team alle vier in dasselbe Feld schreibt. Der letzte Import kann dann eine vorherige Marketinginformation überschreiben, während ein Bericht den Import fälschlich als Akquisitionskanal zählt.
Die korrekte Beschreibung bleibt begrenzt: Ein bekannter Newsletterbesuch, eine Anfrage ohne erfasste UTM-Parameter und eine genannte Empfehlung liegen vor. Welcher Kontaktpunkt den Ausschlag gab, ist damit nicht kausal nachgewiesen.
Die Anfrage als eigene Einheit behandeln
Eine Person kann mehrere Anfragen stellen. Ein Kontaktfeld mit dem letzten UTM-Wert verliert den Bezug zur ersten Anfrage, sobald eine neue Anfrage den Wert überschreibt. Wenn die Auswertung auf Anfragen basiert, muss die Quelle dieser Anfrage erhalten bleiben.
Für kleine Teams reicht häufig ein begrenztes Register mit Anfrage-ID, Kontakt-ID, Eingangszeitpunkt und den tatsächlich erfassten Quellenfeldern. Bei späterer Übernahme ins CRM wird die Anfrage mit dem passenden Deal verknüpft. Nicht jede Anfrage benötigt sofort einen Deal; die Qualifizierungsregel bleibt eine eigene Entscheidung.
Lege fest, ob ein Feld einmalig gesetzt oder bei jedem Ereignis aktualisiert wird. Ein erster bekannter Wert und ein letzter bekannter Wert haben verschiedene Zwecke. Ein historisches Anfragefeld wird nicht durch eine neue Session überschrieben. Eine aktuelle Kontaktansicht kann beide Informationen anzeigen, ohne sie gleichzusetzen.
Rohwert und Berichtskategorie trennen
Speichere den ursprünglichen UTM-Wert neben einer vereinheitlichten Kategorie, wenn dein Datenmodell dies erlaubt. "LinkedIn", "linkedin" und "li" können nach einer dokumentierten Zuordnung gemeinsam ausgewertet werden. Der Rohwert bleibt erhalten, damit eine fehlerhafte Zuordnungsregel später korrigiert werden kann.
| Rohwert | Berichtskategorie | Regel |
|---|---|---|
| Exakte Zuordnung | ||
| Grossschreibung vereinheitlicht | ||
| li | Ungeklärt | Erst nach Prüfung des verwendeten Namensschemas zuordnen |
| leer | Nicht erfasst | Keine Quelle ergänzen |
Ein kurzer Wert ist nicht automatisch eindeutig. Die Zuordnung "li = LinkedIn" braucht eine Grundlage im tatsächlichen Namensschema. Ebenso ist "direkt" kein Synonym für Markenbekanntheit. Fehlende Parameter können verschiedene Gründe haben. Die Datenlage erlaubt dann nur die Aussage, dass der gewählte Erfassungsweg keine genauere Zuordnung geliefert hat.
Personenbezogene Inhalte gehören nicht in frei weitergegebene Kampagnenparameter. Für die hier beschriebene Auswertung reichen sachliche Kampagnennamen und technische IDs. Welche Datenverarbeitung im konkreten Setup zulässig ist, wird unabhängig von der Reportinglogik geprüft.
Einen Quellenreport mit sichtbaren Lücken bauen
Im Beispiel werden zehn eindeutige Anfragen ausgewertet. Bei vier ist eine UTM-Zuordnung zum Anfragebesuch vorhanden. Drei enthalten ausschliesslich eine Selbstauskunft. Bei drei fehlt beides. Die technische UTM-Abdeckung beträgt damit 40 Prozent. Sie beträgt nicht 70 Prozent, nur weil zusätzlich drei Menschen eine Quelle genannt haben.
Zeige beide Erfassungsarten getrennt. Eine kombinierte Kategorie "bekannte Herkunft" ist möglich, benötigt aber eine ausdrückliche Regel und darf nicht als technische Attribution erscheinen. Wenn ein Fall beides enthält, wird er bei der Gesamtzahl eindeutiger Anfragen nur einmal gezählt.
Ein anschliessender Dealreport braucht eine weitere Zuordnungsregel. Welcher Deal gehört zu welcher Anfrage? Mehrere Kontakte am selben Deal dürfen nicht jeweils den vollständigen Betrag als unabhängig gewonnenen Umsatz erhalten. Die Beziehungen zwischen Kontakt, Unternehmen und Deal bestimmen die Körnung.
Den Datenweg vom Link bis zum Report testen
Ein Test umfasst einen markierten Besuch, einen unmarkierten Besuch und eine wiederholte Anfrage derselben Testperson. Prüfe jeweils, welche Werte tatsächlich gespeichert werden und ob die erste Anfrage unverändert erhalten bleibt. Das erwartete Ergebnis wird vor dem Test notiert.
Zusätzlich wird ein Import geprüft. Der technische Anlageweg darf eine fachlich bestätigte Anfragequelle nicht unbemerkt ersetzen. Stimmen Kontaktansicht und Report nicht überein, wird zuerst der Datenweg untersucht. Eine neue Kategorienliste repariert keinen verlorenen Ereignisbezug.
Im Pipeline-Reporting lautet die belastbare Abnahme: eindeutige Anfragen gezählt, bekannte Quellen mit Herkunft belegt, fehlende Zuordnung sichtbar und Dealbeträge nicht vervielfacht. Eine daraus abgeleitete Aussage über verursachten Mehrumsatz benötigt eine andere Untersuchungsmethode.
Quellenprüfung: 5. November 2026. Verlinkte Produktdokumentation belegt die ausdrücklich genannten Funktionen. Methoden, Tabellen und Rechenfälle sind eigene redaktionelle Vorschläge; fiktive Beispiele sind keine Kundenresultate.
Weiterlesen
Passende Anleitungen und Artikel für die nächste Frage im Arbeitsablauf.
Verwandte Artikel
HubSpot-Dubletten prüfen: Wann zwei Datensätze wirklich zusammengehören
5 Min LesezeitExcel nach HubSpot importieren: Bestehende Datensätze aktualisieren, ohne Dubletten anzulegen
4 Min LesezeitEin Kontakt, mehrere Unternehmen: Beziehungen in HubSpot richtig zuordnen
5 Min LesezeitWin Rate berechnen: Warum dieselben Deals verschiedene Abschlussquoten ergeben
5 Min LesezeitWas soll euer CRM besser abbilden?
Leads ohne Owner, unklare Deal-Phasen oder widersprüchliche Reports: Beschreibe einen konkreten Engpass. Im Erstgespräch klären wir den passenden Umfang.
HubSpot · Vertriebsprozesse · Pipeline-Reporting