Stand: 06.10.2026

Datenschutzerklärung PopUplift

0. Geltungsbereich und die zwei Rollen

PopUplift ist eine Shopify-App. Sie läuft im Shop eines Händlers und verarbeitet dort Daten von Besuchern dieses Shops. Daraus folgen zwei getrennte Rollen. Wer diese Erklärung liest, sollte in den nächsten drei Sätzen wissen, welcher Strang für ihn gilt.

PopUplift als Auftragsverarbeiter (Art. 28 DSGVO). Alles, was ein Shop-Besucher in einem Popup tut, verarbeiten wir ausschließlich im Auftrag und auf Weisung des Händlers. Verantwortlicher im Sinne der DSGVO ist dann der Händler, nicht wir. Wir haben für diese Daten keine eigene Rechtsgrundlage. Für die Ausübung von Betroffenenrechten ist allein der Händler zuständig. Shop-Besucher finden die für sie maßgebliche Datenschutzerklärung beim Händler. Abschnitt 2 beschreibt trotzdem vollständig, was wir dabei verarbeiten, weil der Händler diese Angaben für seine eigene Erklärung braucht.

PopUplift als Verantwortlicher (Art. 4 Nr. 7 DSGVO). Für die Daten des Händlers selbst (Shop-Domain, Einstellungen, Nutzungszahlen zur Abrechnung, Support-Kommunikation) sind wir Verantwortlicher. Dafür gilt Abschnitt 3.

1. Verantwortlicher und Kontakt

Kyrill Pysarenko
Danziger Str. 76, 10405 Berlin, Deutschland
E-Mail: privacy@popuplift.com

Datenschutzanfragen: privacy@popuplift.com, Antwort innerhalb von 20 Werktagen.

Ein Datenschutzbeauftragter ist nicht bestellt; eine gesetzliche Bestellpflicht besteht nicht.

Zuständige Aufsichtsbehörde: Berliner Beauftragte für Datenschutz und Informationsfreiheit, Alt-Moabit 59-61, 10555 Berlin.

2. Verarbeitung im Auftrag des Händlers

Alle Angaben sind aus dem Datenmodell der Anwendung abgeleitet. Die Zweck- und Rechtsgrundlagen-Zuordnung steht gebündelt in Abschnitt 4.

Wenn der Händler die SMS-Erfassung aktiviert, verarbeitet PopUplift in seinem Auftrag die Telefonnummer, den separaten Zeitpunkt der SMS-Marketing-Einwilligung und die Kennung der vom Händler gewählten Klaviyo-SMS-Liste. Der SMS-Zeitstempel dokumentiert lediglich den technischen Klicknachweis. Für sich allein belegt er weder Umfang noch Wirksamkeit der Einwilligung; insbesondere ersetzt er nicht die vom Händler bereitzustellende Einwilligungsinformation.

2.1 Besucherprofil (visitors)

2.2 Ereignisse (user_actions) und Zwischenstände

Popup gesehen, Schritt abgeschlossen, E-Mail abgegeben, Reward beansprucht, Popup geschlossen. Jeweils mit Zeitstempel, Popup-Bezug, Besucherbezug und einer anonymen Sitzungs-Kennung.

Tageszusammenfassung (popup_visitor_daily). Für die Auswertung im PopUplift-Betrieb werden abgeschlossene Tage einmal zusammengefasst: je Tag, Popup, A/B-Variante und Besucherkennung die Anzahl der Anzeigen und WhatsApp-Übergaben sowie der Zeitpunkt der ersten E-Mail-Abgabe und der letzten Übergabe. Inhalte der Ereignisse (etwa eine E-Mail-Adresse) stehen dort nicht. Die Besucherkennung ist dieselbe wie bei den Ereignissen und verschwindet mit ihnen (Abschnitt 9).

Smart Trigger (zweite Chance). Ist Smart Trigger aktiviert und sind Marketing- und Analytics-Verarbeitung erlaubt, zeigt PopUplift Besuchern, die ein Popup schließen oder minimieren, höchstens einmal je Sitzung eine zweite Chance zu einem späteren Moment und misst gegen eine Kontrollgruppe, ob das zusätzliche Anmeldungen bringt. Fehlt eine der beiden Erlaubnisse, findet nichts davon statt: kein Lesen, kein Speichern, keine Anfrage — ausgenommen der unten beschriebene Abbruchmarker nach einem Widerruf.

Einstieg und Ausschlüsse. Die Messung beginnt mit dem ersten Schließen oder Minimieren eines Smart-Popups in einer Sitzung. Nie eingeschrieben werden Besucher, deren Sitzung über eine E-Mail-, Klaviyo- oder Newsletter-Kampagne begann (erkennbar an utm_source oder utm_medium), Browser, die Klaviyo bereits erkannt hat (nur wenn dieses Ergebnis wegen einer Popup-Regel ohnehin vorliegt, Abschnitt 5), und Browser, in denen schon eine E-Mail-Adresse abgegeben wurde (pl-has-email, Abschnitt 5). Diese Prüfung läuft ausschließlich im Browser; über ausgeschlossene Besucher wird nichts übertragen.

Zuweisung. Beim Einstieg speichert der Server einmal je Besucher und Experiment eine pseudonyme, zufällige Zuweisung. Sie enthält: Zuweisungs- und Experimentkennung; Version und Prüfsumme der Steuerungsregeln; das Popup, an dem der Einstieg geschah, samt Hash seines ausgelieferten Popup-/Theme-/Reward-Stands; die Einstiegsart (Schließen oder Minimieren) und ihren Zeitpunkt; die zugeteilte Gruppe; bei der Behandlungsgruppe den zugeteilten Moment („Arm“) mit seinen Parametern; die Wahrscheinlichkeit, mit der genau diese Zuteilung gezogen wurde (Propensity); die Version des Lernstands und die Fristen der Messung. Dazu kommt ein grober Kontext aus vier Kategorien:

• Gerät: mobil oder Desktop, aus der Fensterbreite;
• Quellkategorie: direkt, Suche, Social, bezahlt oder sonstige — im Browser aus der Referrer-Domain und den UTM-Parametern abgeleitet; übertragen wird nur die Kategorie, nie die Domain oder ein UTM-Wert;
• neu oder wiederkehrend;
• Warenkorb gefüllt, leer oder unbekannt — bekannt nur, wenn der Shop für seine Popups ohnehin Warenkorb-Bedingungen nutzt.

Ein fester, zufällig gezogener Anteil der Eingeschriebenen (derzeit 20 %) bildet die Kontrollgruppe (Holdout) und erhält nie eine zweite Chance. Alle anderen erhalten einen Moment: derzeit Zeitablauf, Hinzufügen zum Warenkorb, Verlassen-Absicht, Aufruf einer weiteren Produktseite oder — nur nach dem Minimieren — allein den Floating-Button auf Folgeseiten. Die zweite Chance erscheint frühestens nach derzeit 20 Sekunden sichtbarer Zeit, nur innerhalb von derzeit 30 Minuten nach dem Einstieg, nie auf der Warenkorbseite und nie über einem anderen Popup. Ist eine Collection-Sitzung aus Abschnitt 2.7 vorhanden, hängt der Server deren geprüfte Sitzungskennung (session_id) an die Zuweisung; fehlt sie oder ist sie ungültig, bleibt das Feld leer.

Messereignisse und Ergebnis. Zur Zuweisung speichert der Server nur: Öffnungsversuch mit dem auslösenden Moment, tatsächlich sichtbar gewordene zweite Chance, erneutes Schließen oder Minimieren sowie gegebenenfalls einen Abbruchmarker (siehe unten). Als Ergebnis zählt ein serverseitig angenommener neuer E-Mail-Marketing-Opt-in innerhalb von 24 Stunden nach dem Einstieg — auch in einer späteren Sitzung desselben Browsers und auch über ein anderes Popup desselben Shops. Der Server verknüpft ihn selbst mit der jüngsten nicht abgebrochenen Zuweisung dieses Besuchers, deren 24-Stunden-Frist noch läuft, und nur, wenn beim Absenden Marketing- und Analytics-Verarbeitung erlaubt sind; der Browser überträgt dafür keine Zuweisungsdaten. Shopfremde Popups und Besucher sind ausgeschlossen. Für die Diagnose im Händlerreport zählt PopUplift je Zuweisung außerdem die Bestellungen und deren Umsatz, die innerhalb von sieben Tagen nach dem Einstieg mit einem Rabattcode aus einem Popup bezahlt wurden (Abschnitt 2.4), und — über die angehängte Sitzungskennung — die weiteren Seitenaufrufe derselben Collection-Sitzung (Abschnitt 2.7). Übertragen und gespeichert werden ausschließlich die genannten Kategorien und Kennungen: keine Zeile kopiert E-Mail-Adresse, URL oder Pfad, Referrer-Domain, UTM-Wert, Seiten- oder DOM-Inhalt oder den Inhalt des Warenkorbs.

Lernen je Shop. Wie oft welcher Moment zugeteilt wird, lernt PopUplift für jeden Shop getrennt, ausschließlich aus den Zuweisungen und Opt-ins dieses Shops (Thompson Sampling; jeder Moment behält einen Mindestanteil, die Kontrollgruppe nimmt am Lernen nicht teil). Für das Lernen zählt ein Opt-in bis 35 Minuten nach dem Einstieg. Der Lernstand (smart_policy_states) enthält nur Zählwerte und daraus berechnete Anteile je Shop und Experiment, keinen Besucher- oder Sitzungsbezug; er wird mit dem Shop gelöscht. Er wird regelmäßig aus den gespeicherten Zeilen neu berechnet, sodass abgebrochene und nach Abschnitt 9.2 anonymisierte Zuweisungen bei der nächsten Berechnung nicht mehr als Ergebnis zählen. Daten anderer Shops fließen nicht ein. Der grobe Kontext wird protokolliert, steuert die Zuteilung derzeit aber nicht und erscheint in keinem Report. Eine automatische Bremse stoppt neue Zuweisungen, wenn die zweite Chance auffällig oft sofort geschlossen oder die Einwilligung in der Behandlungsgruppe auffällig häufiger widerrufen wird als in der Kontrollgruppe.

Widerruf. Bei Widerruf wird für eine bereits im Arbeitsspeicher bekannte Zuweisung nur ein zweckgebundener Abbruchmarker geschrieben und danach der gesamte lokale Smart-Zustand entfernt. Lässt sich der Zustand im Browser nicht speichern, wird ebenfalls ein Abbruchmarker geschrieben und der Eintrag dieses Popups entfernt. Nach dem Widerruf werden keine neuen Seiten- oder Verhaltenssignale gelesen. Der Marker nimmt die Zuweisung im Report aus Zähler und Nenner und beim Lernen aus der Ergebniswertung; nur ihre Anzahl fließt in die Bremse ein. So erscheint eine abgebrochene Messung im Händlerreport nie als sicher beobachteter Misserfolg und damit nie als künstlich positiver Effekt.

Bei einem laufenden A/B-Test können die Ereignisse „Popup gesehen“ und „E-Mail abgegeben“ zusätzlich die Kennung der gesehenen Variante A oder B tragen. Die Zuteilung fällt im Browser; der Server übernimmt die Kennung nur als Beiwert am einzelnen Ereignis und legt daraus kein Besucherprofil über die Zuteilung an.

Dazu gehört der Zwischenstand eines mehrstufigen Popups (visitor_flow_state): welchen Schritt ein Besucher zuletzt erreicht hat, mit Popup- und Besucherbezug. Er wird bei einer Löschanfrage mitgelöscht (Abschnitt 9.2).

