# Anonymisierte Rohdaten — Serahr-Köln-Studie 2026

## Datensatz-Übersicht

| Datei | Format | Zweck |
|---|---|---|
| `anonymized-locations-koeln.jsonl` | JSON Lines, ein Eintrag pro Location | Maschinenlesbar, primärer Datensatz für Sekundärauswertungen |
| `anonymized-locations-koeln.csv` | CSV, eine Zeile pro Location | Direkt in Excel / R / Python `pandas` einlesbar |
| `anonymized-locations-koeln.sha256.txt` | Text | Kryptographischer Hash über `.jsonl`, fixiert den Datensatz-Stand |
| `aggregate-koeln.json` | JSON | Vorberechnete Aggregate je Bezirk / Stadtteil / Branche / Branche×Bezirk |
| `clean-quotes.json` | JSON | „Beanstandungs-frei"-Quoten (weich + streng) je Bezirk / Stadtteil / Branche |

## Methodik der Anonymisierung

Pro Location ist exakt **eine** Identifizierung im Datensatz enthalten:

```
id = first_16_hex_chars(SHA256(hostname))
```

Dieses Hash ist **nicht reversibel** ohne Kenntnis des ursprünglichen Hostnamens. Bei einer Hostname-Liste lässt sich der Hash zwar prüfen (= Identifikation), das ist aber das mathematische Limit jeder Hash-basierten Anonymisierung.

**Bewusst entfernt** für Anonymisierung:
- Hostname / vollständige URL
- Site-Name / Brand
- OSM-ID, Lat/Lon, Postleitzahl, vollständige Adresse
- Issue-Texte mit eingebetteten URLs (z.B. „Seite https://example.com/dse.pdf konnte nicht geladen werden") — diese sind durch die strukturellen Issue-Typen ersetzt

**Bewusst erhalten** (anonym, aggregat-tauglich):
- Bezirk + Stadtteil (geografische Einordnung)
- Branche / OSM-Tag (z.B. `restaurant`, `shop=clothes`)
- Alle Boolean-Befunde (Impressum, DSE, AGB, Cookie-Banner, Google Fonts, GA, FB-Pixel)
- Cookie-Anzahl + Third-Party-Anzahl (numerisch)
- Strukturelle DSE-/AGB-Issue-Typen (= Pattern, keine site-spezifischen Texte)
- Top-10-Drittanbieter-Domains pro Location (für Tracker-Pattern-Analysen)

## Schema (JSONL)

Pro Zeile ein Objekt:

```json
{
  "id": "a3b2c1d4e5f60718",
  "bezirk": "Mülheim",
  "stadtteil": "Holweide",
  "stadtteil_inferred": false,
  "branche": "restaurant",
  "tag": "amenity",
  "impressum": true,
  "dse": true,
  "agb": false,
  "cookieBanner": true,
  "cookieCount": 3,
  "thirdPartyCount": 7,
  "googleFonts": true,
  "googleAnalytics": true,
  "fbPixel": false,
  "dseIssueTypes": [
    "Keine Auftragsverarbeiter genannt",
    "Keine Rechtsgrundlage (Art. 6 DSGVO) erkennbar"
  ],
  "agbIssueTypes": [],
  "thirdPartyDomains": [
    "fonts.googleapis.com",
    "fonts.gstatic.com",
    "www.googletagmanager.com",
    "region1.google-analytics.com",
    "maps.googleapis.com"
  ]
}
```

`stadtteil_inferred=true` heißt: der Stadtteil wurde nicht durch Polygon-Test direkt zugeordnet, sondern via Centroid-Nearest-Verfahren (border-case zwischen Polygonen). Diese Records sind kennzeichnen, damit Sekundärauswertungen sie ggf. ausschließen können.

## Stichprobe

- **6.153 Locations** mit registriertem Sitz in einem der 9 Kölner Stadtbezirke (OSM-Polygon-Filter, Stand Mai 2026)
- **5.380 erfolgreich gescannte Locations** (87,4 % Success-Rate) — diese sind im anonymisierten Datensatz enthalten
- **3.733 OSM-Records außerhalb der Bezirke 1-9** (Köln-Bbox enthielt auch Pulheim/Bergisch-Gladbach-Ränder) — wurden vor Scan herausgefiltert und sind nicht enthalten

## Lizenz

**CC BY 4.0** — Namensnennung (Thorsten Ahrens / Serahr) und Verlinkung der Originalquelle (`https://serahr.de/studie/koeln/2026`) sind verpflichtend.

Bei wissenschaftlichen Zweitanalysen freut sich der Autor über einen Hinweis an `studie@serahr.de`.

## Reproduzier-Hashes (SHA-256)

| Datei | SHA-256 |
|---|---|
| `anonymized-locations-koeln.jsonl` | `58ae0096b838d384ada5a943e423e358aeafeae0928d9fe48d1b21be50355bfe` |
| `aggregate-koeln.json` | `7fea6f34e6822388d2821147d57e550889ee8b0616d3985ba6e4d2d42ad9052b` |
| `clean-quotes.json` | `287087467497f5a9923e292183f58710105c99d8264fbc497e18dfae50756a1c` |

Die Hashes sind über den offenen Standard **OpenTimestamps** in der Bitcoin-Blockchain verankert (Verfahren analog zur separat veröffentlichten DACH-Studie 2026). Die zugehörigen `.ots`-Proof-Dateien liegen im Unterordner `timestamp Bitcoin chain/` und ermöglichen jedem Dritten den unabhängigen Nachweis, dass diese Daten zum Studien-Zeitpunkt unverändert waren. Vollständige Verifikations-Anleitung in `VERIFIKATION.md`.

## Methodik der Erhebung (kurz)

- **OSM Overpass-Query** für Bezirke 1-9 Köln, Filter auf `website`-Tag + amenity/shop/craft/office/healthcare/leisure/tourism
- **Polygon-Mapping** auf Bezirks-Boundaries (admin_level=9) und Stadtteil-Boundaries (admin_level=10)
- **Hostname-Dedup** auf Scan-Liste (Chains werden einmal gescannt, in der Aggregation aber pro Location gewichtet)
- **Scanner:** SerahrLegalMonitor v1, Microsoft Playwright mit transparentem User-Agent (`SerahrLegalMonitor/1.0 (+https://serahr.de/legal-monitor/bot)`), respektiert robots.txt
- **Stichtag:** Mai 2026

Vollständige Methodik in der Studie selbst: https://serahr.de/studie/koeln/2026