Why do my UTM parameters disappear at checkout?
UTMs live in the URL, and the URL changes several times between landing and purchase — a redirect to a canonical domain, a hop to a hosted checkout, a return from a payment provider. Each one can drop the query string. The fix is not to try to carry the parameters through every hop but to read them once on arrival, store them in a first-party cookie, and attach them to the order from that store when the purchase is created.
Free30 minutesNo obligation
UTMs disappear at checkout · what breaks
What this looks like when it's happening to you — UTMs disappear at checkout
- 01
Campaign data present on landing, gone at purchase
Visible if you watch the URL through the funnel.
- 02
Orders attributed to direct
The campaign that earned them loses credit.
- 03
Attribution working on-site and failing at checkout
Which isolates it to the hosted checkout hop.
UTMs disappear at checkout · the fix
What changes once it's fixed — UTMs disappear at checkout
Campaign data attached to the order
Read once at landing and stored, not carried through hops.
Attribution surviving every redirect
Because it no longer depends on the URL.
Reliable channel reporting
Which is what the UTMs were for.
UTMs disappear at checkout · architecture
Why your conversion data was wrong in the first place — UTMs disappear 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 utms disappear 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.
UTMs disappear at checkout · normal or broken
Some of this is supposed to happen — UTMs disappear 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
UTMs not visible in the URL after navigation
Expected. What matters is whether they were captured before they vanished.
Organic and direct sessions having none
Correct.
Actually broken
A redirect dropping the query string
www-to-apex, http-to-https, or a locale redirect.
Hosted checkout on another domain
Parameters don't cross by default.
Stored in session storage only
Lost when the tab closes or the domain changes.
Overwritten by a later internal referrer
Last-touch logic replacing the original campaign.
UTMs disappear at checkout · diagnose
How we find out why do my utm parameters disappear 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 a tagged link and watch the URL through every hop
The parameters usually disappear at one identifiable step.
- 02
Check where they're stored after landing
Cookie with a lifetime, or session storage that won't survive?
- 03
Check whether the order record has campaign fields at all
Many don't.
- 04
Test through the hosted checkout specifically
That hop is the usual culprit.
- 05
Check whether internal navigation overwrites the stored value
First-touch should win for acquisition reporting.
UTMs disappear at checkout · prove
How we prove it's actually fixed — UTMs disappear at checkout
The tag firing again proves the tag fires. These prove the numbers are right.
Source of truth
The campaign recorded on the order itself
- Campaign data present on the order record after a real tagged purchase.
- Parameters confirmed captured before the first redirect.
- Storage confirmed as a first-party cookie outliving the session.
- Reconciled against the campaign recorded on the order itself 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.
UTMs disappear at checkout · free audit
What we check in the free audit
- Click a tagged link and watch the URL through every hop
- Check where they're stored after landing
- Check whether the order record has campaign fields at all
- Test through the hosted checkout specifically
- Check whether internal navigation overwrites the stored value
Checked against
The campaign recorded on the order itself
Free30 minutesNo obligation
UTMs disappear at checkout · when not to buy
When you don't need us for this — UTMs disappear at checkout
Most of these you can do yourself, and we would rather you did.
- Your checkout is on the same domain with no redirects and attribution already works.
- You can add the capture script at landing yourself — that's most of the fix.
- You rely on platform click IDs rather than UTMs for paid attribution.
UTMs disappear at checkout · what we deliver
What we do about it — UTMs disappear at checkout
Read once at first touch
Parse the landing URL immediately, before any redirect.
Store first-party
A cookie with a real lifetime, not session storage.
Attach to the order at creation
So the campaign is recorded on the order itself.
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
UTMs disappear at checkout questions, answered
It's fragile. Reading them once and storing them first-party is far more reliable than trying to preserve them across every hop.
For acquisition reporting, first touch — you want the campaign that introduced the customer, not the last internal page.
The click IDs handle paid attribution. UTMs matter for email, affiliate, partner and organic-social traffic, where no click ID exists.
At least your median consideration period. Anything shorter loses the customers who take time to decide.
Free · 30 min
Get utms disappear at checkout diagnosed properly
Free30 minutesNo obligation
