Attribution & AnalyticsReferenceIntermediate

Click ids and attribution windows: which parameters to capture, how long to keep them and where to store them

A reference of advertising click ids (gclid, gbraid, wbraid, dclid, msclkid, fbclid, ttclid, li_fat_id, rdt_cid, epik, ScCid, twclid, tblci, ob_click_id, affiliate ids), how consent gates their capture, how attribution windows differ per platform and how first-party storage should expire.

By
Track editorial team
Published
Last reviewed
Reading time
3 min read

Key takeaways

  • Each ad platform stamps its own click id on the landing URL — gclid, msclkid, fbclid, ttclid, li_fat_id, rdt_cid, epik, ScCid, twclid, tblci, ob_click_id and the affiliate ids — and each feeds a specific server field.
  • Click ids are personal data for an advertising purpose: the SDK captures them only with marketing consent and strips them from URLs under analytics-only consent.
  • Attribution windows differ per platform; a conversion uploaded outside the window is not an API error, it is simply not attributed.
  • Ids live first-party in _ts_cid for the site's click-id TTL, are cleared when marketing consent is withdrawn and are scrubbed from page_location and referrer before storage.

The parameter list

ParameterPlatformServer field it feedsNotes
gclidGoogle Ads (search, shopping, display)gclid in click conversion uploadsreplaced by gbraid/wbraid on iOS app campaigns
gbraid, wbraidGoogle Ads (iOS privacy variants)same upload, alternative fieldsmutually exclusive with gclid
dclidCampaign Manager 360 / DV360dclid in Floodlight offline conversions
msclkidMicrosoft AdvertisinguserData.msclkid
fbclidMetauser_data.fbc as fb.1.<timestamp>.<fbclid>the pixel writes the same value into _fbc
ttclidTikTokuser.ttclid
li_fat_idLinkedInLINKEDIN_FIRST_PARTY_ADS_TRACKING_UUIDalso set by the Insight Tag
rdt_cidRedditclick_id
epikPinterestuser_data.click_id
ScCidSnapchatuser_data.sc_click_idcase-sensitive
twclidXtwclid
tblciTaboolaclick-id in the S2S actionrequired; no click id, no conversion
ob_click_id (dicbo)Outbrainob_click_id
irclickidImpactClickId in the postback
cjeventCJCJEVENT
awcAwincks
tduidTradedoublertduid
clickref / pclickidPartnerize, genericpreset-specific
ranMID/ranSiteIDRakutenpreset-specific

Track's SDK recognises all of these and records each under its own name on the event, so the connector for a platform finds exactly the id it needs.

A click id links a person's session to an advertising click; it is personal data and it serves an advertising purpose. The SDK therefore captures click ids only when the marketing purpose is granted. If consent arrives after landing (the visitor clicks "accept" on the second page), the ids from the landing URL are captured for the events that follow the consent decision — never before it.

For analytics-only consent the ids are stripped from the URL before it is sent to the collector, so they do not leak into page-view data either.

Attribution windows differ

Platforms count a conversion only if it happens within their window after the click. Typical defaults, all configurable in the platform UI:

  • Google Ads: 30-day click window per conversion action (1 to 90 days)
  • Meta: 7-day click, 1-day view
  • Microsoft: 30-day click (1 to 90 days)
  • TikTok: 7-day click, 1-day view
  • LinkedIn: 30-day click, 7-day view; API uploads accepted for 90 days
  • Pinterest: 30-day click, 30-day engagement, 1-day view
  • Snapchat: 28-day swipe-up, 1-day view
  • Affiliate networks: usually 30 days, set per programme

Uploading a conversion outside the window is not an error at the API level; it is simply not attributed. The event still counts in your own reporting.

Storage and expiry

Click ids captured on the landing page are kept first-party in the browser under _ts_cid (localStorage), only while the marketing purpose is granted, for the site's click-id TTL — 90 days by default, a sensible ceiling given the longest windows above. Every later event of the visit carries them, a newer id for the same platform replaces the older one, and withdrawing marketing consent clears the store immediately. Safari's 7-day cap on script-written storage applies to this store as well.

Server-side events for the same order receive them when the router pairs a verified shop purchase with the browser purchase that carries the same order id. On the event store, click ids are removed after the click-id retention window, and the DSAR deletion flow removes them together with the visitor's other data.

Landing URL hygiene

Click ids on the landing URL are useful; click ids in your analytics reports are noise and a privacy exposure. The collector scrubs every known click id from page_location and referrer before storage and before delivery to analytics destinations, while keeping them as separate fields for the advertising connectors that need them.

Primary sources

Documentation and standards this article is based on.

  1. Google Ads Help — About auto-taggingsupport.google.com
  2. Meta for Developers — fbc and fbp parametersdevelopers.facebook.com

Was this article helpful?

Responsible editor

Track editorial team

Product & engineering

The people building Track: engineers and analysts who work on server-side tracking, consent tooling and connector integrations every day.