Der Server übernimmt aus dem Umschlag einer Ereignis-Meldung genau drei Sitzungsmerkmale: neue Sitzung ja/nein, Land und Sprache. Herkunft, UTM-Parameter, Referrer und Gerätetyp des Besuchers werden nicht übernommen, nicht ausgewertet und nicht gespeichert; ein Besucherprofil darüber existiert serverseitig nicht (Abschnitt 5). Davon getrennt trägt nur die oben beschriebene Smart-Zuweisung die dort genannten groben Kategorien, nie Rohwerte. Einzige Ausnahme: Meldet das Widget einen Fehler, enthält die Meldung die Adresse der Seite, auf der der Fehler auftrat — ohne Abfrageparameter (Abschnitt 6) — sie dient allein der Fehlersuche.

2.3 Quiz- und Umfrage-Antworten (poll_answers)

Frage- und Antworttext mit Bezug zu Popup und Besucher. Der Besucher hat sie selbst hingeschrieben (zero-party). Sie werden nicht an Dritte weitergegeben, außer der Händler richtet den Klaviyo-Sync ein (Abschnitt 6).

2.4 Ausgegebene Rabattcodes (claimed_rewards, discount_code_pool)

Code, Rabattverhalten, Ausgabezeitpunkt, Ablauf sowie nach Einlösung Bestellnummer, Betrag und Währung.

2.5 Zugeordnete Bestellungen (attributed_orders)

Eine Zeile je Bestellung, die einen von PopUplift ausgegebenen Code benutzt hat: Betrag, Währung, Bestellzeitpunkt, Popup. Der Personenbezug steckt allein in den Feldern claimed_reward_id, order_id und code, die bei einer Löschanfrage geleert werden (Abschnitt 9.2). Quelle ist der Shopify-Webhook orders/create. Aus diesem Webhook liest PopUplift keine Bestellpositionen, keine Lieferadressen und keine Zahlungsdaten; welche Produkte gekauft wurden, erfasst allein das Kauf-Tracking aus Abschnitt 2.9.

2.6 Server-Protokolle und Missbrauchsabwehr

Der Anwendungsserver protokolliert eingehende Anfragen (Methode, Pfad, Statuscode, Zeitstempel, IP-Adresse des Aufrufers). Alle offenen Storefront-Endpunkte haben zusätzlich ein Rate-Limit: global 600 Anfragen pro Minute und IP, je Route enger. Bei Anfragen mit Besucher-Sitzung wird vorrangig die Sitzungskennung gezählt; die IP-Adresse dient dort als Rückfallwert.

Das ist ausdrücklich zu unterscheiden von Abschnitt 2.8: Die IP-Adresse steht in den flüchtigen Betriebsprotokollen der Hosting-Plattform und im Arbeitsspeicher des Rate-Limiters. Sie wird nicht in die Datenbank geschrieben, es gibt kein IP-Feld im Datenmodell, und sie wird mit keinem Besucherprofil verknüpft.

Die Sitzung, der Paket-Ingest und die nachträgliche Bindung aus Abschnitt 2.7 haben eigene, instanzlokale Rate-Limits (vor der Verifikation pro IP, danach zusammen pro Shop und Sitzung). Eine Ablehnung durch das Limit (HTTP 429) zählt als Datenverlust, nicht als Widerruf oder Einwilligung; sie wird gegenüber dem Händler nicht als Consent-Nein dargestellt. Der Lastnachweis prüft die Limits, die CGNAT-/NAT-Lage und einen globalen Backstop getrennt; daraus wird keine globale Quotenbehauptung abgeleitet.

Die Anwendungsprotokolle der Hosting-Plattform (Railway) werden dort 7 Tage vorgehalten und danach automatisch gelöscht.

Diese Protokolle führen wir in eigener Verantwortlichkeit (Abschnitt 4, berechtigtes Interesse): Sie entstehen zwar durch Anfragen der Besucher, dienen aber allein der Sicherheit und Verfügbarkeit unseres Dienstes, nicht einem Zweck des Händlers.

Zur notwendigen Verfügbarkeit gehört außerdem ein begrenztes technisches Consent-Health-Signal: Nur wenn der betriebliche, standardmäßig ausgeschaltete Schalter aktiv ist, meldet eine echte Storefront entweder ready oder unavailable für die technische Bereitschaft von Shopifys Customer Privacy API zusammen mit der Shop-Routing-Domain. false als Antwort einer Marketing- oder Analytics-Methode ist dabei ready und wird nicht als Ablehnung oder Fehler übertragen. Die Meldung enthält keine Consent-Werte, Besucher- oder Sitzungskennung, URL, Referrer, Variante oder Rohfehlermeldung und liest dafür keinen Browser-Speicher.

Gespeichert wird genau eine gedrosselte, shopbezogene Aggregatzeile mit Server-Zeitstempeln und den letzten beiden technischen Ergebnisarten; keine Ereignishistorie und keine IP-Adresse. Alte Beobachtungen werden nach 24 Stunden im Admin als unknown behandelt, denn kein Verkehr ist kein Ausfall. Die Zeile wird mit dem Shop gelöscht. Erforderlichkeit und Minimierung: Ohne dieses Signal könnte ein stiller Plattform-/Integrationsfehler die konservative Nur-pro-Besuch-Funktion dauerhaft unbemerkt lassen; der geschlossene Status ist die kleinste Information, mit der der Händler die technische Verfügbarkeit prüfen kann. Grundlage bleibt das in diesem Abschnitt beschriebene berechtigte Interesse an einem verfügbaren Dienst.

Die Übertragung verwendet keine Credentials und unterdrückt den Referrer. Wie bei jeder Anfrage sieht die Hosting-/Netzwerkstrecke dennoch unvermeidbare Verbindungsmetadaten, insbesondere die IP-Adresse; sie ist deshalb nicht als anonym zu bezeichnen. Für diese gewöhnlichen, sieben Tage vorgehaltenen Host-Protokolle gelten die vorstehenden Regeln. PopUplift übernimmt diese Metadaten weder in die Consent-Health-Tabelle noch in eigene Zusatzprotokolle.

2.7 Consentgebundene Storefront-Nutzungssignale (visitor_events, visitor_event_sessions)

Getrennt vom Popup und vom Smart Trigger erhebt PopUplift — nur wenn die Analyseverarbeitung ausdrücklich erlaubt ist (analyticsProcessingAllowed() ist true) — pseudonyme, kategorisierte Nutzungssignale der Storefront. Diese Erhebung ist kein Marketing und löst weder ein Popup aus noch verändert sie Popup-Frequenz oder die Smart-Zuteilung. Ein Marketing-only-Consent genügt dafür nicht; ohne Analytics bleibt die Erhebung geschlossen (fail-closed).

Der sachliche Zweck ist bewusst neutral und nicht exklusiv formuliert (ADR-008 §7):

Bei erlaubter Analyseverarbeitung erfasst PopUplift pseudonyme, kategorisierte Nutzungssignale der Storefront. Diese Daten unterstützen die Messung von Nutzung und Interaktionen, die Qualität und Weiterentwicklung datenbasierter Funktionen sowie statistische Analysen. Dazu gehören insbesondere die Vorbereitung von Trigger-Kalibrierung und begründeten Optimierungshinweisen. Die Verarbeitung richtet sich nach den jeweils vereinbarten Zwecken und zulässigen Rechtsgrundlagen.

Dieser Wortlaut ist keine Exklusivitätszusage („nur für dein Popup“) und ebenso keine Erlaubnis: Analytics-Einwilligung oder eine offene Zweckbeschreibung erlauben noch keinen Verkauf, kein Cross-Shop-Profiling und keine beliebige eigene Verwendung. Konkrete Zwecke, Transparenz, Rollen und die zulässige Verarbeitung müssen dafür zuerst geklärt sein; die AVV-/Rollenfrage entscheidet Kyrill später. Diesen Strom betreffende Angaben sind also eine Beschreibungsgrenze, keine Nutzungsfreigabe.

Erhoben werden zwei zusammengehörige Tabellen:

• visitor_event_sessions — eine serverseitig erzeugte, zufällige Sitzungskennung (UUID) mit Shop-Bezug, ihrem UTC-Tag als Partitionsschlüssel, einem Server-Zeitstempel und einem Ablaufzeitpunkt (Sitzungsbeginn + 24 Stunden). Sie enthält weder E-Mail, IP, User-Agent, URL, Consent-ID noch Warenkorbdaten und keinen Nutzungs-/Abrechnungsmarker.
• visitor_events — je Dokument (Seite) genau eine Zeile mit einem JSON-Feld (attrs). Darin stehen ausschließlich kategorisierte Größen: der Seitenkontext (Pfadkategorie home/product/collection/cart/checkout/other, Viewport-Klasse, Zeigertyp, Ausrichtung, Referrer-Kategorie, UTM-Kategorie, erste Sichtbarkeit, Exit-Intent-Unterstützung), eine begrenzte Ereignisfolge (Seitenaufruf, Scroll-Tiefe in 10-%-Stufen, Sichtbar/Verborgen, Exit-Intent als reines Ja/Nein, beobachtetes Hinzufügen zum Warenkorb sowie erlaubnisgeprüfte Popup-Ereignisse mit Popup-/Kampagnenkennung, Schrittindex oder Kanal) und zusammengefasste Zähler/Buckets.

Erweiterte Signale. Unter denselben Bedingungen — nur bei erlaubter Analyseverarbeitung, pseudonym, höchstens 180 Tage — erfasst PopUplift zusätzlich:

Normierte Merkmale. Im Archiv (Abschnitt 2.9) berechnet PopUplift aus diesen Daten Merkmale, die Shops vergleichbar machen: Preis- und Warenkorbwert-Stufe relativ zum Shop, Wert in EUR, Branche nach Shopify-Produkttaxonomie, Traffic-Stufe des Shops, lokale Stunde und Wochentag, Besuchsnummer.

Anonymisierte Kennzahlen. Nach dem Auftragsverarbeitungsvertrag (ab Version 2026-10-02) darf PopUplift aus diesen Daten anonymisierte, aggregierte Kennzahlen bilden, etwa Anmelderaten je Design, Mechanik, Moment oder Branche, aus denen weder ein Besucher noch ein einzelner Shop erkennbar ist, und sie zur Verbesserung und Optimierung des Dienstes für alle Kunden nutzen. Ein shopübergreifendes Training auf besucherbezogenen, auch pseudonymisierten Einzeldaten findet ohne gesonderte Vereinbarung mit dem Händler nicht statt.

Nicht gespeichert oder übertragen werden dabei rohe Pfade, URLs oder deren Hashes, Referrer-Domains, freie utm_*-Werte außer den oben genannten geschwärzten Kampagnenwerten, DOM- oder Seitentext, Formulareingaben, E-Mail-Adresse oder Telefonnummer, IP-Adresse, User-Agent, Warenkorb-Notizen oder -Eigenschaften oder Klickkoordinaten. Ein popupSubmit-Signal entsteht nur aus dem erfolgreichen, bereits vorhandenen Bestätigungs-Callback und trägt als Kanal lediglich email oder sms; die eingegebene Adresse wird nicht mitkopiert. Die detaillierte Feldgrenze steht im Vertrag [ADR-008](ADR-008-EVENT-STREAM.md).

Sitzung und spätere Bindung. Der Server vergibt die Sitzung und ein eigenes, auf 24 Stunden begrenztes, gehashtes Collection-Token (eigene Zielgruppe, kein Besuchermerkmal). Der Client hält Token, Sitzungs-ID, Tag und Ablauf nur im sessionStorage (pl-collect-v1); es gibt keine LocalStorage-Wiederkehr-ID und kein Fingerprinting. Nach dem normalen Besucher-Bootstrap kann die Sitzung einmalig an den bereits vorhandenen, gleichen Shop-Besucher gebunden werden; diese Bindung legt keinen neuen Besucher an und ist praktisch der pseudonyme Zusammenschluss mehrerer Seiten einer Sitzung. Eine gelöschte Sitzung kann weder durch ein erneutes Token noch durch eine verspätete Bindung wieder entstehen.

