Wachstum mit Datenschutz: personalisieren mit Einwilligung

Personalisierung funktioniert noch, nur das Fundament ist ein anderes

Jeder Entwickler, dem Wachstum am Herzen liegt, steckt 2026 im selben Zwiespalt. Personalisierung bringt Umsatz. Aber die Werkzeuge, mit denen die Branche bisher personalisiert hat, also Cookies von Drittanbietern, das Verfolgen von Menschen über fremde Websites hinweg und stille Profile aus einer Spur von Klicks, sind entweder von den Browsern eingeschränkt oder streng reguliert.

Die Browser waren zuerst dran. Safari begrenzt Cookies, die ein Skript schreibt, seit 2019 auf sieben Tage,¹ und blockiert seit 2020 standardmäßig Cookies für Inhalte von fremden Websites.² Firefox gibt jeder Website standardmäßig einen eigenen Cookiespeicher, sodass ein Tracker niemandem von einer Seite zur nächsten folgen kann.³ Chrome ist die Ausnahme: Google hat 2025 entschieden, beim bisherigen Weg zu bleiben und Nutzern die Wahl über Cookies von Drittanbietern zu lassen, und hat die meisten Technologien der Privacy Sandbox eingestellt, die sie ersetzen sollten.⁴ Tot sind Cookies von Drittanbietern also nicht überall. Ein Geschäft sollte man trotzdem nicht darauf bauen.

Auch das Recht hat sich bewegt. Für einen Shop in Deutschland braucht das Speichern von Informationen auf dem Gerät eines Besuchers und das Auslesen von dort eine Einwilligung, nach § 25 des Telekommunikation Digitale Dienste Datenschutz Gesetzes (TDDDG). Ausgenommen ist nur, was unbedingt erforderlich ist, damit du einen Dienst bereitstellen kannst, den der Nutzer ausdrücklich gewünscht hat.⁵ Die Aufsicht über Unternehmen liegt bei der Datenschutzbehörde des Bundeslands, in dem das Unternehmen sitzt.⁶ Gemeinsam haben diese Behörden in ihrer Konferenz (DSK) eine Orientierungshilfe für digitale Dienste veröffentlicht, und die ist an dem Punkt, um den es hier geht, deutlich: Mit dem Aufruf eines Webshops ist der Basisdienst gewünscht, nicht automatisch jede Zusatzfunktion, und "unbedingt erforderlich" heißt technisch erforderlich, nicht wirtschaftlich nützlich.⁷ Inhalte danach auszuwählen, was du aus dem Verhalten eines Menschen über seine Interessen schließt, fällt unter keine dieser Ausnahmen. Dafür brauchst du ein Ja.

Das alte Spielbuch ist vorbei: alles erfassen, später segmentieren, sich nie entschuldigen. Geblieben ist, dass Menschen relevante Erlebnisse lieber mögen. Sie kaufen eher, wenn du ihnen zeigst, was sie interessiert, und sie freuen sich über eine Mail, die zur richtigen Zeit mit dem richtigen Angebot kommt. Der Unterschied ist, dass du dir die Daten heute verdienen musst.

Durch den ganzen Artikel begleitet uns ein erfundenes Unternehmen. Elbspeiche ist ein Onlineshop für Fahrräder in Hamburg, betrieben von Jonas, unter elbspeiche.example. Er verkauft rund 2.400 Räder und ein paar Tausend Zubehörteile. Niemand davon ist echt, und jede Zahl unten gehört zum Beispiel, erfunden, damit jeder Schritt sichtbar wird.

Warum Personalisierung durch Überwachung nie besonders gut war

Bevor wir die Alternative bauen, lohnt sich ein ehrlicher Blick darauf, warum der alte Weg enttäuscht hat, nicht nur rechtlich, sondern ganz praktisch.

Websiteübergreifendes Tracking brachte Reichweite, keine Genauigkeit. Du konntest jemandem durchs Netz folgen und ein Profil bauen, aber das Profil war voller Rauschen. Wer ein Geschenk für den Partner suchte, bekam wochenlang Werbung für Dinge, die er für sich selbst nie kaufen würde. Wer auf dem Handy Preise verglich, war auf dem Laptop ein anderer Mensch.

Und weil die Daten heimlich gesammelt wurden, gab es keine Rückmeldung. Niemand konnte eine falsche Vermutung korrigieren. Das System optimierte auf das, was es aus Krümeln schloss, nicht auf das, was der Mensch tatsächlich wollte.

Ein Beispiel: Eine Besucherin liest bei Elbspeiche einen Artikel über Laufräder für Kinder, weil ihr Neffe Geburtstag hat. Im alten Modell ist sie danach monatelang in drei Werbenetzwerken "Elternteil eines Kleinkinds". Sie hat keine Kinder, sie kauft kein zweites Laufrad, und gefragt hat sie niemand. Eine einzige Frage, "Für wen ist das Rad?", hätte es in einer Sekunde richtig gemacht.

