How to Check Whether Your Ad Click IDs Survive the Trip to Your Shopify Orders

|Dan Giura
How to Check Whether Your Ad Click IDs Survive the Trip to Your Shopify Orders

TL;DR

Each ad platform tags its clicks with its own identifier. Google uses gclid (plus two braid variants), Meta fbclid, and the rest ttclid, rdt_cid, epik, ScCid and OpenAI's oppref. If that parameter falls off before your store loads, the order can't recover it. Shopify has no per-order view of click IDs, so the audit that works tests the URL and samples orders. WeltPixel Conversion Tracking reads a missed click ID back out of the order's landing URL for its seven ad platforms, with a catch on Google Ads and never for GA4. Safari matters less here in 2026 than many 2026 posts claim.

Key Takeaways

  • Test each live ad's final URL with ?gclid=TEST168 (or &gclid=TEST168 after existing UTMs) in an ordinary browser window. If the parameter is gone when the page settles, the redirect that removed it is your first fix.
  • Shopify's order export has no landing-site or UTM column [5]; per order, Conversion summary → View conversion details shows landing pages and UTM parameters [4].
  • With "Import all events that have user-provided data, even those without GCLID" off, which is the default, every order the app shows as Sent to Google Ads went up with a Google click ID.
  • A missed click ID is recovered from the order's landing URL for Meta, TikTok, Reddit, Pinterest, Snapchat and OpenAI Ads; for Google Ads only when the browser caught none of its three IDs; for GA4 never.
  • Never place a test order on a made-up click ID. Google refuses an unparseable one, so the test proves nothing.

Which click ID does each destination actually get?

Each destination has its own identifier, and the app sends it with the server-side purchase whenever it has one. When the browser missed it, the landing URL Shopify recorded on the order is the backup, with three exceptions.

Destination Click identifier it receives Recovered from the order's landing URL if the browser missed it?
Google Ads gclid, gbraid or wbraid [2]: an in-window gclid plus at most one braid, never both braids Only when the browser captured none of the three
GA4 gclid, as a purchase parameter No
Meta fbc, built from fbclid Yes, in the fbc format Meta documents [1]
TikTok ttclid Yes
Reddit rdt_cid Yes
Pinterest epik Yes
Snapchat ScCid Yes for ScCid; Snapchat's browser cookie has no URL equivalent
OpenAI Ads oppref, plus the browser reference obref Yes for oppref; never for obref
Klaviyo _kx, an identity link rather than an ad click ID Yes

A value the browser captured always wins, and the landing URL only fills a gap. Google Ads is all or nothing: if the browser caught any of gclid, gbraid or wbraid, the app adds nothing from the URL, and a click older than your conversion action's click-through window is dropped before upload rather than sent for Google to reject. The recovery also runs for the server-side purchase only, when it's sent, so browser events earlier in the funnel keep whatever the browser saw.

When does the browser miss one? An ad blocker that stops the pixel is one common case. Snap's own description of ScCid shows why the URL works as a backup: it's "the ID value stored in the landing page URL's &ScCid= query parameter" [3]. If the parameter reached the landing page, the order still carries it.

If you run Microsoft Ads, msclkid isn't in the table because the app doesn't send to Microsoft Ads. Google's definitions of gbraid and wbraid, and why UTM tags can't be recovered the same way, are in our UTM tagging rules.

What a Shopify order will and won't tell you

Nowhere in the Shopify admin can you read the click ID itself.

The order export's only attribution-style column is Source, described as the order's source, "for example, web, draft order, POS" [5]. There's no landing site, referrer or UTM column. On a single order, the Conversion summary's View conversion details lists each session's referral, landing page and UTM parameters [4]. Shopify doesn't document click identifiers there. Details can take up to 48 hours to appear, and draft orders have no summary [4].

The API route is narrowing. Shopify's legacy REST order object still carries the landing site with its query string (the documentation's example is "landing_site": "http://www.example.com?source=abc"), but "The REST Admin API is a legacy API as of October 1, 2024" [6]. On the GraphQL Order object, landingPageUrl and referrerUrl are marked Deprecated [7]. That landing site is Shopify's own attribution field, covered in our piece on Shopify's attribution cookies.

The app doesn't fill the gap either: the click IDs it captures aren't readable on the order, and its dashboard doesn't list them.

How do you test whether a click ID survives your redirects?