Pseudonym, nicht anonym. Ungebundene Sitzungen sind pseudonym: Sie sind über E-Mail nicht auffindbar, aber die Seitenpakete bleiben innerhalb einer Sitzung verknüpfbar. PopUplift behandelt sie deshalb nicht als anonym und erfindet für sie keine Identität.

Widerruf. Wird die Analytics-Erlaubnis widerrufen, löscht das Modul seine Warteschlange und seinen Session-Speicher sofort, meldet Beobachter ab und bricht einen laufenden Versand soweit möglich ab; es folgt keine Abschlussmessung und kein Versand beim Verlassen der Seite. Bereits angenommene Daten verschwinden dadurch nicht rückwirkend; die Löschung ist getrennt in Abschnitt 9 geregelt. Bei erneuter Erlaubnis beginnt eine neue Sitzungsepoche ohne Wiederaufnahme alter Daten. Zweck und Grenze stehen in [ADR-008 §7](ADR-008-EVENT-STREAM.md); die Aufbewahrung in Abschnitt 8 (Partitionen, harte Höchstfrist), die Löschung und der Export in Abschnitt 9.

Zu diesem Strom gehört außerdem eine optionale Sitzungskennung am bestehenden Ereignis-Umschlag aus Abschnitt 2.2: Nach dem normalen Besucher-Bootstrap kann der Server die Collection-Sitzung an neue Aktionen anhängen, damit ein Lead derselben Sitzung zuordenbar bleibt. Ohne Analytics oder bei ungültigem Token bleibt der Aktionsaufruf unverändert; bestehende Ereignistypen, Zähler und Smart-Zuordnungen werden nicht umgedeutet.

2.8 Was ausdrücklich nicht verarbeitet wird

• Keine IP-Adressen in der Datenbank. Kein IP-Feld im Datenmodell. Zur Verwendung im Protokoll siehe 2.6.
• Keine Cookies. Das Widget setzt keine. Es benutzt localStorage und sessionStorage, vollständig aufgelistet in Abschnitt 5.
• Keine Speicherung genauer IP-Standorte. Shop-Land und Sprache kommen aus der Shopify-Storefront-Lokalisierung. Das separate, optionale geschätzte Besucherland folgt ausschließlich den Bedingungen in Abschnitt 2.1: nur mit Analytics-Einwilligung, nur der Ländercode, ermittelt mit einer lokalen Länderdatenbank auf unserem Server.
• Keine Werbe-IDs, kein Fingerprinting, keine Weitergabe an Werbenetzwerke.
• Keine Zahlungsdaten.
• Keine Schriften von Dritten. Popup-Schriften kommen ausschließlich vom eigenen Server, nie von fonts.googleapis.com. Es entsteht keine Verbindung des Besuchers zu Google.
• Kein Training von KI-Modellen auf besucherbezogenen Einzeldaten. Ein shopübergreifendes Training auf besucherbezogenen, auch pseudonymisierten Einzeldaten findet ohne gesonderte Vereinbarung mit dem Händler nicht statt. Genutzt werden über Shops hinweg nur anonymisierte, aggregierte Kennzahlen (Abschnitt 2.7).
• Keine serverseitige Auswertung roher Herkunft, roher UTM-Werte oder eines Gerätemodells. Diese Rohwerte entstehen im Browser und bleiben dort, deshalb gibt es dazu bewusst auch keinen Report (Abschnitt 5). Davon getrennt überträgt der in Abschnitt 2.7 beschriebene, analytics-gebundene Strom nur grobe Kategorien (Referrer-, UTM- und Pfadkategorie, Viewport-Klasse) sowie die geschwärzten Werte utm_campaign und utm_source — nie Domain, Rohpfad, andere Parameter oder eine Gerätekennung. Die Smart-Zuweisung aus Abschnitt 2.2 trägt ebenfalls nur grobe Kategorien (Gerät mobil/Desktop, Quellkategorie, neu/wiederkehrend, Warenkorbstatus).

2.9 Kauf-Tracking im Shop (pixel_events)

Hat der Händler PopUplift installiert und haben Sie im Cookie-Banner des Shops der Analyse zugestimmt, übermittelt eine Shopify-Web-Pixel-Erweiterung von PopUplift Einkaufsereignisse an PopUplift: angesehene Produkte und Kollektionen, Suchanfragen, Warenkorb, Checkout-Start und Kauf, jeweils mit Shopify-Produkt-, Varianten-, Kollektions- und Bestell-ID, Menge, Betrag, Währung, ob ein Rabatt genutzt wurde, Zeitpunkt und der pseudonymen Sitzungskennung aus Abschnitt 2.7. Suchanfragen werden nur übernommen, wenn sie kein @ und keine Ziffernfolge ab fünf Stellen enthalten, und auf 64 Zeichen gekürzt. Name, E-Mail-Adresse, Telefonnummer, Anschrift und Kunden-ID werden nicht übermittelt: das Pixel verwirft sie im Browser, der Server lehnt sie ab. Shopify lädt das Pixel nur nach Zustimmung zum Zweck „Analytics“ (Shopify Customer Privacy).

Zweck ist die Zuordnung von Käufen zu Popups für den Händler (Umsatz je Popup). PopUplift handelt dabei als Auftragsverarbeiter des Händlers; Grundlage ist der Auftragsverarbeitungsvertrag ab Version 2026-10-02 (Abschnitt 12).

Nächtliches Archiv. Abgeschlossene Tage der Daten aus Abschnitt 2.7, des Ausspielungsprotokolls der Popups und der Einkaufsereignisse legt PopUplift als Dateien in einem eigenen Speicher bei Cloudflare R2 in der EU-Jurisdiktion ab. Besucher-, Sitzungs- und Bestellkennungen werden dabei mit einem geheimen Schlüssel pseudonymisiert. Das Archiv folgt denselben höchstens 180 Tagen; eine Löschung nach Abschnitt 9 schreibt die betroffenen Archivtage neu. Zu den gesehenen Produkten speichert PopUplift außerdem die Shopify-Produktkategorie (Taxonomie), die keine Personendaten enthält. Speicherdauer: höchstens 180 Tage wie der Strom aus Abschnitt 2.7 (Abschnitt 8); Löschung nach Abschnitt 9.

2.10 Smart Rewards (smart_reward_assignments)

Smart Rewards gibt es nur, wenn die Funktion für den Shop freigeschaltet ist und der Händler in einem Popup statt eines festen Angebots ein Set aus zwei oder drei Angeboten (Rewards) verwendet, etwa beim Rubbellos, beim Glücksrad, an einem Code-Element oder als Reward einer Aktion.

Zuweisung. Fragt das Widget für einen Besucher das Angebot eines solchen Popups an, weist der Server ihm eines der Angebote zu: pseudonym und zufällig in gleichen Anteilen, berechnet aus Shop, Besucherkennung, Set und dessen Stand. Hat der Händler ein Angebot für alle übernommen, bekommt jeder Besucher dieses. Gespeichert werden Besucherbezug, Set und dessen Stand, das zugewiesene Angebot, das Popup der ersten Zuweisung und der Zeitpunkt. Die Zuweisung sorgt dafür, dass derselbe Besucher immer dasselbe Angebot sieht — auch nach einer Änderung des Sets — und dass er nur dieses Angebot beanspruchen und einlösen kann. Sie ist Teil der Ausspielung des Popups und hängt nicht an der Analytics-Einwilligung.

Messung (Exposure). Nur wenn der Besucher dem Marketing und der Analyse zugestimmt hat (marketingAllowed() und analyticsProcessingAllowed()), meldet das Widget, dass das zugewiesene Angebot sichtbar gezeigt wurde. Der Server vermerkt dazu einmalig den Zeitpunkt der ersten Anzeige, das Popup dieser Anzeige und — wenn das Popup in einem A/B-Test läuft und der Server die Variante aus seiner eigenen Auslieferung belegen kann — Test und Variante. Eine vom Browser genannte Variante wird nie ungeprüft übernommen. Im Browser bleibt der Merker pl-sr (Abschnitt 5).

Auswertung. Der Händler sieht je Angebot, Popup, A/B-Variante und Format, wie viele gemessene Besucher das Angebot gesehen haben und wie viele davon sich angemeldet, einen Code beansprucht und — innerhalb von 30 Tagen — mit dem Code bezahlt haben, samt Umsatz je Währung. Dafür verknüpft der Server die Zuweisung mit den Ereignissen (2.2), den ausgegebenen Rabattcodes (2.4) und den zugeordneten Bestellungen (2.5) desselben Besuchers. Der Report zeigt nur Summen, keine einzelnen Besucher.

Widerruf. Fehlt später eine der beiden Einwilligungen, meldet das Widget das einmal an den Server. Der Server verwirft daraufhin die Messung aller bereits gemessenen Zuweisungen des Besuchers in diesem Shop (Anzeigezeitpunkt, Popup, Test und Variante) und markiert den betroffenen Stand des Sets als unvollständig, damit der Report keine verzerrten Zahlen zeigt. Die Zuweisung selbst bleibt, damit das Angebot für den Besucher gleich bleibt.

Speicherdauer. Zuweisung und Messung teilen das Schicksal der Besucherzeile: Sie werden mit ihr gelöscht — über den 90-Tage-Lauf für anonyme Besucher, über customers/redact oder mit der Deinstallation (Abschnitte 8 und 9).

PopUplift handelt dabei als Auftragsverarbeiter des Händlers; Grundlage ist der Auftragsverarbeitungsvertrag ab Version 2026-10-03 (Abschnitt 12).

3. Verarbeitung in eigener Verantwortlichkeit (Daten des Händlers)

Shop-Domain und Shop-Status, verschlüsselte Zugangstoken (Shopify, Klaviyo), Einstellungen (Firmenname, Links auf AGB und Datenschutzerklärung des Händlers, Logo), monatliche Nutzungszahlen (usage_counters: Besucher und Leads je Monat) als Grundlage der Abrechnung, sowie Support-Kommunikation. Bei Installation, Reinstallation und Deinstallation liest PopUplift außerdem Name, E-Mail- und Kontaktadresse, Inhabername, Shopify-Plan und Land des Händlers aus Shopify und übermittelt diese zusammen mit Domain, Währung, Zeitzone und Hauptdomain an einen gesondert zu konfigurierenden direkten Marketing-Service. Zweck sind Onboarding, Support und Vertragsverwaltung. PopUplift speichert diese Felder während der Installation in der Shop-Zeile, damit Lifecycle-, Nutzungs- und Vertragsereignisse auch bei vorübergehend nicht erreichbarem Empfänger faktisch und retryfähig zugestellt werden können. Gewöhnliche Marketingereignisse speichern keine zusätzliche Kopie der Kontaktdaten; sie werden erst beim Versand aus der Shop-Zeile ergänzt. Beim Shopify-shop/redact werden Shop-Zeile, Identitätscache und offene gewöhnliche Ereignisse gelöscht. Der minimale, kontaktfreie Löschtombstone bleibt bis zur erfolgreichen Zustellung erhalten; erfolgreich zugestellte gewöhnliche Ereignisse und Tombstones sind nach sieben Tagen löschberechtigt und werden beim nächsten erfolgreichen begrenzten Retentionlauf entfernt (planmäßig alle sechs Stunden). Eine externe Empfängerverarbeitung beginnt erst nach gesonderter Konfiguration und unterliegt deren eigenem, vertraglich festzulegendem Löschkonzept.

3.1 Shopify-Traffic-Empfehlung