Drei Schichten ersetzen den alten Stapel

Der Ersatz ist kein einzelnes Werkzeug. Es sind drei Schichten, die zusammenarbeiten, und jede hängt an der darunter.

Lies es von oben nach unten. Die Einwilligung steht zuerst, weil alles andere aus ihr liest. Die Erfassung steht an zweiter Stelle, weil die meisten Shops genau hier undicht sind: Ein Tag, der feuert, bevor der Besucher gewählt hat, ist ein Problem, das später kein noch so kluges Modell repariert. Und die Entscheidung weiter unten endet nie im Nichts: Wer Nein sagt, bekommt trotzdem einen Shop, der funktioniert und sich nach dem richtet, was er gerade tut.

Gehen wir die Schichten der Reihe nach durch.

Schicht eins: eine Einwilligung, die tut, was sie verspricht

Die meisten Einwilligungslösungen sind Theater. Ein Banner erscheint, der Besucher drückt "Alle akzeptieren", weil das der schnellste Weg zur Seite ist, und das Unternehmen nennt das eine informierte Einwilligung. Oder der Knopf zum Ablehnen ist schwerer zu finden als der zum Zustimmen. Genau das schließen die deutschen Behörden aus: Ablehnen darf keinen Mehraufwand gegenüber dem Zustimmen bedeuten, etwa erst auf einer zweiten Ebene, die Optionen sind gleichwertig zu gestalten, nichts Einwilligungsbedürftiges darf vorab aktiviert sein, und der Widerruf muss so einfach sein wie die Erteilung.⁸

Der Maßstab einer Aufsichtsbehörde ist, ob der Mechanismus tut, was er sagt. Stoppt jeder Tag, wenn jemand ablehnt? Gilt die Wahl auf der nächsten Seite und der übernächsten? So halte ich den Einwilligungsstatus in Rails fest:

module ConsentManagement
  class ConsentState
    PURPOSES = {
      essential:       { requires_consent: false }, # Login, Warenkorb, Sicherheit
      analytics:       { requires_consent: true },  # wie der Shop genutzt wird, nur in Summe
      personalisation: { requires_consent: true },  # Inhalte nach Interessen oder Verhalten
      advertising:     { requires_consent: true }   # Werbemessung und Zielgruppen
    }.freeze

    # Parameter des Google Consent Mode, die jeder Zweck steuert
    CONSENT_MODE_MAP = {
      analytics:       [:analytics_storage],
      personalisation: [:personalization_storage],
      advertising:     [:ad_storage, :ad_user_data, :ad_personalization]
    }.freeze

    def initialize(record)
      @record = record # der jüngste ConsentRecord, oder nil, solange keine Wahl getroffen ist
    end

    def granted?(purpose)
      return true unless PURPOSES.dig(purpose, :requires_consent)
      return false unless @record # noch keine Wahl heißt Nein

      @record.granted_purposes.include?(purpose.to_s)
    end

    def google_consent_signals
      signals = { security_storage: "granted", functionality_storage: "granted" }
      CONSENT_MODE_MAP.each do |purpose, keys|
        keys.each { |key| signals[key] = granted?(purpose) ? "granted" : "denied" }
      end
      signals
    end
  end
end

Jeder Datensatz hält fest, was erlaubt wurde, was abgelehnt wurde, wo die Wahl fiel (im Banner oder auf der Einstellungsseite), welche Fassung des Wortlauts zu sehen war und wann. Der entscheidende Punkt: Die Einwilligung wird geprüft, wenn etwas läuft, nicht nur, wenn Daten erfasst werden. Eine Wahl kann jederzeit zurückgenommen werden, und das System muss das schon bei der nächsten Anfrage respektieren.

Die erste Fassung dieses Artikels hat Österreich, Deutschland und die Schweiz mit unterschiedlichen Voreinstellungen behandelt. Für einen Shop in Deutschland gibt es eine Regel: Noch keine Wahl heißt Nein. Wie sich die deutschsprachigen Märkte im Detail unterscheiden, steht in Cookies, Consent und das ePrivacy Chaos in DACH.

Durchgerechnetes Beispiel: die Wahl einer Besucherin bei Elbspeiche

Eine Besucherin kommt über eine Suche nach "Gravelbike unter 1.500 €". Das Banner bietet vier Schalter, alle aus, mit "Alle akzeptieren" und "Alle ablehnen" nebeneinander und gleich groß. Sie schaltet Personalisierung ein und lässt den Rest aus.

