Datenquellen zusammenführen: So wird aus Daten ein digitales Produkt

Mehrere Datenquellen ergeben nicht automatisch ein brauchbares digitales Produkt. APIs, CSV-Dateien und offene Daten beschreiben dieselben Dinge oft unterschiedlich, enthalten Lücken oder widersprechen sich. Wer sie einfach zusammenführt, übernimmt diese Unterschiede in Suche, Karten und redaktionelle Inhalte – und kann später kaum erklären, woher eine Angabe stammt.

Der entscheidende Schritt ist deshalb nicht der Import, sondern ein verbindliches Modell dafür, was als Datensatz gilt, wie Quellen abgeglichen werden und welche Angabe im Konfliktfall verwendet wird. Dieser Beitrag richtet sich an Geschäftsführung, Produktverantwortliche und technische Leitung, die aus verteilten Daten eine Website, einen Katalog oder ein anderes digitales Produkt entwickeln. Er zeigt, welche Entscheidungen vor der Umsetzung nötig sind und wie sich Herkunft, Qualität und Aktualität kontrollierbar halten lassen.

Kurz gesagt

Führen Sie Datenquellen nicht direkt in der Oberfläche zusammen, sondern über ein gemeinsames fachliches Datenmodell. Legen Sie fest, wie Einträge identifiziert, Dubletten erkannt, Konflikte behandelt und Änderungen übernommen werden. Speichern Sie die Herkunft und den Stand jeder relevanten Angabe mit. Erst dann sollten Sie entscheiden, welche Daten veröffentlicht, gesucht, gefiltert oder ausgeschlossen werden.

Ausgangslage

Organisationen verfügen häufig über mehrere Datenbestände zum gleichen Themenfeld: eine API, eine regelmäßig gelieferte CSV, öffentliche Datensätze und gegebenenfalls redaktionell gepflegte Informationen. Jede Quelle wurde für einen anderen Zweck erstellt. Entsprechend unterscheiden sich Feldnamen, Formate, Aktualisierungsrhythmen und Definitionen.

Ein Datensatz über einen Ort kann zum Beispiel in einer Quelle eine geografische Position, in einer anderen einen Namen und in einer dritten eine Beschreibung enthalten. Auch wenn die Einträge dasselbe reale Objekt meinen, ist ihre Gleichheit nicht automatisch erkennbar. Namen können abweichen, Koordinaten ungenau sein und Kennungen fehlen.

Dazu kommt, dass Quellen nicht immer synchron aktualisiert werden. Eine Information kann in einer Quelle neu, in einer anderen aber veraltet sein. Bei einem Zusammenführen ohne klare Regeln entstehen dann doppelte Einträge, widersprüchliche Angaben oder unbeabsichtigte Überschreibungen.

Das Problem zeigt sich nicht nur in der Datenbank. Es wirkt sich auf die Produktlogik aus: Welche Treffer erscheinen in der Suche? Welche Filter sind zuverlässig? Welche Seiten sollen indexiert werden? Können Nutzende erkennen, woher eine Angabe stammt? Eine Datenpipeline ist daher zugleich Teil der Produkt- und Content-Architektur.

Entscheidungskriterien

Bevor Sie Importwege oder Technologien auswählen, klären Sie die folgenden Punkte. Sie bestimmen, ob eine einfache Datenaufbereitung reicht oder ob Sie ein dauerhaft betriebenes Datenprodukt benötigen.

1. Was ist das gemeinsame fachliche Objekt?

Definieren Sie zuerst, was ein Eintrag im Produkt bedeutet: ein Ort, ein Angebot, ein Unternehmen oder eine andere Entität. Legen Sie fest, welche Eigenschaften dazugehören und welche Beziehungen wichtig sind.

Trennen Sie dabei die Identität eines Objekts von seinen beschreibenden Angaben. Ein Name kann sich ändern; das Objekt soll dadurch nicht zu einem neuen Datensatz werden. Ein gemeinsames Datenmodell macht außerdem sichtbar, welche Felder verpflichtend, optional oder nur für bestimmte Objekttypen relevant sind.

2. Wie werden gleiche Objekte erkannt?

Prüfen Sie, ob die Quellen stabile Kennungen enthalten und ob diese Kennungen quellenübergreifend gelten. Wenn nicht, brauchen Sie Abgleichregeln, die mehrere Merkmale berücksichtigen können. Dazu zählen etwa Namen, Adressen oder geografische Nähe – sofern diese Merkmale für den jeweiligen Datentyp geeignet sind.

