Marktrecherche automatisieren ohne KI: oft die bessere Wahl

Marktrecherche im großen Maßstab zu automatisieren braucht keine KI. Bei mir hat es sogar besser ohne funktioniert.

Der Workflow, der heute läuft, zieht sich pro Durchlauf öffentliche Suchergebnisse zu über 400 Suchbegriffen. Daraus baut er eine saubere, deduplizierte Datenbank an Anbietern, ohne dass ein Vision-Modell Seiten liest und ohne dass ein LLM Text parst. Er läuft komplett regelbasiert, mit reinem JavaScript.

So hat der Workflow aber nicht angefangen. Die erste Version hat mit KI gearbeitet und ist an Gründen gescheitert, die sich im Rückblick gut erklären lassen. Die Lehre reicht über diesen einen Workflow hinaus. Der Reflex gerade ist, zuerst nach einem KI-Modell zu greifen und erst danach zu fragen, ob die Aufgabe das überhaupt braucht. Manchmal gewinnt das langweiligere Werkzeug, und es lohnt sich zu wissen, in welchen Situationen das der Fall ist, bevor man die teure Version baut.

Warum manuelle Recherche bei ein paar hundert Keywords kippt

Ein Team wollte auf Dauer wissen, welche Anbieter zu einem bestimmten Markt auftauchen und welche davon wie echte Interessenten aussehen. Die Information selbst ist nicht schwer zu finden, sie ist öffentlich: Suchergebnisse, Verzeichnisse, vertikale Portale.

Zehn Keywords einmal von Hand durchzugehen, das geht noch. Ein Nachmittag mit offenen Browser-Tabs reicht für eine brauchbare Liste. Das Problem beginnt beim Volumen. Bei Dutzenden Ergebnissen pro Keyword muss jemand jedes einzelne öffnen, den Anbieter identifizieren und gegen alles abgleichen, was die Liste schon enthält.

Bei 400 bis 500 Keywords und mehreren Tausend Ergebnissen pro Durchlauf geht diese Rechnung nicht mehr auf. Für eine aktuelle Liste bräuchte es ein eigenes kleines Team, und bis irgendjemand einen Durchgang beendet hätte, wären die ersten Ergebnisse längst veraltet.

Der erste Versuch: ein Vision-Modell, das an echten Daten scheiterte

Mein erster Ansatz nutzte ein Vision-Modell. Ich hab die Ergebnisseiten als Screenshot genommen, die Bilder ans Modell geschickt und es gebeten, Anbieternamen und Felder daraus zu extrahieren. Das klang plausibel, weil die Seiten kein einheitliches HTML waren, an dem ich einfach hätte mustern können, oder zumindest dachte ich das.

Der Ansatz hat den Kontakt mit echten Daten nicht überlebt. Das Modell halluzinierte Einträge, erfand Anbieternamen, die gar nicht auf der Seite standen, vertauschte Felder zwischen benachbarten Listings und ließ ganze Zeilen einfach fallen. Dieselbe Seite rendert ihre Ergebnisse je nach Ansicht mal als Karussell, mal als Seitenleiste, mal als Raster. Mit Layouts, die sich ständig unter ihm verschoben, kam das Modell einfach nicht mit.

Also hab ich den Workflow um eine Tatsache herum neu gebaut, die ich vorher übersehen hatte: Die Quelldaten haben schon eine Struktur. Es ist HTML. Ein JavaScript-Parser, der nach festen Mustern im Markup sucht, liefert immer dasselbe Ergebnis, egal wie die Seite gerade rendert, ohne Tokenkosten, ohne Halluzinationsrisiko und ohne dass ein Modell einen guten Tag haben muss.

Wer selbst mal kurz nachsehen will, was in so einem HTML-Schnipsel eigentlich steckt, findet dafür mein HTML-Vorschau-Tool, ganz ohne eigenes Projekt.

Allgemeiner gefasst: Zu einem Modell greife ich, wenn ein Schritt wirklich Urteilsvermögen braucht, also Fließtext interpretieren, mehrdeutige Fälle abwägen, etwas in natürlicher Sprache formulieren. Hat die Eingabe dagegen schon ein Schema, schlägt ein regelbasierter Parser ein Sprachmodell meistens bei Kosten, Tempo und Zuverlässigkeit. Die größere Einordnung zwischen Assistent und Agent hab ich im Vergleich zwischen KI-Assistent und KI-Agent ausführlicher aufgeschrieben, falls dich das umfassendere Bild interessiert.

Der Aufbau: erst sammeln, dann zusammenführen

Der Workflow läuft in zwei Phasen mit einem Zwischenspeicher dazwischen. So können Sammeln und Auswerten unabhängig voneinander laufen und auch unabhängig voneinander scheitern. Diese Trennung hat sich am Ende als wichtiger erwiesen als jede der beiden Phasen für sich.

Phase eins sammelt und extrahiert. Sie arbeitet die Keywords in Batches ab, hält sich dabei an API-Limits und zieht aus jeder Ergebnisseite die relevanten Felder. Die Anfragen laufen über Residential Proxies, weil etliche Seiten alles blockieren, was automatisiert aussieht, und ein Cookie-Banner-Handler läuft zuerst, damit der Inhalt darunter überhaupt erreichbar ist.

Phase zwei aggregiert, dedupliziert und reichert an. Sie liest aus dem Zwischenspeicher, nicht live von der Quelle, damit ein langsamer oder fehlgeschlagener Sammel-Durchlauf die Auswertung nicht verfälscht. Wer nach weiteren Einstiegs-Workflows in diesem Muster sucht, findet in den fünf Einsteiger-Workflows für n8n im Marketing ein paar davon. Und falls die Plattform-Frage noch offen ist, lohnt sich mein Vergleich zwischen n8n und Make.com.

