First-Party-Attribution: Besucher ohne Third-Party-Cookies tracken

Du startest eine Kampagne, siehst 400 Besucher in Google Analytics, 12 Anmeldungen… und kannst nicht sagen, welche aus welcher Quelle stammen. Willkommen in der Attribution nach den Third-Party-Cookies, wo 30 bis 50 % deines Traffics unsichtbar geworden sind. Die gute Nachricht: Du brauchst weder GA noch Third-Party-Pixel. Ein Pixel, das von deiner eigenen Domain ausgeliefert wird, genügt, um die Kette Besuch → Anmeldung → Umsatz zu rekonstruieren, und es übersteht alles, was die klassischen Tracker kaputtmacht.

Warum die klassischen Lösungen einbrechen

Third-Party-Pixel (Meta Pixel, Googles `gtag.js`, Hotjar…) setzen ein Cookie oder lesen eine Kennung von einer anderen Domain als deiner. Genau das haben die Browser beschlossen zu töten. Drei Kräfte laufen zusammen, und du erleidest sie bereits:

• Safari / ITP: ein per JavaScript gesetztes Cookie (`document.cookie`) ist auf 7 Tage gedeckelt, und auf 24 h, wenn der Besucher über einen Link mit Tracking-Parametern kommt. Deine 30-Tage-Attribution ist tot, bevor sie begonnen hat.
• Third-Party-Cookies blockiert: Safari und Firefox blockieren sie seit Jahren standardmäßig. Chrome ist 2024 von der vollständigen Abschaffung zurückgerudert, hat aber ein Opt-out verallgemeinert, das den Speicher trotzdem leert.
• Strikte Einwilligung (DSGVO): ohne akzeptiertes Banner dürfen GA und die Marketing-Pixel nicht laden. Ergebnis: ein klaffendes Loch in deinen Daten, und ein Loch, das nicht zufällig ist (die Ablehnungen korrelieren mit bestimmten Profilen).

Das Gemeinsame dieser drei Brüche: Sie zielen auf den Dritten. Wenn die Kennung von deiner Domain stammt und nur dir dient, greifen die meisten dieser Regeln nicht auf dieselbe Weise.

Das Prinzip: ein First-Party-Pixel + eine anonyme visitor_id

Die Idee besteht aus drei Teilen. Du lieferst einen Sammel-Endpoint auf deiner eigenen Domain aus (idealerweise eine Subdomain wie `t.deineapp.com`, keine externe Tracking-Domain). Beim ersten Besuch generierst du eine zufällige `visitor_id` und speicherst sie in einem First-Party-, HttpOnly-, Secure-Cookie. Bei jedem Seitenaufruf schickt der Browser dieses Cookie an deinen Server zurück, der das Ereignis loggt. Das Detail, das alles ändert: Das Cookie wird durch eine HTTP-Antwort `Set-Cookie` auf der Serverseite gesetzt, nicht per `document.cookie` in JavaScript. Genau diese Nuance umgeht die 7-Tage-Grenze von ITP — die Grenze zielt auf per JS gesetzte Cookies, nicht auf die vom Server in First-Party gesetzten. Und `HttpOnly` macht sie für jedes Skript unlesbar, also unbrauchbar für Diebstahl per XSS.

# Réponse de ton endpoint /t/collect servi sur t.tonapp.com
HTTP/1.1 204 No Content
Set-Cookie: vid=8f3c1a9e-...; Max-Age=63072000; Path=/;
  Domain=.tonapp.com; HttpOnly; Secure; SameSite=Lax

// pixel.js côté client (~10 lignes) :
// fetch("https://t.tonapp.com/t/collect", {
//   method: "POST", credentials: "include", keepalive: true,
//   headers: { "Content-Type": "application/json" },
//   body: JSON.stringify({ path: location.pathname,
//     ref: document.referrer, utm: location.search, ts: Date.now() }) });

Die Verschmelzung: von der anonymen visitor_id zur bewiesenen Identität

