#Datenschutz

#Match-Signale: nur als Hash

Die Felder, aus denen Meta und Google ihre Zuordnung bilden (em (E-Mail), ph/ph_e164 (Telefon), fn/ln (Name), ct/st/zp/country (Ort, Land)), nehmen ausschließlich SHA-256 an. Gehasht wird vor dem Versand: im Plugin, im SDK, auf deinem Server. Der Collector weist Klartext dort mit 400 ab, statt ihn anzunehmen und „SHA-256“ darüberzuschreiben. Die Kundennummer aus deinem Shop wird pseudonymisiert, nie roh übernommen. An die Werbeplattformen geht niemals Klartext.

#Was gespeichert wird

• Event-Art, Zeitpunkt, Wert, Währung, Positionen
• Seiten-URL und Referrer
• Klick-Kennungen der Werbeplattformen
• IP und User-Agent des Besuchers
• der mitgeschickte Einwilligungsstand
• eine First-Party-Besucherkennung (Zufallswert, keine Person)
• auf ausdrückliche Veranlassung Name und E-Mail im Klartext (contact_name, contact_email; siehe unten)

#Klartext: zwei Felder, zwei Bremsen

Damit in der Personenansicht ein Name statt einer Zeichenkette steht, gibt es zwei eigene Felder: contact_email und contact_name. Sie sind der einzige Ort, an dem Trackdolphin lesbare Kundendaten hält. Sie werden nie aus einem Hash zurückgerechnet und nie aus anderen Feldern abgeleitet: Was nicht ausdrücklich in diesen beiden Feldern ankommt, gibt es nicht.

Zwei Absender können sie füllen, jeder mit einer eigenen Bremse:

1. Browser-SDK. identify({ email, name }) schickt den Klartext nur, wenn setConsent() eine Einwilligung gesetzt hat, die Speicher gewährt (ad_storage oder analytics_storage = granted). Wurde nie gefragt, geht kein Klartext raus. „Nicht gefragt“ ist kein Ja. Er hängt nur am identify-Ereignis und liegt im Browser nur im Arbeitsspeicher, nicht im localStorage; reset() vergisst ihn.
2. Shop-System (Shopify, Webhook orders/paid). Nur, wenn der Händler unter Einstellungen → Consent & Datenschutz „Name und E-Mail aus Bestellungen speichern“ eingeschaltet hat. Vorgabe ist aus; ohne diesen Schalter speichert Trackdolphin zu einem Käufer weiterhin nur Hashes.

Der Klartext geht an keine Werbeplattform und steht in keinem Kundenlisten-Export. Er unterliegt derselben Löschfrist wie das Ereignis, an dem er hängt (24 Monate), und verschwindet mit ihm bei jeder Löschung.

#Einwilligung

Trackdolphin steuert dein Consent-Banner nicht und ersetzt es nicht. Das SDK hält Events zurück, bis eine Einwilligung vorliegt, und schickt den Einwilligungsstand bei jedem Event mit, damit später nachweisbar ist, unter welcher Bedingung ein Event entstand.

Serverseitig heißt nicht einwilligungsfrei. Ein Kauf, der aus dem Shop-Backend gemeldet wird, trägt den Einwilligungsstand des Besuchers, und der Dispatcher richtet sich danach, bevor er irgendetwas an eine Plattform schickt.

Ob ein serverseitiges Event ohne Einwilligung ausgelöst werden darf, ist eine rechtliche Entscheidung, keine technische. Trackdolphin macht sie dir nicht ab.

#Was ohne Marketing-Einwilligung passiert

Unter Einstellungen → Consent & Datenschutz wählst du je Projekt, was mit einem Event geschieht, dessen Besucher Marketing abgelehnt hat. Drei Modi:

Nur Consent-Mode-Signale (Vorgabe). An Meta, TikTok, Pinterest, LinkedIn, Microsoft und Google Ads geht nichts. Google Analytics bekommt einen Ping ohne Kennungen: Ereignis, Wert, Währung, Positionen. Keine Cookie-ID, keine Klick-ID, kein Hash, keine Sitzung, keine IP. Die Client-ID wird aus der Event-ID abgeleitet und verbindet den Ping mit keinem anderen Event. Das entspricht dem, was Googles Consent Mode im Browser bei abgelehnter Einwilligung tut. Google Ads bekommt bewusst nichts: Eine Conversion ohne Klick-Kennung und ohne Hash wäre keine Conversion.

Gar nichts senden. Kein Event verlässt Trackdolphin, auch nicht der Ping an Google Analytics. Die Events bleiben gespeichert und erscheinen in deinen Berichten; nach außen geht nichts. Googles Modellierung fehlender Conversions hat für diese Besucher dann keine Grundlage.

Trotzdem senden (mit US-Abschwächungen). Events gehen an alle verbundenen Plattformen wie bei erteilter Einwilligung, samt Klick-IDs und Hashes. Gesetzt werden nur Metas Limited Data Use, Googles non_personalized_ads und Pinterests opt_out. Diese Mechanismen stammen aus US-Bundesstaatengesetzen; ob sie in deinem Markt eine fehlende Einwilligung ersetzen, entscheidest du mit deiner Datenschutzberatung. Gedacht ist der Modus für Projekte außerhalb der EU-Datenschutzregulierung. Einzige Ausnahme in diesem Modus: Meldet das Event ad_user_data: denied, bekommt Meta keine Nutzerdaten-Hashes und keine Kundenkennung.