Ihr Datensatz: erlaubt personalisation, abgelehnt analytics und advertising, Quelle banner, Fassung 7 des Wortlauts, 10:42 Uhr. Der Aufruf granted?(:personalisation) liefert true, granted?(:advertising) liefert false. Die Signale an Googles Tag lauten personalization_storage erlaubt, ad_storage, ad_user_data, ad_personalization und analytics_storage abgelehnt. Zwei Tage später öffnet sie die Einstellungen über den Link im Footer und schaltet Personalisierung wieder aus. Die nächste Seite, die sie lädt, zeigt die Fassung nach Kontext, und die Personalisierung liest ihre Historie nie wieder.

Der Consent Mode bringt die Wahl zu Googles Tags

Wenn du Googles Tags nutzt, ist der Consent Mode der Weg, auf dem die Wahl dort ankommt. Er hat sieben Parameter: ad_storage, analytics_storage, ad_user_data, ad_personalization, functionality_storage, personalization_storage und security_storage.⁹

Es gibt ihn in zwei Formen. Im einfachen Modus (basic) sind Googles Tags blockiert, bis der Besucher wählt, und wenn er ablehnt, wird gar nichts gesendet. Im erweiterten Modus (advanced) laden die Tags sofort, die Einwilligung steht standardmäßig auf abgelehnt, und solange sie abgelehnt ist, senden sie Messungen ohne Cookies, mit denen Google modelliert, was es nicht beobachten kann.⁹ Die erste Fassung dieses Artikels hat behauptet, der erweiterte Modus "holt 10 bis 20 % deiner Attributionsdaten zurück". Eine Quelle für diese Zahl habe ich nicht gefunden, also ist sie gestrichen. Ob der erweiterte Modus für einen deutschen Shop überhaupt in Frage kommt, ist eine Abwägung für das Unternehmen und seine Beratung, und die nehme ich in Event Tracking und Consent Mode auseinander.

Die Voreinstellung, gesetzt bevor irgendein Google Tag lädt, ist für jeden Besucher in Deutschland dieselbe:

window.dataLayer = window.dataLayer || [];
function gtag(){dataLayer.push(arguments);}

gtag('consent', 'default', {
  'ad_storage': 'denied',
  'analytics_storage': 'denied',
  'ad_user_data': 'denied',
  'ad_personalization': 'denied',
  'personalization_storage': 'denied',
  'functionality_storage': 'granted',
  'security_storage': 'granted',
  'wait_for_update': 500
});

Ein Beispiel: Die Besucherin aus dem letzten Abschnitt lädt ihre erste Seite um 10:41 Uhr, bevor sie das Banner berührt. Die Voreinstellung oben läuft zuerst, also starten Googles Tags mit allem auf abgelehnt, außer Funktion und Sicherheit. Um 10:42 Uhr schaltet sie Personalisierung ein, und der Shop ruft gtag('consent', 'update', ...) mit den Signalen aus google_consent_signals auf. Nur personalization_storage wechselt auf erlaubt. Werbung bleibt abgelehnt, also wird kein Werbecookie geschrieben, und keine Remarketingliste erfährt je von ihr.

Schicht zwei: Erfassung auf deinem eigenen Server

Tracking im Browser heißt: Das Skript jedes Anbieters läuft im Browser des Besuchers und schickt Daten an die eigene Domain des Anbieters. Was jedes Skript sammelt, kontrollierst du kaum, und jedes kostet Ladezeit.

Serverseitige Erfassung dreht das um. Der Browser schickt Ereignisse an deinen eigenen Server. Dein Server entscheidet, was jedes Ziel bekommen darf, entfernt, was es nicht sehen soll, und gibt den Rest weiter. Die Vorteile sind echt:

• Kontrolle. Dein Server entscheidet, welche Felder bei welchem Anbieter ankommen. Eine Mailadresse kann zurückgehalten oder gehasht und nur dorthin geschickt werden, wo eine Einwilligung zur Werbung vorliegt.
• Tempo. Ein kleines Skript auf der Seite statt eines Dutzends Tags von Anbietern.
• Durchsetzung an einer Stelle. Die Prüfung der Einwilligung läuft einmal, auf dem Server, bevor irgendetwas weitergeht.

Was serverseitige Erfassung nicht tut: das Recht ändern. § 25 TDDDG ist nach Lesart der deutschen Behörden technikneutral formuliert und erfasst alle Techniken, mit denen Informationen auf dem Endgerät gespeichert oder ausgelesen werden, und eingebundene Drittdienste sind einzeln zu benennen, ein allgemeiner Hinweis auf "Partner" genügt nicht.¹⁰ Ein Aufbau, der abgelehnte Besucher an eine Werbeplattform weiterleitet, weil das Pixel nicht mehr im Browser läuft, hat kein Problem gelöst, sondern eines versteckt. Dasselbe gilt für Werbeblocker: Ein Endpunkt auf der eigenen Domain wird seltener blockiert, aber wer Tracking blockiert, hat eine Wahl getroffen, und die Prüfung der Einwilligung gilt auch für ihn.

