Click ID Capture

info

Click ID capture is a pro feature. Get the pro version here

Every ad platform hands you an identifier when someone clicks one of your ads: Google Ads sends a gclid, Meta an fbclid, TikTok a ttclid, and so on. That identifier is what lets the platform connect a purchase in your shop back to the ad it paid for.

The problem is that a click ID only ever exists in the browser. It arrives as a parameter on the landing page, which is almost never the checkout, and it is gone from the address bar long before the order is created. Server-side conversion tracking, however, runs when the order is created, and sometimes much later, from a payment webhook, a status change, or a backfill. By then nothing is left of the original visit.

Since version 1.66.0 the Pixel Manager captures the click IDs of a visit and stores one snapshot on the order. Every server-side destination then reads the click ID from that snapshot, including destinations that were switched on after the order was placed.

Which click IDs are captured

Platform	Click ID
Google Ads	gclid, wbraid, gbraid
Meta (Facebook)	fbclid
Microsoft Advertising	msclkid
TikTok	ttclid
Snapchat	scid (arrives in the URL as ScCid)
Pinterest	epik
Reddit	rdt_cid
Nextdoor	ndclid
OpenAI	oppref

Only the platforms that are actually configured in the Pixel Manager are captured. A click ID is personal data, and storing identifiers for a platform your shop has no destination for would serve no purpose.

Where the click ID comes from

A single source would miss too many orders, so the Pixel Manager reads from four layers and takes the first one that has a value:

1. The ad platform's own cookie. The most durable source, written by the platform's tag itself, for example _gcl_aw for Google Ads.
2. The Pixel Manager's own cookie, _pmw_click_ids. Written in the browser on the landing page and refreshed from the server, it lasts 90 days and survives what the other layers do not: a closed tab, an expired WooCommerce session, and platform tags that never ran. wbraid and gbraid have no platform cookie at all, so for those this is the only cookie.
3. The WooCommerce session. The values the browser reports on cart and checkout pages.
4. The URL of the current request, for visits that land and buy on the same page.

Capture happens where the customer's browser is still present: at checkout, on the pay-for-order page, and on the purchase confirmation page as a second chance. That is what makes it survive orders whose customer never returns from the payment provider.

Marketing consent is required

_pmw_click_ids is classified as a marketing cookie, and the Pixel Manager writes it only after the visitor has granted marketing consent. The platforms' own cookies from layer one follow the same rule, because the tags that write them do not run before consent either.

On a shop with an explicit opt-in banner this has a direct consequence: the share of orders with a click ID can never be higher than the share of visitors who accept the marketing category. If your banner is rarely accepted, or if the marketing category is not wired up correctly in your consent management platform, the capture rate drops with it. That is expected behaviour, not a tracking defect.

See Consent Management for how the Pixel Manager reads consent from your banner.

The Click ID Capture Quality report

The debug report, under Support → Debug report in the Pixel Manager, contains a section that shows how capture is doing on your shop:

## Click ID Capture Quality ##

Orders scanned (newest first):     250 (2026-05-12 to 2026-09-14)
Click ID capture active since:     2026-08-26
Orders created since then:         39
With at least one click ID:        26 (67%)
Browser conversion pixel missed:   4
  of those, with a click ID:       2 (50%)
Click IDs by key:                  gclid 26
Capture layer (per click ID):
  platform_cookie:                 21
  pmw_cookie:                      5
Capture point (per click ID):
  order_created via wc-ajax:checkout: 26

Line by line:

• Orders scanned is how far back the report looked, with the date of the oldest and the newest order in that window. It is always the newest 250 orders, which on most shops is several months.
• Click ID capture active since is the day this shop first ran a version that could capture click IDs. Orders older than that date can never carry a click ID, so they are excluded from everything below.
• Orders created since then is the number of orders the rest of the report is calculated on. This is the number that matters: if it is small, every percentage below is noisy.
• With at least one click ID is the capture rate itself.
• Browser conversion pixel missed counts the orders whose customer never reached the purchase confirmation page, so no browser pixel could fire. The line below it shows how many of those still carry a click ID, which is exactly the gap server-side tracking closes.
• Click IDs by key shows which platforms are actually delivering clicks.
• Capture layer shows which of the four sources delivered each click ID.
• Capture point shows which checkout flow the snapshot was written in, which is useful when only one type of checkout on your shop is losing click IDs.

Right after an update you will see this instead:

Orders scanned (newest first):     250 (2026-05-12 to 2026-08-26)
Click ID capture active since:     2026-08-26
Orders created since then:         0
No order was created after click ID capture became active on this shop,
so there is nothing to measure yet. Check again once orders come in.

That is not a problem. It only means the feature is newer than your most recent order. Come back after a few weeks of orders.

What to check when the rate is low

• Did the shop only recently update? Check the Orders created since then line first. A handful of orders says nothing yet.
• Were campaigns running in that window? A click ID can only be captured if visitors actually arrive through paid ads.
• Is marketing consent being granted? On an explicit opt-in shop this is the single biggest factor. Verify that your banner's marketing category is mapped correctly, and get a feel for how often visitors accept it.
• Is the platform configured? Nothing is captured for a platform that is not set up in the Pixel Manager.
• Are the Pixel Manager's scripts running? If an optimizer delays, defers or strips them, the browser layer never writes the cookie. See Caching and Optimization Exclusions.