Ein Event ohne Consent-Block (etwa aus einem Projekt ohne angebundenes Banner) gilt als nicht widersprochen und wird normal ausgeliefert. Sonst stünde jedes Projekt ohne CMP-Anbindung still.

#Consent Mode v2

Events tragen die vier Signale des Consent Mode v2, so wie das Banner sie im Browser ablegt: ad_storage, analytics_storage, ad_user_data, ad_personalization: je granted oder denied. Der Dispatcher wertet zuerst diese Signale aus: ad_user_data entscheidet, ob Nutzerdaten an ein Werbenetzwerk dürfen; fehlt es, entscheidet ad_storage. Ältere Plugin-Versionen schicken die Signale als Wahrheitswerte. Die werden weiter gelesen.

Was die Plattformen davon sehen:

• Google Ads bekommt adUserData und adPersonalization im Feld consent jeder hochgeladenen Conversion. Google verlangt das Feld für Nutzer aus dem EWR; ohne es kann eine Conversion unzuordenbar bleiben.
• Google Analytics bekommt dieselben zwei Signale im consent-Objekt des Measurement Protocol. Mehr nimmt das Protokoll nicht an. Fehlt der Stand, bleibt das Feld weg; GA4 nimmt dann den Stand aus den Browser-Interaktionen desselben Clients.
• Meta hat kein Consent-Feld. Bei ad_user_data: denied bleiben E-Mail-, Telefon-, Namens- und Adress-Hashes sowie die Kundenkennung aus dem Payload; das Event selbst geht nur im Modus „Trotzdem senden“ hinaus.
• TikTok, Pinterest, LinkedIn, Microsoft kennen ebenfalls kein Consent-Feld. Bei abgelehnter Einwilligung geht dorthin nichts, außer im Modus „Trotzdem senden“.

Ist der Stand unbekannt, wird kein granted erraten. Ein weggelassenes Feld liest Google als „unbekannt“; das ist ehrlicher als eine behauptete Einwilligung.

#Das Besucher-Cookie

Das First-Party-Cookie _td_vid ist ein Zufallswert. Es verbindet die Seitenaufrufe eines Browsers über Besuche hinweg mit einem späteren Kauf, damit der Kauf einer Kampagne zugeordnet werden kann. Es enthält keine Person; gehashte Merkmale kommen erst mit dem Kauf dazu.

In der Vorgabe wird es beim ersten Seitenaufruf gesetzt: vom eigenen Server per Set-Cookie, damit Safari ihm 365 Tage lässt. Ob das ohne Einwilligung zulässig ist, hängt davon ab, wie dein Projekt das Cookie einordnet. Trackdolphin trifft diese Entscheidung nicht, sondern gibt dir einen Schalter:

Cookie erst nach Einwilligung setzen (Einstellungen → Consent & Datenschutz). Dann warten Plugin und SDK, bis das Banner Marketing erlaubt:

• WooCommerce liest die WP Consent API (Kategorie „marketing“), die Borlabs, Complianz, Cookiebot und andere bedienen, im Browser wie auf dem Server. Fehlt sie, gilt eine Entscheidung ad_storage: granted aus dem Consent Mode im dataLayer (ein consent update oder ein erkanntes Banner); dann kann nur das Skript das Cookie setzen, und Safari begrenzt es auf sieben Tage.
• Shopware trägt _td_vid in den Cookie-Manager von Shopware ein, unter „Marketing“. Erlaubt der Besucher es dort, setzt das Skript es; lehnt er ab, löscht Shopware es. Beim nächsten Aufruf stellt der Server es mit 365 Tagen neu aus. Eine Entscheidung ad_storage: granted im dataLayer zählt ebenfalls.
• JTL-Shop trägt _td_vid in den Consent Manager von JTL ein; eine Entscheidung ad_storage: granted im dataLayer zählt ebenfalls.
• Ein gtag('consent','default', …) zählt in keinem Plugin: Das ist die Voreinstellung der Seite, kein Wille des Besuchers. Die Plugins melden sie als consent.source: default, damit der Unterschied im Dashboard sichtbar bleibt.
• SDK: Option visitorCookieRequiresConsent beim init.

Die Folge musst du kennen: Ohne Cookie vor der Einwilligung gibt es keine Verbindung zwischen dem ersten Seitenaufruf und einem späteren Kauf. Die Zuordnung beginnt mit dem Klick im Banner. Was davor lag (der Kampagnen-Klick, die erste Produktansicht) lässt sich dem Kauf nicht mehr zuordnen. Wer ablehnt, bleibt ohne Kennung; sein Kauf kommt trotzdem serverseitig an, nur ohne Vorgeschichte. Die Einstellung wirkt ab dem Umschalten, nicht rückwirkend: Vorher gesetzte Cookies laufen ab, wie sie gesetzt wurden.

Die Einstellung wandert beim Plugin-Download mit ins Paket. Änderst du sie später, stellst du sie im Plugin um. Das Plugin fragt das Backend nicht.

#Wo die Daten liegen

Verarbeitung und Speicherung in der Europäischen Union. Die Zustellung an Google, Meta und LinkedIn erfolgt an deren Schnittstellen: Für diese Übermittlung bist du Verantwortlicher, wir Auftragsverarbeiter.

#Löschung

Ein gelöschtes Projekt nimmt seine Events mit. Auf Anfrage löschen wir einzelne Personen anhand des E-Mail-Hashes. Den Hash kannst du selbst bilden, ohne uns die Adresse zu nennen.