module ServerSideTracking
  class EventProcessor
    def process(event:, consent:, user:)
      return unless valid?(event)

      event = event.merge(event_id: event[:event_id] || SecureRandom.uuid) # mit dem Browser geteilt, zur Deduplizierung
      destinations(consent).each { |d| d.forward!(payload_for(d, event, user, consent)) }
      InternalCounts.increment!(event[:name]) # eine Summe, ohne Nutzer, ohne Sitzung
    end

    private

    def destinations(consent)
      list = []
      list << GA4Forwarder.new if consent.granted?(:analytics)
      list << MetaCapiForwarder.new << GoogleAdsForwarder.new if consent.granted?(:advertising)
      list
    end

    def payload_for(destination, event, user, consent)
      base = event.slice(:name, :event_id, :value, :currency, :occurred_at)
      return base unless destination.advertising? && consent.granted?(:advertising)

      base.merge(hashed_email: Digest::SHA256.hexdigest(user.email.strip.downcase))
    end
  end
end

Die Conversions API von Meta, der serverseitige Weg zu Meta, dedupliziert ein Ereignis aus dem Browserpixel und eines vom Server, wenn beide denselben Ereignisnamen und dieselbe Ereignis ID tragen, und behält innerhalb von 48 Stunden in der Regel das zuerst eingetroffene.¹¹ Deshalb reicht der Prozessor die event_id des Browsers durch, statt eine neue zu erfinden.

Die erste Fassung dieses Artikels berichtete, dass auf einem Marktplatz, den ich gebaut habe, die serverseitige Conversions API ungefähr 25 % bis 30 % der Conversions zurückgeholt hat, die das Browserpixel verpasst hat. Das war meine Beobachtung an diesem einen Produkt, keine allgemeine Zahl. Hinter allem, was auf diesem Weg zurückkam, stand trotzdem eine Einwilligung zur Werbung.

Durchgerechnetes Beispiel: eine Bestellung, drei Ziele

Ein Kunde, der Analyse erlaubt, Werbung aber abgelehnt hat, kauft ein Gravelbike für 1.240 €. Der Browser schickt purchase mit der Ereignis ID a1f3, dem Wert 1240 und der Währung EUR an collect.elbspeiche.example. Der Server prüft das Ereignis, prüft die Einwilligung und findet Analyse erlaubt, Werbung abgelehnt. Also bekommt GA4 den Kauf mit seinem Wert und sonst nichts. Meta und Google Ads bekommen nichts. Der interne Zähler für Käufe steigt um eins. Die Bestellung selbst steht so oder so in der Datenbank des Shops, weil ihre Lieferung der Vertrag ist, nicht Tracking.

Schicht drei: Daten, die Menschen dir bewusst geben

Diese Schicht macht die eigentliche Arbeit. Stehen Einwilligung und Erfassung sauber, lautet die Frage: Welche Daten brauchst du wirklich, und wie bringst du Menschen dazu, sie freiwillig zu teilen?

Zero Party Data sind, was Menschen dir bewusst sagen: Vorlieben, Größen, Budgets, wofür ein Kauf gedacht ist. Ein verlässlicheres Signal gibt es nicht, weil der Mensch es selbst gesagt hat, und zwar damit du es nutzt.

First Party Data sind, was du mit Erlaubnis in deinem eigenen Shop beobachtest: Produktaufrufe, Suchen, Bestellungen, Klicks in Mails.

Second Party Data sind die eigenen Daten eines anderen Unternehmens, geteilt auf Grundlage einer Vereinbarung. Gelegentlich nützlich, und sie brauchen einen ordentlichen Vertrag zur Datenweitergabe und eine Rechtsgrundlage auf beiden Seiten.

Third Party Data sammeln Firmen, die überhaupt keine Beziehung zu dem Menschen haben. Das ist der Teil, der verschwindet, und das ist gut so.

Die Strategie ergibt sich daraus: So viel Zero Party und First Party Data sammeln, wie Menschen in einem fairen Tausch gern geben, und jede Entscheidung der Personalisierung darauf bauen.

Frag nach Vorlieben dort, wo sich die Antwort sofort lohnt

Die erste Fassung dieses Artikels beschrieb vier Produkte, an denen ich gearbeitet habe, und jedes sammelte Zero Party Data auf andere Art: ein Quiz zur Fahrzeugsuche auf einem Marktplatz, ein Schritt zum Festlegen von Zielen im Onboarding eines Kampagnenwerkzeugs, eine Einstellungsseite für Mails und Interessenschlagworte in einem lokalen Verzeichnis. Alle vier Muster passen auch in einen Shop.

