Sie scrapen 20.000 Produktbewertungen, um herauszufinden, welche Beschwerden am häufigsten vorkommen. Geplant waren Bewertungen und Text. Beim Öffnen der CSV-Datei finden Sie aber auch die Namen der Rezensenten, Links zu ihren Profilseiten und in einigen hundert Bewertungen eine E-Mail-Adresse oder Telefonnummer, die jemand in den Text geschrieben hat. Nichts davon hilft der Analyse, doch jetzt liegt es auf Ihrem Laptop und im Backup von letzter Nacht.
Dieser Beitrag erklärt, was in einem gescrapten Datensatz als personenbezogene Daten gilt (im Englischen oft PII, „personally identifiable information“: alles, was auf eine bestimmte Person verweist), warum „das war doch öffentlich“ die Frage nicht klärt und wie Sie damit umgehen: weniger erheben, maskieren, was durchrutscht, benötigte Schlüssel pseudonymisieren und nach festem Zeitplan löschen. Außerdem zeigt er, warum ein Hash einer E-Mail-Adresse schwächer ist, als er aussieht, liefert ein getestetes Python-Skript zum Maskieren und verweist auf die DSGVO, das türkische KVKK aus Türkiye und den kalifornischen CCPA.
Was sind personenbezogene Daten in einem gescrapten Datensatz?
Die Definition in Artikel 4 Nummer 1 DSGVO ist weit: alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen, direkt oder indirekt, etwa über einen Namen, eine Kennnummer, Standortdaten oder eine Online-Kennung. Das Gesetz Nr. 6698 über den Schutz personenbezogener Daten (KVKK) in Türkiye verwendet in seinem Artikel 3 im Kern dieselbe Formulierung.
In einem Scraping-Projekt tauchen personenbezogene Daten an drei Stellen auf:
- Felder, die Sie bewusst auswählen. Autorennamen, Benutzernamen, Profil-URLs, Avatare, Berufsbezeichnungen auf Unternehmensseiten, Verkäufernamen auf Marktplätzen.
- Freitext. Bewertungen, Kommentare, Forenbeiträge und Anzeigentexte, in die Menschen ihre E-Mail-Adresse, Telefonnummer, Straße oder ihr Kennzeichen schreiben.
- Ihre eigenen Logs. Request-Logs und Fehler-Dumps speichern oft das komplette HTML einer Seite und damit alles oben Genannte.
Schwerer zu erkennen sind Felder, die für sich allein niemanden identifizieren. Ein Benutzername, eine Stadt, ein Datum und ein seltenes Produkt können zusammen auf eine einzige Person verweisen. Auch ein Datensatz ohne „Name“-Spalte kann also personenbezogene Daten enthalten.
Heißt „öffentlich“ frei nutzbar?
Im Allgemeinen nicht, und die Antwort hängt vom jeweiligen Gesetz ab.
- DSGVO. Für öffentlich zugängliche personenbezogene Daten gibt es keine Ausnahme. Auch gescrapte Daten brauchen eine Rechtsgrundlage und müssen die Grundsätze aus Artikel 5 einhalten. Artikel 14 regelt die Informationspflicht gegenüber Personen, deren Daten nicht bei ihnen selbst erhoben wurden.
- KVKK. Artikel 5 nennt die Bedingungen für eine Verarbeitung ohne ausdrückliche Einwilligung. Eine davon: Die betroffene Person hat die Daten selbst öffentlich gemacht. Ein Freibrief ist das nicht, denn die Grundsätze aus Artikel 4, etwa festgelegte Zwecke und Verhältnismäßigkeit, gelten weiter.
- CCPA. Die kalifornische Definition von „personal information“ in Civil Code 1798.140 nennt IP- und E-Mail-Adressen als Kennungen und nimmt dann „publicly available“ (öffentlich verfügbare) Informationen aus. Dieser Begriff ist eng gefasst, zum Beispiel Behördenregister oder Informationen, die die Verbraucherin oder der Verbraucher der Allgemeinheit zugänglich gemacht hat.
Die weitere Rechtsfrage, einschließlich Nutzungsbedingungen und Urheberrecht, behandelt der Beitrag Ist Web Scraping legal?.
So gehen Sie in einer Scraping-Pipeline mit personenbezogenen Daten um
Artikel 25 DSGVO verlangt „Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen“: Schutzmaßnahmen gehören in den Entwurf, nicht in eine Aufräumaktion am Ende. Für einen Scraper heißt das:
- Den Zweck aufschreiben. „Die häufigsten Lieferbeschwerden pro Produkt finden“ ist ein Zweck. „Bewertungen sammeln, falls sie mal nützlich sind“ ist keiner.
- Die Felder auflisten, die dem Zweck dienen. Im Beispiel oben: Produkt, Datum, Bewertung, Text. Autorenname und Profil-URL stehen nicht auf der Liste.
- Schon bei der Erhebung filtern. Wählen Sie nicht aus, was Sie nicht verwenden.
- Freitext beim Einlesen maskieren. Ersetzen Sie E-Mail-Adressen und Telefonnummern durch Platzhalter, bevor die Zeile irgendwo gespeichert wird.
- Benötigte Schlüssel pseudonymisieren. Wenn Sie wiederkehrende Rezensenten zählen müssen, speichern Sie statt der Autoren-ID einen Hash mit geheimem Schlüssel.
- Den Schlüssel getrennt halten. Der Pseudonymisierungsschlüssel liegt in einem Secrets Manager oder einer Umgebungsvariable, nie im Datensatz oder im selben Repository.
- Den Speicher absichern. Verschlüsseln Sie ruhende Daten, beschränken Sie den Zugriff auf die Projektbeteiligten und halten Sie Roh-Dumps von gemeinsamen Laufwerken fern.
- Nach Zeitplan löschen. Roh-HTML und unmaskierte Dateien bekommen eine kurze Speicherfrist, der bereinigte Datensatz eine eigene, an den Zweck gebundene.
- Dokumentieren, was Sie getan haben. Zweck, Felder, Speicherfrist und Rechtsgrundlage in einer kurzen Notiz.
Maskierung, Pseudonymisierung, Anonymisierung: der Unterschied
Diese Begriffe sind nicht austauschbar, und der Unterschied entscheidet, ob das Gesetz für Ihre Daten noch gilt.
| Technik | Was sie tut | Ist die Person re-identifizierbar? | Noch personenbezogene Daten? |
|---|---|---|---|
| Löschung bei der Erhebung | Das Feld wird nie gespeichert | Nein, die Daten existieren nicht | Nein, für dieses Feld |
| Maskierung | Ersetzt einen Wert durch einen Platzhalter wie [EMAIL] | Nicht über den maskierten Wert, eventuell über andere Felder | Hängt davon ab, was in der Zeile bleibt |
| Pseudonymisierung | Ersetzt eine Kennung durch ein Token; die Zuordnung liegt in getrennten, geschützten Informationen | Ja, mit Schlüssel oder Zuordnungstabelle | Ja (Erwägungsgrund 26 DSGVO) |
| Anonymisierung | Entfernt oder verallgemeinert Daten, bis niemand mit Mitteln, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, identifiziert werden kann | Nein | Nein |
| Verschlüsselung | Macht Daten ohne Schlüssel unlesbar | Ja, für alle mit dem Schlüssel | Ja |
| Aggregation | Behält nur Anzahlen, Durchschnitte oder Gruppen | Nur bei sehr kleinen Gruppen | Meist nicht, wenn die Gruppen groß genug sind |
Was die DSGVO zur Pseudonymisierung sagt
Artikel 4 Nummer 5 definiert Pseudonymisierung als eine Verarbeitung, bei der die personenbezogenen Daten „ohne Hinzuziehung zusätzlicher Informationen nicht mehr einer spezifischen betroffenen Person zugeordnet werden können“, sofern diese Informationen gesondert aufbewahrt und geschützt werden. Erwägungsgrund 26 zieht dann die Grenze: Pseudonymisierte Daten, die durch Heranziehung zusätzlicher Informationen einer Person zugeordnet werden könnten, „sollten als Informationen über eine identifizierbare natürliche Person betrachtet werden“. Anonyme Informationen fallen nicht unter die Verordnung.
Um zu beurteilen, ob jemand identifizierbar ist, sollen nach Erwägungsgrund 26 alle Mittel berücksichtigt werden, die nach allgemeinem Ermessen wahrscheinlich genutzt werden, einschließlich Kosten, Zeitaufwand und verfügbarer Technologie. Deshalb ist es so schwer, gescrapten Text zu anonymisieren: Den Namen zu entfernen hilft wenig, wenn die Bewertung weiterhin Ort, Datum und Automodell nennt.
Der Europäische Datenschutzausschuss (EDSA) hat im Januar 2025 die Leitlinien 01/2025 zur Pseudonymisierung angenommen. Der Vorschlag „Digital Omnibus“ der Europäischen Kommission vom November 2025 würde ändern, wie die Definition personenbezogener Daten auf pseudonymisierte Daten angewendet wird; laut der Legislative-Train-Seite des Europäischen Parlaments war er bei Erscheinen dieses Beitrags noch nicht angenommen. Bis eine Änderung in Kraft ist, behandeln Sie pseudonymisierte Daten als personenbezogene Daten.
Das KVKK definiert Pseudonymisierung nicht. Artikel 3 definiert Anonymisierung als den Zustand, in dem Daten „selbst durch Abgleich mit anderen Daten“ keiner Person mehr zugeordnet werden können, und Artikel 7 verlangt Löschung, Vernichtung oder Anonymisierung, sobald der Grund für die Verarbeitung entfallen ist.
Warum ein E-Mail-Hash keine Anonymisierung ist
Eine beliebte Abkürzung ist, sha256(email) auszuführen und die Spalte für anonym zu erklären. Das ist sie aus zwei Gründen nicht.
Erstens ist der Hash jedes Mal derselbe. Wer eine Liste von E-Mail-Adressen besitzt, etwa aus einem Datenleck, kann jede Adresse darauf hashen und nach Treffern suchen; in unserem Test fand eine Rateliste mit zwei Einträgen die „anonyme“ Adresse sofort. Dieselben geleakten Listen speisen Credential Stuffing, ein weiterer Grund, keine Roh-E-Mails aufzubewahren, die Sie nicht brauchen.
Zweitens haben manche Kennungen einen kleinen Suchraum. Eine nationale Telefonnummer hat eine begrenzte Anzahl von Ziffern, daher lässt sich jede mögliche Nummer in diesem Bereich mit gewöhnlicher Hardware hashen, und das passende Token verrät die Nummer.
Was besser funktioniert:
- Ein Hash mit geheimem Schlüssel (HMAC), der getrennt von den Daten gespeichert wird. Das Ergebnis sind pseudonymisierte, keine anonymen Daten.
- Ein zufälliges Token und eine Zuordnungstabelle, getrennt gespeichert, wenn Sie die Zuordnung umkehren müssen.
- Gar keine Kennung, wenn Sie nur Anzahlen brauchen. Aggregieren Sie zuerst und verwerfen Sie den Schlüssel.
Python-Beispiel: E-Mail-Adressen und Telefonnummern maskieren
Das Skript liest eine CSV-Datei mit gescrapten Bewertungen und schreibt eine bereinigte Kopie: Es entfernt nicht benötigte Spalten, maskiert E-Mail-Adressen und Telefonnummern in der Freitextspalte und ersetzt die Autoren-ID durch einen Hash mit geheimem Schlüssel, sodass sich wiederkehrende Rezensenten weiterhin zählen lassen. Nur Standardbibliothek, getestet mit Python 3.13.
import csv
import hashlib
import hmac
import os
import re
# Spalten, die wir für die Analyse nie brauchen: beim Einlesen verwerfen
DROP_COLUMNS = {"author_name", "profile_url"}
# Spalte, die wir nur als Pseudonym behalten, um wiederkehrende Rezensenten zu zählen
PSEUDONYM_COLUMN = "author_id"
# Freitextspalten, in die Menschen Kontaktdaten schreiben; strukturierte Spalten bleiben unberührt
TEXT_COLUMNS = {"text"}
EMAIL_RE = re.compile(r"[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}")
# Telefonähnliche Folgen: optional + oder (, dann 9-15 Ziffern mit Leerzeichen, Punkten, Bindestrichen oder Klammern dazwischen
PHONE_RE = re.compile(r"(?<!\w)[+(]?\d(?:[\s.()-]*\d){8,14}(?!\w)")
# Der Schlüssel liegt außerhalb des Datensatzes (Umgebungsvariable, Secrets Manager), nie in derselben Datei
SECRET = os.environ.get("PSEUDONYM_KEY", "").encode()
def mask_text(text: str) -> str:
text = EMAIL_RE.sub("[EMAIL]", text)
return PHONE_RE.sub("[PHONE]", text)
def pseudonym(value: str) -> str:
# Hash mit geheimem Schlüssel (HMAC-SHA256): Ohne den Schlüssel kann niemand die Zuordnung durch Hashen von Vermutungen nachbauen
return hmac.new(SECRET, value.encode(), hashlib.sha256).hexdigest()[:16]
def clean_row(row: dict) -> dict:
out = {}
for col, value in row.items():
if col in DROP_COLUMNS:
continue
if col == PSEUDONYM_COLUMN:
out[col] = pseudonym(value)
elif col in TEXT_COLUMNS:
out[col] = mask_text(value)
else:
out[col] = value
return out
def main(src: str, dst: str) -> None:
if not SECRET:
raise SystemExit("Set PSEUDONYM_KEY first")
with open(src, newline="", encoding="utf-8") as f_in, \
open(dst, "w", newline="", encoding="utf-8") as f_out:
reader = csv.DictReader(f_in)
fields = [c for c in reader.fieldnames if c not in DROP_COLUMNS]
writer = csv.DictWriter(f_out, fieldnames=fields)
writer.writeheader()
for row in reader:
writer.writerow(clean_row(row))
if __name__ == "__main__":
main("reviews_raw.csv", "reviews_clean.csv")Setzen Sie den Schlüssel in der Umgebung (export PSEUDONYM_KEY=... unter Linux und macOS, $env:PSEUDONYM_KEY="..." in PowerShell) und starten Sie dann python mask_pii.py. In unserer erfundenen Stichprobe wurde aus „Rufen Sie mich unter +90 532 000 00 00 oder (0212) 000-0000 an“ der Satz „Rufen Sie mich unter [PHONE] oder [PHONE] an“, E-Mail-Adressen wurden zu [EMAIL], und die zwei Bewertungen eines Autors erhielten dasselbe Token.
Kennen Sie die Grenzen:
- Reguläre Ausdrücke treffen zu viel. In unseren Tests maskierte das Telefonmuster auch eine 13-stellige ISBN, eine 10-stellige Bestellnummer und ein Datum, das direkt mit einer Uhrzeit geschrieben war. Deshalb bearbeitet das Skript nur Freitextspalten.
- Reguläre Ausdrücke treffen zu wenig. Ausgeschriebene Zahlen, „name at domain dot com“, IBANs, Adressen und Namen im Text werden nicht erkannt; dafür brauchen Sie ein Modell zur Eigennamenerkennung (NER) oder eine manuelle Prüfung einer Stichprobe.
- Maskierung ist keine Anonymisierung. Die Zeile behält Text, Datum und Produkt; prüfen Sie, ob schon diese auf eine Person verweisen können.
Führen Sie diesen Schritt dort aus, wo Zeilen zum ersten Mal geschrieben werden, nicht als späteren Job. Der Leitfaden zur Datenbereinigung mit pandas zeigt, wo er in einen vollständigen Bereinigungsdurchlauf passt, und Gescrapte Daten als CSV, JSON und in SQLite speichern behandelt die Speicherung.
Speichersicherheit, Zugriff und Speicherbegrenzung
Artikel 32 DSGVO verlangt ein „dem Risiko angemessenes Schutzniveau“ und nennt Pseudonymisierung und Verschlüsselung, belastbare Systeme, die Wiederherstellung von Daten nach einem Zwischenfall und regelmäßige Überprüfungen. Artikel 12 KVKK legt dem Verantwortlichen eine ähnliche Pflicht auf. Für einen Scraper heißt das:
- Verschlüsselung ruhender Daten für Festplatten, Buckets und Datenbanken mit Roh-Scrapes.
- Getrennte Zonen. Roh-HTML und unmaskierte Zeilen an einem Ort mit beschränktem Zugriff, der bereinigte Datensatz dort, wo Analysten arbeiten.
- Minimaler Zugriff. Nur die Personen und Dienstkonten, die die Rohzone brauchen, dürfen sie lesen.
- Speicherfristen als Code. Ein geplanter Löschjob ist besser als ein Richtliniendokument.
- Backups zählen mit. Eine Datei, die in einem ein Jahr alten Backup weiterlebt, ist nicht gelöscht. Stimmen Sie beide Speicherfristen aufeinander ab.
Unsere Seite zur Datensicherheit beschreibt Proxys in der Sicherheitsarbeit; ein Proxy ändert die IP-Adresse, von der eine Anfrage kommt, nicht das, was Sie speichern.
Wo das Thema auftaucht
- Preis- und Bestandsüberwachung. Produktseiten enthalten selten personenbezogene Daten, Verkäufernamen auf Marktplätzen aber schon. Siehe Preisüberwachung der Konkurrenz.
- Bewertungs- und Sentimentanalyse. Autorenfelder und Kontaktdaten im Text. Siehe Marktforschung.
- Forschung und Data Mining. Forenbeiträge sind voller personenbezogener Daten; aggregieren Sie früh. Siehe Data Mining.
- Große Crawls. Ein allgemeiner Webcrawler erfasst ganze Seiten, sodass alles darauf in Ihrem Speicher landet, wenn Sie nicht filtern.
- Lead-Listen. Kontaktdaten von Einzelpersonen für Akquise zu sammeln, ist hier der Fall mit dem höchsten Risiko; prüfen Sie zuerst Rechtslage und Nutzungsbedingungen der Website.
Häufige Fehler
- Sicherheitshalber die ganze Seite scrapen und den Roh-Dump unbegrenzt im Speicher liegen lassen.
- Einen SHA-256-Hash einer E-Mail-Adresse als „anonymisiert“ bezeichnen.
- Den Pseudonymisierungsschlüssel im selben Repository oder Bucket wie die Daten speichern.
- Die Analysetabelle maskieren, aber nicht die Logs, Fehler-Dumps oder das Debug-HTML.
robots.txtund Nutzungsbedingungen ignorieren, weil die Daten „ohnehin öffentlich“ sind. robots.txt sagt, was der Betreiber Crawlern abzurufen erlaubt.- Daten nach Projektende behalten, weil sich niemand für die Löschung verantwortlich fühlt.
- Annehmen, dass die Regeln des eigenen Landes gelten, obwohl die Personen im Datensatz anderswo leben.
Entscheidungshilfe
| Bedarf | Empfehlung |
|---|---|
| Analyse von Preisen, Bestand oder Produktdaten | Verkäufer- und Nutzerfelder gar nicht erheben |
| Textanalyse von Bewertungen oder Kommentaren | Autorenfelder verwerfen, Kontaktdaten im Text beim Einlesen maskieren |
| Wiederkehrende Autoren zählen oder ein Konto über die Zeit verfolgen | Hash mit geheimem Schlüssel (HMAC) der ID, Schlüssel getrennt gespeichert |
| Datensatz mit einem Kunden teilen oder veröffentlichen | Aggregieren, dann kleine Gruppen und seltene Kombinationen prüfen |
| Roh-HTML zum Debuggen aufbewahren | Kurze Speicherfrist, Zone mit beschränktem Zugriff, verschlüsselt |
| Kontaktdaten von Einzelpersonen sind der Zweck | Anhalten und vor der Erhebung rechtlichen Rat einholen |
Häufige Fragen
Sind gescrapte öffentliche Daten von der DSGVO ausgenommen?
Nein. Die DSGVO kennt keine allgemeine Ausnahme für öffentlich zugängliche personenbezogene Daten. Sie brauchen weiterhin eine Rechtsgrundlage, Artikel 5 gilt weiter, und Artikel 14 regelt die Informationen, die Sie Personen schulden, deren Daten Sie nicht bei ihnen selbst erhoben haben.
Ist eine IP-Adresse ein personenbezogenes Datum?
Das kann sie sein. Die DSGVO nennt Online-Kennungen in Artikel 4 Nummer 1, und der CCPA führt „Internet Protocol address“ unter seinen Beispielen für Kennungen auf. Beim Scraping ist das vor allem für Ihre eigenen Logs relevant.
Macht Hashing Daten anonym?
Nein. Ein einfacher Hash einer E-Mail-Adresse oder Telefonnummer lässt sich umkehren, indem man eine Liste von Vermutungen hasht. Ein Hash mit einem geheimen, getrennt gespeicherten Schlüssel ist Pseudonymisierung, und die DSGVO behandelt das weiterhin als personenbezogene Daten.
Was sagt das KVKK zu Daten, die eine Person selbst veröffentlicht hat?
Artikel 5 erlaubt die Verarbeitung ohne ausdrückliche Einwilligung, wenn die Person die Daten selbst öffentlich gemacht hat. Die Grundsätze aus Artikel 4, etwa festgelegte Zwecke und Verhältnismäßigkeit, gelten trotzdem.
Wie lange darf ich gescrapte personenbezogene Daten aufbewahren?
Nur so lange, wie der Zweck es erfordert. Artikel 5 DSGVO nennt das Speicherbegrenzung, und Artikel 7 KVKK verlangt Löschung, Vernichtung oder Anonymisierung, sobald der Grund für die Verarbeitung entfallen ist.
Ändert ein Proxy etwas an meinen Pflichten?
Nein. Ein Proxy leitet Anfragen über eine andere IP-Adresse. Er ändert nichts daran, was Sie erheben, wo Sie es speichern oder welche Gesetze gelten.
Fazit
Personenbezogene Daten landen selten in einem gescrapten Datensatz, weil jemand sie haben wollte; sie kommen mit der Seite. Die Lösung ist überwiegend Technik: Zweck festlegen, nur die Felder erheben, die ihm dienen, maskieren, was in den Freitext rutscht, Schlüssel mit einem getrennt gespeicherten Geheimnis pseudonymisieren, den Speicher verschlüsseln und nach Zeitplan löschen. Pseudonymisierte Daten bleiben nach der DSGVO personenbezogene Daten; anonym heißt, dass niemand mit Mitteln identifiziert werden kann, die nach allgemeinem Ermessen wahrscheinlich genutzt werden. Für die Erhebung siehe Data Scraping: Residential-Proxy bieten Targeting nach Land und Stadt, Rotierender Proxy verteilen Anfragen, und unsere Seite Proxy listet alle Produkte.




