Händlerstandorte liegen selten bequem in einer einzigen Datenbank. Ein Hersteller stellt ein sauberes Verzeichnis bereit, ein anderer nutzt eine interaktive Karte, ein dritter verlangt eine Postleitzahlensuche, und ein vierter versteckt Händlerdetails hinter einzelnen Profilseiten.
Wenn das Portfolio auf Hunderte von Websites wächst, geht es längst nicht mehr nur darum, „ein paar Adressen zu scrapen“. Das eigentliche Ziel ist ein verlässlicher Händler-Stammdatensatz, der geschäftliche Fragen beantwortet:
- Wo wächst oder schrumpft das Vertriebsnetz?
- Welche Regionen haben Versorgungslücken?
- Welche Händler wurden hinzugefügt, verschoben oder entfernt?
- Welche Standorte führen eine bestimmte Produktlinie oder Dienstleistung?
- Welcher CRM-Verantwortliche sollte einen neu entdeckten Händler erhalten?
- Wie verändert sich die Vertriebspräsenz eines Wettbewerbers im Zeitverlauf?
Die praktische Architektur ist einfach: Quellen finden, Locator-Muster klassifizieren, in ein einheitliches Schema extrahieren, Quellennachweise bewahren, Dubletten auflösen, relevante Änderungen erkennen und an das richtige Team weiterleiten.
Das Zielsystem
Ein produktiver Workflow zur Händlerverfolgung besteht aus sechs Ebenen:
- Quellenregister: Die Websites, Locator-URLs, Länder, Verantwortlichen, Muster, Zeitpläne und der letzte Ausführungsstatus.
- Erkennung: Eine wiederholbare Methode, um Verzeichnisse, Sitemaps, APIs, Suchformulare und Detail-URLs zu finden.
- Extraktion: Browser- oder API-Jobs, die dieselben semantischen Felder über unterschiedliche Layouts hinweg erfassen.
- Normalisierung: Einheitliche Adressen, Telefonnummern, Länder, Kategorien und Statusbezeichnungen, ohne die Rohwerte zu verlieren.
- Entitäts- und Änderungsebene: Kanonische Händleridentitäten, Markenmitgliedschaften, Zeitstempel für erstes und letztes Auftauchen sowie bestätigte Hinzufügungen oder Entfernungen.
- Aktivierung: Benachrichtigungen, CRM-Zuordnung, Abdeckungsanalyse, Dashboards und Prüfwarteschlangen.
Wer direkt von Websites in einen CRM-Import springen will, landet meist bei einem fragilen Haufen aus Einzel-Skripten und Dubletten. Erst Register und Kanonmodell machen Hunderte von Websites beherrschbar.
Schritt 1: Das kanonische Händlerschema definieren
Beginnen Sie mit dem Zielbild, nicht mit der ersten Website. Ein brauchbares Minimal-Schema sieht so aus:
| Gruppe | Felder |
|---|---|
| Quellennachweis | source_domain, source_locator_url, source_dealer_url, source_dealer_id |
| Identität | dealer_name_raw, dealer_name_normalized, brand, manufacturer |
| Adresse | street_address, address_locality, address_region, postal_code, address_country |
| Kontakt | phone_raw, phone_normalized, website |
| Standort | latitude, longitude |
| Kommerzielle Merkmale | services, products, categories, authorized_status_raw |
| Beobachtung | observed_at, first_seen, last_seen, record_status |
| Änderungssteuerung | source_hash, change_hash, parser_version |
Schema.orgs PostalAddress bietet eine sinnvolle Grundlage für Bezeichnung und Struktur von Straße, Ort, Region, Postleitzahl und Land. Verwenden Sie in normalisierten Daten bevorzugt ISO-Ländercodes mit zwei Buchstaben, behalten Sie das vom Quelltext veröffentlichte Land jedoch zusätzlich unverändert bei.
Halten Sie Roh- und Normalisierungsfelder nebeneinander. Wenn eine Seite St. John's, NL angibt und die Normalisierung daraus eine standardisierte Provinz und Vorwahl ableitet, bleiben beide Varianten für die Prüfung erhalten.
Schritt 2: Ein Quellenregister aufbauen
Das Quellenregister ist die Steuerzentrale des gesamten Prozesses. Geben Sie jeder Website eine Zeile mit:
- Domain und Marke
- Land oder Markt
- Vermutete Locator-URL
- Familie des Locator-Musters
- Bevorzugter Crawl-Modus
- Parser- oder Vorlagenversion
- Ausführungstakt
- Fachlicher Verantwortlicher
- Letzter Versuch, erfolgreicher Lauf, leerer Lauf und Fehlversuch
- Hinweise zu Suchfeldern oder Interaktionsanforderungen
Warten Sie nicht, bis jeder Locator vollständig verstanden ist. Legen Sie das Register zuerst an und verfeinern Sie die Klassifizierung während des Piloten.
So finden Sie Locator-Quellen
Prüfen Sie:
- Hauptnavigation und Footer-Links wie „Händler finden“, „Wo kaufen“ oder „Store Locator“
/sitemap.xmlund Sitemap-Indizes- Interne Website-Suche
- Suchmaschinenanfragen wie
site:brand.example dealer locator - Seitenquelltext und eingebettete strukturierte Daten
- Durch eine Locator-Suche ausgelöste Netzwerkrequests
- PDFs oder Händlerdokumente als Fallback-Quelle
Das Sitemaps-Protokoll verlangt für jeden Sitemap-Eintrag eine <loc>-URL und unterstützt Sitemap-Indizes. Sitemaps können die Erkennung beschleunigen, garantieren aber nicht, dass alle dynamischen Locator-Ergebnisse enthalten sind. Außerdem sollte ein <lastmod>-Wert nicht als Beweis für aktuelle Händlerdaten verstanden werden.
Schritt 3: Jeden Locator vor der Skalierung klassifizieren
Die meisten Händler-Websites lassen sich in wenige Musterfamilien einteilen:
- Statische HTML-Liste oder Tabelle — der einfachste Fall; die Datensätze stehen bereits im Quelltext.
- Paginierte Verzeichnisse oder Infinite Scroll — Datensätze wiederholen sich, brauchen aber Navigation.
- Kartenkacheln mit Detail-Links — Übersichts-Kacheln müssen durch Unterseiten ergänzt werden.
- Suchformular — der Nutzer muss ein Land, Bundesland, eine Stadt oder Postleitzahl eingeben.
- Eingebettetes JSON oder Netzwerkantwort — die Seite ist nur eine visuelle Hülle um strukturierte Daten.
- Schmale Liste plus Händler-Detailseiten — die Liste enthält die Identität, während Adressen und Services auf Unterseiten liegen.
- PDF- oder Dokumentenverzeichnis — Extraktion und Änderungsprüfung benötigen einen dokumentenspezifischen Pfad.
Ein universeller Scraper wird nicht alle Hunderten von Websites gut abdecken. Der skalierbare Ansatz ist, pro Musterfamilie einen wiederverwendbaren Workflow zu bauen und dann pro Quelle zu konfigurieren.
Schritt 4: Den Browser-Workflow mit Thunderbit pilotieren
Thunderbit eignet sich hervorragend, um das Schema auf repräsentativen Websites zu testen, bevor Sie in die Massenautomatisierung investieren.
Pilotvorgehen
- Öffnen Sie ein repräsentatives Händlerverzeichnis in Chrome.
- Starten Sie Thunderbit und nutzen Sie AI Suggest Fields.
- Benennen Sie die vorgeschlagenen Felder auf das kanonische Schema um.
- Fügen Sie Field AI Prompts für Normalisierung oder Klassifizierung hinzu — zum Beispiel das sichtbare Ländernamenfeld in einen ISO-Code überführen oder Services in eine freigegebene Kategorienliste einordnen.
- Aktivieren Sie Paginierung oder Infinite-Scroll-Unterstützung für Listen-Seiten.
- Nutzen Sie Subpage-Scraping, wenn einzelne Händlerseiten Telefonnummern, Websites, Services oder Quell-IDs enthalten.
- Exportieren Sie eine kleine Stichprobe nach Sheets oder Excel und prüfen Sie jede Quell-URL.
Der Browsermodus ist besonders hilfreich, wenn ein Locator Interaktion, eine eingeloggte Sitzung oder Rendering braucht, das eine einfache Anfrage nicht reproduziert. Verwenden Sie nur Quellen und Konten, zu denen das Unternehmen berechtigt ist.
Wählen Sie repräsentative statt einfache Websites
Der erste Pilot sollte 20 Websites umfassen und die wichtigsten Muster, Regionen und Seitentechnologien abdecken. Wenn alle Pilotquellen einfache statische Tabellen sind, wirkt der Ablauf perfekt — bis der erste kartenbasierte Locator auftaucht.
Prüfen Sie je Musterfamilie mindestens:
- Ein sauberes Beispiel
- Ein großes Beispiel
- Ein dynamisches oder unregelmäßiges Beispiel
- Eine Website mit Händler-Detailseiten
- Eine Website mit spärlichen oder optionalen Feldern
Schritt 5: Stabile Quellen mit der Batch-Extract-API skalieren
Für wiederholbare öffentliche Seiten verlagern Sie stabile Jobs von der manuellen Browserbedienung zur Thunderbit Web Scraper API.
Der Batch Extract endpoint verarbeitet bis zu 50 URLs in einer Anfrage mit einem einzigen JSON Schema. Er liefert eine Job-ID, verarbeitet URLs parallel, unterstützt Fehler pro URL, kann Webhook-Benachrichtigungen senden und bietet renderMode-Optionen wie none, basic und full.
Batch-Design
- Gruppieren Sie URLs, die dasselbe semantische Ausgabeschema teilen.
- Halten Sie Batches bei höchstens 50 URLs pro Anfrage.
- Wählen Sie den leichtesten Rendering-Modus, der die Daten zuverlässig sichtbar macht.
- Speichern Sie Job-ID und Parser-Version zusammen mit dem Lauf.
- Erfassen Sie Erfolgs-, Leer- und Fehlerstatus pro URL — nicht nur einen Status für den gesamten Batch.
- Wiederholen Sie nur fehlgeschlagene URLs.
- Bewahren Sie rohe Extraktionswerte und Quelllinks vor der Normalisierung auf.
Ein Schema kann unterschiedlich aufgebaute Websites abdecken, solange die fachliche Bedeutung der Felder gleich bleibt. Genau das ermöglicht es, ein statisches Verzeichnis und einen kartenbasierten Locator in denselben Händler-Stammdatensatz einfließen zu lassen.
Schritt 6: Normalisieren, ohne Belege zu löschen
Normalisierung macht Datensätze vergleichbar; sie darf sie aber nicht unauditierbar machen.
Empfohlene Transformationen sind:
- Leerzeichen und Zeichensetzung bereinigen
- Groß-/Kleinschreibung standardisieren und gleichzeitig
dealer_name_rawbehalten - Telefonnummern mit eindeutigem Länderbezug parsen
- Länder- und Regionsnamen auf freigegebene Codes abbilden
- Adressbestandteile konsistent trennen oder zusammenführen
- URLs normalisieren und Tracking-Parameter bei Bedarf entfernen
- Freitext-Services in kontrollierte Kategorien überführen und die Originalformulierung erhalten
Überschreiben Sie nicht das Autorisierungslabel der Quelle. Wenn ein Hersteller „Authorized Dealer“ und ein anderer „Certified Reseller“ sagt, speichern Sie die exakte Formulierung und ergänzen Sie optional eine normalisierte Kategorie in einem separaten Feld.
Schritt 7: Händler über Marken und Quellen hinweg abgleichen
Ein reiner Namensabgleich reicht nicht. „Smith Auto“, „Smith Automotive“ und „Smith Auto LLC“ können ein und dasselbe Unternehmen sein — oder drei verschiedene Betriebe in benachbarten Städten.
Verwenden Sie einen zusammengesetzten Kandidatenschlüssel wie:
normalisierter Name + Postleitzahl + Telefon
oder, falls Koordinaten verfügbar sind:
normalisierter Name + geografische Distanz + Hausnummer
Bewerten Sie dann die Belege:
- Exakter oder nahezu exakter normalisierter Name
- Exakte Telefonnummer
- Gleiche Postleitzahl
- Ähnliche Straßenadresse
- Koordinaten innerhalb eines kleinen Radius
- Gleiche Website-Domain
Legen Sie eine Zuordnungstabelle von Quelle zu kanonischer Entität an, statt Datensätze sofort zusammenzuführen. Mehrere Hersteller können auf denselben physischen Händler verweisen, während Markenmitgliedschaften, Services und Statuslabels getrennt bleiben.
Schritt 8: Relevante Änderungen erkennen
Jeder Lauf sollte eine Beobachtung sein, kein zerstörerisches Überschreiben.
Speichern Sie:
observed_atfür den aktuellen Lauffirst_seen, wenn der Datensatz erstmals auftauchtelast_seenfür die jüngste erfolgreiche Beobachtung- Einen Source-Hash für den Rohdatensatz
- Einen Change-Hash für die normalisierten Geschäftsfelder
Sinnvolle Änderungstypen sind unter anderem:
- Händler hinzugefügt
- Händler fehlt
- Name, Adresse, Telefon oder Website geändert
- Autorisierungsstatus geändert
- Service- oder Produktkategorie geändert
- Standort verschoben
- Quellseite fehlgeschlagen oder Layout verändert
Ein fehlender Datensatz sollte zunächst zu missing_pending_review werden. Bestätigen Sie die Entfernung erst nach wiederholtem Fehlen oder manueller Prüfung. Ein fehlgeschlagener Crawl, eine leere Antwort oder ein kaputter Selektor ist kein Beweis dafür, dass ein Händler geschlossen wurde.
Schritt 9: Google Places optional zur Validierung einbinden
Google Places Place Details kann einen Händlereintrag mit einer stabilen Place ID, einem Anzeigenamen, formatierter Adresse, Koordinaten, Telefonnummer, Website, Geschäftsstatus und Informationen zu einem verlegten Standort anreichern oder validieren — abhängig vom angeforderten Field Mask und SKU.
Nutzen Sie es als sekundäres Signal, nicht als Instanz dafür, ob ein Standort Teil des Händlerprogramms eines Herstellers ist. Die Herstellerquelle bleibt die maßgebliche Autorität für diese Mitgliedschaft. Speichern Sie den Anbieter der Validierung und den Zeitstempel und überschreiben Sie den Herstellerstatus nicht stillschweigend.
Schritt 10: Extraktionsqualität nach Muster und Quelle messen
Verfolgen Sie die Qualität auf Lauf-, Muster- und Domain-Ebene.
Metriken pro Lauf
- Registrierte Quell-URLs
- Angefragte URLs
- Erfolgreiche, leere und fehlgeschlagene URLs
- Extrahierte Datensätze
- Hinzugefügte, geänderte, fehlende und unveränderte Datensätze
- Vollständigkeit der Kernfelder
- Anzahl potenzieller Dubletten
- Vermutete Entfernungen, die auf Prüfung warten
- Vorkommnisse von Schema-Drift
Stichprobenprüfung
Vergleichen Sie bei jeder Musterfamilie und jedem größeren Lauf:
- 20–50 zufällig ausgewählte Datensätze mit den zugehörigen Quellseiten.
- Erwartete URL-Anzahl mit angefragter und erfolgreicher Anzahl.
- Fehlende Kernfelder nach Domain.
- Dublettencluster und Entitäten mit niedriger Vertrauensbewertung.
- Koordinaten-Ausreißer sowie Land-/Postleitzahl-Abweichungen.
- Eine Stichprobe scheinbar entfernter Datensätze erneut.
- Die verwendete Extraktor- oder Vorlagenversion.
Ziel ist nicht eine einzige globale „Genauigkeits“-Zahl. Entscheidend ist zu wissen, welche Muster und Quellen zuverlässig sind, welche Felder schwach sind und wo der Prüfaufwand hingehört.
Schritt 11: Änderungen in Geschäftsprozesse leiten
Unterschiedliche Änderungen gehören an unterschiedliche Stellen:
- Neuer Händler: An den Vertriebsinnendienst für CRM-Anlage, Zuständigkeit und Gebietszuordnung.
- Entfernter oder geschlossener Standort: Vor der Statusänderung in eine Prüfwarteschlange.
- Adress- oder Telefonänderung: Enrichment aktualisieren und offene Chancen oder Serviceabdeckung überprüfen.
- Änderung der Autorisierung: Channel Management und kundennahe Teams benachrichtigen.
- Abdeckungslücke: In Gebietsplanung und Partnerrekrutierung einspeisen.
- Wettbewerberexpansion: Vertriebsintelligenz und Regionalstrategie aktualisieren.
- Wiederholter Quellenfehler: In die Data-Operations-Warteschlange, nicht an das Sales-Team.
Jede Benachrichtigung sollte den kanonischen Händler, die Markenmitgliedschaft, den Änderungstyp, Vorher-/Nachher-Werte, Quell-URL, Beobachtungszeit und Vertrauens- oder Prüfstatus enthalten.
Ein 30/60/90-Tage-Rollout-Plan
Tage 1–30: Entwerfen und nachweisen
- Kanonisches Schema und kontrollierte Kategorien finalisieren.
- Quellenregister aufbauen.
- 20 repräsentative Websites klassifizieren.
- 3–5 Locator-Musterfamilien nachweisen.
- Regeln für Stichprobenprüfung und Laufmetriken festlegen.
- Einen ersten Händler-Stammdatensatz mit Quellennachweisen liefern.
Tage 31–60: Ausbauen und automatisieren
- Klassifizierung über das gesamte Portfolio ausweiten.
- Stabile öffentliche URL-Gruppen auf Batch-Extraktion umstellen.
- Zeitpläne, Job-Tracking, Retry-Logik und Fehler-Dashboards ergänzen.
- Das Mapping von Quelle zu kanonischer Entität einführen.
- Geprüfte Ergänzungen und Updates mit CRM-Workflows verbinden.
Tage 61–90: Änderungserkennung operationalisieren
- Änderungen mit eigenen Benachrichtigungen und Prüfwarten einführen.
- First-seen, Last-seen und Bestätigung von Entfernungen ergänzen.
- Optional Places-Validierung einsetzen, wo sie die Adresssicherheit verbessert.
- Service-Ziele auf Laufebene definieren.
- Muster- und Vorlagenleistung monatlich überprüfen.
- Für jede Quellenfamilie und jede geschäftliche Aktion einen Verantwortlichen benennen.
Häufige Fehlerquellen
Für jede Website einen eigenen Scraper bauen. Das erzeugt Hunderte Wartungspfade. Klassifizieren Sie Musterfamilien und trennen Sie wiederverwendbare Logik von Quellkonfiguration.
Nur nach Händlernamen deduplizieren. Namen sind uneinheitlich und werden oft mehrfach verwendet. Arbeiten Sie mit Adresse, Postleitzahl, Telefon, Koordinaten und Website-Belegen.
Rohwerte überschreiben. Wenn die Quellform verloren geht, lassen sich Normalisierungsfehler nicht mehr prüfen.
Leere Ausgabe als null Händler interpretieren. Leere Ergebnisse können auf einen fehlgeschlagenen Klick, eine Render-Änderung oder eine blockierte Anfrage hindeuten. Trennen Sie Crawl-Gesundheit von Geschäftsstatus.
Eine Entfernung nach einem einzigen Fehlschlag annehmen. Verlangen Sie wiederholtes Fehlen oder manuelle Bestätigung.
Einen Kartenanbieter als Händler-Instanz behandeln. Kartendaten können einen Ort validieren, aber nicht die Autorisierungsbeziehung eines Herstellers bestätigen.
Skalieren, bevor die Musterqualität gemessen wurde. Ein kleiner Extraktionsfehler wird zum großen Betriebsproblem, wenn er über Hunderte von Websites multipliziert wird.
FAQ
Kann ein einziges Schema über Hunderte unterschiedlicher Händler-Websites funktionieren?
Ja. Layouts unterscheiden sich, aber die semantischen Felder — Händlername, Adresse, Telefon, Website, Marke, Services, Quell-URL und Status — sind weitgehend gleich. Nutzen Sie unterschiedliche Extraktionsmuster, um ein kanonisches Schema zu befüllen.
Wie automatisiert man Locator-Seiten, die eine Postleitzahlensuche verlangen?
Behandeln Sie das Suchformular als eigene Musterfamilie. Definieren Sie ein Raster aus Eingabeorten, erfassen Sie die Ergebnis-IDs oder -URLs, deduplizieren Sie überlappende Suchradien und bewahren Sie die Eingabe auf, die jedes Ergebnis erzeugt hat, um Fehler leichter zu debuggen.
Wie oft sollten Händlerstandorte aktualisiert werden?
Richten Sie den Takt nach geschäftlichem Nutzen und Quellverhalten. Hochwertige Wettbewerbs- oder Service-Abdeckungsquellen können wöchentlich laufen; langsamere Herstellerverzeichnisse eher monatlich. Lauffehler sollten unabhängig vom Änderungsrhythmus operativ geprüft werden.
Wie unterscheidet das System einen entfernten Händler von einem fehlgeschlagenen Scrape?
Verfolgen Sie Quellenstatus und Datensatzpräsenz getrennt. Ein fehlgeschlagener oder leerer Crawl ändert den Last-seen-Status des Händlers nicht. Nur erfolgreiche Läufe können Abwesenheit als Hinweis liefern, und eine Entfernung sollte Wiederholung oder Prüfung erfordern.
Soll Google Places die Adresse und den Geschäftsstatus der Website ersetzen?
Nein. Nutzen Sie Places als Anreicherung oder Validierung, speichern Sie Zeitstempel und Anbieter und behalten Sie den Hersteller-Locator als maßgebliche Quelle für die Mitgliedschaft im Händlerprogramm.
Automatisierte Händlerverfolgung funktioniert, wenn sie als Datenprodukt verstanden wird: ein gesteuertes Quellenregister, wiederverwendbare Musterfamilien, bewahrte Belege, vorsichtige Entitätsauflösung und geschäftlich verantwortete Änderungsprozesse. Diese Architektur kann von 20 Pilotseiten auf Hunderte wachsen, ohne dass jede Layout-Änderung zu einem Notfall-Redesign wird.
Mehr erfahren
