Lead Scoring ist ein mächtiges Werkzeug — aber nur, wenn die Datenbasis stimmt. In den letzten Jahren habe ich oft erlebt, dass Teams nach Monaten feststellen, dass ihr Scoring „merkwürdig“ läuft. Dabei lassen sich die größten Fehlerquellen schon in zwei Wochen erkennen, wenn man strukturiert vorgeht. Ich zeige dir, wie ich innerhalb von 14 Tagen prüfe, ob das CRM‑Datenmodell das Lead Scoring verfälscht — mit konkreten Tests, Metriken und schnellen Korrekturansätzen.
Tag 0–2: Hypothesen bilden und Datenlandschaft kartieren
Bevor ich in die Daten eintauche, formuliere ich klare Hypothesen. Typische Verdächtige sind:
Dann erstelle ich eine schnelle Übersicht der relevanten Quellen: CRM (z. B. Salesforce, HubSpot, Pipedrive), Marketing Automation (z. B. Marketo, Pardot), Web/Analytics (Google Analytics, GA4), Eventstreams (Segment, RudderStack). Ziel: Verstehen, welche Datensätze in welchen Systemen landen und wie sie verknüpft werden.
Tag 3–5: Integritätschecks — sind die Rohdaten sauber?
Ich führe einfache Prüfungen aus, die schnell Auffälligkeiten zeigen:
Typische SQL‑Queries (vereinfacht) helfen mir, diese Checks in einem Data Warehouse schnell zu laufen zu lassen:
SELECT COUNT(*) FROM leads WHERE email IS NULL;
SELECT email, COUNT(*) FROM leads GROUP BY email HAVING COUNT(*) > 1;
Wenn du kein Warehouse hast, lassen sich die gleichen Checks mit Listenexporten aus dem CRM und Excel/Sheets machen.
Tag 6–8: Scoring‑Inputs evaluieren
Nun schaue ich mir an, welche Felder ins Scoring einfließen und wie robust diese Felder sind.
Ich erstelle zudem eine Korrelationsmatrix zwischen Scoring‑Score und Zielmetrik (z. B. SQL‑Creation, Deal‑Conversion). Wenn der Score kaum korreliert, ist entweder das Modell schwach oder die Daten verzerren es.
Tag 9–11: Schnelle Experimente im Feld
Theorie ist gut — ich will sehen, wie das Score‑Ranking in der Praxis performt. Dafür mache ich zwei schnelle Experimente:
Erwartung: Wenn die Top‑Scored Leads nicht signifikant bessere Conversion‑Raten zeigen, liegt das Problem entweder am Modell oder an den Inputdaten. Wenn das Entfernen eines Features die Reihenfolge kaum verändert, ist dieses Feature entweder redundant oder fehlerhaft.
Tag 12: Technische Ursachenpunktuntersuchung
Jetzt grabe ich tiefer in Integration und Transformation:
Tools wie Segment, Fivetran oder Airbyte ersparen viele Fehler — aber nur, wenn die Konfiguration sauber ist. Ich prüfe auch, ob Webhooks mehrfach feuern (z. B. bei Retry‑Mechanismen).
Tag 13: Validierung mit Sales
Technik ist nur die halbe Miete. Ich sprich mit Sales‑Colleagues und frage direkt:
Meist zeigen die Sales‑Insights Lücken auf, die reine Datenchecks übersehen — z. B. fehlende Branche oder Zielgrösse in Profilfeldern.
Tag 14: Ergebnis zusammenfassen und Sofortmaßnahmen
Am Ende der zwei Wochen habe ich drei Dinge:
Typische Quick Wins, die ich empfehle:
| Check | Sollwert | Maßnahme bei Abweichung |
|---|---|---|
| Duplikatrate | < 3% | Merge‑Regeln anpassen, dedup‑Job |
| Coverage essentieller Felder | > 90% | Formularvalidierung, Pflichtfelder |
| Time‑stamping konsistent | Alle UTC | ETL korrigieren, Logging |
| Score vs. Conversion Korrealtion | Pearson > 0,3 | Feature‑Engineering, Reweighting |
Wenn du möchtest, kann ich dir eine Checkliste und ein SQL‑Snippet schicken, mit dem du die wichtigsten Prüfungen automatisiert in deinem Data Warehouse laufen lassen kannst. In vielen Fällen reicht eine Woche zusätzlicher Automatisierung, um das Scoring wieder verlässlich zu machen — vorausgesetzt, man hat zuerst die Datenmodelle sauber geprüft.