In der Plan-Auswahl verwendet PopUplift Shopifys aggregierte Zahl der menschlichen Online-Store-Besucher aus den letzten 30 vollständigen Tagen. Die dafür nötige Berechtigung read_reports gehört zu den bei der Installation angefragten Pflichtberechtigungen. Bestandsinstallationen müssen die Scope-Erweiterung einmal in Shopify reautorisieren. PopUplift bietet keinen separaten Knopf zum Nachfordern oder Widerrufen dieser Pflichtberechtigung. Fehlt sie bei einer noch nicht reautorisierten Installation oder ist der Abruf nicht verfügbar, bleibt die Plan-Auswahl mit PopUplifts eigener Hochrechnung nutzbar.

Die hierfür fest programmierte ShopifyQL-Abfrage wählt keine Kundenzeilen, Kundenfelder oder Dimensionen aus. Ihr einziger Traffic-Inhalt ist online_store_visitors als aggregierter Zahlenwert; Zeitraum, Abrufzeitpunkt und Status sind technische Metadaten. PopUplift speichert weder die ShopifyQL-Rohantwort noch individuelle Kundendaten aus diesem Traffic-Pfad in der Datenbank oder in Protokollen. Der Wert liegt nur flüchtig, der Shop-Domain zugeordnet, im Arbeitsspeicher des Servers (30 Minuten als aktueller Wert, bei vorübergehender Nichterreichbarkeit bis zu 24 Stunden als veralteter Fallback). Nach spätestens 24 Stunden wird er automatisch aus dem Arbeitsspeicher entfernt. Eine von Shopify gemeldete Scope-Änderung invalidiert den Cache für den betroffenen Shop sofort.

Der Shopify-Wert dient ausschließlich der initialen Tarifempfehlung. PopUplifts eigener Zähler usage_counters bleibt die alleinige Grundlage für Besucherlimit, Über-Limit-Hinweis und Abrechnungsnachweis.

Shopify verlangt als technische Voraussetzung für jede shopifyqlQuery zusätzlich eine appweite Level-2-Freigabe für die geschützten Kundenfelder Name, Adresse, Telefon und E-Mail, obwohl die konkrete Abfrage diese Felder nicht auswählt. Diese Plattformvoraussetzung ist breiter als der hier beschriebene Traffic-Pfad. Sie bedeutet insbesondere nicht, dass PopUplift insgesamt keine personenbezogenen Daten verarbeiten kann oder verarbeitet: Die tatsächlich genutzten E-Mail-, optionale Telefon-, Lead-Sync- und Attributionspfade sind in Abschnitt 2 und der folgenden Tabelle separat beschrieben.

3.2 KI-Funktionen (Sprachmodelle)

Einige Funktionen der App nutzen Sprachmodelle der in Abschnitt 6 genannten Anbieter Anthropic, OpenRouter und TypeSafe. Sie laufen nur, wenn der Händler sie auslöst oder einschaltet, und erhalten ausschließlich Inhalte des Händlers:

Keine personenbezogenen Daten von Besuchern an Sprachmodelle. Besucher-, Lead-, Kunden- und Bestellzeilen, E-Mail-Adressen, Telefonnummern und Antworten von Besuchern gehen an kein Sprachmodell. Das sagt PopUplift auch im Auftragsverarbeitungsvertrag (§ 2) verbindlich zu.

Speicherung der Eingaben. Was der Händler selbst in die KI-Funktionen eingibt — Prompts wie Wünsche beim Erstellen eines Popups sowie Anweisungen und Chat-Nachrichten im Editor —, speichert PopUplift bis zu 180 Tage. Zweck ist, die KI-Funktionen zu verbessern und nachvollziehen zu können, wie ein Vorschlag entstanden ist, etwa bei einer Rückfrage des Händlers oder einem Fehler. Gespeichert werden nur Inhalte des Händlers, keine Daten von Besuchern. Danach werden die Eingaben automatisch gelöscht, mit dem Shop (shop/redact) sofort. Rechtsgrundlage ist Art. 6 Abs. 1 lit. f DSGVO; das berechtigte Interesse ist, Qualität und Fehlerfreiheit der KI-Funktionen zu sichern.

Zweck ist die Bereitstellung dieser Funktionen; Rechtsgrundlage ist Art. 6 Abs. 1 lit. b DSGVO (Vertragserfüllung). Soweit die Inhalte personenbezogene Daten enthalten — etwa ein Inhabername im Shop-Namen oder ein Name im öffentlichen Text der Startseite —, verarbeiten die Anbieter sie als Auftragsverarbeiter von PopUplift. Zu Speicherort, Löschung beim Anbieter und Übermittlungsgrundlage siehe Abschnitte 6 und 7.

4. Zwecke, Rechtsgrundlagen und Speicherdauer

Die eine Tabelle, in der alles zusammenläuft. Grundlage ist Verordnung (EU) 2016/679. Bei berechtigtem Interesse ist das Interesse ausformuliert und nicht nur die Norm zitiert.

Kriterien, wo keine feste Zahl steht. Wenn wir Daten auf Grundlage eines Vertrags verarbeiten, speichern wir sie für die Dauer des Vertrags und danach, solange Ansprüche daraus geltend gemacht werden können. Bei berechtigtem Interesse endet die Speicherung, sobald das Interesse entfällt oder ein begründeter Widerspruch vorliegt. Bei Einwilligung endet sie mit dem Widerruf. Bei gesetzlicher Pflicht gilt die gesetzliche Frist.

5. Speicherung auf dem Endgerät des Besuchers (§ 25 TDDDG)

Das Widget setzt keine Cookies. Es legt Werte in localStorage und sessionStorage des Browsers ab. Rechtlich ist das derselbe Vorgang: § 25 TDDDG erfasst jede Speicherung von Informationen auf dem Endgerät und jeden Zugriff darauf, unabhängig von der Technik.

Wichtig zur Zuständigkeit: Die Speicherung findet auf der Storefront des Händlers statt, also im Rahmen des digitalen Dienstes, den der Händler anbietet. Eine nach § 25 Abs. 1 TDDDG erforderliche Einwilligung ist deshalb vom Händler einzuholen, in der Regel über sein Consent-Banner. PopUplift liefert die Angaben, die er dafür braucht, und zwar diese:

Zu den unbedingt erforderlichen Einträgen. § 25 Abs. 2 Nr. 2 TDDDG befreit von der Einwilligung, wenn die Speicherung „unbedingt erforderlich ist, damit der Anbieter eines digitalen Dienstes einen vom Nutzer ausdrücklich gewünschten digitalen Dienst zur Verfügung stellen kann". pl-jwt und pl-fs-<id> erfüllen das: Ohne sie kann der Besucher das Popup, das er gerade ausfüllt, nicht abschließen. pl-list-join-<id> ebenso: Ohne ihn ginge die Aufnahme in die Liste, die der Besucher mit seiner Anmeldung ausdrücklich angefordert hat, verloren, wenn er vor dem Ende des Popups die Seite wechselt.

Zu den Einträgen der Frequenzbegrenzung. pl-session-open-<id>, pl-popup-ground, pl-has-email und pl-done-<id> verhindern, dass derselbe Besucher dasselbe Popup wieder und wieder sieht. pl-done-<id> hält dabei das Ende fest: Wer den Reward geclaimt oder das Popup weggeklickt hat, hat den Flow abgeschlossen; ohne diesen Vermerk begänne er auf der nächsten Seite von vorn. Gespeichert ist der Zeitpunkt des Abschlusses und die Popup-ID des Händlers — nichts, was den Besucher beschreibt. Wir ordnen diese vier Einträge als unbedingt erforderlich im Sinne des § 25 Abs. 2 Nr. 2 TDDDG ein: Ohne sie wäre der Dienst für den Besucher keine abgeschlossene Interaktion, sondern eine Endlosschleife — dasselbe Popup erschiene auf jeder Seite erneut, auch nachdem er es ausgefüllt oder weggeklickt hat. Die Frequenzbegrenzung schützt damit in erster Linie den Besucher selbst.

Zweite Ebene zu pl-done-<id>. Der Marker kann verloren gehen: Der Speicher eines Browsers ist begrenzt, und ein fehlgeschlagener Schreibversuch bleibt unbemerkt. Ein bereits abgeschlossenes Popup erschiene dann wieder. Der Launcher fragt deshalb einmal je Sitzung beim Server nach, welche Popups dieser Besucher schon abgeschlossen oder weggeklickt hat, und stellt den Marker wieder her (pl-done-srv merkt sich, dass gefragt wurde). Zwei Punkte dazu, weil sie leicht missverstanden werden:

