Market Research Automation

Ein n8n-Workflow, der öffentlich verfügbare Marktdaten automatisch analysiert und daraus eine strukturierte, deduplizierte Datenbank potenzieller Kunden erstellt. Gebaut für Teams, die Marktrecherche vorher manuell gemacht haben.

Das Problem

Das Team musste regelmäßig herausfinden, welche Anbieter in einem bestimmten Markt aktiv sind und welche davon als potenzielle Kunden infrage kommen. Die Informationen dafür sind öffentlich zugänglich, in Suchergebnissen, Verzeichnissen, Branchenportalen. Aber sie manuell zusammenzutragen dauert ewig.

Pro Suchbegriff dutzende Ergebnisse. Pro Ergebnis Details prüfen, Anbieter identifizieren, Informationen vergleichen. Bei 400 bis 500 Suchbegriffen und mehreren tausend Ergebnissen pro Durchlauf ist das manuell nicht machbar.

Warum am Ende ohne KI

Mein erster Ansatz war ein KI-Flow: Screenshots der Ergebnisseiten machen und per Vision-Modell auslesen. Hat nicht funktioniert. Das Modell hat Daten halluziniert, Anbieter-Namen erfunden, Zuordnungen verwechselt, Einträge ausgelassen. Je nach Viewport zeigen Webseiten Inhalte als Karussell, Sidebar oder Grid an. Das Modell kam mit den wechselnden Layouts nicht klar.

Dann hab ich umgebaut. Für strukturierte Datenextraktion aus HTML braucht man keine KI. Ein JavaScript-Parser, der nach festen Mustern im HTML sucht, liefert konsistente Ergebnisse, egal wie die Seite visuell dargestellt wird. Kein Token-Verbrauch, kein Halluzinationsrisiko. Manchmal ist die einfachere Lösung die bessere.

Der Ansatz

Der Workflow arbeitet in zwei Phasen. Phase 1 sammelt die öffentlich verfügbaren Marktdaten und extrahiert die relevanten Informationen. Phase 2 aggregiert, dedupliziert und reichert die Daten an. Dazwischen ein Zwischenspeicher, damit Datensammlung und Analyse getrennt laufen können.

Die Suchbegriffe werden in Batches verarbeitet, um API-Limits einzuhalten. Jeder Batch wird komplett abgearbeitet, bevor der nächste startet. Die Abfragen laufen über Proxy-Dienste, ein Cookie-Banner-Handler sorgt dafür, dass die Inhalte zugänglich sind.

Die Herausforderungen

Den Parser zu schreiben war der einfache Teil. Die meiste Entwicklungszeit ging in die Randfälle, vor allem bei der Skalierung von kleinen Testläufen auf die vollen 400+ Suchbegriffe.

Das Index-Problem

Bei unter 10 Ergebnissen lief alles sauber. Aber sobald ein neuer Batch mit weiteren 10 Ergebnissen dazukam, entstanden Duplikate, die keine waren. Wenn von 10 Anfragen nur 9 zurückkommen (Timeout, blockierter Request, leere Antwort), verschiebt sich der Index. Suchbegriff 5 wird den Ergebnissen von Suchbegriff 6 zugeordnet. Die gesamte Datenzuordnung bricht zusammen.

Ich habe das gelöst, indem jedes Ergebnis direkt zum ursprünglichen Input zurückverfolgt wird. Nicht über die Position im Array, sondern über eine explizite Zuordnung. Jedes Ergebnis weiß, zu welchem Suchbegriff und welcher Zeile es gehört, egal wie viele andere Anfragen fehlgeschlagen sind.

Das Duplikat-Problem

Ein Anbieter taucht oft mehrfach auf: einmal über den eigenen Account, einmal über einen Partner-Kanal, manchmal beides gleichzeitig für verschiedene Produkte. Einfach eine der Zeilen löschen verliert die Partner-Information.

Die Deduplizierung war auch eine Konsequenz aus der Lösung des Index-Problems. Ich habe erst versucht, auf andere Parameter zu batchen, aber am Ende war ein „Cluster & Enrich“-Ansatz nötig: Alle Einträge eines Anbieters werden gruppiert. Aus dem Cluster wird ein Master-Datensatz gewählt, priorisiert wird der direkteste Eintrag. Dann werden die restlichen Einträge nach zusätzlichen Informationen durchsucht und in den Master integriert. Zwei Einträge zum gleichen Ergebnis werden gemerged statt gelöscht.

Fuzzy Duplicates

Subtile Unterschiede verhindern saubere Gruppierung. „Beispiel GmbH“ und „Beispiel GmbH “ (mit Leerzeichen am Ende) werden als zwei verschiedene Anbieter behandelt. Groß-/Kleinschreibung, Sonderzeichen, das gleiche Problem. Ich normalisiere beim Gruppieren aggressiv: alles auf Kleinbuchstaben, Leerzeichen und Sonderzeichen raus. Unterschiedliche Schreibweisen landen dann im selben Cluster.

API-Constraints

Viele Webseiten blockieren automatisierte Anfragen ohne Residential-Proxies. Cookie-Banner müssen programmatisch akzeptiert werden, bevor die Inhalte zugänglich sind. Und Export-APIs akzeptieren oft keine Texte über eine bestimmte Zeichenlänge, lange Tracking-URLs oder HTML-Artefakte crashen den Export. Jedes Feld wird deshalb vor dem Speichern auf Länge und Sonderzeichen geprüft.

Das Ergebnis

Am Ende steht ein Spreadsheet mit einer sauberen Anbieter-Liste:

• Eindeutige Anbieter pro Zeile, keine Duplikate
• Partner-Zuordnung: Welche Tools oder Dienstleister nutzt der Anbieter bereits?
• Mehrfach-Zuordnungen, falls ein Anbieter über verschiedene Kanäle aktiv ist
• Direkte Links zu Anbieter-Profilen
• Suchbegriff-Zuordnung: Welcher Suchbegriff zu welchem Anbieter gehört
• Automatische Benachrichtigung per E-Mail nach Abschluss

Das Feedback war sehr positiv. Was vorher Stunden manuelle Recherche war, läuft jetzt durch und liefert eine fertige Kontaktliste. Ich könnte heute schneller solche Flows aufsetzen, weil ich mich logischer an die Probleme heranarbeite. Aber jeder Flow ist anders.