Ein Quiz zur Auswahl. Vier schnelle Fragen, die einen großen Katalog auf eine kurze Liste schrumpfen.

Eine Einstellungsseite. Nicht nur "abmelden", sondern eine Seite, auf der Menschen Themen, Häufigkeit und Kanäle wählen.

Interessenschlagworte. Ein paar Antipper auf der Kontoseite, die bestimmen, womit die Startseite beginnt.

Ein Ziel beim Onboarding. Bei einem Softwareprodukt das eigene Ziel des Kunden, damit das Produkt auf das hinarbeiten kann, was er selbst Erfolg nennt.

Hier der Sammler für das Quiz:

module ZeroPartyData
  class PreferenceCollector
    def collect_from_quiz(user:, responses:)
      responses.each do |question, answer|
        UserPreference.create!(
          user: user,
          key: question.key,
          value: answer,
          source: :finder_quiz,
          shared_at: Time.current,
          expires_at: 12.months.from_now # Vorlieben laufen ab
        )
      end
      PersonalisationEngine.refresh_profile(user)
    end
  end
end

Der Tausch ist das, was es zum Laufen bringt, und die Regeln sind einfach:

1. Frag im richtigen Moment. Keine Umfrage mit 20 Fragen am Eingang. Frag nach dem Budget, wenn jemand gerade Räder durchsehen will.
2. Zeig den Nutzen sofort. Schon der nächste Bildschirm sollte die Antwort verwenden. Wer etwas teilt und nichts ändert sich, teilt nie wieder.
3. Halt es kurz. Ein oder zwei Fragen auf einmal. Über mehrere Besuche ein wenig zu fragen schlägt ein langes Formular am ersten Tag.
4. Mach Änderungen leicht. Vorlieben lassen sich jederzeit bearbeiten, und sie laufen ab.
5. Sag, warum du fragst. "Vier Fragen, damit ich dir Räder zeigen kann, die zu deiner Art zu fahren passen" ist ehrlich und motiviert.

Durchgerechnetes Beispiel: das Quiz bei Elbspeiche

Jonas' Quiz fragt vier Dinge: wofür das Rad ist (Pendeln, Gravel, Rennrad, Familie), das Budget (unter 800 €, 800 € bis 1.500 €, über 1.500 €), die Körpergröße in Stufen und ob ein elektrischer Antrieb wichtig ist. Eine Besucherin antwortet Gravel, 800 € bis 1.500 €, 175 bis 185 cm, kein Motor.

Der Filter läuft über den Katalog: 2.400 Räder, davon 310 Gravelbikes, davon 96 im Budget, davon 41 in einer Größe für diese Körpergröße, davon 18 ohne Motor. Der nächste Bildschirm zeigt diese 18, sortiert nach Bestand. Vier Zeilen landen in user_preferences, jede läuft in zwölf Monaten ab. Weil sie selbst nach der kurzen Liste gefragt hat, ist das Ergebnis genau der Dienst, den sie gewünscht hat. Jede Antwort kann sie auf ihrer Kontoseite ändern oder löschen.

Verhalten braucht ein eigenes Ja

Nach dem, was Menschen dir sagen, ist das, was sie in deinem Shop tun, das zweitbeste Signal. Auch das braucht Sorgfalt, denn es zu nutzen ist Profiling: Die Datenschutz Grundverordnung (DSGVO) definiert Profiling als Verarbeitung personenbezogener Daten, um etwa persönliche Vorlieben, Interessen oder das Verhalten eines Menschen zu analysieren oder vorherzusagen.¹²

Die erste Fassung dieses Artikels hat Personalisierung nach Verhalten an die Einwilligung zur Analyse gehängt. Das war falsch. Bei der Analyse geht es darum, wie der Shop in Summe genutzt wird. Aus der Historie eines Menschen auszuwählen, was er sieht, ist Personalisierung, und die ist eine Zusatzfunktion, keine technische Notwendigkeit des Shops, also braucht sie eine Einwilligung.⁷ Verhalten wird deshalb nur mit dem Ja zur Personalisierung genutzt, dieselbe Regel wie in KI Empfehlungen in Solidus bauen.

Das Ereignisschema hält das ehrlich:

module Analytics
  class EventSchema
    EVENTS = {
      page_view:     { properties: %i[page_path], consent: :analytics },
      search:        { properties: %i[query results_count], consent: :personalisation },
      product_view:  { properties: %i[product_id price currency], consent: :personalisation },
      add_to_cart:   { properties: %i[product_id quantity value currency], consent: :personalisation },
      email_click:   { properties: %i[campaign_id link_id], consent: :personalisation }
    }.freeze

    def self.track(name, properties:, user:, consent:)
      schema = EVENTS[name]
      return unless schema && consent.granted?(schema[:consent])

      Event.create!(name: name, user_id: user&.id, properties: properties.slice(*schema[:properties]), recorded_at: Time.current)
    end
  end
