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.

Reading the click ID of a single order

The Click ID Capture Quality report below gives you the picture across the whole shop. When you are investigating one specific order, typically a conversion your ad platform never reported, you want that order's own click ID and the date of the click that produced it.

Both values live in order meta whose keys start with an underscore. WordPress treats those as protected and hides them from the order screen, so you cannot read them in the WooCommerce admin. These are the keys:

Meta key	Written by	Holds
_pmw_click_ids	Pixel Manager 1.66.0 and later	All click IDs captured for the visit, as a key => value map, for example gclid => Cj0KCQ…
_pmw_click_ids_provenance	Pixel Manager 1.66.0 and later	Which layer and capture point delivered each of those click IDs
_wpm_gclid	Pixel Manager, on the purchase confirmation page	The Google Ads click ID only. The pre-1.66.0 mechanism, kept as a fallback for older orders
_wc_order_attribution_session_start_time	WooCommerce order attribution	The date and time the attributed visit was recorded, in other words the click date. This one is WooCommerce's, not ours

The most reliable way to read them is WP CLI, because it works the same whether your shop uses HPOS or the legacy post storage. Replace the order IDs with your own:

wp eval 'foreach ([123,124] as $id) { $o = wc_get_order($id); if (!$o) { echo "$id: not found\n"; continue; } echo $id . " | click IDs: " . wp_json_encode($o->get_meta("_pmw_click_ids", true)) . " | legacy gclid: [" . $o->get_meta("_wpm_gclid", true) . "] | click date: [" . $o->get_meta("_wc_order_attribution_session_start_time", true) . "]\n"; }'

With phpMyAdmin, Adminer or any other database client, use the first query if your shop runs HPOS, and the second one if your orders still live in the posts table. Adjust the wp_ table prefix if yours differs:

SELECT order_id, meta_key, meta_value FROM wp_wc_orders_meta
WHERE order_id IN (123,124)
  AND meta_key IN ('_pmw_click_ids','_wpm_gclid','_wc_order_attribution_session_start_time');

SELECT post_id, meta_key, meta_value FROM wp_postmeta
WHERE post_id IN (123,124)
  AND meta_key IN ('_pmw_click_ids','_wpm_gclid','_wc_order_attribution_session_start_time');

_pmw_click_ids is stored as a serialized array, so in a database client it looks like a:1:{s:5:"gclid";s:95:"Cj0KCQ…";}. WP CLI prints it as readable JSON, which is why we recommend that route.

If a query returns nothing at all, the numbers you used may be display order numbers rather than internal order IDs. Open the order in the admin and take the ID from the address bar.

How to read the result

• No click ID on the order. The visit that produced the order carried none, or marketing consent was never granted, so nothing could be stored. The ad platform has nothing to match the conversion against and will not report it, no matter how well the pixel fired.
• A click ID, and a click date older than the platform's click-through window. Google Ads uses 30 days by default. A click outside the window is not counted. WooCommerce may still show the ad as the order's origin, because its attribution is configured independently of the platform's window.
• A click ID, and a click date inside the window. Attribution had everything it needed. If the platform still reports nothing for that order, the cause is further downstream: a blocked request in the customer's browser, a competing tag writing to the same conversion ID, or the platform's own attribution model. Start with what the order list checkmark does and does not prove.

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%)
  of those, not storefront orders: 3 (75%)
Not from the storefront checkout:  3 (8%)
Click IDs by key:                  gclid 26
Order origin (created_via):
  checkout:                        36 (storefront)
  rest-api:                        2
  admin:                           1
Capture layer (per click ID):
  platform_cookie:                 21
  pmw_cookie:                      5
Capture point (per click ID):
  order_created via wc-ajax:checkout: 26

The of those, not storefront orders, Not from the storefront checkout and Order origin (created_via) lines are new in version 1.67.1.

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.
• of those, not storefront orders is the part of that number that was never going to have a browser event in the first place, because the order was not placed through your checkout. A high missed count made up almost entirely of these is normal, not a broken pixel.
• Not from the storefront checkout is the same idea across all scanned orders. Orders that WooCommerce recorded no origin for are not counted here, since an unrecorded origin proves nothing either way.
• Click IDs by key shows which platforms are actually delivering clicks.
• Order origin (created_via) breaks the scanned orders down by what created them. checkout is the classic checkout and store-api is the block checkout, and both are marked (storefront). Everything else, for example rest-api, admin or a subscription renewal, arrives without a browser. These orders still send server-side purchase events, which is why an ad platform can show far more server events than browser events on shops that sell through integrations.
• 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.
• Do your orders come from the storefront at all? Check Not from the storefront checkout and the Order origin breakdown. An order created by an integration, in the admin, or as a subscription renewal has no browser visit behind it, so it can never carry a click ID. On a shop where most orders arrive that way, a low overall rate is arithmetic rather than a fault.
• 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.