First-Party Cookie Restoration: ITP-Überleben mit Cloudflare Workers & ssGTM

First-Party Cookie Restoration: ITP-Überleben mit Cloudflare Workers & ssGTM

Safaris Intelligent Tracking Prevention (ITP) und moderne Browser-Privacy-Engines limitieren die Gültigkeitsdauer clientseitiger Cookies massiv. Identifikatoren, die per JavaScript (über document.cookie) gesetzt werden, erhalten eine maximale Lebensdauer von 7 Tagen – bei Erkennung von Ad-Click-Parametern im URL-String wird diese Laufzeit häufig auf 24 Stunden reduziert. Auch klassische CNAME-Cloaking-Verfahren werden von WebKit-Algorithmen erkannt und abgewertet, wenn der DNS-Eintrag auf bekannte Drittanbieter-Tracker verweist.

Um die Datenqualität und Attributionsgenauigkeit über längere Customer Journeys aufrechtzuerhalten, muss die Architektur von clientseitigem JavaScript auf echtes First-Party Edge Routing über serverseitig verwaltete HTTP-Cookies umgestellt werden.

1. Das Architektur-Konzept: Server-Managed Edge Cookies

Die Umgehung der 7-Tage-Limitierung erfordert es, Identifikatoren direkt am Netzwerkrand (Edge) per HTTP-Response-Header (Set-Cookie) zu generieren. Da Browser-Restriktionen strikt zwischen Skript-Cookies und legitimen Server-Session-Headern unterscheiden, können Edge-generierte Cookies bis zu 365 Tage bestehen bleiben, sofern eine gültige datenschutzrechtliche Zustimmung vorliegt und die Antwort von der eigenen Infrastruktur der Website kommt: Wird der antwortende Host über einen CNAME oder eine IP-Adresse eines Drittanbieters erreicht, begrenzt WebKit auch per HTTP-Antwort gesetzte Cookies auf 7 Tage.

2. Cookie-Wiederherstellung über Cloudflare Workers und ssGTM

Eine robuste Wiederherstellungs-Pipeline nutzt Cloudflare Workers als Reverse Proxy vor einem Server-Side Google Tag Manager (ssGTM) Container. Wird ein HTTP-Request an der Edge abgefangen, prüft der Worker, ob ein gültiger Server-Managed-Identifikator existiert. Fehlt dieser, injiziert der Worker einen neuen Set-Cookie-Header in die Response.

// Cloudflare Worker Edge Script: Server-Managed Identifier Restoration
function getCookieValue(cookieHeader, name) {
  if (!cookieHeader) return null;
  for (const part of cookieHeader.split("; ")) {
    const eq = part.indexOf("=");
    if (eq !== -1 && part.slice(0, eq) === name) return part.slice(eq + 1);
  }
  return null;
}

export default {
  async fetch(request, env) {
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    
    // Anonymen First-Party-Identifikator auslesen oder erzeugen
    let fpId = getCookieValue(request.headers.get("Cookie"), "fp_id");
    if (!fpId) {
      fpId = crypto.randomUUID();

      // Set-Cookie-Header mit 1 Jahr Laufzeit nur bei fehlendem Identifikator setzen
      newResponse.headers.append(
        "Set-Cookie",
        `fp_id=${fpId}; Max-Age=31536000; Path=/; Domain=example.com; Secure; HttpOnly; SameSite=Lax`
      );
    }

    return newResponse;
  }
};

Im ssGTM wird dieser persistente Edge-Identifikator mit dem Standard-Client-ID-Feld von GA4 oder Google Ads gemappt, wodurch Multi-Touch-Attributionsmodelle auch bei langen Konversionszyklen konsistente Daten liefern.

3. Google Tag Gateway (GTG): Die perfekte Ergänzung an der Edge

Das Google Tag Gateway (GTG) stellt einen spezialisierten First-Party-Routing-Mechanismus dar, der Analytics-Traffic direkt über die Hauptdomain leitet. Die Bereitstellung des GTG über Cloudflare Workers erzeugt eine perfekte Synergie mit der Cookie-Wiederherstellung:

• Same-Origin-Kontext: Das GTG routet Skript-Bibliotheken (z. B. /gtg/gtm.js) und Daten-Payloads (/gtg/collect) über exakt dieselbe IP-Adresse und Autonomous System Number (ASN) wie die eigentliche Website.
• Immunität gegen CNAME-Abwehr: Da das GTG direkt auf der Infrastruktur der Hauptdomain via Edge-Proxying läuft statt über externe DNS-Delegationen, stufen WebKit-Tracking-Filter den Traffic als reguläre Backend-Kommunikation ein.
• Keine eigene Tracking-Verbindung: Da GTG-Routing und Cookie-Wiederherstellung im selben Cloudflare-Worker unter dem Hostnamen der Website laufen, kann der Browser seine bestehende Verbindung weiterverwenden und braucht keinen eigenen TLS-Handshake zu einer separaten Tracking-Domain; die Weiterleitung des Workers an den Server-Container bleibt ein zusätzlicher Netzwerkschritt.

Zusammenfassung

Die Überwindung von ITP-Restriktionen erfordert die Verlagerung des Identifikator-Managements von Browser-Skripten auf Edge-Infrastrukturen. Die Kombination aus serverseitigen HttpOnly-Cookies via Cloudflare Workers und dem Same-Origin-Routing des Google Tag Gateways (GTG) etabliert eine rechtskonforme, datenschutzfreundliche und technisch absolut hochverfügbare Tracking-Architektur.

Variante: das eigene _ga-Cookie des Google-Tags verlängern

Der Worker oben legt eine eigene Kennung an, fp_id, die im Server-Container auf die Client-ID gemappt wird. Eine schmalere Variante überlässt die Kennung dem Google-Tag und erneuert nur das vorhandene _ga-Cookie per HTTP-Response, etwa über einen eigenen Endpunkt auf demselben Hostnamen. Ob das funktioniert, hängt an vier Details.

• Kein HttpOnly bei _ga: Das Google-Tag liest die Client-ID per JavaScript, und ein HttpOnly-Cookie ist über document.cookie nicht zugänglich. Die Attributtabelle oben gilt für eine eigene Server-Kennung, nicht für _ga.
• Passende Domain: Ein neues Cookie ersetzt ein vorhandenes nur, wenn Name, Domain und Pfad übereinstimmen. Mit cookie_domain: 'auto' schreibt das Google-Tag seine Cookies auf die höchstmögliche Domain, bei www.example.com also auf example.com. Ein Worker, der _ga mit Domain=www.example.com schreibt, legt ein zweites Cookie an, statt das erste zu verlängern.
• cookie_update: false im Google-Tag: Mit dem Standardwert true darf das Tag seine Cookies bei jedem Seitenaufruf aktualisieren und die Laufzeit ab dem letzten Besuch neu setzen, in Safari also wieder als Skript-Cookie. Mit false werden die Cookies nicht bei jedem Seitenaufruf aktualisiert.
• Verlängern, nie erzeugen: Kommt die Anfrage ohne _ga, antwortet der Endpunkt ohne Set-Cookie. Andernfalls vergeben beim ersten Besuch Worker und Tag je eine ID, und aus einem Besucher können zwei Nutzer werden.

Google gibt für _ga eine Standardlaufzeit von zwei Jahren an, das entspricht Max-Age=63072000. Chrome begrenzt die Laufzeit von Cookies seit Version 104 (August 2022) auf 400 Tage: Längere Werte werden nicht abgewiesen, sondern auf 400 Tage gekürzt, und jede Erneuerung bei einem späteren Besuch startet die Frist neu.

Der Weg über einen Response-Header ändert nichts an der Einwilligungspflicht. Artikel 5 Absatz 3 der ePrivacy-Richtlinie erfasst das Speichern von und den Zugriff auf Informationen im Endgerät unabhängig von der Technik; der Aufruf des Verlängerungs-Endpunkts gehört deshalb hinter ein erteiltes analytics_storage.