end

Zwei Änderungen gegenüber der ersten Fassung. Öffnungen von Mails sind raus: Apples Mail Privacy Protection lädt entfernte Inhalte, auch das unsichtbare Bild, das eine Öffnung zählt, im Hintergrund, ob jemand die Nachricht liest oder nicht. Eine Öffnung ist also nichts, was ein Mensch getan hat.¹³ Ein Klick schon. Und preference_updated ist gar kein Ereignis mehr: Die Zeile mit der Vorliebe ist selbst der Nachweis.

Menschen können außerdem jederzeit dem Profiling für Direktwerbung widersprechen, und dann endet es.¹⁴ Und die Daten müssen auf das beschränkt sein, was der Zweck braucht, und dürfen nicht länger als nötig aufbewahrt werden.¹⁵ Deshalb zeichnet das Schema fünf Ereignisse mit je einer Handvoll Felder auf, und nicht mehr.

Ein Beispiel: Eine Besucherin, die Personalisierung erlaubt hat, sieht sich drei Gravelbikes an und sucht nach "Tubeless Reifen". Vier Zeilen werden geschrieben. Eine Besucherin, die nur Analyse erlaubt hat, sieht sich dieselben drei Räder an: drei Zeilen page_view mit dem Pfad, keine Nutzer ID im Profil und nichts, womit die Personalisierung arbeiten könnte. Eine Besucherin, die alles abgelehnt hat: gar keine Zeilen.

Die Personalisierung wählt das reichste Erlebnis, das jeder erlaubt

Mit den drei Schichten hat die Personalisierung saubere Daten mit Einwilligung, und sie wird stufenweise schlanker, statt alles oder nichts zu sein.

module Personalisation
  class Engine
    def personalise(user:, context:, consent:)
      profile = PersonalisationProfile.new
      profile.merge_context(page: context[:page], query: context[:query], month: Date.current.month)

      if user && consent.granted?(:personalisation)
        profile.merge_preferences(user.active_preferences) # was sie dir gesagt haben
        profile.merge_behaviour(views: user.recent_product_views(30.days), searches: user.recent_searches(30.days))
      end

      Ranker.for(context[:surface]).rank(profile)
    end
  end
end

Das Profil setzt sich aus drei Arten von Signal zusammen:

1. Kontext, für alle: die Seite, auf der jemand ist, was er gerade eingetippt hat, die Jahreszeit. Er stammt aus der aktuellen Anfrage, dafür wird nichts auf dem Gerät gespeichert, und hinterher wird nichts behalten. Braucht ein Signal aus dem Kontext je eine gespeicherte Kennung, ist es kein Kontext mehr.
2. Genannte Vorlieben, für angemeldete Kunden, die Ja gesagt haben: die Antworten aus dem Quiz und die Interessenschlagworte.
3. Verhalten, unter demselben Ja: jüngste Aufrufe und Suchen, höchstens dreißig Tage.

Durchgerechnetes Beispiel: drei Besucher an einem Samstagvormittag

Besucher eins hat alles abgelehnt und stöbert im März in der Kategorie Gravel. Die Personalisierung kennt die Seite und den Monat, also beginnt die Kategorie mit Gravelbikes für das Frühjahr, und der Zubehörblock zeigt Schutzbleche und Lichter, für alle in dieser Kategorie gleich.

Besucherin zwei ist angemeldet, hat Ja gesagt und das Quiz gemacht: Gravel, 800 € bis 1.500 €, kein Motor. Die Startseite öffnet mit ihren 18 Rädern aus der kurzen Liste, dazu zwei Neuheiten, die passen.

Besucher drei hat Ja gesagt, das Quiz aber nie gemacht. In der letzten Woche hat er sich vier Rennräder um 2.000 € angesehen und nach "Carbon Laufräder" gesucht. Die Startseite beginnt mit Rennrädern in dieser Preislage und einem Ratgeber zum Aufrüsten der Laufräder.

Drei Besucher, drei ehrliche Erlebnisse, und niemandem wurde irgendwohin gefolgt, wohin er nicht selbst wollte.

Mails brauchen die richtige Erlaubnis, auch die freundlichen

Für personalisierte Mails gelten zusätzlich eigene Regeln. Werbung per Mail braucht nach § 7 Abs. 2 Nr. 2 des Gesetzes gegen den unlauteren Wettbewerb (UWG) grundsätzlich die vorherige ausdrückliche Einwilligung. Die Ausnahme für Bestandskunden in § 7 Abs. 3 UWG greift nur, wenn du die Adresse beim Verkauf selbst bekommen hast, eigene ähnliche Waren bewirbst, der Kunde nicht widersprochen hat und du ihn bei der Erhebung und in jeder Mail klar auf sein Widerspruchsrecht hingewiesen hast.¹⁶