Wo die eigentliche Arbeit steckt

Den Parser zu schreiben war der leichte Teil, ein Nachmittag Arbeit. Fast die gesamte übrige Zeit ging in Randfälle, die erst auftauchten, als ich den Workflow von einer Handvoll Test-Keywords auf die vollen 400+ hochskalierte.

Das Index-Problem

Unter zehn Ergebnissen blieb alles sauber. Sobald ein Batch mit Lücken zurückkam, sei es durch Timeouts, blockierte Anfragen oder leere Antworten, tauchten aus dem Nichts falsche Duplikate auf. Gelingen neun von zehn Anfragen in einem Batch, verschiebt sich das Array um eins, und die Ergebnisse von Keyword sechs landen dann unbemerkt bei Keyword fünf. Die ganze Zuordnung bricht, ohne dass irgendwo ein Fehler auftaucht.

Die Lösung war, der Array-Position gar nicht mehr zu vertrauen. Jedes Ergebnis hängt über eine explizite Referenz an seinem ursprünglichen Keyword, nicht am Index. So weiß ein Ergebnis immer, zu welchem Keyword und welcher Zeile es gehört, egal wie viele benachbarte Anfragen fehlgeschlagen sind.

Das Duplikate-Problem

Ein einzelner Anbieter taucht oft mehr als einmal auf, einmal über das eigene Konto, einmal über einen Partnerkanal, manchmal beides gleichzeitig für unterschiedliche Produkte. Eine der beiden Zeilen zu löschen kostet echte Information, nämlich die Partner-Zuordnung.

Das Beheben des Index-Problems hat dieses Problem großteils mitgelöst. Mein Ansatz heißt Cluster-and-Enrich: Ich gruppiere jeden Eintrag zu einem Anbieter, wähle daraus einen Master-Datensatz, wobei der direkteste Eintrag gewinnt, und übernehme aus dem Rest der Gruppe die Felder, die dem Master fehlen. Zwei Einträge zum selben Anbieter führe ich so zusammen, statt sie wegzuwerfen.

Unscharfe Duplikate

Winzige Unterschiede sprengen sauberes Gruppieren, bevor es überhaupt anfängt. Example GmbH und Example GmbH mit einem Leerzeichen am Ende zählen als zwei getrennte Anbieter, weil Groß- und Kleinschreibung und vereinzelte Sonderzeichen dasselbe Problem erzeugen.

Ich normalisiere deshalb konsequent, bevor ich überhaupt gruppiere: alles klein schreiben, Leerzeichen entfernen, Sonderzeichen entfernen. Unterschiedlich geschriebene Varianten desselben Namens landen so in derselben Gruppe statt in zwei getrennten.

Grenzen der APIs

Mehrere Seiten lehnen automatisierte Anfragen rundweg ab, außer sie laufen über Residential Proxies. Cookie-Banner muss der Workflow programmatisch bestätigen, bevor überhaupt Inhalt sichtbar wird. Und Export-APIs lehnen üblicherweise Strings jenseits einer bestimmten Länge ab, sodass schon eine lange Tracking-URL oder ein Rest HTML-Markup reicht, um den ganzen Export abstürzen zu lassen. Deshalb prüfe und bereinige ich jedes Feld auf Länge, bevor ich es schreibe.

Am meisten hat mich überrascht, wie viel von der Schwierigkeit Zuverlässigkeit im großen Maßstab war, nicht die Extraktionslogik selbst. Den Parser zum Laufen zu bringen hat einen Nachmittag gedauert. 400+ Keywords und mehrere Tausend Zeilen bei jedem Durchlauf sauber durchzubekommen hat dagegen Wochen gedauert.

Was daraus in der Produktion läuft

Der Workflow läuft auf n8n, mit JavaScript, Residential Proxies und Google Sheets als Auslieferungsebene. Gebaut hat ihn eine Person über etwa vier Wochen, seitdem läuft er produktiv. Jeder Durchlauf verarbeitet 400+ Keywords und liefert eine saubere Anbieterliste per Mail, ohne Duplikate.

Die Partner-Zuordnung bleibt erhalten, wo ein Anbieter über mehr als einen Kanal auftaucht. Dazu kommen direkte Links zum Profil jedes Anbieters und die Zuordnung zurück zu dem Keyword, das ihn ursprünglich ausgespielt hat. Was früher ein Team stundenlange manuelle Recherche gekostet hat, läuft jetzt unbeaufsichtigt und liefert nach eigenem Zeitplan eine fertige Kontaktliste.

Für einen Kontrast lohnt sich ein Blick auf den Content-Machine-Fall. Die Automatisierung sitzt am anderen Ende des Spektrums, gleiche Plattform, gleicher Umfang von einer Person in ein paar Wochen, aber KI verdient sich dort ihren Platz in der Pipeline wirklich. Die Entscheidungen in diesem Workflow sind genau die Art, die ein regelbasierter Parser nicht treffen kann.

Der Gedanke, bei dem ich am Ende hängen geblieben bin: Bevor ich zu einem Modell greife, prüfe ich zuerst, ob die Daten schon eine Form haben. Haben sie das, kommt ein Parser meistens schneller ans Ziel, günstiger, und mit weniger nächtlichen Überraschungen, wenn der Workflow ohne Aufsicht durchläuft.