Unterscheiden Sie automatische Zuordnung von unsicheren Treffern. Eine falsche Zusammenführung kann schwerer zu entdecken sein als ein fehlender Abgleich: Informationen über zwei verschiedene Objekte landen dann unter einem Eintrag. Legen Sie deshalb fest, wann ein Treffer automatisch übernommen werden darf und wann eine Prüfung nötig ist.

3. Welche Quelle ist für welche Angabe maßgeblich?

Eine Quelle muss nicht für alle Felder die beste sein. Eine kann die Position liefern, eine andere Öffnungszeiten oder eine Beschreibung. Definieren Sie die Vorrangregeln auf Ebene einzelner Felder oder klar abgegrenzter Datenbereiche – nicht pauschal für den gesamten Datensatz.

Regeln Sie auch Konfliktfälle. Was passiert, wenn zwei Quellen verschiedene Werte liefern? Wird ein Wert bevorzugt, bleibt die Angabe leer oder wird der Fall zur Prüfung markiert? Ohne diese Entscheidung wird die Reihenfolge des Imports schnell zur unbeabsichtigten Geschäftsregel.

4. Wie bleibt die Herkunft nachvollziehbar?

Für wichtige Angaben sollte sich feststellen lassen, aus welcher Quelle sie stammen und auf welchem Stand sie sind. Das ist nicht nur für Transparenz gegenüber Nutzenden hilfreich. Es ermöglicht auch, fehlerhafte Einträge gezielt zu prüfen und Änderungen einer Quelle von redaktionellen Anpassungen zu unterscheiden.

Prüfen Sie, ob die Herkunft je Datensatz ausreicht oder ob sie für einzelne Felder dokumentiert werden muss. Wenn Werte aus mehreren Quellen kombiniert werden, ist eine reine Quellenangabe auf Seitenebene oft zu grob.

5. Wie oft ändern sich die Daten – und wie werden Änderungen verarbeitet?

Klären Sie, wie häufig die Quellen aktualisiert werden, wie Sie neue und veränderte Einträge erkennen und was mit Datensätzen passiert, die in einem Import fehlen. Ein fehlender Eintrag kann bedeuten, dass er gelöscht wurde, der Export unvollständig ist oder die Quelle nur einen Ausschnitt liefert.

Unterscheiden Sie deshalb zwischen Hinzufügen, Aktualisieren und Entfernen. Legen Sie fest, ob ein Import vollständig, inkrementell oder nur ergänzend ist. Der Update-Prozess muss wiederholbar sein und Fehler erkennbar machen, statt den vorherigen Datenstand stillschweigend zu ersetzen.

6. Welche Qualität braucht das Produkt?

Die erforderliche Qualität hängt davon ab, was Nutzende mit den Daten tun. Für eine Karte können fehlende oder ungenaue Koordinaten besonders problematisch sein. Für Filter und Vergleichsfunktionen sind konsistente Kategorien und Werte entscheidend. Für redaktionelle Landingpages zählen außerdem ausreichende Inhalte und ein klarer Veröffentlichungsstatus.

Definieren Sie Mindestanforderungen pro Verwendung. Ein Eintrag kann für eine Suche sinnvoll sein, aber für eine eigene Detailseite zu dünn. Datenqualität ist damit keine abstrakte Gesamtbewertung, sondern eine Entscheidung darüber, wofür ein Datensatz geeignet ist.

7. Was darf veröffentlicht werden?

Importierte Daten sollten nicht automatisch vollständig öffentlich werden. Legen Sie fest, welche Datensätze und Felder veröffentlichungsfähig sind, welche geprüft werden müssen und welche ausgeschlossen bleiben. Berücksichtigen Sie dabei auch, ob die Daten für eine öffentliche Detailseite genug eigenständigen Nutzen bieten.

Prüfen Sie außerdem die Nutzungsbedingungen der jeweiligen Quellen für den geplanten Zweck. Die konkrete Zulässigkeit hängt von Quelle und Verwendung ab und sollte im Einzelfall geprüft werden.

Vorgehen: vom Quelleninventar zum Produkt

Quellen erfassen

