fbclid ttclid: Keeping Click IDs Alive Through Your Funnel
What Click IDs Do
When a user clicks a Meta ad, Meta appends its ClickID to the advertiser's URL: https://example.com/?fbclid=IwAR2F4.... Meta documents the benefits directly - more attributed conversion volume, better campaign attribution and optimization - because the click identifier lets Meta connect a later conversion to the exact ad click that caused it. TikTok does the same with ttclid: the parameter is added to landing page URLs and used for attribution within the click window.
The pair fbclid and ttclid have rules that matter operationally. Meta's documentation warns that the ClickID value is case sensitive - do not lowercase, uppercase, or otherwise modify it before use. Both platforms recommend storing the value on your side: Meta's pixel automatically persists ClickID into the first-party _fbc cookie, and TikTok attaches ttclid automatically when the feature is enabled for the ad.
The reason these parameters deserve a whole guide is that they are fragile in transit. Everything downstream - redirect chains, trackers, link shorteners, messenger clients - handles your landing URL, and a single rewrite that drops the query string quietly severs the attribution chain. No error appears; conversions simply stop matching.
Where Click IDs Get Lost
Click IDs die in transit, not at the source. The typical loss points in an affiliate funnel:
- Redirect chains. Each hop must forward the full query string. A 301 that hard-codes a clean destination URL strips
fbclidandttclidin one line of configuration. - Link shorteners and smart links. A shortener that re-encodes parameters - or drops unknown ones - breaks every platform identifier it carries.
- Messenger and in-app openings. Traffic opened through messengers passes additional layers you do not control, which is precisely why the platforms give you a cookie fallback for on-site navigation.
- Prelander-to-offer hops. In affiliate funnels the most common break is between your prelander and the offer: the offer link is built without the tracker macros, so the click ID captured on the prelander never travels to the page where the conversion fires. Pass the tracker macros - and the platform parameters - into every outgoing link you build.
- Tracker URL rewrites. A tracker that rebuilds the landing URL must pass platform parameters through verbatim - and Meta's warning about case sensitivity applies here: modifying the value breaks it.
The operational rule: treat fbclid and ttclid as immutable strings. Capture them on the first request, carry them through every hop unchanged, and log them alongside the click in your tracker. If you cannot answer "where is the fbclid for this conversion?", the attribution chain is already broken somewhere between the ad and the postback.
The First-Party Cookie Fallback
The platforms designed for URL loss. Meta's pixel, once installed, automatically writes the ClickID into the _fbc first-party cookie; the _fbp cookie carries a browser identifier alongside it. Meta's guidance for server events is to send both cookie values in the fbc and fbp event parameters when available, and to refresh them over sessions because the values change. If your server reads the _fbc cookie from the request, you can recover the click context for visitors who reached the site with the ClickID intact - the cookie protects the path between pages of your funnel, not the hop before the first page load. If a redirect upstream already stripped fbclid, the pixel never sees it and never creates the cookie, which is why preserving the parameter on the way to the landing remains non-negotiable.
TikTok's ttclid similarly persists through the pixel for web events. The cookie fallback has limits - cookies are per-browser and clear with consent or housekeeping - which is why the authoritative setup captures the click ID server-side at the first touch and stores it in your own tracker rather than trusting the browser alone.
Carrying Click IDs Through a Tracker Into CAPI Events
For tracker-driven traffic the preservation chain has three links. First, capture: the landing page or tracker records fbclid/ttclid from the URL together with the tracker's own click ID. Second, storage: the pair lives in the tracker until the conversion happens - days or weeks later. Third, replay: when the postback arrives, the server event sent to the platform's Conversions API carries the stored click identifier, letting the network connect the conversion to the original click. This is the same mechanism described in TikTok Events API delivery from trackers and the Keitaro Facebook CAPI integration. Event ID deduplication then keeps the replayed event from double-counting against the browser copy.
Skipping the first link poisons the rest: a postback without a click identifier can still be sent - hashed user data provides fallback matching - but it loses the strongest attribution signal, which shows up as match-rate and discrepancy problems rather than as errors. Diagnose those with the Facebook Ads conversion discrepancy guide and the general postback troubleshooting checklist.
Manual plumbing of click IDs across landings and networks is exactly the fragile layer MOST automates: capture at the landing, storage in the tracker, and replay into each network's Conversions API with retries and deduplication handled. For a single landing and a manual workflow, Pixel Activator applies the same click-ID mechanics without code - and the broader server-side context lives in server-side tracking versus browser pixels.