• Es entsteht kein neues Erkennungsmerkmal. Gefragt wird ausschließlich mit dem Sitzungstoken pl-jwt, das ohnehin existiert. Es liegt im selben Speicher desselben Browsers wie pl-done-<id> — wer seine Website-Daten löscht, den Browser wechselt oder privat surft, löscht beides und ist danach auch für den Server ein neuer Besucher. Ohne Sitzungstoken wird nicht gefragt, und es wird zu diesem Zweck kein Besucher angelegt.
• Es entstehen keine neuen Datenarten. Die Antwort wird aus dem gebildet, was ohnehin gespeichert ist: den Ereignissen aus Abschnitt 2.2 (darunter „Popup geschlossen") und den ausgegebenen Rabattcodes aus Abschnitt 2.4. Die dort genannten Löschfristen gelten damit unverändert auch hier.

Abfrage und Meldung hängen zusätzlich am Consent-Signal des Shops (marketingAllowed()): Der lokale Marker ist unbedingt erforderlich, diese zweite Ebene ist es nicht — ohne Einwilligung findet sie nicht statt.

Zu den nicht erforderlichen Einträgen. Sie dienen den Ausspielungsregeln (Targeting), der Sitzungszählung, der zweiten Ebene oben, A/B-Tests, der zweiten Chance (Smart Trigger), der Smart-Rewards-Messung und der Collection-Sitzung aus Abschnitt 2.7. Sie entstehen nur, wenn der Händler entsprechende Regeln konfiguriert hat. Rechtsgrundlage ist die Einwilligung des Besuchers nach Art. 6 Abs. 1 lit. a DSGVO sowie § 25 Abs. 1 TDDDG. Die Einwilligung ist jederzeit mit Wirkung für die Zukunft widerrufbar, in der Regel über das Consent-Banner des Shops. Ein Widerruf berührt die Rechtmäßigkeit der bis dahin erfolgten Verarbeitung nicht.

Lesen von Klaviyos __kla_id (Erkennung, #1106). Schaltet der Händler die Popup-Bedingung „Klaviyo has not recognized this browser" ein, liest das Widget zusätzlich zu den fünf Targeting-Schlüsseln ein Cookie, das Klaviyo auf der Storefront des Händlers setzt: __kla_id. Gelesen wird nur, ob dieses Cookie einen erkennenden Token (kx/exchange_id) trägt — ein anonymer Browser trägt dort nur cid. Das Ergebnis wird nicht gespeichert und nicht übertragen; es entscheidet ausschließlich lokal im selben Seitenaufruf, ob das Popup erscheint. PopUplift setzt dieses Cookie nicht und schreibt es nicht: es entsteht kein neuer Schlüssel und keine neue Ablage, und PopUplift fragt keine Klaviyo-Liste ab und sendet keine E-Mail an Klaviyo. Dieses Lesen ist § 25 TDDDG-relevant (Lesen zählt wie Speichern) und geschieht deshalb nur bei marketingAllowed() und nur, wenn mindestens eine ausgelieferte Popup-Regel die Bedingung tatsächlich auswertet. Ist die Bedingung nicht im Einsatz, wird das Cookie gar nicht erst gelesen. Ohne Einwilligung wird das Cookie ebenfalls nicht gelesen und die Bedingung bleibt aus. Die Einordnung von __kla_id selbst obliegt dem Händler und Klaviyo; Klaviyo beschreibt das Cookie in der eigenen Doku („Understanding cookies in Klaviyo", Stand 03.04.2026) als Tracking-/Marketing-Cookie. Zweck hier ist allein die Frequenz-/Ansprachebegrenzung gegenüber bereits bekannten Browsern. Liegt dieses Ergebnis im selben Seitenaufruf ohnehin vor, nutzt Smart Trigger es — nur bei erlaubter Marketing- und Analytics-Verarbeitung — zusätzlich als Ausschlusssignal (Abschnitt 2.2): Ein von Klaviyo erkannter Browser wird nicht eingeschrieben. Smart Trigger liest das Cookie nicht selbst und veranlasst keinen zusätzlichen Zugriff darauf.

Der Gegenwert dieser Aufstellung. Alle Werte in dieser Tabelle bleiben im Browser des Besuchers. Das Besucherprofil, gegen das die Ausspielungsregeln ausgewertet werden, wird ausschließlich lokal im Browser gebildet und an niemanden übertragen. Der Server erfährt aus dem Targeting nicht, wer ein Besucher ist, sondern nur, welche Kampagnen-IDs am Ende angefragt wurden. Deshalb gibt es in PopUplift bewusst keinen Report über UTM-Quelle, Referrer oder Gerät. Einzige Übertragung daraus abgeleiteter Werte: Mit Einwilligung in Marketing und Analytics sendet Smart Trigger beim Einstieg die groben Kategorien aus Abschnitt 2.2 (Gerät, Quellkategorie, neu/wiederkehrend, Warenkorbstatus), nie die Rohwerte; auch sie erscheinen in keinem Report.

Das Widget wertet den Consent-Status aus. Es lädt Shopifys Customer-Privacy-API ausdrücklich mit Shopify.loadFeatures und wartet vor dem ersten nicht erforderlichen Zugriff höchstens 1.000 ms insgesamt darauf, dass der Loader erscheint und dessen Callback antwortet. Erst eine vollständig bereite API darf einen der zwölf nicht erforderlichen Schlüssel öffnen — beim Schreiben ebenso wie beim Lesen, denn § 25 TDDDG erfasst beides gleichermaßen. Fehlende, ladende, verspätete, unvollständige oder fehlerhafte APIs werden nicht als Zustimmung behandelt. PopUplift setzt selbst nie eine Consent-Entscheidung. Die Zuordnung folgt dem Zweck:

Ohne Einwilligung entsteht keiner dieser Schlüssel. Das Popup funktioniert weiter; die Ausspielungsregeln werten dann gegen das Profil eines Erstbesuchers aus (leere Historie, erster Seitenaufruf, keine Wiedererkennung, Quelle nur auf der Landing-Seite). Regeln, die auf Seite, Gerät oder aktueller URL beruhen, greifen unverändert — Einwilligung kostet hier Treffgenauigkeit, nicht die Funktion. Auch das zusätzliche Lesen von Klaviyos __kla_id (Abschnitt oben, #1106) unterbleibt ohne Einwilligung. Bei Widerruf werden alle nicht erforderlichen Schlüssel — die fünf Targeting-Schlüssel, alle A/B-Zuteilungen, pl-done-srv, pl-tracked-session, pl-collect-v1 und alle pl-smart-*-Einträge — unmittelbar entfernt (der Launcher hört auf visitorConsentCollected). pl-sr bleibt, bis der Server die Meldung des Widerrufs bestätigt hat, und wird dann entfernt. Klaviyos eigenes Cookie bleibt unberührt; es gehört nicht uns.

Hat der Shop keine Consent-Pflicht für den Besucher, wird geschrieben — aber erst nach API-Bereitschaft. Das ist Shopifys eigene API-Semantik: In Regionen mit Consent-Pflicht sind nicht erforderliche Zwecke bis zur Einwilligung gesperrt, in allen anderen antwortet die bereite API mit „ja“. Eine bloß fehlende API ist dagegen keine Aussage über Region oder Einwilligung und bleibt deshalb geschlossen. Kann Shopify die API innerhalb der Bootstrap-Grenze nicht bereitstellen, funktioniert das Popup weiter mit einem flüchtigen Erstbesucherprofil; ein später erfolgreicher Callback kann künftige Zugriffe öffnen, speichert das frühere Profil aber nicht rückwirkend.

Die Einträge der Frequenzbegrenzung hängen bewusst nicht an diesem Gate: Sie sind nach der Einordnung oben unbedingt erforderlich, und ihr Wegfall würde den Dienst für den Besucher in eine Endlosschleife verwandeln.

Speicherung im Verwaltungsbereich

Die Verwaltungsoberfläche ist ein anderer Dienst mit einem anderen Betroffenen: Dort ist der Händler (oder sein Mitarbeiter) der Nutzer, nicht der Shop-Besucher. In diesem Bereich legt Microsoft Clarity zwei Cookies an — _clck (Kennung des Nutzers beim Anbieter) und _clsk (Zuordnung der Seitenaufrufe zu einer Sitzung) —, sobald die Aufzeichnung nach der AVV-Zustimmung beginnt. Ohne diese Zustimmung und ohne konfigurierte Projekt-ID entstehen sie nicht. Sie dienen allein der Zuordnung innerhalb des Verwaltungsbereichs; das Widget in der Storefront setzt sie nicht und lädt Clarity überhaupt nicht. Einzelheiten zum Empfänger in Abschnitt 6, zur Drittlandübermittlung in Abschnitt 7.

6. Empfänger und Unterauftragsverarbeiter

Verarbeitungsort und Speicherort werden getrennt ausgewiesen, weil ein Unternehmen mit Sitz in einem Drittland Daten in der EU speichern kann und umgekehrt. Beides ist für die Bewertung nötig.

Wer davon Unterauftragsverarbeiter ist. Unterauftragsverarbeiter im Sinne des AV-Vertrags (dort Anlage 1) sind Supabase, Railway, Shopify und Sentry, ab AV-Vertrag Version 2026-10-03 außerdem Anthropic, OpenRouter (mit den Modellbetreibern, an die OpenRouter weiterleitet) und TypeSafe. Sie erhalten nach dem AV-Vertrag keine personenbezogenen Daten von Besuchern; sie stehen dort, damit die Zusage verbindlich ist und der Händler sieht, wer Inhalte seines Shops verarbeitet. Der geplante direkte Marketing-Service ist bis zur vollständigen Dokumentation der in seiner Tabellenzeile genannten Angaben nicht aktiviert und noch nicht als Unterauftragsverarbeiter oder sonstiger Empfänger eingeordnet. Die übrigen Zeilen sind Empfänger, aber keine Unterauftragsverarbeiter: Klaviyo, weil der Vertrag über diese Übermittlung zwischen Händler und Klaviyo besteht; Microsoft (Clarity), weil Microsoft für die Aufzeichnung nach eigener Angabe als eigener Verantwortlicher auftritt und keine Auftragsverarbeitungsverträge abschließt — die Übermittlung ist deshalb keine Auftragsverarbeitung und gehört nicht in Anlage 1 des AV-Vertrags; der Betreiber, weil er der Auftragsverarbeiter selbst ist. Cloudflare verarbeitet beim E-Mail-Routing Daten aus Abschnitt 3. Soweit der optionale Edge-Proxy für einen Host aktiviert wird, verarbeitet Cloudflare dort auch Besucheranfragen und ist für diesen Betrieb als Unterauftragsverarbeiter zu berücksichtigen; die neue Aktivierung ist auf Staging begrenzt.

Zu Sentry. Sentry ist aktiv. Fehlerberichte des Servers und der Verwaltungsoberfläche werden vor dem Versand von personenbezogenen Daten befreit: E-Mail-Adressen, Zugangstoken, JWTs, Authorization-Header, Klaviyo-Keys und die Werte sensibler Feldnamen werden ersetzt. Adressen werden auf Schema, Host und Pfad gekürzt — Abfrageparameter und Fragment verwirft die Bereinigung vollständig, unabhängig davon, wie sie heißen. Tracing und Profiling sind abgeschaltet; die Verwaltungsoberfläche sendet weder Sitzungsaufzeichnungen (Session Replay) noch Bedienungsverläufe noch Nutzerkennungen. Das Storefront-Widget enthält kein Fehler-SDK eines Drittanbieters, sondern meldet Fehler an unseren eigenen Server; die Meldung enthält Fehlertext, Stack und die Adresse der Seite, auf der der Fehler auftrat — ohne Abfrageparameter —, und wird erst nach der Bereinigung an Sentry weitergegeben. Die Ereignisdaten liegen in Sentrys EU-Datenregion (Frankfurt am Main) und werden vom Anbieter automatisch gelöscht — im derzeit genutzten Sentry-Plan nach 30 Tagen.

Zu Klaviyo. Der Sync ist optional und wird erst aktiv, wenn der Händler die Verbindung selbst herstellt — über den Connect-Knopf in den App-Einstellungen (OAuth) oder mit einem eigenen API-Key. Übergeben werden dann E-Mail-Adresse, Einwilligungszeitpunkt und die vom Händler gewählten Zusatzfelder einschließlich Quiz-Antworten als Profil-Eigenschaften; auf dieser Grundlage legt PopUplift im Konto des Händlers auch Segmente an, sofern der Händler das konfiguriert. Bei aktiviertem SMS-Sync übergibt PopUplift außerdem die Telefonnummer und ausschließlich die SMS-Marketing-Einwilligung an die vom Händler gewählte Klaviyo-SMS-Liste. Der lokale SMS-Einwilligungszeitpunkt wird dabei weder als zurückdatierter Klaviyo-Zeitstempel noch als E-Mail-Einwilligung übermittelt.

Zu den Sprachmodellen. Die KI-Funktionen aus Abschnitt 3.2 senden ihre Anfragen entweder direkt an Anthropic oder über OpenRouter an einen Betreiber des jeweils gewählten Modells, den OpenRouter je Anfrage wählt; das kann auch ein Betreiber außerhalb der EU sein, etwa in China oder Singapur. Welche Inhalte das sind, steht dort je Funktion. Personenbezogene Daten von Besuchern gehen an kein Sprachmodell.

Zu Microsoft Clarity. Clarity zeichnet Sitzungen in der Verwaltungsoberfläche auf — nicht in der Storefront. Damit betrifft es Sitzungen des Händlers und seiner Mitarbeiter, nicht Shop-Besucher. Die Aufzeichnung startet erst, wenn der Händler den Auftragsverarbeitungsvertrag akzeptiert hat; ohne diesen Vertrag und ohne konfigurierte Projekt-ID wird kein Skript geladen und kein Wert auf dem Endgerät gespeichert.

Erhoben werden Seitenaufbau und Interaktionen (Klicks, Mausbewegungen, Scrollen) und daraus Heatmaps. Die Übertragung erfolgt an Clarity in den USA; eine EU-Region ist nicht wählbar. Nach Anbieterangabe werden Aufzeichnungen 30 Tage aufbewahrt, Klick- und Heatmap-Daten sowie als Favorit markierte Sitzungen 13 Monate. Eine Löschung einzelner Betroffener sieht der Anbieter nicht vor — gelöscht wird nur das gesamte Projekt.

Maskierung. Inhalte von Eingabefeldern und Auswahllisten werden in jedem Maskierungsmodus nicht erhoben und sind nicht abwählbar; getippter Inhalt ist in der Aufzeichnung nie sichtbar. Das Projekt steht zusätzlich auf „Balanced", womit erkannte E-Mail-Adressen und Ziffern maskiert werden. Die Flächen, die Daten von Shop-Besuchern anzeigen — die Trefferliste der Lead-Seite und der Reportkörper — sind darüber hinaus ausdrücklich maskiert, weil dort auch im Popup erfasste Freitextantworten stehen, die „Balanced" nicht erkennt.

Grenzen, die der Händler kennen sollte. Werden Drittanbieter-Cookies im Browser blockiert oder blockiert eine Erweiterung die Adresse des Anbieters, findet keine Aufzeichnung statt. In diesem Fall sind die Zahlen in Clarity nicht repräsentativ für alle Händler.

Änderungen an dieser Liste. Neue oder ersetzte Unterauftragsverarbeiter werden 15 Tage vor Wirksamkeit angekündigt. Der Händler kann innerhalb von 10 Tagen widersprechen; kommt keine Einigung zustande, kann er den Vertrag kündigen. Die Regelung steht in § 6 des AV-Vertrags (Abschnitt 12), hier nur zur Information.

7. Übermittlung in Drittländer

Die Datenbank und der Anwendungsserver stehen in der EU (Frankfurt und Amsterdam). Für den regulären Betrieb der App findet keine Übermittlung personenbezogener Daten in ein Drittland statt.

Acht Ausnahmen, die ehrlich benannt gehören:

1. Klaviyo verarbeitet in den USA. Die Übermittlung findet nur statt, wenn der Händler den Sync aktiv einrichtet, und sie geschieht in seinem Auftrag und auf seine Rechnung. Grundlage: EU-US Data Privacy Framework und ergänzende Standardvertragsklauseln.
2. Shopify ist die Plattform, auf der der Shop ohnehin läuft. Die Datenverarbeitung dort regelt der Vertrag zwischen Händler und Shopify (für EU-Händler mit Shopify International Limited, Irland); für die Übermittlung nach Kanada gilt der Angemessenheitsbeschluss der EU-Kommission.
3. Supabase und Railway betreiben EU-Rechenzentren, sind aber Gesellschaften außerhalb der EU (Singapur bzw. USA). Die Daten liegen in der EU; ein Zugriff von außerhalb (etwa durch Support oder Administration) ist nicht ausgeschlossen und über die jeweiligen AV-Verträge samt Standardvertragsklauseln abgedeckt.
4. Sentry speichert die Fehler-Ereignisse in der EU (Frankfurt am Main); die Konto- und Organisationsdaten des Sentry-Kontos liegen beim Anbieter in den USA. Grundlage: Standardvertragsklauseln und EU-US Data Privacy Framework.
5. Cloudflare leitet die E-Mails an die Support- und Datenschutz-Postfächer über sein globales Netz weiter, ohne die Inhalte nach Anbieterangabe zu speichern. Bei aktiviertem Edge-Proxy verarbeitet es außerdem die Anfragen der freigegebenen Hosts einschließlich IP-basierter Länderbestimmung; die neue Aktivierung ist auf Staging begrenzt. Grundlage: Standardvertragsklauseln und EU-US Data Privacy Framework.
6. Microsoft Clarity verarbeitet die Aufzeichnungen der Verwaltungsoberfläche in US-Rechenzentren; eine EU-Region ist nicht wählbar. Betroffen sind ausschließlich Sitzungen des Händlers und seiner Mitarbeiter. Da Microsoft für Clarity nach eigener Angabe als eigener Verantwortlicher auftritt, handelt es sich nicht um eine Auftragsverarbeitung; unsere Übermittlungsgrundlage ist das berechtigte Interesse an der Verbesserung der Verwaltungsoberfläche. EU-Kunden kontrahieren mit Microsoft Ireland Operations Limited, das über Standardvertragsklauseln mit Microsoft Corporation verbunden ist.
7. Anthropic und OpenRouter verarbeiten die Anfragen der KI-Funktionen (Abschnitt 3.2) in den USA. OpenRouter leitet sie an Modellbetreiber weiter, die auch außerhalb der EU sitzen können, etwa in China oder Singapur, und die diese Inhalte teils speichern oder zum Training verwenden. Übermittelt werden nur Inhalte des Händlers, keine personenbezogenen Daten von Besuchern. Grundlage: Standardvertragsklauseln in den jeweiligen AV-Verträgen (für Anthropic mit Anthropic Ireland, Limited).
8. TypeSafe prüft die Bearbeitungsvorschläge des Editor-Assistenten in den USA (Abschnitt 3.2). Übermittelt werden nur Inhalte des Händlers, keine personenbezogenen Daten von Besuchern. Grundlage: Standardvertragsklauseln im AV-Vertrag.

8. Löschfristen

Der reguläre Löschlauf ist automatisiert und läuft alle sechs Stunden. Der partitionierte Collection-Strom aus Abschnitt 2.7 hat zusätzlich eine eigene, engere Wartung: beim Serverstart und danach alle 15 Minuten wird eine fehlende Partition angelegt und werden abgelaufene Partitionen entfernt.

Wenn die Wartung ausfällt, ist die Frist nicht garantiert. Fehlt eine benötigte Partition, antwortet der Collection-Ingest mit 503 und ein datensparsamer Alarm geht heraus; ein Ausfall wird nicht als Erfolg dargestellt und stoppt die breite Aktivierung, statt still über die Frist hinauszugehen. Fehlende EXECUTE-Rechte der App-Rolle auf der Wartungsfunktion oder ein Lock-Timeout werden sichtbar gemacht. Die App-Rolle kann keine Tabelle frei erzeugen oder löschen; die DDL läuft ausschließlich über eine eng begrenzte, argumentlose Wartungsfunktion des Migrationseigentümers mit festem Namensmuster und interner Datumsermittlung.

Ohne automatische Frist, und zwar bewusst:

• Besucher mit E-Mail-Adresse bleiben, solange die App beim Händler installiert ist. Sie sind der Lead-Bestand des Händlers; ihn nach Frist zu löschen wäre eine Weisung, die der Händler nicht erteilt hat. Gelöscht wird über customers/redact, über die Deinstallation oder auf Wunsch des Händlers.
• Zähl-Log (usage_counters) ist die Abrechnungsgrundlage und append-only. Er enthält nur Zahlen je Shop und Monat, keinen Personenbezug. Die App-Rolle in der Datenbank hat dafür nicht einmal das Recht zum Löschen.
• Nachweiszeilen im Compliance-Ledger (compliance_requests ohne result) bleiben als Beleg, dass eine Anfrage bearbeitet wurde. Sie enthalten nie eine Klartext-E-Mail, sondern Kunden-ID und SHA-256-Hash.
• Zwischenstände im Popup teilen das Schicksal der Besucherzeile: Sie werden mit ihr gelöscht — über den 90-Tage-Lauf für anonyme Besucher, über customers/redact oder mit der Deinstallation.
• Smart-Rewards-Zuweisungen (Abschnitt 2.10) ebenso; ihre Messung wird schon beim Widerruf der Einwilligung verworfen.

Nach Deinstallation: Die Zugangstoken werden schon beim Uninstall-Webhook (app/uninstalled) sofort gelöscht. 48 Stunden nach der Deinstallation sendet Shopify shop/redact. Damit wird die Shop-Zeile gelöscht; der Fremdschlüssel-Cascade nimmt Leads, Popups, Uploads, verschlüsselte Token, offene Jobs sowie die beiden Collection-Tabellen samt ungebundener Sitzungen mit.

Nach einer Wiederherstellung aus einer Sicherungskopie werden zwischenzeitlich eingegangene Löschanfragen erneut angewendet; das Nachweisregister der bearbeiteten Anfragen übersteht die Wiederherstellung.

9. Betroffenenrechte und die Shopify-Compliance-Webhooks

Besucher eines Shops richten ihre Anfragen an den Händler, er ist der Verantwortliche. Der Händler leitet sie über Shopify weiter; Shopify stellt sie PopUplift als Webhook zu.

Alle drei Webhooks werden HMAC-geprüft (ungültige Signatur: 401), im Ledger compliance_requests protokolliert (mit unique(topic, payload_hash) gegen Doppelverarbeitung), sofort mit 200 quittiert und danach von einem Hintergrund-Worker ausgeführt. Grund für die Trennung: Shopify bricht eine Zustellung nach 5 Sekunden ab, ein shop/redact ist aber keine Fünf-Sekunden-Arbeit.

9.1 customers/data_request, Auskunft nach Art. 15

Die zu diesem Kunden gespeicherten Daten werden automatisch zusammengestellt (Besucherzeile, Ereignisse, Quiz-Antworten, ausgegebene Rabattcodes sowie — sobald eine Collection-Sitzung gültig an denselben Besucher gebunden ist — die Sitzungs-Metadaten und sämtliche Seitenpakete dieser Sitzungen; niemals die Collection-Tokens) und in die Ledger-Zeile geschrieben. Den Export stellt der Betreiber dem Händler auf Anfrage unverzüglich zur Verfügung, spätestens binnen 10 Tagen — dieselbe Frist, die der AV-Vertrag (§ 7) zusagt, damit der Händler seine eigene 30-Tage-Frist gegenüber dem Betroffenen wahren kann. Der Export wird nach 30 Tagen automatisch geleert, weil Shopify dem Händler 30 Tage zum Antworten gibt und die Kopie danach nur noch Risiko ist.

9.2 customers/redact, Löschung nach Art. 17

Drei Klassen, absichtlich unterschiedlich behandelt:

• Identitätszeilen werden gelöscht: visitors, visitor_flow_state, claimed_rewards, smart_reward_assignments sowie offene Sync-Jobs, die dem Besucher zugeordnet werden können. Ein noch gespeicherter Auskunfts-Export desselben Kunden (9.1) wird dabei ebenfalls geleert.
• Ereigniszeilen werden anonymisiert statt gelöscht: user_actions.data wird auf den Ereignistyp und, falls vorhanden, die A/B-Variantenkennung eingedampft, poll_answers verlieren die Besucher-Verknüpfung, attributed_orders behalten Betrag, Währung, Datum und Popup und verlieren claimed_reward_id, order_id und code. Die Variantenkennung hängt danach an keiner Person mehr: Die visitors-Zeile wird gelöscht und user_actions.visitor_id fällt durch ON DELETE SET NULL auf null. Die Tageszusammenfassung (popup_visitor_daily) verliert dabei ebenso die A/B-Bindung und die Übergabeart; ihre Besucherkennung fällt auf demselben Weg auf null.

Eine anonymisierte Smart-Zuweisung verliert ihre Gruppe. Der Report nimmt sie wie einen Messabbruch aus Zähler und Nenner und weist die Messung als ungültig aus, sobald der Anteil solcher Ausschlüsse eine feste Grenze überschreitet oder sich zwischen Behandlungs- und Kontrollgruppe deutlich unterscheidet; beim Lernen (Abschnitt 2.2) zählt sie ab der nächsten Neuberechnung nicht mehr. Die anonymisierte Zeile wird nie als beobachteter Null-Erfolg verwendet und kann daher keinen positiven Smart-Effekt erzeugen.

• Collection-Sitzungen werden gelöscht, nicht anonymisiert: Vor der Besucher-Löschung sperrt PopUplift die betroffenen Sitzungen und löscht ihre Seitenpakete, ihre Einkaufsereignisse aus dem Kauf-Tracking (Abschnitt 2.9) und die Sitzungen selbst. Einkaufsereignisse zu den Bestellungen, die Shopify in der Anfrage nennt, löscht PopUplift auch ohne gebundene Sitzung. Ein bloßes SET NULL des Bezugs wäre keine Anonymisierung einer weiterhin verknüpfbaren Sequenz und wird deshalb nicht verwendet. Zusätzlich werden die neu eingeführte user_actions.session_id und in Aktionsdaten mitgesendete Session-Schreibweisen entfernt; bestehende Typ-/Aggregatsemantik bleibt erhalten. Parallele Lösch-, Bind- und Ingest-Vorgänge laufen unter Zeilensperre, sodass eine gelöschte Sitzung weder durch Token-Wiederverwendung noch durch eine verspätete Bindung wieder entstehen kann.

Der Grund ist inhaltlich: Nach der Anonymisierung ist die Zeile kein personenbezogenes Datum mehr, und die Kennzahlen des Händlers sinken nicht rückwirkend bei jeder Löschanfrage.

9.3 shop/redact, Löschung des ganzen Shops

Kommt 48 Stunden nach der Deinstallation. Die shops-Zeile wird gelöscht, der Cascade räumt alles daran Hängende ab. Der Compliance-Ledger hat bewusst keinen Fremdschlüssel auf shops, sonst nähme der Cascade den Nachweis mit.

9.4 Alle Rechte im Überblick

10. Technische und organisatorische Maßnahmen (Art. 32)

• Verschlüsselung bei der Übertragung: HTTPS auf allen Endpunkten.
• Verschlüsselung im Ruhezustand für Geheimnisse: Shopify- und Klaviyo-Token liegen AES-256-GCM-verschlüsselt in der Datenbank. Eine Kopie der Datenbank ohne diesen Schlüssel ist für diese Felder unlesbar, und das ist so gewollt.
• Mandantentrennung: Jede fachliche Tabelle trägt shop_id; die Trennung der Shops wird in der Anwendungsschicht durchgesetzt und ist durch Tests abgedeckt. Zusätzlich ist auf allen Tabellen Row-Level-Security aktiv, um die öffentlichen Datenbankrollen vollständig auszusperren; die Trennung zwischen Shops leistet sie nicht selbst. Die Anwendungsrolle besitzt die für den Betrieb nötigen Schreibrechte; auf dem Zähl-Log usage_counters sind DELETE und TRUNCATE entzogen.
• Authentifizierung: Merchant-Zugriffe über App-Bridge-Session-Token je Request; Besucher-Sitzungen über eigene, ablaufende JWTs mit Key-ID zur Rotation. Webhooks werden HMAC-geprüft, bevor der Body geparst wird.
• Getrennte Collection-Tokens und DDL-Rechte: Die Collection-Routen nutzen ein eigenes Token mit eigener Zielgruppe, das normale Widget-Routen nicht akzeptieren (und umgekehrt). Die Collection-Tabellen sind nach UTC-Tag partitioniert; die Anwendungsrolle erhält keine allgemeinen CREATE/DROP- Rechte und kein Migrations-Secret zur Laufzeit, sondern nur EXECUTE auf eine eng begrenzte, argumentlose Wartungsfunktion. Jede Kind-Tabelle wird mit RLS/Grants abgesichert, damit historische Default-Grants keinen direkten Kind-Zugriff öffnen; anon/authenticated werden an Parent und Child abgewiesen. Die tatsächliche PostgreSQL-Version und die Rechte werden erst am lokalen Integrationsstand und später auf Staging belegt, nicht aus der Dokumentation abgeleitet.
• Datensparsamkeit im Monitoring: Fehlerberichte werden vor dem Versand von personenbezogenen Daten befreit; das Widget enthält kein Fehler-SDK eines Drittanbieters, sondern meldet an den eigenen Server.
• Fest begrenzte Shopify-Traffic-Abfrage: keine frei eingebbare ShopifyQL- Abfrage, sondern ausschließlich der aggregierte 30-Tage-Wert aus Abschnitt 3.1. Unerwartete Spalten oder mehrere Ergebniszeilen werden verworfen; Rohantworten und einzelne Kundenfelder werden weder persistiert noch geloggt.
• Rate-Limits auf allen offenen Storefront-Endpunkten.
• Sicherungskopien täglich, asymmetrisch verschlüsselt abgelegt (der private Schlüssel liegt getrennt von den Kopien); Wiederherstellung am 03.08.2026 geübt und bestanden.
• Getrennte Umgebungen: Testdaten laufen nie gegen die Produktionsdatenbank, Secrets werden zwischen Umgebungen nicht wiederverwendet.
• Zugriff auf Produktionsdaten: ausschließlich der Betreiber, über zwei protokollierte Wege — die Anwendung selbst und die kontogebundene, vom Anbieter auditierte Konsole des Datenbankdienstes.
• Verfahren bei Sicherheitsvorfällen: dokumentiert; Meldewege und Fristen in Abschnitt 11.

11. Verletzung des Schutzes personenbezogener Daten

Wird uns eine Verletzung des Schutzes personenbezogener Daten bekannt, informieren wir den betroffenen Händler unverzüglich, in der Regel binnen 24 Stunden ab Kenntnis, damit er seinen Pflichten aus Art. 33 und 34 DSGVO nachkommen kann (Meldung an die Aufsichtsbehörde binnen 72 Stunden, Benachrichtigung der Betroffenen bei hohem Risiko). Gegenüber Shopify besteht zusätzlich eine Meldepflicht binnen 24 Stunden aus dem Partner Program Agreement.

Das zugehörige Verfahren ist seit dem 03.08.2026 dokumentiert und regelt Erkennung, Meldewege und die genannten Fristen.

12. Auftragsverarbeitungsvertrag

Zwischen Händler und PopUplift ist ein Vertrag zur Auftragsverarbeitung nach Art. 28 DSGVO erforderlich. Shopifys eigene DPA regelt nur Händler gegenüber Shopify und deckt den App-Anbieter nicht ab.

Der AVV wird unter /avv bereitgestellt, frühere Versionen bleiben dort abrufbar. Händler stimmen ihm im Admin ausdrücklich zu; die Zustimmung in elektronischem Format wahrt die Form des Art. 28 Abs. 9 DSGVO. Version, Zeitpunkt und — soweit von Shopify verfügbar — die Shop-Owner-E-Mail werden als Nachweis protokolliert. Die Version 2026-10-02 mit dem Kauf-Tracking (Abschnitt 2.9) braucht diese ausdrückliche Zustimmung. Die Version 2026-10-03 (Smart Rewards, Anbieter von Sprachmodellen, geschätztes Besucherland) braucht keine Zustimmung im Admin, sondern wird angekündigt. Spätere Änderungen kündigt PopUplift nach § 12 des AVV mindestens vier Wochen vorher per E-Mail an die Shop-Owner-Adresse und mit einem Hinweis im Admin an; widerspricht der Händler nicht vor dem genannten Tag per E-Mail an privacy@popuplift.com, gilt die neue Fassung. Zeitpunkt der Ankündigung, genannter Tag und ein etwaiger Widerspruch werden je Shop protokolliert. Der AVV umfasst die Regelungen nach Art. 28 Abs. 3 DSGVO einschließlich seiner Unterauftragsverarbeiter-Liste (Anlage 1); Abschnitt 6 dieser Erklärung führt darüber hinaus Empfänger auf, die keine Unterauftragsverarbeiter sind, und erklärt die Abgrenzung.

13. Änderungen dieser Erklärung

Diese Erklärung wird angepasst, wenn sich Verarbeitung, Unterauftragsverarbeiter oder Fristen ändern. Stand: 06.10.2026.

Privacy Policy (short English version)

Who we are. PopUplift is a Shopify app operated by Kyrill Pysarenko, Danziger Str. 76, 10405 Berlin, Deutschland, privacy@popuplift.com.

Two roles, and which one applies to you. For everything a shop visitor does in a popup, the merchant is the controller and PopUplift is a processor acting on the merchant's instructions. We have no legal basis of our own for that data, and data subject rights are exercised with the merchant. This policy does not replace the merchant's own privacy notice. For the merchant's account data (shop domain, settings, usage counts for billing, support conversations) PopUplift is the controller.

Shopify traffic recommendation. In the plan chooser, PopUplift uses Shopify's aggregate count of human online-store visitors from the last 30 complete days. read_reports is a required permission requested during installation; existing installations must reauthorize the scope extension once in Shopify. PopUplift provides no separate control to request or revoke this required permission. If it is missing or the report is unavailable, the manual plan chooser remains usable. The fixed query selects no customer rows, customer fields or dimensions. Its only traffic content is the aggregate visitor number; period, fetch time and status are operational metadata. PopUplift stores no raw ShopifyQL response or individual customer data from this path in its database or logs. The number is held only in server memory (fresh for 30 minutes and, on temporary failures, usable for up to 24 hours as a stale fallback). It is automatically removed from memory after no more than 24 hours; a scope change reported by Shopify invalidates it immediately for the shop. It recommends the initial plan only; PopUplift's independent usage_counters remains the sole basis for visitor limits and over-limit notices. Shopify technically requires app-wide Level 2 approval for name, address, phone and email before any shopifyqlQuery, even though this query does not select those fields. This is not a claim that PopUplift has no PII access overall: the e-mail, optional phone, lead-sync and attribution processing described elsewhere in this policy still applies.

What we process on the merchant's behalf. E-mail address and optional phone number entered in the popup, separate timestamps for e-mail and SMS marketing consent, and the identifier of the Klaviyo SMS list selected by the merchant; quiz and survey answers; popup events (view, step, signup, reward claimed, close) with an anonymous session id; a daily summary of these events per popup, A/B variant and visitor id (counts and the times of the first e-mail sign-up and the last WhatsApp hand-off, no event content), used for PopUplift's own evaluation; the progress state of a multi-step popup; store country and language taken from Shopify storefront localisation; an optional, separate estimated visitor country (country code only), only for new visitors with explicit analytics consent: taken from an authenticated edge proxy where one supplies it, otherwise looked up from the visitor's IP address in a local country database on our own server, without any request to a third party (the IP address is not stored for this, existing visitors are not backfilled; unavailable values remain empty and VPNs may affect accuracy); the discount codes we issued; and, for revenue attribution, the order id, amount and currency of orders that used one of those codes. The SMS timestamp is only a technical record of the popup click. It is not legal advice or a complete legal assessment of the consent and does not replace the consent information the merchant must provide.

Smart Trigger (second chance). Only if the merchant enables it and the visitor allows both marketing and analytics processing: from the first close or minimise of a Smart popup in a session, PopUplift offers at most one second chance per session at a later moment and measures the effect against a fixed random control group (currently 20 %, never shown a second chance). Visitors from e-mail, Klaviyo or newsletter campaigns (session utm_source or utm_medium), browsers Klaviyo already recognised (only when that result exists anyway because of a popup rule) and browsers that already submitted an e-mail (pl-has-email) are never enrolled; this check runs in the browser and nothing about excluded visitors is sent. At entry the server stores one pseudonymous random assignment per visitor and experiment: assignment and experiment id, policy version and checksum, the entry popup with a hash of its delivered popup/theme/reward state, entry type (close or minimise) and time, group, the assigned moment ("arm") and its parameters, the propensity of exactly this allocation, the learning-state version, the measurement deadlines, and a coarse context — device (mobile/desktop), source category (direct/search/social/paid/other, derived in the browser from the referrer domain and UTM parameters; the domain itself is never sent), new/returning and cart filled/empty/unknown — plus the verified collection session_id from section 2.7 when one exists. Lifecycle rows record only the open attempt with its moment, the actual display, a renewed close or minimise and, on revocation, an erasure marker. The outcome is a genuinely new e-mail marketing opt-in within 24 hours of entry, also in a later session of the same browser and via another popup of the same shop; the server links it to the visitor's newest non-erased assignment itself, only if both consents are given at submit time. For diagnostics the merchant report also counts orders and their revenue paid with a popup discount code within 7 days of entry and further page views of the bound collection session. No row copies an e-mail address, URL or path, referrer domain, UTM value, page or DOM content or cart contents. Which moment is allocated how often is learned per shop, only from that shop's own rows; the learning state holds aggregate counts and shares without any visitor or session reference and is deleted with the shop. The coarse context is logged but currently neither steers the allocation nor appears in any report. On revocation, an assignment already held in memory is reported once as erased and every pl-smart-* entry is removed; erased and redacted assignments never count as observed failures. Rows are kept 180 days like other events. Details are in section 2.2 of the German version.

Purchase tracking. If the visitor consented to analytics in the shop's cookie banner, a PopUplift Shopify web pixel sends shopping events (products and collections viewed, search terms without @ or long digit sequences, cart, checkout start, purchase) with Shopify product, variant, collection and order ids, quantities, amounts, currency, discount use, time and the pseudonymous session id. No name, e-mail, phone, address or customer id. Purpose: attribute purchases to popups for the merchant (revenue per popup), as the merchant's processor under the data processing agreement from version 2026-10-02. Kept at most 180 days (section 2.9 of the German version).

We also collect pseudonymous, categorised Storefront usage signals when — and only when — analytics processing is explicitly allowed (section 2.7 of the German version). A server-issued random session and one page package per document carry a categorised page context (path category, viewport class, pointer, orientation, referrer category, UTM category, initial visibility, exit-intent support), a limited event sequence (pageview, scroll depth in 10 % steps, visible/hidden, boolean exit intent, observed cart addition, and allowlisted popup events with popup/campaign id, step index or channel) and summary buckets. In addition, under the same conditions: the product or collection viewed (ids, product type, price, currency), the cart after a change (product/variant ids, quantities, value, currency), customer status (logged in, prior purchaser — no customer id), country and language, the click-target category, a redacted search term and redacted utm_campaign/utm_source, popup field type and focus/error (never a value), local hour/weekday, load-time bucket, visit number, and a delivery log of which popups were eligible and shown. Normalised features (price/cart tier, EUR value, industry, traffic tier) are computed in the archive. PopUplift may derive anonymised, aggregated metrics (e.g. sign-up rates per design, mechanic, moment or industry; no visitor or individual store identifiable) and use them to improve the service for all customers; no cross-store training on visitor-level (including pseudonymised) data without a separate agreement with the merchant. No raw URL/path/hash, referrer domain, other UTM value, DOM or page text, form input, e-mail, phone, IP address, user agent, cart note or attributes, or click coordinates are stored or transmitted. Marketing consent alone does not allow this; without analytics the collection stays closed. Collection alone changes neither the visitor counter nor billing nor any free limit. The stated purpose is deliberately non-exclusive: it is neither a promise that the data is used only for the merchant's popup nor a permission to sell it, profile it across shops or use it for arbitrary own purposes; the concrete purposes, roles and lawful basis must be settled first, and the controller/processor question for any such later use remains open. The full wording is in section 2.7 of the German version.

What we do not do. We store no IP addresses in the database (there is no IP column in the data model), set no cookies, perform no precise IP location tracking, use no advertising identifiers or fingerprinting, load no fonts from Google, and do not train AI models across stores on visitor-level (including pseudonymised) data without a separate agreement with the merchant. We do not evaluate raw origin, raw UTM values or a device model server-side; the analytics stream transmits only coarse categories (referrer/UTM/path category, viewport class) plus redacted utm_campaign/utm_source, never a domain, raw path, other parameter or device identifier. Request logs on the hosting platform do contain the caller's IP address for abuse prevention and are deleted after 7 days; the public storefront endpoints are rate limited.

Storage on the visitor's device. The widget uses localStorage and sessionStorage, never cookies. Three entries are strictly necessary to deliver the popup the visitor is filling in and the list sign-up they requested (pl-jwt, pl-fs-<id>, pl-list-join-<id>). Four limit how often a visitor sees the same popup — including pl-done-<id>, which records that a visitor finished or dismissed a popup so it does not come back; we classify these frequency caps as strictly necessary, because without them the popup would reappear on every page even after the visitor completed or dismissed it. Twelve further entries are not strictly necessary and therefore require consent under section 25 (1) TDDDG and Art. 6 (1) (a) GDPR: eight for targeting rules, session counting and the server-side second layer behind pl-done-<id>; two pl-smart-* entries for the second chance (pl-smart-observe-<id>: assignment and experiment id, display deadline, the arm's moments and whether the floating button follows to later pages (only after a minimise), accrued visible time, the entry page path — kept locally, never sent — policy checksum and a "show nothing more" flag; pl-smart-done: the session's single display is spent), both only with marketing and analytics consent; pl-sr, a marker that a Smart Rewards offer was shown and measured (written only with marketing and analytics consent, read only after a revocation to report it once, removed after the server confirms); and pl-collect-v1, the analytics-only collection session (token, session id, UTC day, expiry; runtime of the tab, at most 24 hours). The full table with purposes and lifetimes is in section 5 of the German version. Smart Trigger additionally reads pl-has-email (a frequency-cap entry) as an exclusion signal and uses the already collected pl-src, pl-seen and pl-ret values for its exclusion and coarse context; these extra purposes apply only with marketing and analytics consent. All raw targeting values stay in the browser: the visitor profile the targeting rules are evaluated against is built locally and never transmitted, which is also why PopUplift deliberately has no report on raw UTM source, referrer or device. The only values derived from them that leave the browser are the coarse Smart Trigger categories described above, which appear in no report either.

Smart Rewards (offer sets). Only if the feature is enabled for the store and the merchant uses a set of two or three offers in a popup instead of a fixed offer: when the widget requests the offer for a visitor, the server assigns one of the offers pseudonymously and at random in equal shares (or, once the merchant has adopted one offer for everyone, that offer) and stores the visitor reference, set and revision, assigned offer, popup of the first assignment and time, so that the same visitor always sees and can redeem only the same offer. Only with marketing and analytics consent does the widget report that the offer was visibly shown; the server then records once the time, the popup and — if the popup runs in an A/B test and the server can prove the variant from its own delivery — test and variant. The merchant sees totals per offer, popup, variant and format: measured visitors who saw the offer, sign-ups, claimed codes and, within 30 days, paid orders with the code and their revenue per currency, linked from events, issued codes and attributed orders of the same visitors. If either consent is later withdrawn, the measurement of the visitor's measured assignments is discarded and the affected set revision is marked incomplete; the assignment remains so the offer stays the same. Assignments and measurement are deleted with the visitor row (90-day run for anonymous visitors, customers/redact, uninstall). Basis: the data processing agreement from version 2026-10-03.

AI features (language models). Some features use language models from Anthropic (directly) or via OpenRouter: creating a popup proposal, choosing images for it, text suggestions for A/B tests, matching Klaviyo welcome e-mails and old flow splits, and, once available, edit suggestions in the editor. They receive only the merchant's content: store name and language, the public home page text (shortened), product titles and images, popup texts, the confirmed offer and the merchant's own wishes, text snippets from the merchant's Klaviyo templates with links and e-mail addresses replaced, and aggregated popup figures. No personal data of visitors is ever sent to a language model — no visitor, lead, customer or order rows, e-mail addresses, phone numbers or visitor answers; the data processing agreement (§ 2) makes this a binding commitment. Legal basis for the merchant's content: Art. 6 (1) (b) GDPR. What the merchant types into the AI features (prompts, instructions, chat messages) is stored for up to 180 days to improve the features and to trace how a suggestion came about; it contains merchant content only, never visitor data, and is deleted with the store (legitimate interest, Art. 6 (1) (f) GDPR).

Sub-processors. Supabase Pte. Ltd. (Postgres, processed and stored in AWS eu-central-1, Frankfurt), Railway Corporation (application hosting, europe-west4, Amsterdam), Shopify International Limited (source and destination of the data; EU merchants contract with the Irish entity), Klaviyo, Inc. (only if the merchant connects their own account via OAuth or API key; United States, EU-US Data Privacy Framework plus standard contractual clauses), Functional Software, Inc. (Sentry — error reporting; event data is stored in Sentry's EU data region in Frankfurt and automatically deleted — after 30 days under the currently used Sentry plan — while Sentry account and organization metadata resides in the United States), Cloudflare, Inc. (DNS, storage of the nightly pseudonymised event archive in R2 under EU jurisdiction, optional authenticated edge proxy and country estimation for explicitly enabled hosts, initially Staging only, and e-mail forwarding for the support mailboxes; forwarded e-mail content is not stored according to the provider), plus daily encrypted database backups held by the operator in Germany. Supabase, Railway, Sentry and Cloudflare are bound by data processing agreements with standard contractual clauses; Railway, Sentry and Cloudflare are additionally certified under the EU-US Data Privacy Framework. The Klaviyo transfer runs under the merchant's own contract with Klaviyo, not under a PopUplift agreement.

From data processing agreement version 2026-10-03, the sub-processors also include Anthropic Ireland, Limited (Ireland; parent Anthropic, PBC, USA — language models; processing in the USA; inputs and outputs are not used for training and are deleted within 30 days according to the provider; Anthropic Data Processing Addendum with standard contractual clauses) and OpenRouter, Inc. (USA — routes each request to an operator of the selected model, chosen per request by availability, price and latency, currently including Anthropic, Google, Amazon Web Services and Microsoft for Claude models and DeepSeek, Alibaba, Baidu, DeepInfra, Together AI and others for open models; these model providers may be located outside the EU, for example in China or Singapore, and may store inputs or use them for training; data processing agreement with standard contractual clauses). TypeSafe AI, Inc. (USA — checks the editor assistant's suggestions with its Jev model for offer, consent and intent questions; receives only popup texts, proposed wording and the merchant's messages; inputs are not used for training according to the provider; data processing agreement with standard contractual clauses). None of them receives personal data of visitors.

The planned direct marketing-service receiver is not active and is not included in the active processor list above. Its operator and legal entity, processing and storage locations, role and data-processing agreement, subprocessors, any third-country transfer mechanism, and receiver retention/deletion terms must be verified and documented at the activation gate; a receiver URL alone is not evidence.

Retention. Events and survey answers 180 days; the daily event summary at most 178 days (PL_RETENTION_DAYS minus 2; older days are not summarised); pseudonymous collection sessions, page packages and purchase-tracking events at most 180 days, removed as whole UTC-day partitions by the 15-minute maintenance (earlier for smaller settings, and a failed maintenance job is alarmed rather than reported as success); anonymous visitors without an e-mail address and without a claimed reward 90 days from last contact; GDPR export copies 30 days; completed background jobs 7 days; backups 14 copies. Visitors who gave an e-mail address are the merchant's lead list and are kept until the merchant deletes them, a customers/redact arrives, or the app is uninstalled.

Data subject rights. Visitors exercise their rights with the merchant. Shopify forwards requests to us as the three mandatory compliance webhooks. customers/data_request produces an export we hand to the merchant on request without undue delay, at the latest within 10 days (auto-purged after 30 days); once a collection session is validly bound to the same visitor, it includes the session metadata and all page packages of those sessions, never the collection tokens. customers/redact deletes identity rows and anonymises event rows, so aggregate reporting stays correct without a personal reference; the daily event summary loses the A/B binding and hand-off type the same way, and its visitor id becomes null; bound collection sessions are locked and their packages and sessions deleted before the visitor record is removed, rather than detached as a fake anonymisation of a still joinable sequence. shop/redact, which arrives 48 hours after uninstall, deletes the shop row and everything cascading from it, including unbound collection sessions. Merchants also have the right to lodge a complaint with a supervisory authority.

Security. HTTPS everywhere, AES-256-GCM encryption of Shopify and Klaviyo tokens at rest, row-level security in Postgres locking out the platform's public database roles with per-shop separation enforced in the application layer, HMAC verification of every webhook before parsing (401 on an invalid signature), expiring session tokens with key rotation (the collection stream uses its own audience and verifier), PII scrubbing before any error report leaves the server, partitioned collection tables whose DDL runs through a narrow, argument-less maintenance function rather than general CREATE/DROP rights, and rate limits on all public storefront endpoints.

Breach notification. We inform the affected merchant without undue delay — as a rule within 24 hours of becoming aware — so that they can meet their Art. 33 and 34 GDPR obligations, and we notify Shopify within 24 hours as required by the Partner Program Agreement.

Contact. privacy@popuplift.com