Dokumentieren Sie für jede Quelle Format, Verantwortlichkeit, verfügbare Felder, Aktualisierungsrhythmus und erkennbare Einschränkungen. Halten Sie fest, ob es sich um einen vollständigen Bestand, einen Ausschnitt oder eine Ergänzung handelt. Klären Sie auch, wie sich ein fehlerhafter oder verspäteter Import bemerkbar macht.

Gemeinsames Datenmodell festlegen

Ordnen Sie die Quellfelder den Eigenschaften Ihres fachlichen Modells zu. Behandeln Sie fehlende Werte ausdrücklich: Ein leeres Feld ist nicht dasselbe wie ein unbekannter Wert, ein nicht zutreffendes Merkmal oder eine bewusst entfernte Angabe.

Trennen Sie außerdem Quelldaten von abgeleiteten Werten. So bleibt nachvollziehbar, welche Informationen übernommen und welche durch Regeln berechnet oder normalisiert wurden.

Import und Abgleich kontrollierbar machen

Bauen Sie die Verarbeitung in nachvollziehbare Schritte auf: Einlesen, Format prüfen, Werte normalisieren, Datensätze abgleichen, Konflikte behandeln und Ergebnisse freigeben. Ein Fehler in einem Schritt sollte nicht unbemerkt die gesamte Datenbasis verändern.

Bei unsicheren Zuordnungen oder ungewöhnlichen Änderungen kann eine Prüfstrecke sinnvoll sein. Entscheidend ist, dass automatische Verarbeitung nicht mit automatischer Veröffentlichung gleichgesetzt wird.

Nutzung und Veröffentlichung getrennt steuern

Erst nach dem Abgleich sollten Sie festlegen, wie das Produkt die Daten verwendet: für Suche, Karten, Filter, Detailseiten oder redaktionelle Inhalte. Diese Nutzungen können unterschiedliche Mindestanforderungen haben. Eine Seite kann beispielsweise aus der Suche ausgeschlossen bleiben, wenn die verfügbaren Angaben für eine eigenständige Detailseite nicht ausreichen.

Aktualisierungen nachweisen

Protokollieren Sie, wann eine Quelle verarbeitet wurde und welche Änderungen daraus entstanden sind. Prüfen Sie nach einem Lauf nicht nur, ob der Import technisch erfolgreich war, sondern auch, ob Datensatzanzahl, Pflichtfelder und Verteilungen plausibel sind. So wird aus einem wiederkehrenden Import ein kontrollierter Prozess.

Praxisbeispiel

Bei erlebe-nrw werden rund 8.300 Ausflugsziele aus OpenStreetMap, Wikidata, Wikivoyage und Data Hub Tourismus NRW verarbeitet. Die Daten laufen durch eine nummerierte Python-Pipeline über SQLite und JSONL in eine Astro-Site. Das Beispiel zeigt, dass mehrere Quellen eine eigene Verarbeitungsschicht und ein klares Veröffentlichungsmodell benötigen.

Die Slugs sind eingefroren, damit sich URLs nicht bei jeder Verarbeitung ändern. Quelle und Stand werden bei jeder Angabe ausgewiesen. Für die Kartendarstellung kommen MapLibre und eine selbst gehostete PMTiles-Datei zum Einsatz; dünne Seiten werden per noindex ausgeschlossen. Damit sind Abgleich, Herkunft, URL-Stabilität und die Frage, welche Datensätze eine eigene Seite tragen, Teil derselben Produktentscheidung.

Typische Fehler

• Quellen direkt in der Oberfläche zusammenführen. Dadurch werden Abgleichregeln und Konflikte in Darstellungslogik versteckt. Änderungen sind später schwerer kontrollierbar.
• Eine Quelle pauschal als maßgeblich festlegen. Unterschiedliche Quellen können für unterschiedliche Felder geeignet sein.
• Dubletten nur anhand des Namens erkennen. Schreibvarianten, gleichnamige Objekte und fehlende Kennungen erfordern einen fachlich passenden Abgleich.
• Fehlende Werte ungeprüft überschreiben. Ein leeres Feld in einem Import bedeutet nicht zwingend, dass ein zuvor bekannter Wert gelöscht werden soll.
• Import und Veröffentlichung gleichsetzen. Technisch eingelesene Daten sind nicht automatisch vollständig, aktuell oder für jede Produktfunktion geeignet.
• Herkunft nur einmal pro Seite nennen. Wenn Angaben aus unterschiedlichen Quellen stammen, muss die Herkunft ausreichend genau zugeordnet sein.
• Aktualisierung nur als Zeitplan behandeln. Ein regelmäßig gestarteter Prozess braucht zusätzlich Prüfungen, Fehlerbehandlung und Regeln für fehlende Einträge.
• Jeden Datensatz als eigene Landingpage veröffentlichen. Zu dünne oder wenig hilfreiche Seiten können die Qualität des Produkts und seiner Sichtbarkeit beeinträchtigen.

