Deine Warenkorbabbruch-Mail braucht eine Einwilligung — und dein Kundenkonto ist keine

Es gibt eine Mail, die fast jeder Shop verschickt und über die fast niemand nachdenkt: „Du hast noch etwas im Warenkorb." Sie ist schnell eingerichtet, sie bringt messbar Umsatz, und sie fühlt sich harmlos an — schließlich erinnert man den Kunden nur an etwas, das er selbst angefangen hat.

Die Landesbeauftragte für Datenschutz und Informationsfreiheit NRW sieht das anders. In ihrem 31. Tätigkeitsbericht, Kapitel 9.7, hat sie einen Beschwerdefall bewertet und kommt zu einem Ergebnis, das die meisten Abandoned-Cart-Setups in Deutschland betrifft: Diese Mails sind Werbung. Und Werbung per E-Mail braucht eine Einwilligung.

Keine Rechtsberatung. Ich bin Entwickler, kein Anwalt. Dieser Beitrag ordnet eine Behördenbewertung ein und zeigt die technische Umsetzung — er ersetzt keine anwaltliche Prüfung deines konkreten Falls.

Was ich liefern kann, ist das, was im Bericht tatsächlich steht — ich habe die PDF gelesen, nicht nur die Pressemeldungen darüber — und die technische Antwort darauf: welche Abfrage deinem Workflow fehlt und an welcher Stelle sie hingehört.

Der Fall

Ein Kunde legte Produkte in den Warenkorb eines Online-Shops und schloss die Bestellung nicht ab. Danach bekam er drei E-Mails hintereinander. Er beschwerte sich bei der Aufsichtsbehörde.

Der Händler argumentierte, wie vermutlich die meisten argumentieren würden: Das sei keine Werbung, sondern „Servicekommunikation" im Interesse des Kunden.

Die LDI NRW zerlegt dieses Argument in zwei Schritten.

Schritt eins: Das vorvertragliche Verhältnis ist beendet

Die naheliegende Rechtsgrundlage wäre Art. 6 Abs. 1 lit. b DS-GVO — Datenverarbeitung zur Durchführung vorvertraglicher Maßnahmen. Der Kunde hat ja selbst angefangen, etwas zu bestellen.

Der Bericht lässt das nicht gelten:

Da Kund*innen beim Verlassen einer Webseite ohne Einkauf aber deutlich zeigen, dass sie einen Vertrag nicht mehr eingehen wollen, können sich Online-Händler*innen bei der Warenkorberinnerung nicht darauf berufen. Vielmehr ist das vorvertragliche Verhältnis damit beendet.

Das ist der härteste Satz des Kapitels. Der Abbruch ist nicht ein Pausieren, das man wieder aufnehmen darf — er ist das Ende.

Und einen Satz später wird klar, warum „Service" nicht trägt:

Die betroffene Person stellt auch nicht den Antrag, an den Warenkorb erinnert zu werden.

Ein Service ist etwas, das jemand angefordert hat. Die Erinnerungsmail erfolgt, so der Bericht wörtlich, „ausschließlich auf Initiative der Online-Händler*innen".

Schritt zwei: Werbung bleibt Werbung, auch über den Umweg DS-GVO

Bleibt das berechtigte Interesse nach Art. 6 Abs. 1 lit. f DS-GVO — die Abwägung. Hier kommt die Einordnung, die der Rest des Kapitels trägt:

Kaufabbruch- oder Erinnerungsmails verfolgen den Zweck der Umsatzsteigerung mit Bezug auf ein zuvor beobachtetes Kaufverhalten und sind daher als Online-Werbung („Retargeting") anzusehen.

Damit ist die Mail Werbung, und damit greift das Wettbewerbsrecht in die Abwägung ein. Der Bericht formuliert die Verzahnung in einem Satz, den man sich merken sollte:

Soweit das UWG Werbung nicht zulässt, kann dies auch nicht über die DS-GVO erlaubt werden. Umgekehrt ist nach dem UWG explizit zulässige E-Mail-Werbung auch nach der DS-GVO grundsätzlich zulässig.

Die Konsequenz: Du kannst dir die Interessenabwägung nicht zurechtlegen. Die Frage „darf ich das senden?" wird im UWG beantwortet, nicht in der DS-GVO.

Und dort lautet die Antwort für E-Mail-Werbung: nur mit vorheriger ausdrücklicher Einwilligung (§ 7 Abs. 2 Nr. 2 UWG). Kleine Randbemerkung für alle, die den Bericht selbst nachlesen: Dort steht an dieser Stelle „§ 7 Abs. 2 Nr. 1" — das ist ein Zitierfehler, Nr. 1 regelt Telefonwerbung. Gemeint ist Nr. 2.

Die Bestandskundenausnahme — und warum sie dein Setup meistens nicht rettet

Es gibt einen Weg ohne Einwilligung. Er steht in § 7 Abs. 3 UWG, und der Bericht zitiert ihn vollständig. Entscheidend ist: Die vier Bedingungen gelten kumulativ. Eine reicht nicht.

Im entschiedenen Fall scheiterte es an Nummer 1:

Der Beschwerdeführer war noch kein Kunde des Online-Händlers geworden, da er die Erstbestellung abgebrochen hatte und somit noch kein vorheriger Kaufvertrag zustande gekommen war. Die Datenverarbeitung war damit unzulässig.

An dieser Stelle ein Hinweis zur Quellenlage, weil in mehreren Meldungen zu diesem Fall Formulierungen kursieren, die so nicht im Bericht stehen: Den oft zitierten Satz, ein bloßes Kundenkonto oder ein gefüllter virtueller Warenkorb begründe den Bestandskundenstatus nicht, gibt es im Kapitel nicht. Der Bericht begründet nur fallbezogen. Die Richtung ist dieselbe, der Satz ist trotzdem eine Zuspitzung Dritter — zitiere ihn nicht als Wortlaut der Behörde.

Und noch ein Punkt zur Einordnung des Ganzen: Ein Tätigkeitsbericht ist die Rechtsauffassung einer Aufsichtsbehörde, kein Urteil. Allerdings hat das Landgericht Köln am 21.07.2026 in einem anderen Verfahren eine einstweilige Verfügung gegen Kaufabbruch-Mails erlassen (Az. 31 O 363/26), mit Ordnungsgeldandrohung bis 250.000 Euro und gerichtet auch persönlich gegen die Geschäftsführer. Der Beschluss erging ohne mündliche Verhandlung, ist nicht rechtskräftig und öffentlich bislang nur über die Darstellung der prozessführenden Kanzlei bekannt — belastbar ist er also nicht, aber er zeigt, dass das Thema nicht in der Behördenakte bleibt.

Inventur: Was verschickt dein Shop überhaupt?

Bevor du irgendetwas umbaust, musst du wissen, wer sendet. Und das ist in Shopware unangenehmer, als es klingt, weil es dafür keine zentrale Stelle gibt.

Shopware hat keinen nativen Warenkorbabbruch-Auslöser im Flow Builder. Es gibt kein Core-Event „Warenkorb verlassen". Wenn in deinem Shop solche Mails rausgehen, kommen sie aus genau einer dieser vier Richtungen:

1. Ein Plugin mit eigener Logik und eigenem Mailversand. Prüfen: Erweiterungen durchsehen, bei jedem Kandidaten in die Konfiguration schauen, ob der Versand aktiv ist.
2. Ein App-Flow-Trigger. Seit 6.5.3 können Apps eigene Auslöser in den Flow Builder einhängen. Im Flow Builder nach Auslösern suchen, die nicht im Shopware-Standard vorkommen.
3. Ein n8n-Workflow (oder ein anderes Automatisierungswerkzeug) auf einem Webhook oder einem Zeitplan.
4. Ein externer E-Mail-Dienst — Klaviyo, Dotdigital, Brevo und Vergleichbare bringen Abandoned-Cart als Standardfunktion mit und tracken oft über ein eigenes Skript im Storefront-Theme. Das läuft völlig an Shopware vorbei und wird bei Inventuren regelmäßig vergessen.

Geh alle vier durch, nicht nur die naheliegende. Erfahrungsgemäß findet man genau eine Quelle, hört auf zu suchen, und die zweite läuft weiter.

Ein Detail, das bei der Inventur hilft: cart ist in Shopware keine API-Entität. Der persistierte Warenkorb liegt in der Datenbank, hat aber keine DAL-Definition und taucht deshalb nicht unter /api/search/… auf. Wenn ein externes Werkzeug offene Warenkörbe über die Admin-API liest, dann nur, weil ein Plugin sie in eine eigene Entität spiegelt. Das ist ein brauchbarer Hinweis darauf, wo du suchen musst.

Die eine Abfrage, die fehlt

Egal welche der vier Quellen bei dir sendet: Die Frage, die der Workflow beantworten muss, ist immer dieselbe.

Existiert zu dieser E-Mail-Adresse ein tatsächlich zustande gekommener Kauf?

Nicht „gibt es ein Kundenkonto". Nicht „war der Checkout weit fortgeschritten". Ein abgeschlossener Kauf.

Über die Admin-API ist das eine einzige Suche:

POST /api/search/order

{
  "limit": 1,
  "total-count-mode": 1,
  "filter": [
    {
      "type": "equals",
      "field": "orderCustomer.email",
      "value": "kunde@example.com"
    },
    {
      "type": "not",
      "operator": "and",
      "queries": [
        {
          "type": "equals",
          "field": "stateMachineState.technicalName",
          "value": "cancelled"
        }
      ]
    }
  ],
  "includes": {
    "order": ["id", "orderNumber", "orderDateTime"]
  }
}

Die Antwort steht in meta.total: größer null heißt Bestandskunde, null heißt neuer Interessent.

Drei Dinge daran sind wichtig, und alle drei werden gern falsch gemacht.

Der Filter geht auf die Adresse, nicht auf die customerId. Gastbestellungen hängen an keinem Konto. Und ein Kunde, der sich mit derselben Mailadresse ein zweites Konto angelegt hat, hat zwei customerIds und eine Kaufhistorie. Die Adresse ist das, worauf § 7 Abs. 3 Nr. 1 abstellt — also ist die Adresse der richtige Schlüssel.

Stornierte Bestellungen zählen nicht. Deshalb der not-Block auf cancelled. Die Statusmaschine order.state kennt genau vier Zustände: open, in_progress, completed, cancelled.

limit: 1 plus total-count-mode reicht. Du brauchst keine Bestellliste, du brauchst ein Ja oder Nein. Die Rolle der Integration kommt mit order:read aus.

Die Grenzfälle — zählt eine widerrufene Bestellung? eine, die nie bezahlt wurde? — beantwortet weder die API noch ich. Das ist eine juristische Abgrenzung, und sie gehört in eine Kanzlei. Was du technisch tun kannst: Die Abfrage so bauen, dass sich die Statusliste an einer Stelle ändern lässt, wenn die Antwort kommt.

Das Gate gehört vor den Versand

Der zweite Teil ist Architektur, nicht Recht, und er entscheidet darüber, ob die Lösung hält.

Die Versuchung ist, die Prüfung hinten anzubauen: Liste erzeugen, Mails rausschicken, hinterher bereinigen. Oder ein Reporting bauen, das zeigt, wie viele Nicht-Bestandskunden angeschrieben wurden.

Beides hilft nicht. Eine versendete Mail lässt sich nicht zurückholen. Ein Workflow, der erst sendet und danach filtert, hat den Verstoß bereits begangen — die Bereinigung dokumentiert ihn nur sauberer.

Die Prüfung gehört deshalb zwischen die Kandidatenliste und den Mail-Knoten:

In n8n ist das ein IF-Knoten vor dem Mail-Node, in einem Flow Builder eine Regel vor der Aktion. Der Aufwand ist klein. Entscheidend ist die Reihenfolge: Der teure Teil (die API-Abfrage) läuft nur für die Kandidaten ohne Einwilligung, und niemand erreicht den Mail-Knoten, ohne vorher durch das Gate gegangen zu sein.

Zwei praktische Hinweise zum Betrieb:

• Fehler beim Prüfen heißt nicht senden. Wenn die Order-Abfrage mit einem Timeout zurückkommt, ist das Ergebnis „unbekannt", nicht „erlaubt". Den Kandidaten überspringen und beim nächsten Lauf erneut prüfen.
• Ergebnis protokollieren, nicht nur die Entscheidung. Welche Adresse, welcher Grund, welcher Zeitpunkt. Bei einer Beschwerde ist das der Unterschied zwischen „wir haben ein Gate" und „wir können zeigen, dass das Gate gegriffen hat".

Der Einwilligungsnachweis in Shopware

Hier wird es dünn, und es hilft nichts, das zu beschönigen.

Shopware kennt genau einen nativen Einwilligungsnachweis: die Newsletter-Anmeldung. Die Entität newsletter_recipient hat ein Feld status mit den Werten notSet, optIn, optOut und direct sowie ein confirmedAt. Ein bestätigter Double-Opt-in steht dort als optIn mit gesetztem Zeitstempel.

Das ist ein sauberer Nachweis — für den Newsletter. Eine Einwilligung deckt den Zweck ab, für den sie erteilt wurde. Wer „Ja" zum Newsletter gesagt hat, hat nicht „Ja" zu Warenkorberinnerungen gesagt. Dass das Feld technisch verfügbar ist und sich im Workflow bequem abfragen ließe, macht es nicht zur passenden Rechtsgrundlage.

Was der Bericht als Weg beschreibt, ist eine eigene Einwilligung:

Dabei könnte eine datenschutzkonforme Einwilligung – wie bei der Anmeldung zu einem Newsletter – mit einer aktiv anzuklickenden Checkbox und einem sog. Double-Opt-in-Prozess eingeholt werden.

Technisch bedeutet das in Shopware: eine eigene, nicht vorbelegte Checkbox im Checkout oder in der Registrierung, mit eigenem Text zum Zweck „Erinnerung an nicht abgeschlossene Bestellungen", und ein eigener Speicherort. Ein Custom Field auf customer reicht für registrierte Kunden; für Gäste braucht es eine eigene Entität, weil es kein Konto gibt, an dem die Zustimmung hängen könnte. In beiden Fällen gehören drei Dinge in den Datensatz: Zeitpunkt, Wortlaut des Einwilligungstextes zum Zeitpunkt der Erteilung, und der Bestätigungszeitpunkt aus dem Double-Opt-in.

Ob eine konkrete Formulierung oder Platzierung trägt, beantworte ich nicht — das ist genau die Frage, die ein Anwalt beantworten muss, bevor die Checkbox live geht.

Die Variante, die immer erlaubt bleibt

Es gibt einen Weg, den abgebrochenen Warenkorb zurückzuholen, der gar keine Einwilligung braucht: nicht senden.

Der Unterschied liegt in der Richtung. Eine Mail ist eine Ansprache, die der Händler initiiert — das ist der Punkt, an dem das UWG greift. Ein Hinweis, den der Kunde sieht, weil er von selbst wiederkommt, ist keine Direktwerbung. Er verlässt den Shop nicht.

Konkret heißt das:

• Der Warenkorb überlebt die Session und ist beim nächsten Besuch noch da.
• Im Kundenkonto gibt es eine sichtbare Stelle „Dein offener Warenkorb" statt nur einer stillen Wiederherstellung.
• Wiederkehrende Besucher bekommen einen unaufdringlichen Hinweis im Shop, keine Mail.

Das konvertiert schlechter als eine Mailserie. Es konvertiert aber ohne Einwilligung, ohne Widerspruchsliste und ohne die Frage, wer bei einer Beschwerde den Kopf hinhält.

Und es hat einen zweiten Vorteil, der unterschätzt wird: Du kannst die Abbrecher trotzdem auswerten. Die Daten im Shop zu haben ist das eine, sie zur Ansprache zu nutzen das andere — das Datenschutzproblem entsteht erst beim zweiten Schritt. Aus genau diesem Grund macht unser eigenes Plugin Novastrix Offene Warenkörbe nur den ersten: Es zeigt im Admin, welche Warenkörbe offen stehen, mit Artikelanzahl, Warenwert, Verkaufskanal und letzter Aktivität, und markiert sie als erledigt, sobald bestellt wurde. Einen Mailversand hat es nicht — und bekommt auch keinen.

Was es seit Kurzem zusätzlich führt, ist genau die Angabe aus dem Gate oben: ob unter der E-Mail-Adresse des Warenkorbs jemals eine nicht stornierte Bestellung zustande kam. Mit drei Zuständen, nicht zwei — „Ja", „Nein" und „ungeprüft". Eine Adresse, für die der Hintergrund-Task noch nicht gelaufen ist, darf nicht wie ein geprüftes „Nein" aussehen, sonst versteckt sich ein defekter Job hinter einer plausiblen Antwort.

Dass die Einwilligung dort nicht mitverwaltet wird, ist Absicht: Ob eine Einwilligung trägt, hängt an ihrem Wortlaut und ihrer Platzierung, nicht an einem Datenbankfeld. Ein Plugin, das so ein Feld anbietet, verspricht eine Sicherheit, die es nicht halten kann.

Wenn du so eine Übersicht selbst baust und später doch mailen willst, denk deshalb an beide Hälften: Die Kaufhistorie ist eine Tatsache aus deinen eigenen Daten und lässt sich automatisch ermitteln. Die Einwilligung ist es nicht — die gehört in das System, das tatsächlich versendet, und ihr Text gehört vorher zu jemandem, der dafür haftet.

Was heute zu tun ist

1. Inventur. Alle vier möglichen Quellen durchgehen — Plugin, App-Flow-Trigger, n8n, externer E-Mail-Dienst. Aufschreiben, was tatsächlich sendet.
2. Gate einbauen. Die Order-Abfrage auf orderCustomer.email vor den Mail-Knoten hängen, mit „im Zweifel nicht senden" als Fehlerverhalten.
3. Einwilligung klären. Wenn du die Mails behalten willst: eigene Checkbox, eigener Zweck, Double-Opt-in, Nachweis mit Zeitstempel und Textfassung. Vorher mit jemandem sprechen, der dafür haftet.
4. Onsite-Pfad bauen. Für alle, die durch das Gate fallen, ist das die Alternative — nicht gar nichts.

Die Behördenbewertung ist kein Urteil, und nichts davon muss heute Nacht fertig sein. Aber der Aufwand ist eine Abfrage und eine Bedingung. Das ist wenig gegen das Risiko, es nach der ersten Beschwerde unter Zeitdruck zu machen.

Haftungsausschluss

Dieser Beitrag gibt meinen Stand vom 27. Oktober 2026 wieder und dient der allgemeinen Information. Er ist keine Rechtsberatung und begründet kein Mandatsverhältnis. Ich bin Entwickler, kein Rechtsanwalt.

Die zitierte Bewertung stammt aus dem Tätigkeitsbericht einer Aufsichtsbehörde — das ist deren Rechtsauffassung, kein Gesetz und kein Urteil. Ob sie auf deinen Shop zutrifft, hängt an Umständen, die ich nicht kenne: wie deine Adressen erhoben wurden, was in deinen Einwilligungstexten steht, welche Mails tatsächlich rausgehen. Gerichte können das abweichend sehen, und die Rechtslage kann sich nach dem Erscheinen dieses Beitrags geändert haben.

Lass die konkrete Bewertung deines Setups von einer Anwältin oder einem Anwalt für IT- und Wettbewerbsrecht prüfen, bevor du darauf Entscheidungen stützt. Für Schäden aus der Anwendung der hier beschriebenen Technik übernehme ich keine Haftung.

Quellen: 31. Bericht der Landesbeauftragten für Datenschutz und Informationsfreiheit NRW (PDF), Kapitel 9.7 „Dürfen die das? Wenn Online-Händler*innen an den Warenkorb erinnern", S. 82–84.

Du hast so einen Workflow laufen und willst das Gate einbauen, bevor jemand anderes die Frage stellt? Meldet euch.