Click-ID uitgelegd: gclid, fbclid, ttclid en msclkid

Een click-ID is een ondoorzichtig token dat een advertentieplatform genereert op het moment dat iemand op zijn advertentie klikt, toevoegt aan de bestemmings-URL, en later bij de conversie weer uitleest - zodat het een verkoop of aanmelding kan koppelen aan de exacte klik die eraan voorafging. De versie van Google is gclid. Die van Meta is fbclid. Die van TikTok is ttclid. Die van Microsoft Advertising is msclkid. Voer je betaalde campagnes op meer dan één platform, dan kom je alle vier tegen, meestal terwijl je je afvraagt waarom je URL zo lang is geworden.

Elk vervult exact dezelfde taak voor zijn eigen platform, en geen enkele is een label dat je zelf schrijft. Een UTM-tag is tekst die je zelf samenstelt zodat je eigen analytics verkeer per campagne kan groeperen. Een click-ID is dat niet - het is een string die het platform genereert, en alleen de eigen pixel of API van dat platform weet er iets mee te doen. Je hebt beide nodig. Ze beantwoorden verschillende vragen. Dat is het deel dat de meeste uitleggers overslaan.

Wat een click-ID eigenlijk is

Zie een click-ID als een garderobebonnetje, geen naamplaatje. Wanneer iemand op een Google-advertentie klikt, genereert de server van Google een unieke string, koppelt die aan de campagne, advertentiegroep en het zoekwoord achter de klik, en voegt hem toe aan de URL als ?gclid=.... De string is voor jou of wie dan ook onleesbaar - het is een referentienummer in Google's eigen klik-log. Fbclid, ttclid en msclkid volgen hetzelfde patroon: een andere generator, hetzelfde idee.

De essentie is het sluiten van de cirkel tussen "we hebben een advertentie getoond" en "dit gebeurde op jouw site". Zonder click-ID kan een platform alleen schattingen op campagneniveau rapporteren. Met een click-ID kan het zeggen: deze exacte klik, drie dagen geleden, leidde tot deze exacte aankoop - een precisie die UTM's je alleen niet geven. Dat is wat offline-conversie-import, Smart Bidding en CAPI-achtige server-events mogelijk maakt. UTM-parameters uitgelegd is het bijbehorende artikel voor de campagneniveau-tagging die de meeste teams naast click-ID's gebruiken.

De vier click-ID's die je tegenkomt

Elk groot advertentieplatform heeft zijn eigen versie, en de verschillen die ertoe doen zijn wie hem terugleest en hoe lang hij bruikbaar blijft.

Vier platforms, vier parameternamen, één mechanisme. Adverteer je op alle vier, dan kan één landingspagina meerdere click-identifiers tegelijk dragen - een verouderde gclid van de klik van vorige week naast een verse fbclid van de retargeting-advertentie van vandaag.

Hoe een click-ID verschilt van een UTM-parameter

Dit is de verwarring achter elke zoekopdracht naar "wat is fbclid": hij staat vlak naast utm_source in de query string en ziet eruit als een trackingparameter, maar doet iets compleet anders.

Een UTM-parameter is een label: jij kiest de waarde - utm_campaign=spring-sale - en je analyticstool groepeert sessies op basis van welke string je ook typte. Een click-ID is een opzoeksleutel. Jij koos de waarde van gclid niet; Google deed dat, en alleen Google's eigen systemen kunnen er iets mee. Zet je een gclid in een generiek analyticsrapport, dan blijft hij daar gewoon liggen - nuttig voor Google Ads, nutteloos voor al de rest.

Die asymmetrie is belangrijk bij troubleshooting. Wanneer UTM's niet meer in rapporten verschijnen, ligt de oorzaak meestal bij de browser of een kapotte link - Firefox en Brave breken je UTM-attributie behandelt dat storingspatroon. Wanneer een click-ID niet meer matcht, ligt de oorzaak vrijwel altijd erin dat hij nooit op tijd de eigen pixel of API van het platform bereikte, of dat het geldigheidsvenster sloot voordat de conversie plaatsvond.

Hoe de heen- en terugreis van een click-ID precies werkt

Haal de platformspecifieke naamgeving weg en elke click-ID doorloopt dezelfde reis in drie fasen.

Fase een, de generatie. Op het moment dat een gebruiker op de advertentie klikt, nog voordat de browser je landingspagina zelfs maar opvraagt, genereert het platform de identifier en codeert hem in de redirect-URL.

Fase twee, de rit. De identifier reist als query parameter door welke hops er ook tussen de advertentie en je landingspagina zitten - de redirect van het platform, dan je domein. Leg hem hier vast en schrijf hem weg in een cookie, een verborgen formulierveld, of je CRM-record voor later.

Fase drie, de match. Wanneer de conversie plaatsvindt - een aankoop, een aanmelding, een formulierinzending - stuurt je pixel of server de opgeslagen click-ID samen met het event terug naar de API van het platform. Het platform zoekt hem op in zijn eigen klik-log en crediteert, als hij nog binnen het geldigheidsvenster valt, de oorspronkelijke advertentie. Dat is het mechanisme achter conversies doorsturen naar Meta's Conversions API: vroeg vastleggen, vasthouden, later terugsturen.

