Click-IDs erklärt: gclid, fbclid, ttclid, li_fat_id im Vergleich

Wenn jemand auf eine Anzeige klickt und auf deiner Site landet, hängt die Plattform einen Token an die URL. Dieser Token, die Click-ID, ist das stärkste einzelne Attributions-Signal, das die Plattform hat. Jede Plattform macht es leicht anders. Mechanik, Lebensdauer und Capture-Regeln an einer Stelle.

Was eine Click-ID tatsächlich ist

Ein Ad-Klick führt den Besucher von der Anzeigenfläche (Google Search, Facebook-Feed, TikTok For You, LinkedIn-Timeline) zu deiner Landing-URL. Direkt vor dem Redirect hängt die Plattform einen Query-Parameter an die URL: ?gclid=..., ?fbclid=..., ?ttclid=..., ?li_fat_id=.... Der Wert ist ein signierter, undurchsichtiger Token, den nur die Plattform decodieren kann. Er enkodiert die Kampagne, Ad-Group, Creative, den Timestamp des Klicks und eine Prüfsumme, die beweist, dass der Klick vom eigenen Ad-Server der Plattform kam.

Sobald du diesen Token zusammen mit einem Conversion-Event an die Plattform zurückschickst, kann die Plattform die Conversion mit Sicherheit dem ursprünglichen Klick zuordnen. Kein Fingerprinting, kein Cookie-Matching, keine probabilistische Attribution. Nur ein einziger Beweis.

Die vier Click-IDs nebeneinander

Capture: einmal lesen, sofort speichern

Click-IDs existieren nur in der URL der allerersten Seite, auf der der Besucher landet. Sobald er zu einer zweiten Seite navigiert, ist der Parameter weg. Wenn du den Wert nicht erfasst und persistierst, bevor der Besucher weiterklickt, verlierst du Attribution für alles, was danach kommt.

Beaconrys nl-data.js liest document.location.search beim allerersten Page-Load, extrahiert jede bekannte Click-ID auf einmal und speichert sie in einem einzigen First-Party-Cookie namens nl_ext. Die Struktur ist JSON: {"gclid":"...","fbclid":"...","ttclid":"...","li_fat_id":"..."}. Cookie-Scope ist nur deine Domain, Expiry 90 Tage, consent-gated.

Persistenz und Decay

Jede Plattform hat ihr eigenes Attributions-Fenster. Nach Ablauf des Fensters akzeptiert die Plattform die Click-ID nicht mehr fürs Matching, auch wenn du sie noch sendest. Der praktische Effekt:

• Wenn der Besucher innerhalb von 7 Tagen für Meta konvertiert, funktioniert das Senden von fbclid.
• Wenn er an Tag 8 konvertiert, ist die fbclid technisch noch in nl_ext, aber Meta lehnt das Match ab.
• Metas First-Party-fbp-Cookie (gesetzt vom Browser-Pixel im Hybrid-Modus) erweitert das auf 90 Tage als Backup-Signal.

Beaconry sendet jede Click-ID, die es hat, bei jedem Event. Plattformen ignorieren abgelaufene Werte, kein Schaden. Der umgekehrte Fehler, abgelaufene IDs absichtlich zu entfernen, kostet dich die Grenzfälle, in denen das Plattform-Fenster zufällig länger ist als erwartet.

Was Beaconry sendet, pro Kanal

• Meta CAPI: fbc-Feld konstruiert aus fbclid + Landing-Timestamp, plus fbp-Cookie im Hybrid-Modus.
• TikTok Events API: ttclid-Feld wie erfasst, plus _ttp-Cookie im Hybrid-Modus.
• Google Ads API: gclid bei jedem Conversion-Action-Upload. wbraid und gbraid gesendet wenn vorhanden (Mobile- und iOS-Attributions-Varianten).
• LinkedIn CAPI: conversionEventToken aus li_fat_id gebaut, am Event angehängt.

Für den Conversion-Event-Payload hängt Beaconry je nach Kanal die passende Click-ID an. Ein Purchase-Event an Meta bekommt fbc, dasselbe Purchase-Event an Google Ads bekommt gclid. Keine Vermischung.

Was ohne Click-IDs schiefgeht

Conversion-Attribution fällt auf das nächststärkste Signal zurück, das die Plattform hat:

1. First-Party-Cookie, gesetzt vom plattformeigenen Browser-Pixel (nur mit Hybrid-Modus verfügbar).
2. Gehashtes-PII-Match (E-Mail, Telefon), in derselben Session in einem Formular eingereicht.
3. IP plus User-Agent-Fingerabdruck, das schwächste Signal, oft auf iOS komplett verworfen.

Für Ad-Click-Besucher, die ohne Formular konvertieren, ist die Click-ID der Unterschied zwischen "korrekt attribuiert" und "ungetracked". Netto-Effekt auf einem typischen E-Commerce-Setup: 30-50 % der Paid-Search-Conversions werden für Google Ads unsichtbar, wenn gclid nicht erfasst und replayed wird.

Direkt-Besuche und organischer Traffic

Besucher, die ohne Click-ID kommen, organische Suche, Direkt-Traffic, Referral, haben nie eine. Es gibt nichts zu erfassen, das nl_ext-Cookie bleibt für sie leer. Beaconry sendet das Conversion-Event mit leerem Click-ID-Feld; Plattformen schreiben die Conversion einfach keinem Paid-Click zu. Das ist korrektes Verhalten, weil es kein Paid-Click war.

Häufige Stolperer

• URL-Stripping. Manche CDNs und Security-Tools entfernen Query-Parameter, die sie nicht erkennen. Wenn keine Click-IDs in nl_ext landen, prüf Cloudflare Page Rules und "Always Online"-Tools auf Parameter-Stripping. Whiteliste die vier Click-ID-Namen.
• Server-side Redirects. Wenn deine Landing-URL auf einen kanonischen Pfad redirected, stell sicher, dass der Redirect den Query-String erhält. 301 /landing?fbclid=... → /home verliert die fbclid.
• Single-Page-Apps. SPAs, die Navigation client-side ohne Page-Load handhaben, triggern Beaconrys URL-Parsing nicht bei nachfolgenden Navigationen. Capture passiert nur beim Initial-Load, was du auch willst, aber stell sicher, dass die SPA die URL nicht via history.replaceState ersetzt, bevor Beaconry läuft.
• iOS Mail Privacy und E-Mail-Click-Throughs. iOS Mail prefetched Links, was heißt, der Click-ID wird vom Apple-Prefetcher "verbraucht", nicht vom menschlichen Besucher. Mitigation: Kampagnen an E-Mail-Listen sollten 10-15 % Attributions-Verlust auf iOS-Audiences erwarten, unabhängig vom Tracking-Tool.

Fazit

Vier Query-Parameter, vier Plattformen, ein architektonisches Pattern: beim Landing lesen, in einem First-Party-Cookie persistieren, bei jedem Conversion-Event replayen. Beaconry handhabt alle vier out of the box, im selben nl_ext-Cookie, mit dem richtigen Server-Side-Mapping pro Kanal. Das einzige, worüber der Kunde nachdenken muss, ist ob die URL überhaupt intakt ankommt, was meist eine CDN-Konfigurations-Frage ist, keine Tracking-Frage.