Stand: 12.08.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.

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.

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). Einzige Ausnahme: Meldet das Widget einen Fehler, enthält die Meldung die Adresse der Seite, auf der der Fehler auftrat (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. PopupLift liest keine Bestellpositionen, keine Lieferadressen und keine Zahlungsdaten.

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.7: 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 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.

2.7 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 IP-Geolokalisierung. Land und Sprache kommen aus der Shopify-Storefront-Lokalisierung.
• 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.
• Keine Nutzung von Händler- oder Kundendaten für das Training von KI-Modellen. Es existiert kein Trainings- oder Exportpfad im Code.
• Keine serverseitige Auswertung von Herkunft, UTM oder Gerät. Diese Merkmale entstehen im Browser und bleiben dort, deshalb gibt es dazu bewusst auch keinen Report (Abschnitt 5).

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.

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.

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 und der zweiten Ebene oben. 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.

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.

Das Widget wertet den Consent-Status aus. Seit dem 03.08.2026 fragt es Shopifys Customer-Privacy-API (window.Shopify.customerPrivacy) ab, bevor es einen der sieben nicht erforderlichen Schlüssel schreibt — und bevor es einen davon liest, denn § 25 TDDDG erfasst beides gleichermaßen. 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. Bei Widerruf werden die fünf Targeting-Schlüssel unmittelbar entfernt (der Launcher hört auf visitorConsentCollected).

Hat der Shop keine Consent-Konfiguration, wird geschrieben. Das ist Shopifys eigene Semantik: In Regionen mit Consent-Pflicht sind nicht erforderliche Zwecke bis zur Einwilligung gesperrt, in allen anderen sind sie erlaubt. Sehr viele Shops betreiben kein Banner; dort gibt es keine Einwilligungsentscheidung, die eine App respektieren könnte, und die Bewertung nach § 25 liegt beim Händler als Anbieter des digitalen Dienstes — er bekommt mit dieser Tabelle genau die Angaben, die er dafür braucht. Ist die API vorhanden, antwortet sie in Consent-Regionen von sich aus mit „nein", solange nichts entschieden wurde; der Default greift also nur dort, wo nichts zu respektieren ist.

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.

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. Die übrigen Zeilen sind Empfänger, aber keine Unterauftragsverarbeiter: Klaviyo, weil der Vertrag über diese Übermittlung zwischen Händler und Klaviyo besteht; Cloudflare, weil es keine Besucherdaten aus der App verarbeitet, sondern nur die Support-Postfächer des Betreibers weiterleitet (Daten aus Abschnitt 3); der Betreiber, weil er der Auftragsverarbeiter selbst ist.

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, die Werte sensibler Feldnamen und Geheimnisse in URL-Parametern werden ersetzt. 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, 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.

Ä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.

Fünf 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. Grundlage: Standardvertragsklauseln und EU-US Data Privacy Framework.

8. Löschfristen

Der Löschlauf ist automatisiert und läuft alle sechs Stunden.

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.

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 und offene Jobs 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) 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

Zwei Klassen, absichtlich unterschiedlich behandelt:

• Identitätszeilen werden gelöscht: visitors, visitor_flow_state, claimed_rewards 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 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.

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.
• 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.
• 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 in Version 2026-08-12 wird unter /avv bereitgestellt. Der Vertragsschluss nach Art. 28 Abs. 9 DSGVO erfolgt in Textform über die Zustimmung in der App; diese Funktion wird derzeit ausgerollt. 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: 12.08.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.

What we process on the merchant's behalf. E-mail address and optional phone number entered in the popup, the timestamp of marketing consent, quiz and survey answers, popup events (view, step, signup, reward claimed, close) with an anonymous session id, the progress state of a multi-step popup, country and language taken from the Shopify storefront localisation (never from IP geolocation), the discount codes we issued, and, for revenue attribution, the order id, amount and currency of orders that used one of those codes.

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, run no IP geolocation, use no advertising identifiers or fingerprinting, load no fonts from Google, and have no path in the code that exports data for AI training. 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. Two entries are strictly necessary to deliver the popup the visitor is filling in (pl-jwt, pl-fs-<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. Seven further entries exist only for targeting rules, session counting and the server-side second layer behind pl-done-<id>; they are not strictly necessary and therefore require consent under section 25 (1) TDDDG and Art. 6 (1) (a) GDPR. The full table with purposes and lifetimes is in section 5 of the German version. All of these 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 UTM source, referrer or device.

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 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.

Retention. Events and survey answers 180 days; 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). customers/redact deletes identity rows and anonymises event rows, so aggregate reporting stays correct without a personal reference. shop/redact, which arrives 48 hours after uninstall, deletes the shop row and everything cascading from it. 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, PII scrubbing before any error report leaves the server, 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