Solange der Besucher anonym ist, sammelst du Ereignisse, die an eine undurchsichtige `visitor_id` gebunden sind. Die Magie passiert im Moment der Anmeldung: Der Nutzer beweist seine E-Mail (Bestätigungslink oder OTP), und du machst das Stitching — du verbindest die `visitor_id` des Cookies mit dem frisch erstellten Konto. In diesem Augenblick wird die ganze anonyme Vorgeschichte (erster Besuch, Quelle, gesehene Seiten) rückwirkend an eine echte Identität gebunden.

1. Lies im Moment des Signups das Cookie `vid` serverseitig in derselben Anfrage.
2. Schreibe eine Zeile `identity(visitor_id, user_id, email_verified_at)` — die bewiesene E-Mail, nicht nur die eingegebene.
3. Hänge alle anonymen Ereignisse mit dieser `visitor_id` an die `user_id`. Du erhältst den vollständigen Pfad: Twitter → /pricing → /signup → E-Mail bestätigt.
4. Bonus: Wenn sich dieselbe E-Mail von einem anderen Gerät erneut verbindet, verschmilz zwei `visitor_id` unter einer einzigen `user_id`.

Was du gegenüber Google Analytics und Third-Party-Pixeln gewinnst

• Langfristige Attribution: Dein Server-Cookie kann auf 2 Jahre statt 24 h zielen. Für einen B2B-Funnel, bei dem die Entscheidung 3 Wochen dauert, ist das der Unterschied zwischen einem zugeordneten Verkauf und einem im Rauschen verlorenen.
• Vollständige Daten: Du loggst serverseitig, also treffen dich die Blocker (uBlock, Brave), die `gtag.js` schlucken, nicht. Du siehst deinen echten Traffic, nicht die von Erweiterungen durchlöcherte Version.
• Direkte Verknüpfung mit deinem Umsatz: Die `visitor_id` liegt in deiner Datenbank, neben deinen Tabellen `users` und `subscriptions`. Du machst einen SQL-`JOIN` zwischen einer Quelle und echtem MRR — unmöglich mit dem anonymisierten Aggregat von GA4.
• Einfacher abzugrenzende Compliance: Eine strikt First-Party-Kennung mit dem Zweck interner Messung ist leichter zu rechtfertigen als die Daten an Google und Meta zu schicken. Mit deinem Anwalt zu prüfen, aber der Umfang ist radikal klarer.
• Kein Sampling und keine Kardinalitätsschwelle: GA4 sampelt und verbirgt Segmente < ~50 Nutzer. In deinen eigenen Logs existiert jede Zeile.

Die Fallen, die das Setup in der Produktion zerlegen

• Das Pixel von einer wirklich eigenen Subdomain ausliefern: Ein CNAME auf eine bekannte Tracking-Domain (etwa `.analytics-vendor.com`) wird von ITP als Dritter umklassifiziert, was die 7-Tage-Grenze wieder aufzwingt. Die Subdomain muss auf deine* Infrastruktur auflösen.
• `SameSite=Lax` als Minimum: Mit `None` ohne Grund führst du Third-Party-Verhalten wieder ein. `Lax` deckt den Normalfall ab (Klick zu deiner Seite).
• Idempotenz des Stitchings: Dieselbe `visitor_id` kann zweimal ankommen (Doppel-Submit, Retry). Eindeutiger Schlüssel auf `(visitor_id, user_id)`.
• Die PII aus den Rohlogs löschen: Logge die IP nicht ewig im Klartext. Kürzen oder hashen; behalte die IP nur so lange wie nötig fürs Geo/Anti-Fraud.
• Der Fall "nie angemeldet": 95 % der Besucher werden sich nie verschmelzen. Das ist normal. Du behältst das anonyme Aggregat für den Top-of-Funnel, die Verschmelzung betrifft nur die Konvertierten.

Fang klein an: ein Endpoint, ein `Set-Cookie`-HttpOnly-Cookie, das auf deiner Subdomain ausgeliefert wird, eine Tabelle `events(visitor_id, path, ref, ts)` und eine Tabelle `identity(visitor_id, user_id)`, die befüllt wird, sobald die E-Mail bewiesen ist. Du hast an einem Nachmittag eine Attribution, die Safari, die Blocker und die Einwilligung übersteht — und die sich direkt an dein MRR anschließt. Wenn das läuft, ergänze Multi-Device und die Zählung der Quellen. Der Rest ist SQL.