Waarom de parameter ongevraagd verscheen, en of je hem kunt verwijderen

De meeste mensen komen per ongeluk met een click-ID in aanraking. Auto-tagging staat standaard aan bij Google Ads en Microsoft Advertising, en TikTok maakte ttclid in 2024 automatisch, zonder opt-in. Niemand vroeg om de parameter; het platform begon hem gewoon toe te voegen, omdat conversietracking tegenwoordig zo werkt.

Dus ja, je kunt hem verwijderen - maar de timing bepaalt of dat onschuldig opruimwerk is of een zelf veroorzaakt attributiegat. Fbclid verwijderen uit een link voordat je die deelt, of hem wegpoetsen uit de URL-kolom van een rapport, verandert niets aan de conversiedata die je pixel al heeft vastgelegd. Hem verwijderen voordat je eigen script of redirect hem heeft gelezen is een ander verhaal: je hebt het ene ding weggegooid dat het platform nodig had om de klik te crediteren, en geen hoeveelheid UTM-data herstelt dat. De veiligste gewoonte is de click-ID server-side bij de eerste hop vast te leggen - de aanpak uit server-side conversietracking - en de parameter pas op te schonen in wat je toont of opslaat na die vastlegging.

Bekijk hoe conversietracking op Elido elke click-ID automatisch vastlegt → Worstel je handmatig met gclid, fbclid, ttclid en msclkid over vier advertentieaccounts heen, dan lost dit precies dat probleem op - één redirect-laag die de identifier vastlegt voordat iets anders de URL aanraakt.

Waar click-ID's verloren gaan

Een click-ID is kwetsbaar op precies dezelfde manieren als een UTM, plus een of twee eigen faalmodi.

Vier situaties zijn verantwoordelijk voor het grootste deel van het verlies, en elk vraagt om een andere oplossing.

Een bezoeker kopieert en plakt de bereikte URL in een groepschat. Iedereen die op die geplakte link klikt, draagt nu iemand anders' click-ID mee. De conversie matcht dan óf de verkeerde klik óf helemaal niets. Sla de identifier op tegen de sessie die als eerste aankwam, en stop met de URL in de adresbalk als de bron van waarheid te behandelen.

De klik opent in een in-app-browser. Instagram en TikTok geven de tap door aan een beperkte webview die een first-party-cookie vaak niet langer dan die sessie kan vasthouden, waardoor de identifier die meereist met de URL nergens kan blijven bestaan. Lees de parameter server-side uit bij het eerste verzoek in plaats van erop te vertrouwen dat de browser hem onthoudt.

Een redirect bouwt de bestemmings-URL opnieuw op en laat de query string vallen. De click-ID bereikt de landingspagina dan helemaal niet. Hij is al weg voordat je pixel laadt, dus niets verderop in de keten kan hem nog redden. Controleer of elke redirect-laag in het pad query parameters standaard doorstuurt.

De browser verwijdert de parameter voordat de pagina laadt. Firefox' query parameter stripping noemt fbclid expliciet in de Strict-modus. Leg de identifier vast bij de redirect, voordat de bestemmingspagina en zijn scripts ooit draaien.

Het kopieer-plak-geval is eigenlijk een dark-socialprobleem in een click-ID-jasje - de link reist via een privékanaal dat je analytics niet kan zien, en dark-social-attributie behandelt dat gat in volle omvang. Voor de Safari-specifieke cookiebeperkingen die de persistentie van fbclid en ttclid beïnvloeden, is click-attributie na Safari ITP de aangewezen leesstof - dat herhaal ik hier niet.

Conversies toegeschreven houden: de praktische checklist

Niets hiervan vereist het herbouwen van je stack. Het vereist alleen dat de click-ID één keer, vroeg, wordt vastgelegd, voordat iets verderop hem kan laten vallen.

• Leg gclid, fbclid, ttclid en msclkid server-side vast bij de eerste redirect-hop, niet op de landingspagina nadat scripts zijn geladen.
• Sla de click-ID op bij het order- of leadrecord in je eigen database, niet alleen in een cookie die kan verlopen voordat de verkoop rond is.
• Stuur de opgeslagen click-ID door naar de API van elk platform - Conversions API, Enhanced Conversions, Events API, UET offline import - binnen het geldigheidsvenster van dat platform.
• Controleer of je verkorter of redirect-keten query strings ongewijzigd doorgeeft; test met een dummy ?gclid=test123 en bevestig dat hij de hop overleeft.
• Combineer click-ID's met UTM's in plaats van er één te kiezen; UTM's end-to-end bijhouden behandelt de parallelle opzet voor het campagneniveau-overzicht dat een click-ID alleen je niet kan geven.

De meeste attributiegaten die ik heb uitgezocht, zijn terug te voeren op dat tweede punt: een click-ID die alleen in een cookie leefde, op een domein dat veranderde, of een sessie die verliep voordat de deal rondkwam. Die ene gewoonte fixen dicht meer gaten dan welke platforminstelling dan ook - precies het soort fix waar de tutorials-sectie van de blog om draait.

Gerelateerd op de blog

• UTM-parameters uitgelegd: de complete gids
• Firefox en Brave breken je UTM-attributie
• Click-attributie na Safari ITP
• Server-side conversietracking
• Conversies doorsturen naar Meta's Conversions API