Empfehlung

Wenn Quellen stabile, gemeinsame Kennungen und ähnliche Datenmodelle bieten, können Sie mit einer überschaubaren Import- und Abgleichlogik starten. Dokumentieren Sie trotzdem Vorrang, Herkunft und Aktualisierung.

Wenn Quellen unterschiedliche Felder oder Aktualisierungsrhythmen haben, führen Sie sie über ein gemeinsames fachliches Modell zusammen. Trennen Sie Rohdaten, normalisierte Daten und veröffentlichte Inhalte.

Wenn Dubletten nicht sicher automatisch erkannt werden, legen Sie Schwellen für automatische Zuordnung und manuelle Prüfung fest. Veröffentlichen Sie unsichere Treffer nicht stillschweigend als bestätigte Datensätze.

Wenn das Produkt Suche, Karten, Filter, redaktionelle Seiten und regelmäßige Aktualisierungen verbindet, behandeln Sie die Datenpipeline als Teil der Produktarchitektur. Ein einfacher Dateiimport reicht dann meist nicht als dauerhaftes Betriebsmodell.

Wenn Herkunft, Konflikte oder Änderungen später erklärt werden müssen, speichern Sie diese Informationen von Beginn an strukturiert. Nachträgliche Rekonstruktion ist oft schwieriger als eine nachvollziehbare Verarbeitung bei jedem Lauf.

Checkliste

• Ist klar definiert, welches fachliche Objekt ein Datensatz beschreibt?
• Sind die Felder und Kennungen aller Quellen dokumentiert?
• Gibt es Regeln für Normalisierung und Dublettenerkennung?
• Ist festgelegt, welche Quelle für welche Angabe maßgeblich ist?
• Werden Herkunft und Stand relevanter Daten gespeichert?
• Ist geregelt, wie neue, geänderte und fehlende Einträge verarbeitet werden?
• Gibt es Prüfungen für unvollständige oder ungewöhnliche Importe?
• Sind Import, Freigabe und Veröffentlichung getrennte Schritte?
• Ist pro Produktfunktion definiert, welche Datenqualität erforderlich ist?
• Sind Nutzung und Darstellung der Quelldaten im Einzelfall geprüft?

Häufige Fragen

Reicht eine CSV-Datei als Datenpipeline?

Für einen einmaligen oder überschaubaren Import kann eine CSV-Datei genügen. Wenn sie regelmäßig aktualisiert wird, mehrere Quellen abgeglichen werden oder Änderungen nachvollziehbar sein müssen, brauchen Sie zusätzlich Regeln für Validierung, Zuordnung und Aktualisierung.

Sollten Daten vor dem Import bereinigt werden?

Die Verarbeitung sollte Werte normalisieren und ungültige oder unerwartete Inhalte erkennen. Bewahren Sie dabei die Herkunft und – wenn relevant – die ursprünglichen Quelldaten auf, damit sich Änderungen nachvollziehen lassen.

Wann ist eine manuelle Prüfung notwendig?

Wenn eine automatische Zuordnung unsicher ist, Konflikte Auswirkungen auf Nutzende haben oder ein Import ungewöhnliche Änderungen enthält. Definieren Sie dafür klare Prüffälle, statt alle Datensätze manuell zu kontrollieren.

Wie hängen Datenzusammenführung und SEO zusammen?

Das Datenmodell bestimmt, welche Seiten und Filter sich verlässlich erzeugen lassen. Legen Sie deshalb fest, welche Datensätze ausreichend eigenständigen Nutzen für eine indexierbare Seite bieten und welche nur innerhalb von Suche oder Karte verwendet werden.

Weiterführend

• Open Data als Basis digitaler Produkte: Möglichkeiten und Grenzen
• Content-Modell entwickeln: Von Seiten zu strukturierten Inhalten
• Sichtbarkeit beginnt in der Contentstruktur
• Datenquellen und Datenprodukte bei erlebe-nrw