Was eine First-Party-Domain ändert
Requests an t.shop.example sind Same-Site mit shop.example. Daraus folgt dreierlei:
- Blocklisten greifen nicht. Die meisten Content-Blocker matchen Hostnamen; eine Subdomain deiner eigenen Site steht nicht darauf. Das ist keine Umgehung einer Nutzerentscheidung — die Consent-Entscheidung steuert weiterhin jeden Zweck — es beseitigt das kollaterale Blockieren eingewilligter First-Party-Requests.
- Third-Party-Cookie-Beschränkungen gelten nicht. Browser, die Drittanbieter-Cookies partitionieren oder blockieren, lassen Same-Site-Speicher in Ruhe.
- Deine Sicherheitsrichtlinie bleibt eng. Ein zusätzlicher Host in
script-srcundconnect-src, keine Wildcard-Anbieterdomains für den Collector-Weg.
Das Setup
- Füge die Domain in den Site-Einstellungen hinzu. Track stellt einen Verifikations-Token aus; weise die Kontrolle per DNS-TXT-Eintrag, Datei auf der Domain oder Meta-Tag nach. Die Domain wird erst aktiv, wenn die Verifikation gelingt, sodass niemand eine fremde Domain auf deine Site zeigen lassen kann.
- Lege
t.shop.exampleals CNAME auf den in den Einstellungen angezeigten Collector-Host an. Die Domain-Seite hält fest, wann die CNAME-Prüfung zuletzt bestanden wurde. - TLS für den Tracking-Host wird von der Plattform-Edge terminiert, sobald der CNAME auflöst.
- Aktualisiere deine Content Security Policy:
script-srcundconnect-srcbrauchen den Tracking-Host.unsafe-inlineist nicht nötig, weil der Loader ein externes Skript ist. - Der SDK-Loader wird dann über den Tracking-Host zusammen mit der signierten Konfiguration der Site ausgeliefert.
Was das SDK speichert und was ITP weiterhin begrenzt
Track schreibt drei Dinge im Browser, jedes erst nach dem passenden Consent:
| Schlüssel | Zweck | Geschrieben bei | Laufzeit |
|---|---|---|---|
_ts_id (Cookie, im localStorage gespiegelt) | anonyme Besucher-ID | Analytics- oder Marketing-Consent | bis zu 13 Monate oder die Aufbewahrung der Site |
_ts_sid (Session Storage) | Sitzungs-ID | Analytics- oder Marketing-Consent | 30 Minuten rollierend |
_ts_cid (localStorage) | Click-IDs der Landing-URL | Marketing-Consent | Click-ID-TTL, standardmäßig 90 Tage |
Click-IDs der Landing-URL werden im localStorage unter _ts_cid gehalten, nur mit Marketing-Consent und nur für die Click-ID-TTL der Site (standardmäßig 90 Tage); sie werden an jedes spätere Event des Besuchs gehängt und beim Widerruf des Marketing-Consents gelöscht.
Beide Kennungen werden per JavaScript geschrieben. Safaris Intelligent Tracking Prevention begrenzt skriptgeschriebene Cookies und Speicher auf 7 Tage (24 Stunden, wenn die Landing-URL einen bekannten Tracking-Parameter trug), und eine First-Party-Domain hebt diese Grenze nicht auf. Der Collector setzt keine Cookies über HTTP-Antworten, sodass ein wiederkehrender Safari-Besucher nach mehr als einer Woche eine neue anonyme ID erhält. Firefox und Brave wenden vergleichbare Heuristiken an; Chrome behält First-Party-Speicher für die volle Laufzeit.
Die ehrliche Zusammenfassung: Die eigene Domain schützt die Zustellung der Requests; sie verlängert nicht die Lebensdauer der Kennungen auf Safari.
Was eine First-Party-Domain nicht löst
- Sie stellt keine verweigerten Zwecke wieder her. Ohne Marketing-Consent wird keine Click-ID erfasst und keine Werbe-Destination erhält Events — unabhängig von der Domain.
- Sie macht Anbieter-Pixel nicht zu First-Party.
fbevents.jslädt weiterhin von Meta und setzt_fbp; nur der Collector-Weg gehört dir. - Sie versteckt nichts vor dem Besucher. Tracking-Host, SDK-Quelle und Collector-Endpunkte sind in den Entwicklertools sichtbar, und die Datenschutzseite listet sie.
Checkliste
- Offen: Domain verifiziert (TXT, Datei oder Meta-Tag) und CNAME-Prüfung bestanden
- Offen: CSP für
script-srcundconnect-srcaktualisiert - Offen: Snippet referenziert den Tracking-Host, nicht den Plattform-Standard
- Offen: Datenqualitätsseite zeigt Browser-Events vom neuen Host