Analytics
Why Did My UTM Disappear Before Checkout? Redirects and Tracking Explained

Your UTM tag can get silently stripped by a redirect, link shortener, or cloaking script before the visitor ever reaches your checkout page — and when that happens, GA4 shows nothing even though the traffic delivered just fine. This is one of the most common reasons buyers think an order “didn’t work” when in reality the visits arrived, the redirect just dropped the tracking parameters along the way.
Why does my UTM disappear before checkout?
Because most redirects weren’t built with attribution in mind. A 301 redirect, a link shortener, or a cloaking layer is designed to move a visitor from point A to point B as fast as possible — not to carefully pass every query string along for the ride. Some redirect types rewrite the destination URL entirely, some truncate parameters after a certain length, and some simply forward the base path and drop everything after the question mark. The visitor still lands on your page. Your GA4 just never sees the utm_source=netotraffic that proves where they came from.
What actually strips a UTM tag mid-redirect?
Several common setups are guilty of this, usually without anyone noticing until someone goes looking. The usual suspects:
- Link shorteners that generate a new short URL and don’t forward query parameters by default (you often have to enable “pass-through” manually).
- 301/302 redirects set up in .htaccess or a CDN rule that redirect to a static path instead of appending the original query string.
- Cloaking or landing-page builders that swap the visible URL for a “clean” one and lose the UTM in the process.
- Multi-step funnels (ad click → lander → opt-in → checkout) where each hop is a chance for the tag to get dropped, especially if different tools or platforms handle each step.
- Caching plugins or page builders that serve a cached version of the checkout page without re-reading the current query string.
None of this means the traffic itself was bad. It means the plumbing between the click and the checkout page has a leak, and the leak happens to be exactly where your attribution data lives.
How do I test a redirect chain before scaling an order?
Test it manually before you put real budget behind it. A five-minute check now saves you a confusing GA4 report later. Here’s the checklist:
- Build the full URL with the UTM attached — e.g.
yoursite.com/landing?utm_source=netotraffic&utm_medium=native&utm_campaign=test— and open it in an incognito window. - Watch the address bar at every hop. If you’re using a shortener or a redirect rule, click through and note the URL at each stage: does the UTM string survive, change, or vanish?
- Check the final checkout URL. If it loads without the UTM string visible, your tag didn’t make it — even if the page itself looks correct.
- Use GA4’s DebugView or Realtime report while you do this test click. If the session shows up with
source/medium = netotraffic / native, the chain is clean. If it shows up as Direct or (none), something along the way stripped it. - Test on mobile and desktop separately. Some redirect rules behave differently by device, especially with app-based cloaking or mobile-specific landers.
- Repeat after any site change. New caching plugin, new page builder, new CDN rule — any of these can quietly break a redirect chain that worked fine last month.
If you’re running native ads specifically because you want GA4-visible attribution, this test matters more than almost anything else in the setup. Order your native ads traffic with a landing URL that keeps the UTM intact end to end, and you’ll actually see the sessions land where you expect them.
What should I expect in the stats panel vs GA4 after fixing redirects?
Fixing the redirect chain closes the attribution gap, but it won’t make the two numbers match exactly — and that’s normal, not a bug. The stats panel counts unique IPs delivered to your URL. GA4 counts sessions based on browser behavior: cookies, consent settings, ad blockers, and bot filtering all affect what actually gets logged on the GA4 side. Even with a perfectly clean redirect chain, you should expect GA4 sessions to run lower than panel unique IPs. What a clean redirect buys you is correct source/medium attribution for the sessions that do get logged — instead of everything dumping into Direct or (none) because the tag got lost along the way.
This is really the same mismatch we cover in our breakdown of how to filter Netotraffic visits in GA4: panel and GA4 measure different things, and a broken redirect just adds a second, avoidable layer of confusion on top of that expected gap.
Does this apply to banner or display orders too?
Less directly, but it’s worth knowing the difference. Banner and website ads traffic is measured by delivery volume and unique IPs in the stats panel — GA4 is often weak or missing a referrer for this traffic type regardless of redirect hygiene, because display clicks don’t always carry a clean referring URL in the first place. If you need to confirm delivery on a banner order, a shortener like cutt.ly or bitly (used as your own click-tracking layer, not as part of the ad network’s redirect) is the simplest add-on. Native and GA-visible traffic is the type where redirect chain hygiene actually changes your GA4 numbers.
Quick comparison: redirect-safe setup vs leaky setup
| Setup | What happens to the UTM | What you’ll see in GA4 |
|---|---|---|
| Direct link, no redirect | UTM passes through untouched | Source/medium correctly shows netotraffic / native |
| 301 redirect with query forwarding enabled | UTM preserved if rule is configured correctly | Correct attribution, matches test click |
| Link shortener, pass-through off | UTM stripped at the shortener | Session shows as Direct or (none) |
| Cloaking script / multi-step funnel | UTM often lost at one of the hops | Inconsistent attribution, hard to debug |
| Cached checkout page | Stale query string or none at all | Session may not register the campaign at all |
Still have questions about redirects and UTMs?
Does a stripped UTM mean the traffic didn’t deliver?
No. The stats panel still shows the delivered unique IPs regardless of what GA4 reports. A stripped UTM is a tracking problem on the landing page side, not a delivery problem on the order side.
Can I fix a redirect issue without touching the ad order?
Yes, in almost every case. The fix usually lives in your redirect rule, link shortener settings, or page builder configuration — not in the traffic order itself. Test the chain, fix the leak, and the next batch of traffic will attribute correctly.
Why does GA4 show Direct instead of netotraffic even with a UTM?
This almost always means the UTM string didn’t survive one of the hops between the ad click and the final page load. Walk through the redirect chain manually using the checklist above to find where it drops.
Should every landing page use the same UTM structure?
Keep it consistent across campaigns so you can compare apples to apples in GA4 later. Changing utm_source or utm_medium naming between orders makes it harder to track performance trends over time.
Do I need to re-test the redirect chain for every new order?
Only if something on your site has changed — a new caching plugin, CDN rule, or page builder update. Otherwise, one clean test per funnel setup is usually enough before scaling.