Die Falle ist die freundliche Mail. "Wie zufrieden warst du?" und "Aktualisiere deine Einstellungen" fühlen sich nach Service an. In Deutschland ist hier weniger Spielraum als anderswo. Werbung ist nach dem Bundesgerichtshof jede Äußerung mit dem Ziel, den Absatz zu fördern, auch mittelbar, indem weiteren Geschäften der Weg geebnet wird, und das gilt regelmäßig auch für Kundenzufriedenheitsbefragungen, selbst wenn sie mit der Rechnung in derselben Mail kommen.¹⁷ Eine Bitte um Feedback ist in einem deutschen Shop also keine reine Servicenachricht, mit Produktreihe darunter erst recht nicht. Der sichere Weg: Alles, was über die Abwicklung der Bestellung hinausgeht, geht nur an Menschen, die Werbung erlaubt haben oder unter die Ausnahme für Bestandskunden fallen. Das ist dieselbe Linie, die ich in KI gestützter Marketingautomatisierung ziehe.

Ein Beispiel: Jonas will 900 Kunden anschreiben, die letztes Frühjahr ein Rad gekauft haben und seitdem nicht wiedergekommen sind. 600 haben Werbung erlaubt oder fallen unter die Ausnahme für Bestandskunden, weil sie beim Kauf korrekt auf ihr Widerspruchsrecht hingewiesen wurden und nie widersprochen haben. Sie bekommen eine Erinnerung an die Inspektion ihres Rads und eine personalisierte Reihe mit Zubehör, mit einem Link zum Abmelden. Ob Zubehör als "ähnliche Ware" zum Rad durchgeht, lässt Jonas im Zweifel einmal prüfen. Die anderen 300 bekommen keine Mail. Auch kein harmloses "Wie fährt sich das Rad nach einem Jahr?", denn nach der Rechtsprechung oben wäre schon das Werbung. Für sie bleibt ein Hinweis im Kundenkonto beim nächsten Login.

Zahlt sich Datenschutz zuerst wirklich aus?

Die ehrliche Antwort: Es funktioniert anders, und nach meiner Erfahrung meistens besser.

Was ich an den Produkten beobachtet habe, die ich gebaut habe:

Genannte Vorlieben schlagen erschlossene. Menschen, die aktiv Vorlieben geteilt haben, waren ungefähr zwei bis drei Mal so aktiv wie Menschen, die im alten Modell passiv profiliert wurden. Das ist meine Beobachtung, keine veröffentlichte Studie, und es leuchtet ein: Sie haben dir gesagt, was sie wollen.

Listen mit Einwilligung kommen besser an. Versand auf Grundlage von Einwilligung heißt sauberere Listen und weniger Beschwerden, und die Zustellbarkeit wurde spürbar besser, nachdem nur noch mit Einwilligung versendet wurde.

Sauberere Attribution. Serverseitige Erfassung mit ordentlicher Deduplizierung lieferte Zahlen, denen ich mehr trauen konnte, weil das, was ankam, vollständig war und nur einmal zählte.

Der Mechanismus, den ich dahinter vermute, ist ein Kreislauf aus Vertrauen. Eine offene Einwilligung schafft Vertrauen. Vertrauen macht Menschen bereiter zu teilen. Mehr geteilte Daten erlauben bessere Personalisierung. Bessere Personalisierung stärkt das Vertrauen. Das ist meine Lesart dessen, was ich gesehen habe, kein Naturgesetz, und der Kreislauf dreht sich nur, wenn der erste Schritt ehrlich ist.

Ein Beispiel: Angenommen, Elbspeiche hat 10.000 Besucher im Monat, und, als Annahme des Beispiels, 45 % sagen Ja zur Personalisierung. Das sind 4.500 Menschen mit einem persönlichen Erlebnis und 5.500 mit einem nach Kontext. Baut der Shop dann eine klare Einstellungsseite und die Zustimmung steigt auf 50 %, bekommen jeden Monat weitere 500 Menschen die persönliche Fassung, ohne einen einzigen zusätzlichen Tracker.

Die Checkliste für Datenschutz zuerst

1. Prüf, was feuert, und wohin es geht. Wenn du das nicht genau beantworten kannst, hast du es nicht im Griff.
2. Mach das Banner ehrlich, stell die Voreinstellungen im Consent Mode auf abgelehnt und wähl den einfachen oder erweiterten Modus bewusst.
3. Erfass auf deinem eigenen Server, wenn du die Kontrolle brauchst, mit demselben Einwilligungsstatus.
4. Bau das Programm für Zero Party Data auf, jede Frage zahlt sich auf dem nächsten Bildschirm aus.
5. Halt das Ereignisschema schmal, Verhalten nur unter dem Ja zur Personalisierung.
6. Prüf den Zweck jeder Mail, bevor du entscheidest, wer sie bekommt.

