Click ID Prelander Loss: Where Click IDs Die

The quietest way affiliate funnels leak money is click ID prelander loss: the ad platform appends its identifier to the ad URL, the visitor passes through a prelander, a redirect or two, and an offer page - and somewhere in that chain the identifier stops traveling. Conversions still happen; the postback arrives with an empty subid; and the platform never learns which of its clicks produced the money. This guide walks the prelander hop by hop, marks where click IDs survive and where they die, and shows the two techniques that keep attribution alive even when the markup misbehaves.

The loss points at the link level - UTM stripping, URL length limits, ad-setting mistakes - live in where fbclid and ttclid get lost. This page stays on the prelander chain itself. Per-platform names live in the click ID glossary.

The Chain: Every Hop Is a Hand-Off

A typical prelander funnel passes the identifier through four hops:

1. Ad to tracker. The platform appends fbclid (Meta), ttclid (TikTok), or its own parameter to the ad's destination URL. If the destination is your tracker link, the tracker stores the click with the identifier immediately - before anything else can go wrong.
2. Tracker to prelander. The tracker redirects to your prelander, passing through whatever parameters the prelander needs. Here the click ID is already safely stored tracker-side; the copy riding the URL is only a convenience.
3. Prelander to offer. The prelander's CTA moves the visitor to the offer URL with the network's subid parameter attached. This hop is where on-page techniques - plain links, meta refresh, JavaScript, iframes - each carry the parameters differently.
4. Offer to postback. The advertiser reports the conversion; the network echoes your subid back. Whether it echoes anything depends entirely on what survived hop three.

The safety rule follows from the structure: get the identifier into the tracker at hop one, and hops two through four only carry the network's subid - a parameter you chose, formatted the way the network documents. Meta's own guidance for server-side setups makes the same point from the other side: the _fbc cookie value can be constructed from the fbclid URL parameter when the browser never set it (fbp and fbc parameters) - the identifier's canonical home is the URL at click time, not any later page.

Hop Three: Where the Quiet Losses Live

The prelander-to-offer hop has three common implementations, with very different failure profiles:

The iframe case deserves the warning it rarely gets: an offer embedded in an iframe loads the offer URL you put in the frame's src. If that URL was saved without the subid placeholder - or with a placeholder the template never resolves - every visitor converts with no identity attached, and the prelander looks perfectly fine in a browser. Meta and TikTok document their identifiers as URL parameters - fbclid on ad URLs, ttclid per TikTok's click ID documentation - and URL parameters do not teleport across frames or refreshes: something in the markup has to carry them.

TikTok's documentation notes that each Click ID is unique and adheres to the CTA window configured in Attribution Manager - and the parameter lives on the landing URL, so the receiver should capture it on first visit; one more argument for hop-one capture instead of mid-funnel reliance.

Hop One Done Right: Tracker-Side Capture

The single highest-leverage decision in a prelander funnel is the ad's destination URL. Aim the ad directly at the offer or at a bare-bones prelander that hands parameters onward, and every hop is a chance to lose them. Aim it at your tracker link, and hop one ends with the click - including its platform identifiers and the visitor's IP and user agent - recorded in the tracker's database:

1. The tracker link receives the click with fbclid/ttclid attached and stores them on the click row.
2. Every later hop only needs the tracker's own subid to make the return trip - one short parameter, documented by the network, stable across all your landings.
3. At conversion time, the network's postback echoes the subid; Keitaro matches it to the click, and the stored identifiers ride the server event to the platform (Keitaro's postback contract).

This is also why the postback warning from Keitaro's docs matters so much in prelander funnels: "affiliate networks do not send a real subid in test postbacks" - the only valid test of hops two through four is a real conversion through the real chain.

Server-Side Reconstruction: The Safety Net

Two different losses hide behind one symptom ("conversions not attributed"), and they have opposite recoverability:

• Lost browser-side identifiers. The _fbp/_fbc cookies of the offer domain never existed in affiliate flows anyway - there is no pixel on the offer. What replaces them is construction: Meta documents that _fbc is built from the fbclid parameter your tracker captured at click time (fbp and fbc parameters). As long as hop one stored the click, this reconstruction works no matter what the prelander markup did.
• Lost subid. If the network never received your subid - the meta refresh that dropped it, the iframe's bare src - the conversion reaches the tracker unmatched, and no downstream technique rebuilds a link that was never formed. Keitaro's postback log names it directly: "Click for subid REPLACE not found," with the fix being the offer-parameter mapping or a conversation with the network (postback troubleshooting).

The recovery ladder is therefore: prevent with hop-one capture, detect with the postback log, and reconstruct server-side what the browser lost. What the tracker never stored has no ladder rung - see the broader losses in the no-access playbook.

Testing the Chain Before Scaling

A five-minute pre-deploy ritual catches every loss mode above:

1. Click the ad (or copy its destination URL) and confirm the click ID parameter is present on arrival at the tracker.
2. Open each prelander hop and inspect the offer URL it produces: the subid parameter must be present and non-empty - test it with a real click, because template macros sometimes resolve only for real visitor sessions.
3. Fire a real conversion and verify Keitaro's logs: the postback log confirms the incoming subid match (no "Click for subid not found"), and the S2S log shows a populated {external_id}, proving the loop back to the source.
4. Confirm the platform-side event carries the reconstructed identifiers - Test Events shows the arrival, Events Manager within about 20 minutes (get started).

The postback troubleshooting checklist turns this ritual into a printable routine, and the wiring behind hop four is in the postback-to-CAPI guide.

Click ID Loss Through Prelanders: Frequently Asked Questions

Sources