Open the landing URL your ads actually use, with test parameters added, and see what's left once the page loads:

  1. Copy the final URL of a live ad from each platform you run, UTM tags included.
  2. Add test click parameters to the end. Use ? if the URL has no query string yet and & if it does:
https://yourstore.com/products/linen-shirt?utm_source=meta&utm_campaign=fall&fbclid=TEST168&gclid=TEST168&ttclid=TEST168&ScCid=TEST168
  1. Open it in an ordinary window, on desktop and then on a phone. Skip Safari Private Browsing, which strips known tracking parameters on purpose [9].
  2. When the page settles, read the address bar. Every parameter you added should still be there, with its exact case. Meta asks that the click ID's case not be changed [1].
  3. If something's missing, find the hop that dropped it: in Chrome, open DevTools → Network, tick Preserve log, and load the URL again. Each redirect shows as a 3xx line (301, 302 and so on) with its destination.
  4. Repeat for every variant your ads land on: each market or country redirect (test from the country you target), your non-www and myshopify domains, shortened links, and any page built in a landing-page tool or quiz.

When the break sits in an external funnel or a chain of domains, our cross-domain tracking guide covers the fix. The full list of reasons a gclid goes missing, auto-tagging switched off included, is in our no-gclid guide.

Test visits with a fake gclid may show up in GA4 as paid traffic, so run them from a network your internal-traffic filter excludes if that matters.

Stop at the page. Don't place an order on a made-up click ID. Google refuses an unparseable one, so the order tells you nothing the address bar didn't.

Sample the paid orders, then read one number in the app

The URL test proves the path works. The sample shows whether real orders kept their clicks.

  1. In Shopify admin, go to Orders and take up to 20 online-store orders placed 3 to 7 days ago, old enough for the summary [4] and inside the card's 7-day window.
  2. On each, open Conversion summary → View conversion details and note the visit's source and UTM parameters [4]. Mark it by paid platform, or none. This relies on UTM tags on your ad URLs, since Shopify doesn't document click IDs there [4].
  3. In the app, open the home page's Conversion tracking card. It shows the last 7 days per destination: Sent (as sent out of attempted), Skipped, and Accuracy.

Google Ads is the one row on that card that measures click IDs. With "Import all events that have user-provided data, even those without GCLID" off, the app uploads only orders that carry a usable Google click ID, so every Sent order had one. Everything else lands in Skipped: organic and email orders, clicks older than the conversion window, clicks Google refuses as stale, unparseable or from another account, and any admin orders you exclude. Skipped is a ceiling on clickless orders, and Sent counts the orders that kept a usable Google click all the way through and were accepted.

Run the comparison on an illustrative store. Nine of the 20 sampled orders (45%) show a Google Ads visit inside the conversion window, but Google Ads Sent, at 100% accuracy, is only 20% of the week's orders (attempted plus skipped). More than half the Google-clicked orders weren't sent with a usable click ID, and the URL test is where to look next. A sample of 20 is noisy, so treat a gap of one or two orders as nothing.

You've probably had the week where Shopify credits Google with a dozen orders and Google Ads shows four. This is how you find out whether the click IDs or the attribution models are to blame.

The other six ad platforms don't give you that number: the app sends their purchases with or without a click ID, since they also match on hashed customer data, so the order sample is your gauge there. How Meta weighs a purchase that arrives without fbc is in our Meta match quality piece, and the card's limits as an alarm are in our tracking alerts guide. Orders with no paid visit at all are a different problem, covered in why Shopify marks logged-in and cross-device orders as Direct.

Is Safari stripping click IDs in 2026?

In specific places, by Apple's own account, and fewer of them than the 2026 warnings suggest.

Apple announced Link Tracking Protection on June 5, 2023: tracking information "will be removed from the links users share in Messages and Mail", and "will also be removed from links in Safari Private Browsing" [8]. WebKit's "Private Browsing 2.0" post (July 16, 2024) says Safari "removes a subset of query parameters that have been identified as being used for pervasive cross-site tracking granular to users or clicks" in Private Browsing. For regular browsing, the user has to turn it on under Settings > Apps > Safari > Advanced > Advanced Tracking and Fingerprinting Protection, set to "All Browsing" [9].

