Fachbeitrag · Wirtschaftsinformatik ·
Lead Scoring: Warum gute Testergebnisse aus Informationen nach dem Stichtag entstehen können
Ein Modell zur Priorisierung von Vertriebsanfragen soll mit Informationen arbeiten, die im Entscheidungszeitpunkt vorhanden sind. Historische Daten enthalten jedoch häufig spätere Ergänzungen. Lernt das Modell daraus, kann es im Test überzeugend wirken und im Betrieb deutlich schwächer werden. Der Fehler liegt dann nicht unbedingt im Lernverfahren, sondern in der zeitlichen Konstruktion des Datensatzes.
Den Vorhersagezeitpunkt festlegen
Vor dem Training muss klar sein, wann eine Anfrage bewertet werden soll: unmittelbar beim Eingang, nach einer ersten Prüfung oder zu einem späteren Bearbeitungsschritt. Erst danach lässt sich entscheiden, welche Felder zulässig sind. Eine heute exportierte Kontaktkarte zeigt oft den aktuellen Stand, nicht den damaligen. Auch ein scheinbar harmloses Merkmal wie die Zahl dokumentierter Aktivitäten kann bereits Gespräche enthalten, die erst nach der ursprünglichen Bewertung stattgefunden haben. Der Datenauszug muss diese zeitliche Grenze respektieren.
Ein indirektes Leck erkennen
Ein Team bewertet Anfragen am Eingangstag. Für das Training verwendet es rückblickend die spätere Zahl erstellter Angebote. Diese Zahl hängt eng mit einem erfolgreichen Verlauf zusammen, stand beim Eingang aber noch nicht fest. Das Modell nutzt somit einen Teil des späteren Ergebnisses als Erklärung. Ähnliche Lecks können durch einen erst nach Vertragsabschluss vergebenen Kundentyp oder durch nachträglich bereinigte Qualifizierungsfelder entstehen. Eine hohe Testgüte bestätigt in solchen Fällen vor allem die Verbindung zwischen späteren Prozessschritten.
Zeitgerechte Testdaten aufbauen
Für jeden Trainingsfall werden ein Bewertungsstichtag, der zu diesem Zeitpunkt verfügbare Merkmalsstand und ein späteres Ergebnisfenster benötigt. Vorverarbeitung und Merkmalsauswahl dürfen Testfälle nicht zur Anpassung verwenden. Werden mehrere Einträge derselben Organisation verteilt, kann auch deren enge Ähnlichkeit eine Bewertung beschönigen. Deshalb sollten zeitliche Trennung und geeignete Gruppierung gemeinsam geprüft werden. Ein einfacher Vergleich mit einer transparenten Ausgangsregel zeigt zusätzlich, ob das Modell über bekannte Muster hinaus einen nachvollziehbaren Beitrag leistet.
Den Betrieb anders kontrollieren
Auch ein zeitlich korrektes Modell bleibt von Datenqualität und veränderten Prozessen abhängig. Neue Anfragekanäle oder andere Qualifizierungsregeln können die Verteilung der Merkmale verändern. Wichtig sind deshalb verständliche Prüfgrößen für Priorisierung, Nachbearbeitung und Fehlentscheidungen. Das Ergebnis sollte als Unterstützung mit erkennbaren Grenzen behandelt werden. Ein belastbarer Test beantwortet, wie das Modell mit tatsächlich verfügbaren Angaben gearbeitet hätte; er behauptet nicht, dass ein hoher historischer Trefferwert unter allen künftigen Bedingungen bestehen bleibt.
Eine fachliche Merkmalsliste sollte deshalb neben jeder Spalte dokumentieren, durch welches Ereignis sie entsteht und wann sie erstmals verfügbar ist. Diese kurze Beschreibung entdeckt häufig bereits vor einem technischen Experiment problematische Informationen im Trainingsbestand.
Technical article · Business informatics ·
Lead scoring: Why strong test results can rely on information from after the decision date
A model that prioritises sales enquiries should use information available when the decision is made. Historical records, however, often contain later additions. Learning from them can produce convincing test results and much weaker performance in operation. The problem may lie in the timing of the dataset rather than in the learning method itself.
Define the prediction moment
Before training starts, decide when an enquiry is to be scored: immediately on arrival, after initial review or at a later processing stage. Only then can the admissible fields be identified. A contact record exported today often shows its current state rather than its historical state. Even an apparently harmless feature such as the number of recorded activities may already include conversations that happened after the intended scoring time. The extracted dataset needs to respect that temporal boundary, not just the field names.
Identify an indirect leak
A team scores enquiries on the day they arrive. Its retrospective training dataset includes the number of quotations eventually produced. That number is closely associated with progress, but was not yet known on arrival. The model therefore uses part of the later process to explain its outcome. Similar leaks can arise from a customer classification assigned only after contract completion or from qualification fields corrected retrospectively. In these situations, impressive test quality mainly confirms relationships between later processing steps rather than useful predictive ability.
Build time-correct evaluation data
Each training example needs a scoring date, the feature values available at that date and a subsequent outcome window. Preprocessing and feature selection must not use test examples to fit transformations. Distributing closely related records from the same organisation across datasets can also flatter evaluation results. Temporal separation and suitable grouping therefore need joint review. Comparison with a simple and transparent baseline additionally reveals whether the model provides an understandable improvement beyond patterns that are already well known to the team.
Monitor operation appropriately
Even a model built with correct timing depends on data quality and changing processes. New enquiry channels or different qualification rules can alter the feature distribution. Useful monitoring therefore considers prioritisation, follow-up workload and incorrect decisions, rather than one performance score alone. Treat the output as support with visible limits. A credible historical test asks how the model would have behaved using information genuinely available at the time; it does not establish that strong historical accuracy will persist unchanged under every future operating condition.
A business feature list should document which event produces each column and when that information first becomes available. This short description often identifies problematic information in the training dataset before a technical experiment is even performed.