Für die tiefere Technik lies Server Side Tracking, DSGVO konforme KI Features und was das Recht auf Vergessenwerden für Modelle bedeutet. Nichts davon ist Rechtsberatung, und für alles, was über einen kleinen Shop hinausgeht, ist eine Stunde bei einer Anwältin gut angelegtes Geld.

Unterm Strich

Wachstum mit Datenschutz ist kein Widerspruch. Es ist der einzige Ansatz, der nicht jedes Mal bricht, wenn ein Browser ein Update bekommt oder eine Behörde neue Leitlinien veröffentlicht.

Es kostet am Anfang mehr Technik: eine Einwilligung, die funktioniert, eine Erfassung, die du kontrollierst, und Daten, die Menschen dir bewusst geben. Das Ergebnis ist Personalisierung, die besser wird, je mehr Menschen dir anvertrauen, statt schlechter, jedes Mal wenn ein Browser die nächste Lücke schließt. Verdien dir die Daten. Personalisier mit Erlaubnis.

Quellen

Footnotes

1. John Wilander, Intelligent Tracking Prevention 2.1, WebKit, 21. Februar 2019, https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/

2. John Wilander, Full Third Party Cookie Blocking and More, WebKit, 24. März 2020, https://webkit.org/blog/10218/full-third-party-cookie-blocking-and-more/

3. Mozilla, Firefox rolls out Total Cookie Protection by default to more users worldwide, The Mozilla Blog, 14. Juni 2022, aktualisiert 28. August 2024, https://blog.mozilla.org/en/mozilla/firefox-rolls-out-total-cookie-protection-by-default-to-all-users-worldwide/

4. Anthony Chavez, Update on plans for Privacy Sandbox technologies, Google, 17. Oktober 2025, https://privacysandbox.google.com/blog/update-on-plans-for-privacy-sandbox-technologies

5. Bundesministerium der Justiz, Telekommunikation Digitale Dienste Datenschutz Gesetz (TDDDG), § 25 Schutz der Privatsphäre bei Endeinrichtungen, Absätze 1 und 2, Gesetze im Internet, https://www.gesetze-im-internet.de/ttdsg/__25.html

6. Bundesdatenschutzgesetz (BDSG), § 40 Aufsichtsbehörden der Länder, Gesetze im Internet, https://www.gesetze-im-internet.de/bdsg_2018/__40.html

7. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten (OH Digitale Dienste), Version 1.2, Randnummern 74, 76 und 78, DSK, November 2024, https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf

8. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten (OH Digitale Dienste), Version 1.2, Randnummern 58, 59, 61, 118 und 126, DSK, November 2024, https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf

9. Google, Consent mode overview, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/security/concepts/consent-mode

10. Konferenz der unabhängigen Datenschutzaufsichtsbehörden des Bundes und der Länder (DSK), Orientierungshilfe der Aufsichtsbehörden für Anbieter:innen von digitalen Diensten (OH Digitale Dienste), Version 1.2, Randnummern 21 und 120, DSK, November 2024, https://www.datenschutzkonferenz-online.de/media/oh/OH_Digitale_Dienste.pdf

11. Meta, Handling duplicate Pixel and Conversions API events, Marketing API documentation, Meta for Developers, https://developers.facebook.com/docs/marketing-api/conversions-api/deduplicate-pixel-and-server-events

12. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 4 Nummer 4 (Profiling), EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

13. Apple, Mail Privacy Protection and privacy, Apple Legal, https://www.apple.com/legal/privacy/data/en/mail-privacy-protection/

14. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 21 Absätze 2 und 3, Widerspruchsrecht, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

15. Europäisches Parlament und Rat, Verordnung (EU) 2016/679 (Datenschutz Grundverordnung), Artikel 5 Absatz 1 Buchstaben c und e, EUR Lex, 2016, https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32016R0679

16. Bundesministerium der Justiz, Gesetz gegen den unlauteren Wettbewerb (UWG), § 7 Unzumutbare Belästigungen, Absatz 2 Nummer 2 und Absatz 3, Gesetze im Internet, https://www.gesetze-im-internet.de/uwg_2004/__7.html

17. Bundesgerichtshof, Urteil vom 10. Juli 2018, VI ZR 225/17, Randnummern 17, 18 und 24 (Kundenzufriedenheitsbefragung per Mail als Werbung), über dejure.org, https://dejure.org/dienste/vernetzung/rechtsprechung?Gericht=BGH&Datum=10.07.2018&Aktenzeichen=VI%20ZR%20225/17