Safari 26 changed something different. WebKit's June 9, 2025 post: "Safari prevents known fingerprinting scripts from reading state that could be used for navigational tracking, such as query parameters and document.referrer" [10]. That limits what those scripts can read, and says nothing about removing click IDs from the address in normal browsing. An independent Mac developer's reading of Safari 26 (lapcatsoftware.com, September 2025) is that the default for that protection is still Private Browsing and "has not changed since Safari 18" [11].

Plenty of 2026 posts say iOS 26 strips gclid and fbclid from all Safari browsing by default. None of Apple's or WebKit's own pages we read say that, and we found no published share of Safari traffic affected.

The Messages case is arguably a favour. A friend who opens your product from a shared link never clicked your ad.

Where a parameter is stripped before the page loads, it's missing from the landing URL Shopify records too, so no recovery from the order can bring it back. What's left is matching on customer data, which Meta, TikTok, Reddit, Pinterest, Snapchat and OpenAI Ads already receive with the purchase. For Google Ads, that path needs the no-gclid import covered in the guide linked above. Cookie lifetimes under Safari's tracking prevention are a separate limit, explained in our iOS tracking piece.

FAQ

Does Safari remove gclid and fbclid in 2026?

Apple says tracking information is removed from links shared in Messages and Mail and from links in Private Browsing [8][9], without naming which parameters. In normal browsing, only when the user sets Advanced Tracking and Fingerprinting Protection to All Browsing [9].

Is GA4's gclid recovered from the landing URL too?

No. GA4's purchase carries gclid only when the browser captured it. The recovery covers the seven ad platforms and Klaviyo.

Why does Google Ads show so many skipped orders in the app?

With the no-gclid import off, every order without a usable Google click ID is skipped, and on most stores that includes every organic, email and social order. Failures show separately, as the gap between sent and attempted.

Recover the clicks the order still carries

WeltPixel Conversion Tracking captures each destination's click ID in the browser and, for the server-side purchase, reads a missed one back out of the order's landing URL on all seven ad platforms it sends to (for Google Ads, when the browser caught none of its three IDs). GA4 is on the free plan. Google Ads, Meta, TikTok, Reddit, Pinterest, Snapchat, OpenAI Ads and Klaviyo come with Plus at $39/month [12].

Sources

  1. Meta for Developers, Conversions API, "fbp and fbc parameters", developers.facebook.com/docs/marketing-api/conversions-api/parameters/fbp-and-fbc, accessed October 6, 2026
  2. Google Ads API reference, ClickConversion (v25), developers.google.com/google-ads/api/reference/rpc/v25/ClickConversion, accessed October 6, 2026
  3. Snap for Developers, Conversions API "Parameters" (sc_click_id), developers.snap.com/api/marketing-api/Conversions-API/Parameters, accessed October 6, 2026
  4. Shopify Help Center, "Conversion summary", help.shopify.com/en/manual/fulfillment/managing-orders/analytics/conversion-summary, accessed October 6, 2026
  5. Shopify Help Center, "Exporting orders", help.shopify.com/en/manual/fulfillment/managing-orders/exporting-orders, accessed October 6, 2026
  6. Shopify developer documentation, REST Admin API "Order" resource, shopify.dev/docs/api/admin-rest/latest/resources/order, accessed October 6, 2026
  7. Shopify developer documentation, GraphQL Admin API Order object, shopify.dev/docs/api/admin-graphql/latest/objects/Order, accessed October 6, 2026
  8. Apple Newsroom, "Apple announces powerful new privacy and security features", June 5, 2023, apple.com/newsroom/2023/06/apple-announces-powerful-new-privacy-and-security-features/, accessed October 6, 2026
  9. WebKit blog, "Private Browsing 2.0", July 16, 2024, webkit.org/blog/15697/private-browsing-2-0/, accessed October 6, 2026
  10. WebKit blog, "News from WWDC25: Web technology coming this fall in Safari 26 beta", June 9, 2025, webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/, accessed October 6, 2026
  11. Lapcat Software, on the Safari 26 tracking protection default, September 2025, lapcatsoftware.com/articles/2025/9/4.html, accessed October 6, 2026
  12. WeltPixel Conversion Tracking, Shopify App Store listing, apps.shopify.com/weltpixel-conversion-tracking, accessed October 6, 2026

Ready to upgrade your tracking?

Server-side tracking for Magento and Shopify — accurate data, better attribution, full privacy compliance.