# BGH-Urteil VI ZR 144/23: Wenn dein Shop Daten an Drittanbieter schickt

> Der BGH lässt Unterlassungsklagen gegen Datenweitergabe an Drittanbieter zu. Was entschieden ist, was offen bleibt und was ein Test-Shop wirklich sendet.

Source: https://www.jpkc.com/db/blog/bgh-unterlassung-datenweitergabe/

Am **16. September 2026** titelte heise online: [„Grundsatzurteil: BGH stärkt Verbraucherrechte bei Datenweitergabe im Netz"](https://www.heise.de/news/Grundsatzurteil-BGH-staerkt-Verbraucherrechte-bei-Datenweitergabe-im-Netz-11455760.html). Dahinter steht ein Urteil des Bundesgerichtshofs vom **21. Juli 2026** mit dem Aktenzeichen **VI ZR 144/23**. Ein Kläger hatte einen Online-Shop verklagt, weil dessen Seiten beim Aufruf nach eigener Darstellung Daten an Google, Facebook, Pinterest und andere Anbieter schickten.

Das Thema begegnet mir ständig. In WordPress- und WooCommerce-Projekten sehe ich regelmäßig Themes und Plugins, die ungefragt Schriften, Videos, reCAPTCHA oder ganze Bibliotheken von fremden Servern nachladen — und baue sie um. Die Frage, die danach fast immer kommt, lautet: *Was geht da eigentlich raus?* Die ehrliche Antwort war bisher meistens: mehr, als du denkst, aber genau weiß es niemand, der nicht nachgesehen hat.

Deshalb habe ich für diesen Artikel beides gemacht. Ich habe das Urteil samt beiden Vorinstanzen gelesen, weil in den Meldungen einiges verkürzt oder schlicht falsch wiedergegeben wird. Und ich habe einen Test-Shop gebaut, typische Drittanbieter eingebunden und protokolliert, was sie senden — mit Fantasie-Daten und so, dass die Datensendungen abgefangen wurden, statt beim Anbieter anzukommen. Dass mir dabei im ersten Anlauf selbst eine Sendung durchgerutscht ist, gehört zu den Ergebnissen. Am Ende weißt du, was der BGH entschieden hat, was er offengelassen hat, welche Daten neben der IP-Adresse wirklich fließen und wie du das auf deiner eigenen Seite findest und abstellst.

> **Das hier ist keine Rechtsberatung.** Ich bin IT-Berater, kein Rechtsanwalt, und ich darf keine Rechtsberatung erteilen — Rechtsberatung im Einzelfall ist nach dem Rechtsdienstleistungsgesetz Anwältinnen und Anwälten vorbehalten. Was du hier bekommst, ist aufbereitete Fachinformation: Ich führe jede rechtliche Aussage auf das Urteil, eine Norm oder eine Veröffentlichung einer Aufsichtsbehörde zurück und kennzeichne durchgehend, **was Rechtsprechung ist und was meine Einschätzung ist**. Für die verbindliche Bewertung deines Shops brauchst du anwaltlichen Rat oder deine Datenschutzbeauftragte. Der technische Teil dieses Artikels ist dagegen genau mein Fach.

## Worum es in dem Verfahren ging

Die Beklagte betreibt einen Online-Shop, dessen Name in allen drei Urteilen anonymisiert ist. Auf den Seiten sind Funktionen von Drittanbietern so eingebunden, dass der Browser sie direkt von deren Servern lädt. Dabei erhält der fremde Server die IP-Adresse des Besuchers, „um den Abruf von dort zu ermöglichen". Das Urteil nennt das eine „sog. Cloud-Lösung" ([BGH, Rn. 2](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2023/VI_ZR_144-23.pdf?__blob=publicationFile&v=1)). Gemeint ist ganz gewöhnliches Nachladen, keine Umleitung.

Welche Dienste das waren, steht nicht im BGH-Urteil, wohl aber im Urteil der ersten Instanz. Der Klageantrag vor dem [Landgericht Wiesbaden](https://www.rv.hessenrecht.hessen.de/bshe/document/LARE220002519) zählt **17 Dienste** auf:

> Google Tag Manager, Google Analytics, Google Fonts, Google Recaptca, Google Optimize, Doubleclick, Youtube, Facebook, Pinterest, Taboola, Fonts Awesome, Fonts.com, Bing Ads, Cquotient, Amplify, Trbo, Zenloop
> — LG Wiesbaden, Urteil vom 20.01.2022 – 10 O 14/21, Klageantrag a–q (Schreibweise wie im Urteil)

Das ist ein ziemlich typischer Shop-Stapel: Tag-Manager und Analyse, Werbe- und Social-Pixel, drei Schriften-Dienste, Video, Captcha und Produktempfehlungen.

Der Kläger hat nach eigenem Vortrag 2020 in dem Shop bestellt. Behauptet wird, neben der IP-Adresse seien „zahlreiche Nutzungsdaten aus dem Bestellvorgang" an Dritte geflossen (BGH, Rn. 3). Das [Oberlandesgericht Frankfurt](https://www.rv.hessenrecht.hessen.de/bshe/document/LARE230004412) gibt das als „Informationen über Hard- und Software seiner Endgeräte" wieder, die Hilfsanträge zählen beispielhaft auf: IP-Adresse, Zeitpunkt des Aufrufs, Referrer, Betriebssystem und Browser samt Version, Spracheinstellungen, installierte Anwendungen und unterstützte Programmiersprachen. **Name, Anschrift oder E-Mail-Adresse stehen da nicht.** Name und Anschrift tauchen nur als Beleg für die Bestellung auf und als Argument, warum die IP-Adresse auf die Person des Klägers verweist. Dass sie an Dritte gingen, wird nicht behauptet; eine E-Mail-Adresse kommt gar nicht vor. Beim OLG heißt es zudem, der Kläger sei Informatiker und habe bei einer späteren Bestellung den Datenverkehr mitprotokolliert.

Die Beklagte hielt dagegen, die Besucher hätten über das Cookie-Banner eingewilligt, und mit mehreren Diensten bestünden Auftragsverarbeitungsverträge. Ob das stimmt, hat bis heute kein Gericht entschieden.

Der Weg durch die Instanzen:

| Instanz | Datum, Aktenzeichen | Ergebnis |
| --- | --- | --- |
| LG Wiesbaden | 20.01.2022 – 10 O 14/21 | Klage abgewiesen: Antrag unbestimmt, zudem unbegründet; die DSGVO sperre nationale Ansprüche, § 1004 BGB sei nicht analog anwendbar |
| OLG Frankfurt am Main | 30.03.2023 – 16 U 22/22 | Berufung zurückgewiesen: Der neue Antrag („jegliche Daten") ist bestimmt, aber die DSGVO regle die Folgen abschließend; Revision nicht zugelassen |
| BGH, VI. Zivilsenat | 21.07.2026 – VI ZR 144/23 | Revision (vom BGH zugelassen) erfolgreich: OLG-Urteil aufgehoben, Sache zurückverwiesen |

## Was der BGH entschieden hat

Der Kern steht im Leitsatz, und er ist kürzer als die meisten Überschriften dazu:

> „Ein Unterlassungsanspruch nach nationalem Recht, der sich gegen eine erneute Übermittlung personenbezogener Daten unter Verstoß gegen die Datenschutz-Grundverordnung richtet, kann nicht grundsätzlich unter Berufung auf einen abschließenden Regelungsgehalt der unionsrechtlichen Bestimmungen abgelehnt werden."
> — BGH, Urteil vom 21. Juli 2026 – VI ZR 144/23, Leitsatz

Übersetzt: Wer sich gegen eine datenschutzwidrige Übermittlung wehren will, darf das auch mit dem deutschen Zivilrecht tun. Das OLG hatte genau das ausgeschlossen, weil die DSGVO eine „abschließende, weil voll harmonisierte" Regelung sei und ohne Öffnungsklausel kein Platz für nationales Recht bleibe (Rn. 7). Diese Begründung trägt nicht mehr.

Der Grund dafür liegt in Luxemburg. Der Europäische Gerichtshof hat am **4. September 2025** in der Rechtssache [C-655/23](https://curia.europa.eu/juris/document/document.jsf?docid=302595&doclang=DE) entschieden, dass die DSGVO selbst zwar keinen vorbeugenden Unterlassungsanspruch kennt, wenn die betroffene Person nicht zugleich Löschung verlangt. Sie hindert die Mitgliedstaaten aber nicht daran, einen solchen Rechtsbehelf vorzusehen (Rn. 52). Im Gegenteil: Eine solche Klage könne „die praktische Wirksamkeit dieser Bestimmungen verstärken" (Rn. 50). Das EuGH-Urteil kam knapp zweieinhalb Jahre nach dem OLG-Urteil — Frankfurt konnte es nicht kennen.

Als Anspruchsgrundlagen nennt der BGH zwei Wege aus dem Bürgerlichen Gesetzbuch (Rn. 15):

- **§ 1004 Abs. 1 und § 823 Abs. 1 BGB analog** in Verbindung mit Art. 1 Abs. 1 und Art. 2 Abs. 1 Grundgesetz — also das allgemeine Persönlichkeitsrecht in seiner Ausprägung als Recht auf informationelle Selbstbestimmung.
- **§ 1004 Abs. 1 Satz 2 analog und § 823 Abs. 2 BGB**, wenn eine Datenschutzvorschrift verletzt ist, die als Schutzgesetz gilt.

Zwei Details finde ich für die Praxis wichtiger, als sie in den Meldungen wirken.

**Erstens: „jegliche Daten" ist bestimmt genug.** Die ursprüngliche Formulierung „personenbezogene oder -beziehbare Daten des Klägers – wie dessen IP-Adresse –" hielten LG und OLG für zu unbestimmt, weil ein Vollstreckungsgericht dafür erst juristisch subsumieren müsste. Der später gestellte Hauptantrag, es zu unterlassen, dass „beim Seitenaufruf jegliche Daten des Klägers" ohne Einwilligung des Klägers an die im Antrag benannten Dienste übermittelt werden, genügt dagegen „jedenfalls" den Anforderungen (Rn. 9–11). Wer künftig klagt, hat damit eine Antragsfassung, die der BGH als bestimmt genug akzeptiert hat — ob ein so weiter Antrag auch begründet ist, ist damit nicht gesagt.

**Zweitens: Das Urteil steht nicht allein.** Es ist Teil einer Linie. Im November 2024 hatte der Senat die Frage noch ausdrücklich offengelassen ([VI ZR 10/24, Rn. 83](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR__10-24A.pdf?__blob=publicationFile&v=1)). Nach dem EuGH folgten am 12. Mai 2026 [VI ZR 375/24](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR_375-24.pdf?__blob=publicationFile&v=1) (Widerruf einer rechtswidrigen SCHUFA-Einmeldung — offen, ob schon aus der DSGVO, jedenfalls aus nationalem Recht) und am 23. Juni 2026 [VI ZR 97/22](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2022/VI_ZR__97-22A.pdf?__blob=publicationFile&v=2) — das Ausgangsverfahren der EuGH-Vorlage. VI ZR 144/23 überträgt diese Linie auf Drittanbieter in Online-Shops.

## Was der BGH nicht entschieden hat

Hier liegt der Unterschied zwischen „Grundsatzurteil" und „der Shop hat verloren". Der BGH hat dem Kläger **nichts zugesprochen**. Er hat eine Begründung des OLG verworfen und die Sache zurückgeschickt. Offen ist unter anderem:

- **Ob die Übermittlung überhaupt rechtswidrig war.** Der BGH sagt nur, ein Anspruch sei „nicht auszuschließen" und die Anspruchsgrundlagen seien „in Betracht zu ziehen" (Rn. 14–15).
- **Ob die Einwilligung über das Cookie-Banner wirksam war.** Darauf hatte sich die Beklagte berufen; keine Instanz hat es geprüft.
- **Ob die übermittelten Daten personenbezogen sind.** Dass alle Daten „schon aufgrund ihrer Übermittlung zusammen mit seiner IP-Adresse" personenbezogen seien, gibt der BGH ausdrücklich als „Ansicht des Klägers" wieder (Rn. 11) — nicht als eigene Feststellung.
- **Ob Wiederholungsgefahr besteht.** Ohne sie — oder eine drohende Erstbegehung — gibt es keinen Unterlassungsanspruch. Im Verfahren VI ZR 97/22 ist der Unterlassungsantrag genau daran gescheitert: ein einmaliger Fehlversand, das Bewerbungsverfahren abgeschlossen (Rn. 26–30). Schadensersatz steht dem Kläger dort dem Grunde nach trotzdem zu.
- **Ob ein nationaler Anspruch überflüssig ist, wenn die DSGVO-Rechte im Einzelfall genügen.** Das lässt der BGH offen und hält nur fest, dass nach den bisherigen Feststellungen keines der DSGVO-Rechte, insbesondere nicht die Löschung nach Art. 17, das Ziel des Klägers erreicht (Rn. 16).

Einen weiteren offenen Punkt sehe ich selbst, ohne dass das Urteil ihn anspricht: Im Oktober 2025 hat derselbe Senat entschieden, dass ein Unterlassungsantrag, der auch datenschutzrechtlich nicht zu beanstandendes Verhalten erfasst, zu weit gefasst und damit unbegründet ist ([VI ZR 431/24, Leitsatz a](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR_431-24.pdf?__blob=publicationFile&v=1)). Ob „jegliche Daten" an diesem Maßstab scheitert, hat der BGH in VI ZR 144/23 nicht erörtert. Welche dieser Fragen das OLG beantworten muss, hängt davon ab, worauf es für seine Entscheidung ankommt. Wie es entscheidet, weiß niemand — ich prognostiziere es auch nicht.

## Was in den Meldungen anders klingt

Beim Lesen der Berichte ist mir einiges aufgefallen, das nicht zum Urteilstext passt. Keine Kritik an den Kolleginnen und Kollegen, die unter Zeitdruck schreiben — aber wer seinen Shop danach ausrichtet, sollte die Unterschiede kennen:

- **„Verbraucherrechte".** Das Wort „Verbraucher" kommt im Urteil nicht vor. Der BGH spricht von der „betroffenen Person" (Rn. 13), dem „Verletzten" (Rn. 15) und dem „Betroffenen" (Rn. 16); die Anspruchsgrundlagen knüpfen am Persönlichkeitsrecht an, nicht an die Verbrauchereigenschaft. Ausdrücklich äußert sich der BGH dazu allerdings nicht. Der Kläger selbst hat laut LG-Tatbestand „als Verbraucher" bestellt — bei der Person liegen die Meldungen also richtig, nur hängt der Anspruch nicht daran. Im Verfahren VI ZR 97/22 war der Kläger Stellenbewerber.
- **„Der EuGH-Fall drehte sich um Schmerzensgeld nach einem Datenleck".** In [C-655/23](https://curia.europa.eu/juris/document/document.jsf?docid=302595&doclang=DE) schickte eine Bankmitarbeiterin eine Nachricht mit der Gehaltsvorstellung eines Bewerbers über ein Karrierenetzwerk versehentlich an einen Dritten. Eingeklagt waren Unterlassung **und** Ersatz des immateriellen Schadens (Rn. 2, 23–24). Ein Hackerangriff oder Massenleck war das nicht, sondern eine einzelne fehlgeleitete Nachricht — datenschutzrechtlich allerdings durchaus eine „Verletzung des Schutzes personenbezogener Daten" im Sinne von Art. 4 Nr. 12 DSGVO.
- **„Der Browser wird auf fremde Server umgeleitet".** Das Urteil schreibt, der Browser werde auf Seiten der Dienste „gelenkt" (Rn. 2). Gemeint ist nach dem OLG-Tatbestand, dass die Funktionen „eingebettet" sind — also das Nachladen eingebundener Inhalte, nicht eine Weiterleitung der Seite.
- **„Ohne wirksame Einwilligung".** Steht so als Tatsache in manchen Berichten, ist aber gerade offen. Genauso wenig kommt § 25 TDDDG im Urteil vor.
- In mindestens einer Meldung steht ein **falsches Urteilsdatum** (21. Juni statt 21. Juli), in einer anderen werden **zwölf** statt 17 Dienste gezählt, und eine Meldung legt ein „LG Frankfurt" als erste Instanz nahe — tatsächlich war es das LG Wiesbaden.

## Warum schon die IP-Adresse zählt

Wer das Urteil einordnen will, braucht drei ältere Bausteine.

**Die IP-Adresse ist ein personenbezogenes Datum**, wenn der Empfänger rechtliche Mittel hat, die Person dahinter über den Internetanbieter bestimmen zu lassen. So hat es der EuGH 2016 für dynamische IP-Adressen entschieden ([C-582/14 „Breyer"](https://curia.europa.eu/juris/document/document.jsf?docid=184668&doclang=DE), Tenor 1). Das Urteil legte noch die alte Datenschutzrichtlinie 95/46/EG aus. Das LG München I hat 2022 die dynamische IP-Adresse auch unter der DSGVO als personenbezogenes Datum eingestuft (3 O 17493/20, Rn. 4–5).

**Wer einbettet, ist mitverantwortlich.** Ein Online-Modehändler hatte den „Gefällt mir"-Button von Facebook eingebunden; der Browser übermittelte schon beim Seitenaufruf IP-Adresse und Browserdaten an Facebook — ohne Klick, ohne Facebook-Konto. Der EuGH entschied 2019, dass der Websitebetreiber für das Erheben und die Übermittlung dieser Daten gemeinsam mit dem Anbieter verantwortlich sein kann, nicht aber für das, was Facebook danach damit macht ([C-40/17 „Fashion ID"](https://curia.europa.eu/juris/document/document.jsf?docid=216555&doclang=DE), Tenor 2). Auch dieses Urteil erging zur alten Richtlinie. Für Shop-Betreiber heißt das trotzdem: „Das lädt ja der Anbieter, nicht ich" ist kein Argument.

**Google Fonts, 2022.** Das [LG München I](https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2022-N-612) verurteilte am 20.01.2022 (3 O 17493/20) einen Websitebetreiber, es zu unterlassen, die IP-Adresse des Klägers durch die Einbindung von Google Fonts an Google offenzulegen, und sprach 100 Euro Schadensersatz zu. Interessant im Rückblick: Das Gericht stützte die Unterlassung schon damals auf § 823 Abs. 1 in Verbindung mit § 1004 BGB analog — genau den Weg, den der BGH jetzt grundsätzlich offenhält. Ein berechtigtes Interesse lehnte es in einem einzigen Satz ab: Google Fonts lasse sich auch nutzen, ohne dass beim Aufruf eine Verbindung zu Google-Servern hergestellt werde (Rn. 8).

Was danach kam, gehört ebenfalls zur Einordnung. Es folgte eine Welle von Abmahnungen. Polizei und Staatsanwaltschaft Berlin durchsuchten im Dezember 2022 Räume einer Anwaltskanzlei und eines Mandanten wegen des Verdachts auf Abmahnbetrug und versuchte Erpressung in mindestens 2.418 Fällen, bei einer Vergleichsforderung von jeweils 170 Euro ([Polizeimeldung vom 21.12.2022](https://www.berlin.de/polizei/polizeimeldungen/2022/pressemitteilung.1277732.php)). Der Vorwurf: Die Seitenbesuche sollen per Software fingiert worden sein — mangels betroffener Person läge dann keine Persönlichkeitsrechtsverletzung vor, und wer die Übermittlung bewusst auslöst, willige faktisch ein. Einen Ausgang des Verfahrens habe ich nicht gefunden; es gilt die Unschuldsvermutung. Das [LG München I](https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2023-N-6354) stellte 2023 in einem solchen Fall fest, dass dem Abmahnenden weder Unterlassung noch Schmerzensgeld zustand: kein persönlich Betroffener, Rechtsmissbrauch (4 O 13063/22). Die Lehre daraus: Der Unterlassungsanspruch ist ein Werkzeug für echte Betroffene, kein Geschäftsmodell.

### Unterlassung ist nicht Schadensersatz

Beides wird ständig vermischt. Der EuGH trennt es in C-655/23 sauber: Der Schadensersatz nach Art. 82 DSGVO hat eine „ausschließlich ausgleichende Funktion", die Unterlassungsanordnung eine „rein präventive Zielsetzung" (Rn. 82). Für Schadensersatz reicht ein bloßer Verstoß nicht, der Schaden muss nachgewiesen werden ([C-300/21](https://curia.europa.eu/juris/document/document.jsf?docid=273284&doclang=DE), Tenor 1 und Rn. 50). Er kann allerdings schon im Kontrollverlust über die eigenen Daten liegen; für einen solchen Fall hielt der BGH eine Größenordnung von 100 Euro für rechtlich unbedenklich (VI ZR 10/24, Rn. 98–101). Bei der Unterlassung geht es dagegen nicht um Geld für die Vergangenheit, sondern darum, dass es aufhört.

### TDDDG oder DSGVO?

Auch das wird oft durcheinandergeworfen. Die Datenschutzkonferenz unterscheidet in ihrer [Orientierungshilfe für Anbieter:innen von digitalen Diensten](https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf) (Version 1.2, November 2024) zwei Schritte:

- **§ 25 TDDDG** regelt das Speichern von Informationen im Endgerät und das Auslesen daraus — Cookies, Local Storage, aber auch ein Skript, das aktiv Geräteeigenschaften ausliest und etwa für einen Fingerprint an einen Server schickt (Rn. 21, 24).
- **Art. 6 DSGVO** regelt die Verarbeitung personenbezogener Daten danach. Und ausdrücklich: Mit der Einbindung von Drittinhalten ist „regelmäßig eine Offenlegung personenbezogener Daten an Betreiber:innen des jeweiligen Drittservers verbunden" — typische Beispiele seien „Werbeanzeigen, Schriftarten, Skripte" (Rn. 101). Werden Drittdienste beim Tracking als Auftragsverarbeiter eingebunden, verarbeiten die Daten aber auch zu eigenen Zwecken — oder behalten sich das auch nur vor —, kann das berechtigte Interesse nach lit. f die Übermittlung „und sei es nur der IP-Adresse" nach Auffassung der DSK in der Regel nicht tragen (Rn. 111).

Der Fall vor dem BGH betrifft den zweiten Schritt: die Übermittlung. Der Kläger hatte zwar auch gerügt, es seien ohne Einwilligung Cookies gespeichert worden (LG-Tatbestand); geprüft hat das keine Instanz, und keines der drei Urteile nennt § 25 TTDSG oder TDDDG.

## Was das für dich als Shop-Betreiber heißt

In diesem Abschnitt folgt **meine Einschätzung**, gestützt auf die zitierten Entscheidungen — soweit ich nicht ausdrücklich Rechtsprechung zitiere, ist nichts davon eine Aussage des BGH.

Vorweg eine Übertragung, die ich für naheliegend halte: Die Rechtsaussage des BGH gilt ihrem Wortlaut nach für personenbezogene Daten allgemein — also auch dann, wenn ein Shop E-Mail-Adressen an Werbeplattformen schickt. Das war nicht der Sachverhalt des Verfahrens, aber es ist der Teil, der viele Shops betrifft.

1. **Betroffene haben ein zusätzliches Werkzeug.** Neben Beschwerde bei der Aufsichtsbehörde und Schadensersatz können sie auf Unterlassung klagen, und der BGH hat eine Antragsfassung als bestimmt genug akzeptiert. Das Risiko für einen Shop steigt nicht über Nacht, aber die Hürde für eine Klage ist niedriger geworden.
2. **Stilles Abschalten reicht nicht, wenn es schon passiert ist.** Nach der Rechtsprechung des BGH räumt die bloße Einstellung einer Praxis die Wiederholungsgefahr in der Regel nicht aus; dafür braucht es meist eine strafbewehrte Unterlassungserklärung ([VI ZR 431/24, Rn. 27](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR_431-24.pdf?__blob=publicationFile&v=1); ebenso LG München I 3 O 17493/20, Rn. 10). Wer abgemahnt wird, braucht anwaltlichen Rat — und nicht bloß einen schnellen Commit.
3. **Die Einwilligung wird zur zentralen Frage.** Nach Vortrag der Beklagten hatte der Shop ein Cookie-Banner, über das Besucher auch in die Drittdienste einwilligten. Ob das trägt, hat noch kein Gericht geprüft — das OLG muss es klären, wenn es für seine Entscheidung darauf ankommt. Für dich heißt das: Nicht „habe ich ein Banner?", sondern „lädt vor der Entscheidung wirklich nichts, und steht nach einem Nein wirklich alles still?"
4. **Missbrauch bleibt Missbrauch.** Automatisierte Massenabmahnungen sind durch dieses Urteil nicht attraktiver geworden; die Gerichte haben dafür Maßstäbe entwickelt.

Die eigentliche Frage ist also technisch: Was schickt dein Shop wann an wen? Genau das habe ich gemessen.

## Die Drittanbieter eines typischen Shops

Die meisten der 17 Dienste aus dem Verfahren lassen sich in Kategorien sortieren, die in fast jedem Shop wieder auftauchen:

| Kategorie | Beispiele (kursiv: aus dem Klageantrag) | Was beim Seitenaufruf passiert |
| --- | --- | --- |
| Tag-Manager | *Google Tag Manager* | lädt weitere Skripte nach, je nach Konfiguration |
| Webanalyse und Datenanalyse | *Google Analytics*, *Trbo* | Seitenaufrufe und Ereignisse gehen an den Anbieter |
| Werbung und Konversionen | *Doubleclick*, *Bing Ads*, *Taboola*, TikTok | Pixel melden Seitenaufrufe, Warenkorb und Käufe |
| Social | *Facebook*, *Pinterest* | Pixel wie oben, teils mit „erweitertem Abgleich" |
| Schriften | *Google Fonts*, *Fonts Awesome*, *Fonts.com* | CSS und Schriftdateien vom fremden Server |
| Video und Captcha | *Youtube*, *Google Recaptca* | iframe bzw. Skript vom Anbieter |
| Empfehlungen und Tests | *Cquotient*, *Google Optimize* | Nutzungsverhalten geht an die Engine |
| Zahlung und Bewertungen | Stripe, PayPal, Trustpilot | Skript und oft iframes vom Anbieter |
| Bibliotheken | jsDelivr und andere CDNs | JavaScript vom fremden Server |

Allen gemeinsam: Der **Browser** stellt die Verbindung her. Damit hat der fremde Server die IP-Adresse, den User-Agent und den Referrer, bevor irgendein Skript überhaupt etwas tut. Google selbst beschreibt das für Google Fonts genau so: IP-Adresse, angefragte URL und HTTP-Header einschließlich User-Agent und Referer ([Google Fonts FAQ](https://fonts.google.com/faq#privacy), englisch).

## Die Messung: ein Test-Shop mit Fantasie-Daten

Dokumentationen sagen, was ein Anbieter senden *kann*. Ich wollte sehen, was er sendet. Also habe ich am 17. September 2026 einen kleinen Test-Shop gebaut: Produktseite, Warenkorb, Bestellbestätigung. Kundin „Erika Mustermann", E-Mail `erika.mustermann@example.com`, Bestellung `TEST-10042`, ein Wanderschuh `SKU-4711` für 89,90 Euro — alles erfunden, alle Anbieter-IDs sind Test-IDs.

Eingebunden habe ich die Anbieter nach den Snippets aus der jeweiligen Hersteller-Dokumentation — Stripe.js nur geladen, nicht initialisiert, Trustpilot nur mit dem Lade-Skript ohne Widget — und so konfiguriert, wie ich es in Shops oft vorfinde:

- **Ohne Einwilligung aktiv:** Google Fonts, eine Bibliothek von jsDelivr, das Google-Tag (`gtag.js`) für Google Analytics und Google Ads im Consent Mode „advanced" mit Voreinstellung „abgelehnt", Stripe.js, das PayPal-SDK im Sandbox-Modus, Trustpilot, ein YouTube-Video auf der Produktseite und reCAPTCHA mit Googles Test-Schlüssel im Warenkorb.
- **Erst nach Einwilligung:** Meta Pixel (mit E-Mail, Telefon, Name, Ort und Postleitzahl), TikTok Pixel und Microsoft UET für Bing Ads (jeweils mit E-Mail und Telefonnummer), Pinterest Tag (mit E-Mail) — Funktionen, die „erweiterter Abgleich", „Advanced Matching", „erweiterte Konvertierungen" oder „Enhanced Match" heißen — sowie Microsoft Clarity und Hotjar.

Damit sind acht der 17 Dienste aus dem Klageantrag im Test vertreten: Google Analytics, Google Fonts, reCAPTCHA, Doubleclick, YouTube, Facebook, Pinterest und Bing Ads. `gtag.js` kommt zwar vom Server des Google Tag Managers, einen Tag-Manager-Container habe ich aber nicht eingebunden.

Der Trick liegt in der Regel für das Netzwerk. Ein Playwright-Skript mit Chromium lässt nur eine **feste Liste von 18 Anbieter-Dateien** echt laden — die Skripte, Stylesheets und Schriften, ohne die kein Anbieter-Code liefe — und auch die nur, wenn in ihrer Adresse keine meiner Fantasie-Daten steht. **Jeder andere Request** an einen fremden Host wird mit URL, Referer-, Cookie- und Content-Type-Header und Nutzlast protokolliert und dann **abgebrochen**.

Diese Liste hat eine Vorgeschichte, die selbst ein Befund ist. Im ersten Durchlauf ließ meine Regel alles durch, was der Browser als Skript einstuft. Beim adversarischen Faktencheck dieses Artikels fiel auf, dass genau darüber sechs Sendungen an Google Ads tatsächlich rausgegangen waren — an `googleads.g.doubleclick.net`, mit Testbestellung, Produkt-ID, Wert und Seiten-URL. Google verschickt diese Conversion-Meldung als Anfrage, die der Browser wie ein Skript lädt. Mit erfundenen Daten und einer erfundenen Konto-ID ist das harmlos, als Lehre wertvoll: Wer Drittanbieter nur nach „Skript oder nicht" sortiert — oder in einer Content-Security-Policy nur den Host eines Werbedienstes für Skripte freigibt —, lässt solche Sendungen durch. Die Zahlen unten stammen aus dem Durchlauf mit der festen Liste, in dem keiner der durchgelassenen Requests Testdaten enthielt.

```js title="measure.cjs (Auszug)"
const LOADABLE = new Set(['script', 'stylesheet', 'font']);
// Only these exact vendor files may load. A resource type alone is not enough:
// Google Ads sends its conversion hit as a "script" request with the order in the query.
const ALLOW = [
	/^https:\/\/www\.googletagmanager\.com\/gtag\/js\?id=(G-TEST123456|AW-000000000)(&cx=c&gtm=\w+)?$/,
	/^https:\/\/connect\.facebook\.net\/en_US\/fbevents\.js$/,
	// … 16 more exact vendor files
];
// Belt and braces: never let a request through that carries any of the fake test data.
const MARKERS = ['TEST-10042', 'SKU-4711', '89.9', 'localhost', 'erika', 'mustermann', '4915100000000'];

// …

await context.route('**/*', async (route) => {
	const req = route.request();
	const url = new URL(req.url());
	if (url.origin === ORIGIN || url.protocol === 'data:' || url.protocol === 'blob:') return route.continue();
	const headers = await req.allHeaders();
	const entry = {
		run: name, page: current, resourceType: req.resourceType(), host: url.host, method: req.method(),
		url: req.url(), referer: headers.referer || '', cookie: headers.cookie || '',
		contentType: headers['content-type'] || '', postData: (req.postData() || '').slice(0, 20000),
	};
	const decoded = decodeURIComponent(req.url()).toLowerCase();
	const carriesData = MARKERS.some((m) => decoded.includes(m.toLowerCase()));
	if (LOADABLE.has(req.resourceType()) && ALLOW.some((re) => re.test(req.url())) && !carriesData) {
		lines.push({ ...entry, action: 'loaded' });
		return route.continue();
	}
	lines.push({ ...entry, action: 'aborted' });
	return route.abort('blockedbyclient');
});
```

Zwei Durchläufe, jeweils durch alle drei Seiten: einmal ohne Einwilligung, einmal mit. Danach habe ich die abgefangenen Requests nach den Fantasie-Daten durchsucht — im Klartext und als SHA-256-Hash —, jeden Treffer im Roh-Request nachgesehen und geprüft, dass keiner der durchgelassenen Requests solche Daten enthält.

### Ohne Einwilligung

26 abgefangene Sendungen an sechs fremde Hosts. Das Ergebnis, das mich am meisten überrascht hat, betrifft Google Analytics. Im Consent Mode „advanced" laden die Google-Tags schon vor der Einwilligung und senden laut Google „Messungen ohne Cookies" ([Google: Consent mode overview](https://developers.google.com/tag-platform/security/concepts/consent-mode?hl=de)). Was das auf einer Bestellbestätigung konkret heißt, zeigt die abgefangene Sendung:

```text title="POST region1.google-analytics.com/g/collect (gekürzt)"
gcs=G100            # nach Einwilligung: G111
en=purchase
pr1=idSKU-4711~nmTestprodukt Wanderschuh~pr89.9~qt1
ep.transaction_id=TEST-10042
epn.value=89.9
cu=EUR
dl=http://localhost/thanks.html
dt=Danke für deine Bestellung — Test-Shop
sr=1280x720
ul=de-de
uap=Linux
```

Bestellnummer, Produkt, Preis, Seiten-URL, Seitentitel, Bildschirmgröße, Sprache und Betriebssystem — ohne Einwilligung. Was **nicht** darin stand: ein Cookie und eine seitenübergreifende Kennung. Die Client-ID war auf jeder der drei Seiten eine andere. Google Ads meldete sich parallel über `pagead2.googlesyndication.com`, ebenfalls mit Seiten-URL, Bestellwert und Bestellnummer.

Außerdem wären ohne Einwilligung rausgegangen: auf jeder Seite ein Protokoll-Event des PayPal-SDK an die Sandbox mit Domain, User-Agent, Sprache und einer Session-ID, die auf allen drei Seiten **dieselbe** war — anders als bei Google also eine seitenübergreifende Kennung —, sowie die Anfragen der iframes von Stripe, YouTube und reCAPTCHA. Die IP-Adresse steckt in jeder dieser Verbindungen, auch wenn sie in keiner Nutzlast auftaucht — sie ist schlicht die Absenderadresse. Der Referer-Header enthielt übrigens bei allen 113 abgefangenen Requests beider Läufe nur `http://localhost:8790/`, nicht den Pfad. Die volle Seiten-URL kam über die Nutzlast.

### Nach Einwilligung

87 abgefangene Sendungen (zwischen Durchläufen schwankt die Zahl um einen einzelnen Hotjar-Ping). Die wichtigsten Befunde:

| Empfänger | Was drin war |
| --- | --- |
| Google (Analytics, Ads, Remarketing) | Kauf mit Bestellnummer, Produkt, Wert und Seiten-URL an `region1.google-analytics.com` und `www.google.com` |
| TikTok | **E-Mail und Telefonnummer als SHA-256**, Seiten-URL, User-Agent, Produkt und Wert; Cookie `_ttp` |
| Pinterest | **E-Mail als SHA-256**, beim Kauf die komplette Bestellung mit Bestellnummer, Produktname, Produkt-ID und Wert im Klartext |
| Microsoft UET (Bing Ads) | **E-Mail und Telefonnummer als SHA-256**, Seiten-URL, Seitentitel, Sprache, Bildschirmgröße, Kaufwert; Cookie `MUID` |
| Doubleclick | Kauf mit Bestellnummer, Produkt-ID, Wert, Seiten-URL und Seitentitel an `googleads.g.doubleclick.net` — als Skript-Anfrage, siehe oben |

So sieht das bei TikTok im Roh-Request aus:

```json title="POST analytics.tiktok.com/api/v2/pixel (gekürzt)"
{
	"event": "Purchase",
	"context": {
		"user": {
			"email": "5e5a6082e3087d33b2a6a5700d8a307361e4a10408448a344b9e8a4f61e9cd84",
			"phone_number": "e18d0e0ef936bd206d9a2c6ca4168109aa26240f1cd79284b5da4bac5ec8dd31"
		},
		"page": { "url": "http://localhost:8790/thanks.html" }
	},
	"properties": { "content_id": "SKU-4711", "value": 89.9, "currency": "EUR" }
}
```

Der erste Wert ist exakt der SHA-256-Hash von `erika.mustermann@example.com`. Microsoft hat die Adresse vor dem Hashen sogar normalisiert: Der gesendete Hash entspricht `erikamustermann@example.com`, also ohne den Punkt im lokalen Teil.

### Was nicht messbar war — und warum das kein Entwarnungssignal ist

Zu einer ehrlichen Messung gehört, was sie nicht zeigt:

- **Meta Pixel sendete nichts.** Das Skript lud, verwarf die erfundene Pixel-ID aber schon im Browser als ungültig (Konsole: „Invalid PixelID"), fragte keine Konfiguration an und feuerte nicht. Mit erweitertem Abgleich gehen laut Metas Dokumentation unter anderem E-Mail, Name, Telefon, Stadt und Postleitzahl mit, „hashed automatically by the pixel using SHA-256" ([Meta: Advanced Matching](https://developers.facebook.com/documentation/meta-pixel/advanced/advanced-matching?locale=de_DE)).
- **Google sendete die E-Mail nicht**, obwohl ich sie übergeben hatte. Das ist dokumentiert: Das Google-Tag sammelt solche Daten erst, wenn im Ads- oder Analytics-Konto die entsprechenden Nutzungsbedingungen akzeptiert sind ([Google Ads-Hilfe](https://support.google.com/google-ads/answer/13258081?hl=de)). Zu meinen erfundenen Tag-IDs gibt es kein Konto, in dem diese Bedingungen akzeptiert sein könnten. In einem echten Shop mit aktivierten „erweiterten Conversions" sieht das anders aus.
- **Hotjar erkannte den Headless-Browser am User-Agent als Bot** und startete nicht; gelegentlich ging eine einzelne Ablehnungsmeldung raus. **Clarity** lieferte für die erfundene Projekt-ID kein Skript.
- **Die iframes** von Stripe, YouTube und reCAPTCHA habe ich abgebrochen. Was darin weiter passiert wäre, etwa die Betrugserkennungs-Signale, die Stripe laut eigener Doku an `m.stripe.com` schickt, ist nicht gemessen.
- Die Konfiguration ist ein **Modell**. Welche Dienste in deinem Shop vor der Einwilligung laden, entscheidet dein Set-up, nicht meine Tabelle.

Echte Shops mit echten IDs senden also eher mehr als mein Test-Shop, nicht weniger.

### Warum ein Hash keine Anonymisierung ist

SHA-256 klingt nach Verschlüsselung, ist hier aber das Gegenteil von Anonymität. Dieselbe E-Mail-Adresse ergibt überall denselben Hash. Genau dafür wird er geschickt: Microsoft gleicht die gehashten Daten mit Nutzern ab, die bei Microsoft-Diensten angemeldet sind ([Microsoft: Erweiterte Konvertierungen](https://learn.microsoft.com/de-de/advertising/msa-help/hlp_ba_conc_uet_enhancedconversions)), und Pinterest schreibt, Enhanced Match sende verschlüsselte E-Mail-Adressen, „um Webseiten-Events zuzuordnen, wenn kein Pinterest-Cookie vorhanden ist" ([Pinterest: Enhanced Match](https://help.pinterest.com/de/business/article/enhanced-match)). Der Landesdatenschutzbeauftragte Baden-Württemberg formuliert es knapp: User-IDs oder Hashes als Ersatz für Identifikationsmerkmale sind keine Anonymisierung ([LfDI BW, FAQ Cookies und Tracking, Frage 3.2](https://www.baden-wuerttemberg.datenschutz.de/faq-zu-cookies-und-tracking-2/)).

## So findest du heraus, was deine Seite sendet

Du brauchst dafür kein Skript. Ein Browser reicht, wenn du ein paar Dinge beachtest.

1. **Frisches Profil.** Ein privates Fenster ohne Erweiterungen, damit weder alte Cookies noch ein Werbeblocker das Bild verfälschen.
2. **Vor der Entscheidung messen.** Entwicklertools öffnen (F12), Reiter „Netzwerk", dann die Seite laden — und das Cookie-Banner **nicht** anklicken. Alles, was jetzt in der Liste steht und nicht von deiner eigenen Domain kommt, geht ohne Einwilligung raus. Die Spalte „Domain" einblenden und danach sortieren hilft enorm.
3. **Den ganzen Weg gehen.** Produktseite, Warenkorb, Kasse, Bestellbestätigung. Die spannenden Sendungen kommen oft erst auf der letzten Seite.
4. **Nach „Ablehnen" erneut messen.** Ein Banner, das nach „Ablehnen" trotzdem nachlädt, ist schlimmer als keines.
5. **Nach „Akzeptieren" in die Nutzlasten sehen.** Einen Request anklicken, Reiter „Payload" beziehungsweise „Nutzlast": Dort siehst du Bestellwerte, Produkt-IDs und lange Hex-Werte, die verdächtig nach Hashes aussehen.
6. **Als HAR exportieren**, wenn du die Aufnahme archivieren oder jemandem zeigen willst.

Für eine dauerhafte Kontrolle eignet sich eine Content-Security-Policy im Nur-Bericht-Modus. Sie blockiert nichts, meldet aber jeden Verstoß in der Browser-Konsole — und, wenn du einen Endpunkt angibst, an deinen Server:

```http title="Response-Header"
Content-Security-Policy-Report-Only: default-src 'self'; report-to csp
Reporting-Endpoints: csp="https://shop.example/csp-reports"
```

Jede Ressource von einer fremden Domain erscheint dann als Verstoß. Das ist ein sehr ehrliches Inventar, weil es aus dem echten Browser deiner echten Besucher kommt.

## So stellst du es ab

### Selbst hosten, was sich selbst hosten lässt

Schriften, Icon-Fonts und JavaScript-Bibliotheken gehören auf den eigenen Server. Aufsichtsbehörden empfehlen das für Google Fonts seit 2022 ausdrücklich ([LfD Niedersachsen](https://www.lfd.niedersachsen.de/startseite/infothek/presseinformationen/abmahnungen-zu-datenschutzverstossen-auf-webseiten-vermeiden-google-fonts-lokal-einbinden-217509.html), [HBDI](https://datenschutz.hessen.de/datenschutz/internet-und-medien/google-fonts-abmahnungen)). Das ist die billigste Maßnahme überhaupt: einmal herunterladen, einbinden, fertig. Diese Seite hier macht es so — Martian Mono, Instrument Sans und ein kleines JetBrains-Mono-Subset liegen als WOFF2-Dateien im eigenen Repository.

### Laden erst nach der Entscheidung

Alles, was sich nicht selbst hosten lässt und eine Einwilligung braucht, darf erst nach der Einwilligung laden. Die DSK formuliert es klar: Während das Einwilligungsbanner angezeigt wird, werden zunächst keine weitergehenden Skripte und insbesondere keine Inhalte von fremden Servern geladen, „soweit eine Einwilligung hierfür erforderlich ist" (Orientierungshilfe, Rn. 121).

Für Google heißt das konkret: Der Consent Mode hat zwei Varianten. Im **„basic"**-Modus bleiben die Google-Tags blockiert, bis jemand mit dem Banner interagiert, und vorher geht laut Google nichts an Google. Im **„advanced"**-Modus laden sie sofort und senden Messungen ohne Cookies ([Google](https://developers.google.com/tag-platform/security/concepts/consent-mode?hl=de)). Was das auf einer Danke-Seite bedeutet, hast du oben gesehen. Eine Aussage einer Aufsichtsbehörde speziell zum „advanced"-Modus habe ich nicht gefunden. **Meine Einschätzung:** Wenn du das Urteil ernst nimmst, ist „basic" die Variante, die du erklären kannst, ohne zu argumentieren.

Für YouTube, Karten und ähnliche Einbettungen gibt es die bekannte Zwei-Klick-Lösung: Erst ein lokales Vorschaubild, das iframe lädt erst nach dem Klick. Die Variante `youtube-nocookie.com` ändert nichts daran, dass der Browser beim Laden des iframes eine Verbindung zu einem fremden Server aufbaut — und damit die IP-Adresse überträgt.

### Server-Side-Tagging löst das Problem nicht, es verlagert es

Beim serverseitigen Tagging schickt der Browser die Daten an deinen eigenen Server, und der leitet sie an Google, Meta & Co. weiter. Das kann Datenflüsse kontrollierbarer machen, weil du filtern kannst. In der Praxis bleibt es aber meist eine Übermittlung personenbezogener Daten — es sei denn, du anonymisierst vollständig, bevor etwas weitergeht, und dafür reichen Hashes oder IDs nicht. Der LfDI Baden-Württemberg schreibt: „Selbstverständlich müssen auch beim serverseitigen Tracking die Anforderungen des TTDSG und – da es sich bei der Übermittlung personenbezogener Daten um eine Verarbeitung handelt – der DS-GVO eingehalten werden" (FAQ, Frage 3.2; das TTDSG heißt heute TDDDG). Und Google selbst lässt die Einwilligung auch beim serverseitigen Tag Manager im Browser einholen ([Google](https://developers.google.com/tag-platform/tag-manager/server-side/consent-mode?hl=de)).

### Keine E-Mail-Adressen ohne Rechtsgrundlage an Werbeplattformen

Erweiterter Abgleich, Advanced Matching, erweiterte Conversions oder Konvertierungen, Enhanced Match — die Funktionen heißen bei jedem Anbieter anders und tun im Kern dasselbe: Sie schicken Kundendaten als Hash mit. Das ist eine bewusste Entscheidung, die du in der Konfiguration triffst, nicht ein Nebeneffekt. Schalte sie nur ein, wenn du dafür eine Rechtsgrundlage hast und das in deiner Datenschutzerklärung stimmt.

### Eine Content-Security-Policy als Schutzgeländer

Die Nur-Bericht-Variante von oben lässt sich scharf schalten. Dann lädt der Browser schlicht nichts, was nicht erlaubt ist — auch nicht das Plugin, das jemand in einem halben Jahr installiert. Diese Seite hier sendet folgende Policy (live gemessen am 17. September 2026):

```http title="Content-Security-Policy von www.jpkc.com/db/"
default-src 'self'; script-src 'self' 'unsafe-inline' blob:; worker-src 'self' blob:;
style-src 'self' 'unsafe-inline'; img-src 'self' data: blob:; font-src 'self';
connect-src 'self' blob:; manifest-src 'self'; object-src 'none'; base-uri 'self';
form-action 'self'; frame-ancestors 'self'; upgrade-insecure-requests
```

Beim Aufruf eines Artikels hat mein Browser ausschließlich Requests an `www.jpkc.com` gestellt. Ehrlicherweise: `'unsafe-inline'` für Skripte und Styles ist kein Vorbild für Sicherheit gegen eingeschleusten Code. Als Schutz gegen ungeplante Drittanbieter funktioniert die Policy trotzdem, denn fremde Hosts stehen nirgends drin. Für einen Shop mit Zahlungsanbietern wird die Liste länger — aber dann ist sie wenigstens eine bewusste Liste.

## WordPress und WooCommerce: die typischen Stellen

In WordPress-Projekten finde ich die Drittanbieter meistens an denselben Stellen.

- **Themes laden Google Fonts.** Die Regeln für das offizielle Theme-Verzeichnis verbieten Ressourcen von fremden Servern ohne Einwilligung — mit einer ausdrücklichen Ausnahme: Google Fonts ([Theme Review Handbook](https://make.wordpress.org/themes/handbook/review/required/), englisch). Ein Theme aus dem Verzeichnis darf Google Fonts also remote laden. Das Themes-Team selbst hat nach dem Münchner Urteil empfohlen, Schriften lokal einzubinden ([Beitrag vom 18.06.2022](https://make.wordpress.org/themes/2022/06/18/complying-with-gdpr-when-using-google-fonts/), englisch).
- **Das Emoji-Skript ist harmloser als sein Ruf.** WordPress bindet auf jeder Seite ein kleines Erkennungsskript ein. Das fragt aber nicht bei jedem Aufruf `s.w.org` an. Erst wenn der Browser Flaggen oder die neuesten Emoji nicht darstellen kann, lädt WordPress einen Polyfill vom eigenen Server; steht auf der Seite ein solches Emoji, holt der das Bild von `s.w.org` ([`emoji-loader.js`](https://raw.githubusercontent.com/WordPress/wordpress-develop/7.1/src/js/_enqueues/lib/emoji-loader.js) und [`formatting.php`](https://github.com/WordPress/wordpress-develop/blob/7.1/src/wp-includes/formatting.php#L6023), WordPress 7.1, englisch). Nur dann entsteht eine Verbindung.
- **WooCommerce Order Attribution** ist seit Version 8.5.0 standardmäßig aktiv ([WooCommerce 8.5.0](https://developer.woocommerce.com/2024/01/09/woocommerce-8-5-0-released/), englisch). Es speichert Herkunft, UTM-Parameter und Gerätetyp in den Bestelldaten und setzt dafür `sbjs_*`-Cookies im Browser. Laut Dokumentation werden diese Daten nur bei einer Bestellung ausgelesen und als Bestell-Metadaten im Shop gespeichert; an Automattic gehen nur bei vorherigem Opt-in statistische Attributionsdaten ohne Kundendaten ([WooCommerce-Doku](https://woocommerce.com/document/order-attribution-tracking/), englisch). Die Cookies fallen trotzdem unter § 25 TDDDG — ob sie ohne Einwilligung zulässig sind, ist eine eigene Prüfung. WooCommerce unterstützt dafür die WP Consent API.
- **Zahlungs-Plugins laden Stripe.js früher als nötig.** Das offizielle WooCommerce-Stripe-Plugin lädt es standardmäßig schon auf Produktseiten und im Warenkorb, nicht erst an der Kasse; abschalten lässt sich das per Filter ([Quellcode `class-wc-stripe-helper.php`](https://github.com/woocommerce/woocommerce-gateway-stripe/blob/develop/includes/class-wc-stripe-helper.php), englisch). Stripe selbst empfiehlt sogar, das Skript auf jeder Seite einzubinden ([Stripe: Including Stripe.js](https://docs.stripe.com/js/including), englisch), und schickt Signale zur Betrugserkennung an `m.stripe.com`. Diese Risikosignale lassen sich über den Parameter `advancedFraudSignals=false` abschalten, hCaptcha und Ereignisse der Eingabefelder aber nicht ([Stripe: Erweiterte Betrugserkennung](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection?locale=de-DE)). Ob du darauf verzichten willst, ist eine Abwägung zwischen Datenschutz und Betrugsschutz, keine reine Technikfrage.
- **Plugins, die „nur ein kleines Widget" einbauen.** Bewertungen, Chat, Newsletter-Pop-ups, Produktempfehlungen. Jedes davon ist ein Eintrag in der Liste aus dem Verfahren.

## Das Wichtigste in fünf Sätzen

1. Der BGH hat am 21. Juli 2026 entschieden, dass Betroffene sich gegen eine datenschutzwidrige Übermittlung auch mit einer **Unterlassungsklage nach deutschem Recht** wehren können — nicht, dass der Shop im Verfahren rechtswidrig gehandelt hat.
2. Im Verfahren ging es um **17 eingebundene Dienste** und die dabei übertragene IP-Adresse samt Geräte- und Nutzungsdaten, nicht um Namen oder E-Mail-Adressen.
3. Ob die Übermittlung rechtswidrig war, ob das Cookie-Banner trug und ob Wiederholungsgefahr besteht, **muss das OLG Frankfurt erst noch klären**.
4. In meinem Test-Shop gingen **ohne Einwilligung** Bestellnummer, Produkt und Preis an Google, **nach Einwilligung** die E-Mail-Adresse als Hash an TikTok, Pinterest und Microsoft, bei TikTok und Microsoft auch die Telefonnummer.
5. Die robusteste Antwort ist technisch: **selbst hosten, erst nach der Entscheidung laden, Hashes nicht für Anonymisierung halten und eine Content-Security-Policy als Geländer setzen.**

Wenn du nur eine Sache aus diesem Artikel umsetzt, dann die Messung: privates Fenster, F12, Netzwerk, einmal bis zur Bestellbestätigung durchklicken, ohne das Banner anzufassen. Die Liste, die du dann siehst, ist genau die Liste, um die es in diesem Verfahren ging.

Alle Aussagen in diesem Artikel habe ich vor der Veröffentlichung gezielt gegen die Primärquellen geprüft — wie das abläuft, beschreibe ich in [Adversarische Faktentreue für KI-Texte](https://www.jpkc.com/db/blog/faktentreue-review/). Und wenn du wissen willst, wie lange du die Daten aus deinen Formularen überhaupt behalten darfst: [Aufbewahrungsfristen für Bewerbungs- und Kontaktdaten](https://www.jpkc.com/db/blog/aufbewahrungsfristen-bewerbung-kontaktformular/).

## Quellen

**Das Verfahren**

- [BGH, Urteil vom 21.07.2026 – VI ZR 144/23](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2023/VI_ZR_144-23.pdf?__blob=publicationFile&v=1) (PDF)
- [OLG Frankfurt am Main, Urteil vom 30.03.2023 – 16 U 22/22](https://www.rv.hessenrecht.hessen.de/bshe/document/LARE230004412) (Hessenrecht)
- [LG Wiesbaden, Urteil vom 20.01.2022 – 10 O 14/21](https://www.rv.hessenrecht.hessen.de/bshe/document/LARE220002519) (Hessenrecht)
- [heise online, 16.09.2026: „Grundsatzurteil: BGH stärkt Verbraucherrechte bei Datenweitergabe im Netz"](https://www.heise.de/news/Grundsatzurteil-BGH-staerkt-Verbraucherrechte-bei-Datenweitergabe-im-Netz-11455760.html)

**Rechtsprechung**

- [EuGH, Urteil vom 04.09.2025 – C-655/23 (Quirin Privatbank)](https://curia.europa.eu/juris/document/document.jsf?docid=302595&doclang=DE)
- [EuGH, Urteil vom 29.07.2019 – C-40/17 (Fashion ID)](https://curia.europa.eu/juris/document/document.jsf?docid=216555&doclang=DE)
- [EuGH, Urteil vom 19.10.2016 – C-582/14 (Breyer)](https://curia.europa.eu/juris/document/document.jsf?docid=184668&doclang=DE)
- [EuGH, Urteil vom 04.05.2023 – C-300/21 (Österreichische Post)](https://curia.europa.eu/juris/document/document.jsf?docid=273284&doclang=DE)
- [BGH, Urteil vom 23.06.2026 – VI ZR 97/22](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2022/VI_ZR__97-22A.pdf?__blob=publicationFile&v=2) · [BGH, Urteil vom 12.05.2026 – VI ZR 375/24](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR_375-24.pdf?__blob=publicationFile&v=1) · [BGH, Urteil vom 14.10.2025 – VI ZR 431/24](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR_431-24.pdf?__blob=publicationFile&v=1) · [BGH, Urteil vom 18.11.2024 – VI ZR 10/24](https://www.bundesgerichtshof.de/SharedDocs/Entscheidungen/DE/Zivilsenate/VI_ZS/2024/VI_ZR__10-24A.pdf?__blob=publicationFile&v=1)
- [LG München I, Urteil vom 20.01.2022 – 3 O 17493/20 (Google Fonts)](https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2022-N-612) · [LG München I, Urteil vom 30.03.2023 – 4 O 13063/22 (Abmahnwelle)](https://www.gesetze-bayern.de/Content/Document/Y-300-Z-BECKRS-B-2023-N-6354)

**Behörden**

- [DSK: Orientierungshilfe für Anbieter:innen von digitalen Diensten, Version 1.2](https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf) (PDF)
- [LfDI Baden-Württemberg: FAQ zu Cookies und Tracking](https://www.baden-wuerttemberg.datenschutz.de/faq-zu-cookies-und-tracking-2/)
- [LfD Niedersachsen: Google Fonts lokal einbinden](https://www.lfd.niedersachsen.de/startseite/infothek/presseinformationen/abmahnungen-zu-datenschutzverstossen-auf-webseiten-vermeiden-google-fonts-lokal-einbinden-217509.html) · [HBDI: „Google Fonts"-Abmahnungen](https://datenschutz.hessen.de/datenschutz/internet-und-medien/google-fonts-abmahnungen)
- [Polizei Berlin: Gemeinsame Meldung mit der Staatsanwaltschaft vom 21.12.2022](https://www.berlin.de/polizei/polizeimeldungen/2022/pressemitteilung.1277732.php)

**Hersteller**

- [Google: Consent mode overview](https://developers.google.com/tag-platform/security/concepts/consent-mode?hl=de) · [Google: Consent mode mit serverseitigem Tag Manager](https://developers.google.com/tag-platform/tag-manager/server-side/consent-mode?hl=de) · [Google Ads-Hilfe: erweiterte Conversions](https://support.google.com/google-ads/answer/13258081?hl=de) · [Google Fonts FAQ](https://fonts.google.com/faq#privacy) (englisch)
- [Meta: Erweiterter Abgleich](https://developers.facebook.com/documentation/meta-pixel/advanced/advanced-matching?locale=de_DE) · [Microsoft: Erweiterte Konvertierungen](https://learn.microsoft.com/de-de/advertising/msa-help/hlp_ba_conc_uet_enhancedconversions) · [Pinterest: Enhanced Match](https://help.pinterest.com/de/business/article/enhanced-match)
- [Stripe: Erweiterte Betrugserkennung](https://docs.stripe.com/disputes/prevention/advanced-fraud-detection?locale=de-DE) · [WooCommerce: Order Attribution Tracking](https://woocommerce.com/document/order-attribution-tracking/) (englisch) · [WordPress: Theme Review Handbook](https://make.wordpress.org/themes/handbook/review/required/) (englisch)