Why are my UTM parameters lost at checkout?
UTM parameters and click identifiers live in the landing page URL, and almost nothing carries them forward on its own. They are lost when checkout moves to another domain, when a redirect drops the query string, when a customer browses several pages before converting, and when a cookie set on the first visit expires before the purchase. The consequence is worse than losing campaign labels: the same mechanism loses the click identifier, which is what every ad platform needs to attribute the sale. The fix is to capture the parameters once on arrival and persist them server-side against your own record, rather than hoping the browser carries them to the end.
Free30 minutesNo obligation
UTM parameters lost at checkout · what breaks
What this looks like when it's happening to you — UTM parameters lost at checkout
- 01
Orders attributed to direct or none when you know they came from ads
The most common presentation, and the most misleading — it makes paid channels look like they produced nothing.
- 02
Campaign labels present on the landing page and absent on the order
Confirms the loss happens between arrival and conversion rather than at arrival.
- 03
Attribution that works on desktop and fails on Safari
A cookie-lifetime problem rather than a parameter problem.
- 04
Everything working in testing and failing in production
Testers convert in one session, in one tab, immediately. Customers do not.
UTM parameters lost at checkout · the fix
What changes once it's fixed — UTM parameters lost at checkout
Parameters captured once, on arrival
Before anything can strip them, and stored somewhere that is not the URL.
Persisted against your own record
Server-side, so the browser's storage rules stop being the constraint.
Surviving the checkout domain hop
Carried into the order through a mechanism the platform actually supports, not through a cookie that cannot cross origins.
Attribution that holds across sessions
A customer who lands today and buys on Thursday is still attributed, because the identifier lives on your record rather than in their browser.
UTM parameters lost at checkout · architecture
Why your conversion data was wrong in the first place — UTM parameters lost at checkout
Fixing this specific fault is worth doing. But it is worth understanding why it happened, because the same underlying weakness produces a different symptom every few months — and the reason your conversion data is wrong is almost never the tag itself.
- 1
Your conversion depends on a browser that is being restricted on purpose
A browser-side tag has to survive the page loading, the visitor staying, the script executing and the request leaving. Every one of those is now contested. The order in your database is certain; the browser event reporting it is not, and that gap is where wrong numbers come from.
- 2
Safari caps the cookie your attribution depends on
Intelligent Tracking Prevention limits cookies written by JavaScript to seven days, whatever expiry you set. Any customer who takes longer than a week to decide comes back as a stranger, so the sale is recorded and credited to nobody. A cookie your own server writes in an HTTP response is not subject to that cap — which is the single largest practical difference between browser-side and first-party server-side tracking.
- 3
Ad blockers remove the tag before it can run
A blocked pixel does not error, retry or warn anyone. The visitor buys, the order lands in your store, and no platform ever hears about it. First-party events sent from your own subdomain aren't filtered the same way, because they are not a third-party request.
- 4
Consent banners stop tags, sometimes when they didn't need to
Where consent is genuinely required, losing the event is correct. What is not correct — and what we find repeatedly on US-majority accounts — is an EU-style prior-consent banner applied to every visitor, discarding conversions no law asked you to discard. A server container enforces the real decision at the container rather than hoping each vendor script honours a flag.
- 5
The checkout can end somewhere your tag isn't
Wallets and hosted payment pages can be abandoned after the money moves. The customer paid; the confirmation page never rendered; the browser event never fired. Sending the purchase from the order record instead means the conversion arrives whether or not anyone came back to your site.
- 6
What that adds up to
Each of these is a separate route to utm parameters lost at checkout, and they compound. First-party server-side tracking doesn't patch them one at a time — it moves the money event off the browser entirely, so the order in your backend is what gets reported. That is why we reconcile against your own order records and put 95%+ accuracy in writing: with the event sourced from the order, the number is checkable rather than hopeful.
UTM parameters lost at checkout · normal or broken
Some of this is supposed to happen — UTM parameters lost at checkout
Half the time nothing is broken and the number is being read wrong. Knowing which is which stops you paying to fix something that was never a fault.
Normal, not a fault
Working
The click identifier is on the order record for the large majority of orders, including ones placed days later and on other pages.
Broken
Present only when the customer converts immediately from the landing page, which is a small minority of real purchases.
Broken and flattering
Testing always passes because testers convert instantly, so the problem is invisible to the person checking.
Actually broken
Checkout on a different origin
The single largest cause. Hosted checkouts do not receive your first-party cookies, so nothing crosses on its own.
Redirects dropping the query string
A vanity URL, a language redirect, a trailing-slash rule — each can silently remove everything after the question mark.
Cookie lifetime shorter than the purchase cycle
Safari's cap on script-set cookies is well under the consideration window of most considered purchases.
Multi-page browsing before conversion
The parameters were on the landing page and the customer converted from a page reached five clicks later.
Script blocked before it could capture
Consent tooling and ad blockers both prevent capture entirely, which is different from losing it later and needs a different fix.
UTM parameters lost at checkout · diagnose
How we find out why are my utm parameters lost at checkout
Always in this order. Each step eliminates a class of cause, so by the last one there is usually a single explanation standing.
- 01
Click your own ad and complete a purchase, then read the order record
Is the parameter there? One test answers the whole question.
- 02
Repeat, but browse four or five pages first
Most setups pass the direct test and fail this one, which is why the problem reaches production.
- 03
Repeat in Safari
Cookie-lifetime problems only appear on the browsers that enforce short lifetimes.
- 04
Check every redirect between the ad and the landing page
Watch the query string through each hop and note where it disappears.
- 05
Count what share of recent orders carry any parameter at all
That percentage is the real state of your attribution, and it is usually lower than anyone expects.
- 06
Test with a consent banner set to reject
If capture depends on a script that consent blocks, coverage will be much worse than your own testing suggests.
UTM parameters lost at checkout · prove
How we prove it's actually fixed — UTM parameters lost at checkout
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
Your own order records, counted for the presence of a click identifier
- A purchase completed after browsing several pages, with the identifier confirmed on the resulting order.
- Identifier coverage measured across the last hundred orders, before and after the fix.
- Reconciled against your own order records, counted for the presence of a click identifier for a fully closed window, matched on ID rather than on totals.
- No record counted twice, checked across the whole window rather than spot-checked.
- The same check repeated 30 days later, because a fix that holds once and drifts is the harder failure to catch.
UTM parameters lost at checkout · free audit
What we check in the free audit
- Click your own ad and complete a purchase, then read the order record
- Repeat, but browse four or five pages first
- Repeat in Safari
- Check every redirect between the ad and the landing page
- Count what share of recent orders carry any parameter at all
- Test with a consent banner set to reject
Checked against
Your own order records, counted for the presence of a click identifier
Free30 minutesNo obligation
UTM parameters lost at checkout · when not to buy
When you don't need us for this — UTM parameters lost at checkout
Most of these you can do yourself, and we would rather you did.
- Pull your last hundred orders and count how many carry a click identifier. That number is your attribution ceiling.
- Click your own ad, browse five pages, then buy. Check the order. This single test finds most of these problems.
- Follow the query string through every redirect between your ad and your landing page — one of them is often eating it.
UTM parameters lost at checkout · what we deliver
What we do about it — UTM parameters lost at checkout
Capture on arrival and store immediately
Server-side or in a first-party cookie written by your server, not by a script that may be blocked.
Carry the value into the order record through a supported field
A cart attribute, an order note, order metadata, a hidden form field — whichever your platform actually offers.
Stop relying on the URL after the first page
Any redirect, any link without the query string, and it is gone.
Check what redirects do to the query string
Marketing redirects and vanity URLs strip parameters more often than anyone expects.
Pricing
Pick the package that fits your ad spend
Browser-side starter
$400One-time fee · lifetime ownership
We fix the fault in your existing browser-side setup and verify it on a live transaction. Honest disclosure: this repairs what you have, it does not make it durable. If you spend $1K+/month on paid media, the fault will recur the next time Safari, a consent banner or a checkout change moves under you — the server-side tier is what stops that.
- Root cause found and fixed, not worked around
- Verified on a live transaction, not in preview
- Reconciled against your own order records
- Written handover documenting what changed and why
1st-party server-side
Recommended$800One-time fee · most popular
The tier that removes the whole class of failure rather than this instance of it. Your money events stop depending on the browser: they are sent from your order records through a first-party server container on your own subdomain, so iOS, ad blockers, consent banners and interrupted payment redirects can no longer take them away. Built in 2–4 days. You own the stack outright — no monthly SaaS.
- First-party server container on your own subdomain
- Purchases sent from your order records, not the browser
- Meta, Google, TikTok, Microsoft and LinkedIn all fed server-side
- Deduplicated on a shared event ID, verified at every destination
- First-party cookies beyond Safari's 7-day cap on JavaScript-set cookies
- 95%+ conversion accuracy and 8+ Meta EMQ, guaranteed in writing
Full 1st-party stack
$1,800One-time fee · lifetime ownership
Every paid-media channel server-side, end to end, plus the offline loop. For advertisers whose spend makes an attribution leak more expensive than the build. Pay once, own everything.
- Everything in 1st-party server-side
- Pinterest, Snapchat, Reddit and LinkedIn CAPI
- CRM and offline conversion loop, so closed revenue reaches bidding
- Refunds and cancellations reversed at every destination
- Klaviyo identity stitching, BigQuery and Looker Studio
- Monitoring, so the next break surfaces in days rather than a quarter
FAQ
UTM parameters lost at checkout questions, answered
Sometimes, and it is fragile. It depends on every link preserving the query string, it breaks the moment a customer navigates in a way you did not anticipate, and it puts campaign data into URLs that get shared and indexed. Capturing once and storing server-side avoids all of that.
The click identifier is what ad platforms need for attribution, so it is the one that affects your bidding. UTMs matter for your own analytics and for channels with no click identifier. Both are lost by the same mechanism, so fixing it fixes both.
Because testers convert immediately, in one session, in one tab, with no consent banner and no ad blocker. Real customers browse, leave, come back on a different device, and reject cookies. Always test the multi-page, multi-day path.
Write the identifier to a cart attribute on the storefront, which becomes an order note attribute you can read back server-side. That path survives the domain hop because it travels with the cart rather than with the browser.
Free · 30 min
Get utm parameters lost at checkout diagnosed properly
WhatsAppFree30 minutesNo obligation
