DB-Leads verstehenTeil 5 von 13
Warum ein Voll-Scan über Nacht läuft und die Hälfte kostet
Ein Lauf, der über Nacht wartet, ist kein Nachteil, wenn niemand daneben sitzt. Teil 5 der Serie über Stapelverarbeitung, doppelt eingereichte Datensätze und den Unterschied zwischen geschätzten und tatsächlichen Kosten.
REOSA-Team · 05.09.2026 · 6 Min. Lesezeit
Die Analyse eines einzelnen Kontakts dauert wenige Sekunden. Bei 1.300 Kontakten sind das mehrere Stunden reine Wartezeit, in denen ein Hintergrundprozess belegt ist und der volle Listenpreis anfällt. Es gibt einen zweiten Weg: die Stapel-Schnittstellen der Modellanbieter. Man reicht eine Datei mit tausenden Anfragen ein, bekommt keine Zeitzusage außer einer Obergrenze von 24 Stunden und zahlt dafür etwa die Hälfte.
Dieser Text beschreibt, warum inzwischen jeder Scan diesen Weg geht, und was dabei schiefging.
Die Annahme, die nicht hielt#
Die erste Fassung unterschied nach Lauf-Art: Ein vollständiger Scan geht über den Stapel, ein laufender Scan sofort. Die Begründung klang zwingend. Ein Voll-Scan ist groß, niemand sitzt daneben, 24 Stunden sind egal. Ein laufender Scan ist klein, jemand hat gerade auf den Knopf gedrückt und wartet.
Zwei Läufe aus dem Referenzkonto vom 31. Juli 2026:
| Lauf | Art | analysiert | Kosten | Dauer |
|---|---|---|---|---|
| A | laufend | 1.332 | 2,34 Euro | 73 Minuten |
| B | vollständig, Stapel | 1.225 | 1,22 Euro | 211 Minuten |
Der laufende Scan war größer als der vollständige. Das ist kein Ausreißer, sondern der Normalfall nach einem größeren Abgleich: Wenn der Import 3.000 neue Aktivitäten bringt, hat der nächste laufende Scan genauso viel zu tun wie ein Voll-Scan. Die Annahme „laufend heißt klein" ist eine Aussage über die Lauf-Art, und die Lauf-Art sagt nichts über die Menge.
Nebenwirkung: In der Betriebskonsole erschienen tagelang keine neuen Stapel-Läufe, obwohl über tausend Kontakte analysiert wurden. Die Zahlen sahen nach einem ruhigen Werkzeug aus, während es zum doppelten Preis arbeitete.
Seither gilt: Jeder Scan geht über den Stapel, sofern ein Anbieter eingerichtet ist. Ist keiner eingerichtet, fällt der Lauf auf den Sofort-Weg zurück und läuft normal weiter.
Was der Umbau nach sich zog#
Ein Lauf, der auf einen Anbieter wartet, lebt länger als seine einzelnen Arbeitspakete. Daran hängen drei Dinge, die nicht offensichtlich sind.
Ein Lauf wird erst geschlossen, wenn kein Auftrag mehr offen ist. Vorher galt: Alle Seiten durchgearbeitet, also fertig. Beim Stapel-Weg heißt „alle Seiten eingereicht" gerade nicht „fertig".
Ein wartender Lauf muss seinen Herzschlag setzen. Es gibt einen Aufräum-Vorgang, der abgestürzte Läufe schließt, erkannt an einem ausbleibenden Lebenszeichen. Ohne Herzschlag hätte er gesunde wartende Läufe abgeräumt.
Die Oberfläche muss sagen, dass gewartet wird. Sonst sieht Warten aus wie Hängen, jemand startet den Lauf neu, und das Werkzeug bezahlt dieselbe Arbeit zweimal.
Drei Lücken, die ein einziger Lauf offenlegte#
Der Lauf B aus der Tabelle oben war technisch ein Erfolg: 15 Aufträge, alle abgeschlossen, 1.498 Ergebniszeilen, kein einziger Anbieter-Fehler, 1,22 Euro bezahlt. Gemeldet hat er: 591 analysiert, 0 Funde, 0 Modell-Aufrufe. Drei voneinander unabhängige Ursachen.
98 doppelt eingereichte Datensätze#
1.498 Zeilen für 1.400 Kontakte. Ein Arbeitspaket wird bei einem Fehlschlag bis zu fünfmal wiederholt, und die Frische-Prüfung aus Stufe 1 greift hier nicht: Sie schaut auf den Zeitstempel der letzten Analyse, und beim Stapel-Weg entsteht die Analyse erst Stunden später. Ein wiederholtes Paket sieht denselben Kontakt also erneut als Kandidaten und bezahlt ihn erneut.
Die Lösung sitzt bewusst in der Stapel-Schicht und nicht im Werkzeug: Sie kann beantworten, was dieser Lauf bereits eingereicht hat, weil die Ergebniszeilen dort liegen. Ein Werkzeug, das diese Frage selbst beantworten müsste, bräuchte eine zweite Buchführung über dieselben Daten.
175 Kontakte ohne Ergebnis, ohne Grund#
175 von 1.400 Kontakten hatten keine Einschätzung, obwohl ihre Ergebniszeile als erfolgreich gemeldet war. Die Nachbereitung zählte in einem stillen Fehlerzweig nur einen Zähler hoch. Ohne Grund war nicht unterscheidbar, ob das Modell Unsinn geliefert hat, ob der Kontakt inzwischen gelöscht war oder ob unsere eigene Auswertung die Antwort verworfen hat.
Heute trägt die Zusammenfassung je Datensatz einen Fehlertext, und die Fehler landen in der Fehlerliste des Laufs. Das ist der unspektakulärste Teil dieses Textes und der wichtigste: Ein Fehler ohne Grund ist ein Fehler, den man nicht beheben kann.
Die Kosten waren die Schätzung#
Der Lauf verbuchte 3,30 Euro projiziert gegen 1,22 Euro tatsächlich, und die Zahl der Modell-Aufrufe blieb auf null stehen. Ein Stapel-Ergebnis ist ein Modell-Aufruf, er wurde nur nicht gezählt. Und die tatsächlichen Kosten aus den echten Tokenzahlen standen zwar in den Ergebniszeilen, kamen aber nie am Lauf an.
Beides ist behoben. Es klingt nach Buchhaltung und ist die Grundlage für jede Preisentscheidung: Wer den Preis eines Werkzeugs festlegen will, braucht Ist-Kosten und nicht die Schätzung, mit der er vorher gerechnet hat.
Eine Nachbereitung für beide Wege#
Die vielleicht wichtigste Konsequenz betrifft die Struktur. Die Nachbereitung eines Ergebnisses, also Bewertung, Fund, Zähler, Rückschreiben ins CRM und Ereignis, schrieb auf dem Stapel-Weg lange nur die Einschätzung und die Phase. Kein Punktwert, kein Fund, kein Rückschreiben.
Der Stapel-Weg hätte also selbst dann null Funde erzeugt, wenn er von Anfang an korrekt angeschlossen gewesen wäre. Heute liegt die Nachbereitung an genau einer Stelle und wird von beiden Wegen aufgerufen. Zwei Kopien wären nach dem ersten Änderungswunsch auseinandergelaufen, und der Fehler wäre wieder derselbe gewesen: Ein Weg schreibt Funde, der andere nicht.
Was ein Arbeitspaket enthält#
Damit der Rest nachvollziehbar bleibt, kurz die Mechanik. Ein Lauf zerlegt seine Kandidaten in Pakete. Jedes Paket wird als Datei beim Anbieter eingereicht und trägt dabei eine Kennung, die auf den Lauf zeigt. Der Lauf geht danach sofort weiter zur nächsten Seite, statt auf ein Ergebnis zu warten; die Arbeit des Vorfilters läuft also weiter, während der Anbieter rechnet.
Ein regelmäßiger Takt fragt danach die offenen Aufträge ab. Kommt ein Ergebnis, wird es durch dieselbe Nachbereitung geschickt wie ein Sofort-Ergebnis, und der Lauf zählt seine Zahlen hoch. Sind alle Aufträge eines Laufs beantwortet, wird er geschlossen und die Benachrichtigung geht raus.
Die Aufteilung in Pakete ist auch eine Schadensbegrenzung. Lehnt ein Anbieter ein Paket ab, etwa weil eine einzelne Zeile zu groß ist, betrifft das dieses Paket und nicht den Lauf. Der Verteiler kann ein abgelehntes Paket neu planen, gegebenenfalls bei einem anderen Anbieter, sofern die Route das zulässt. Ist eine Route ausdrücklich festgelegt, wird sie als Erlaubnisliste behandelt: Dann wechselt ein abgelehntes Paket nie auf ein Modell außerhalb davon, auch nicht, wenn das technisch ginge. Eine Route, die unter Last stillschweigend etwas anderes tut, als sie sagt, wäre keine Route.
Was das Büro davon merkt#
Praktisch drei Dinge.
Der Scan liefert nicht sofort. Man startet ihn und bekommt eine Benachrichtigung, wenn er fertig ist. Die Oberfläche sagt währenddessen, in welcher Phase er steckt und dass die Seite geschlossen werden darf.
Er ist etwa halb so teuer. Das ist der Grund, warum die enthaltenen Voll-Läufe im Add-on überhaupt kalkulierbar sind. Mehr dazu in Teil 13.
Die Zahl am Ende ist die echte. Was ein Lauf gekostet hat, steht als Ist-Kosten am Lauf, nicht als Hochrechnung.
Wer wirklich sofort ein Ergebnis für einen einzelnen Kontakt braucht, bekommt es weiterhin: Eine Einzel-Einschätzung läuft über den Sofort-Weg und ist in Sekunden da. Der Stapel ist der Weg für die Menge, nicht für den Einzelfall.