To verify UTM persistence, run a controlled test from a uniquely tagged ad URL through the exact conversion path, then inspect the landing-page URL, browser storage, form or checkout payload, and final CRM or order record. If the values disappear, the first checkpoint where they are missing tells you where tracking broke. GA4 sessions or ad clicks alone do not prove that campaign data reached the lead, sale, or report your team relies on. A passing test means the expected campaign values are available where decisions are made: in the form submission, CRM contact or deal, ecommerce order, or reporting system. The UTMs do not need to remain visible in every URL. Many sites remove them after storing them; what matters is that they were captured, retained for the required period, and assigned under your documented first-touch or last-touch rules. Treat this as a trace exercise, not a dashboard exercise. Start with a known link, record each handoff, and you can usually locate the break instead of guessing which platform is at fault.
What should still be true after someone clicks your tagged link?
Seeing UTMs in the address bar after an ad click is only the first check. A pass means the expected campaign information survives the visitor journey and appears in the system your team uses to evaluate campaign performance.
Before testing, write down the values you expect to retain. For a paid social test, that might be utm_source=linkedin, utm_medium=paid_social, utm_campaign=demo_test_sep, utm_content=carousel_a, and a platform click ID if you capture one. Record the values exactly. Capitalization, underscores, and naming differences can cause a correct-looking result to fail your reporting rules.
Define what “survives” means in your setup. Valid patterns include:
- UTMs remain in the URL until conversion.
- The site reads UTMs on arrival, stores them in a cookie or browser storage, and removes them from later URLs.
- A form copies stored values into hidden fields on submission.
- A CRM integration sets source properties from the form payload or its own tracking cookie.
- An ecommerce platform attaches attribution information to the order after checkout.
A later page without utm_source is not automatically a failure. It is a failure when a qualified lead or order cannot be connected to the intended campaign under your agreed rules.
Be equally clear about attribution. Under first touch, a returning visitor who originally arrived from organic search remains attributed to organic even if they later click a paid ad. Under last touch, the paid campaign might replace the prior source. Neither model is inherently better, but an undocumented mix of the two creates confusion.
A useful pass statement is: “A new visitor arriving through this test URL and submitting the demo form should create a CRM contact with the raw UTM values, first-touch source of linkedin / paid_social, and last-touch source of linkedin / paid_social.” That gives the test a concrete expected result.
Start with one clean test link and a test conversion
Create a test link that is distinctive enough to find in every system later. Do not use a live campaign URL that real visitors are also using; you need a trail that belongs only to your test.
For example:
https://example.com/demo?utm_source=test_linkedin&utm_medium=paid_social&utm_campaign=utm_persistence_check&utm_content=sept_test_01
The names are not special. They simply need to be easy to recognize in browser tools, form payloads, CRM properties, and reports. Keep values simple. Spaces, special characters, inconsistent casing, and duplicate parameters make diagnosis harder.
Open a private browsing window or clear relevant site data before you begin. Existing cookies can make a broken implementation look healthy. If you visited through an email campaign last week, a first-touch cookie could still identify you as email even when the new test link is working correctly. A fresh browser profile is better if you have one.
Complete the same conversion path a real visitor would follow. Do not jump from the landing page to a form preview or CRM test screen. Use the same calls to action, scheduling tool or checkout, and confirmation flow. Submit with a dedicated test email address such as campaign-test+sept01@yourdomain.com. For ecommerce, use a test payment method or a low-risk internal test process approved by your team.
Record:
- The full original URL.
- The date and time, including timezone.
- Browser and device.
- Consent choice.
- Pages and external domains visited.
- Test email address, booking reference, or order reference.
Start with the standard path, then use it as your baseline for return visits, delayed conversions, and cross-domain journeys. The first test answers a narrow but useful question: can a new visitor following the intended route be attributed correctly at all?
Check whether the UTMs are still in the landing-page URL
Your first checkpoint is the landing page. After clicking the tagged link, inspect the full address bar and confirm that every expected parameter arrived with an unchanged value.
This catches failures before your site can store anything. Ad platforms can use tracking templates, click trackers, or redirect links. Link shorteners can drop parameters when configured poorly. Server-side redirects are another common culprit, especially when a campaign points to a non-www domain, an HTTP URL, a locale-specific page, or a URL that forces a trailing slash.
For example, the original URL might contain utm_campaign=utm_persistence_check, but a redirect leaves only utm_source and utm_medium. The break occurred before the page loaded. Review redirect rules, link-template settings, and any redirect service between the ad and landing page.
If the redirect is too quick to inspect, use browser developer tools. In the Network panel, enable “Preserve log,” then reload or repeat the click. Review the chain of document requests and the Location response headers to find the redirect that dropped or rewrote a parameter.
UTMs do not have to remain in the URL after the landing page. A site can read them, store them, and clean the URL for usability or to avoid visitors copying long campaign links. Check what happened before the URL changed: were the values captured?
If UTMs disappear on the first landing-page request and you cannot find them in storage or the initial analytics request, treat that as a likely issue. A later form cannot reliably recover parameters it never received. Fix this earliest break before investigating downstream systems.
See what your browser actually stores after the click
After the landing page loads, inspect what the browser retained. This shows whether the site has a persistence mechanism beyond the current URL.
In Chrome-based browsers, open Developer Tools and go to Application. Under Storage, review Cookies, Local Storage, and Session Storage for your site. Firefox and Safari have similar inspection tools, though the labels and locations differ. Search for terms such as utm, source, campaign, attribution, landing, or a vendor-specific prefix used by your analytics or CRM tool.
You might find raw values such as utm_source=test_linkedin. You might instead find encoded JSON, a structured value, or a first-party identifier that points to campaign data managed elsewhere. Some systems store only an anonymous visitor ID and associate source data server-side. That is not automatically a problem, but browser storage alone cannot prove the entire chain.
Check storage scope and expiry where available. A session cookie disappears when the browser session ends, which can work for a same-session form conversion but not for someone returning next week. A cookie restricted to one subdomain might not be available when a visitor moves from www.example.com to app.example.com. Restrictive SameSite behavior can also fail in some embedded or cross-site contexts.
Timing matters too. Some scripts write attribution values only after consent is granted, a tag manager loads, or an asynchronous request finishes. Wait briefly, inspect again, and watch the Network panel if an API call populates storage.
If you find no raw UTMs, no related identifier, and no evidence that the CRM or form provider received them, you have a strong lead. The persistence script could be missing, firing too late, or prevented from running by a tag manager condition. Capture screenshots or export the relevant values before changing anything.
Make sure consent banners are not quietly blocking persistence
Consent choices can change what is stored, what analytics platforms receive, and what reaches your CRM. That behavior can be intentional and legally required, but it should not be mistaken for a random tracking failure.
Run the clean test at least twice in a fresh browser state: once after accepting the relevant consent categories and once after declining non-essential cookies. Record the precise choices. Some banners separate analytics, advertising, functional storage, and personalization, so “accept” and “decline” are not detailed enough for a useful test record.
After accepting, inspect browser storage and complete the conversion. Then repeat after declining. Compare GA4 events, the form submission, and the CRM record. A site might still pass raw UTMs in a submitted form when analytics cookies are disabled. It might also intentionally omit them because attribution storage is treated as non-essential.
A consented test does not prove that all traffic is tracked. If many visitors decline optional cookies, CRM source data can be incomplete by design. That does not mean consent should be overridden; it means reporting needs a clear definition of what it can and cannot claim.
Check for accidental blocking as well. A consent management platform can prevent a tag manager container from loading, including a first-party script your team expected to run regardless of analytics consent. Scripts can be categorized incorrectly, and banner updates can alter their behavior. Browser extensions and strict privacy settings add another variable, so test in an ordinary browser profile as well as conditions likely to affect privacy-focused users.
The right result is not always “all values persist after rejection.” The observed behavior should match your privacy policy, consent configuration, and reporting expectations. If campaign attribution is expected only after consent, document that clearly so paid-media and sales teams do not compare consented analytics data with all CRM leads as though they represent the same population.
Follow the values through forms, booking tools, and checkout
Many UTM persistence failures appear after the landing page, when a visitor submits data or leaves your site. The URL can be correct and browser storage can contain the values, while the form or checkout sends none of them onward.
Start with the form. Inspect hidden fields in the browser through Developer Tools, or submit while watching the Network panel. Look for fields such as utm_source, utm_medium, utm_campaign, original_source, landing_page, or a visitor ID. Field names vary by stack; the key is whether the submitted payload contains the values the CRM integration expects.
A hidden field on the page is not proof. It can be blank, populated only on some pages, or overwritten by another script. Review the submitted request in Network, usually under Payload or Form Data. If values are present there but absent in the CRM, the likely break is in the integration or CRM mapping. If they are blank before submission, inspect the form-population script and its trigger timing.
Booking tools and payment providers deserve extra scrutiny because they often run on another domain. A visitor might start on example.com, book through calendarvendor.com, and return to a confirmation page on example.com. First-party browser storage does not automatically cross that boundary. You might need to pass UTMs in the outgoing booking URL, use the vendor’s custom-field support, or transfer an identifier that lets your backend recover attribution.
Hosted checkout has the same risk. It can start a new session with no knowledge of the original landing page. Check the outgoing checkout URL, order metadata, webhook payload, and final order record. Some platforms preserve referral information but not arbitrary UTM fields unless configured to do so.
Test intermediate interactions too: chat widgets, iframe lead forms, scheduling pages, and login flows. Each handoff can change ownership, storage access, or parameter passing. Your goal is to identify the exact handoff where known values stop appearing.
Compare the CRM record with the original test link
After the form, booking, or order is processed, find the actual record created by your test. Use the dedicated test email address, timestamp, or order reference rather than campaign name alone. Inspect the raw record, not only a summary dashboard that could update later or apply separate attribution logic.
Compare the record with the original test URL field by field. Check raw UTM properties first: utm_source, utm_medium, utm_campaign, utm_term, and utm_content. Then review supporting fields such as first page seen, original referrer, latest source, source detail, ad click ID, and conversion page.
These fields answer different questions. First-touch values show where the contact was first known to come from. Last-touch values show the source associated with the most recent qualifying visit or conversion. Raw UTM fields can reflect only the conversion session, or be overwritten on each visit depending on the integration. A single “Lead Source” field can hide those distinctions, so it should not be your only proof.
For a new contact that clicks the test paid-social link and submits a demo form, a straightforward pass could show the raw test UTMs, first-touch values matching the test link, and last-touch values matching it too. If raw fields are correct but the high-level source is “Other,” review the CRM’s source-classification rules. It might not recognize your medium naming convention even though the data arrived intact.
If raw fields are blank, work backward through the form payload, integration logs, automation rules, and property mappings. If raw fields are correct but later change, inspect workflows that update source properties after record creation. Duplicate-merging rules can also confuse a test when a new submission attaches to an older contact with a different first-touch source.
Capture a screenshot or export a record view with property history if your CRM supports it. The history can show when a value was set, cleared, or replaced.
Why GA4 can look right when your CRM is wrong
GA4 and your CRM do not validate the same thing. GA4 generally reports how it attributed a web session or event using its own collection and attribution rules. Your CRM stores contact or revenue-source properties through forms, cookies, integrations, and automation.
GA4 can correctly record a paid-social session because its tag saw campaign parameters on the landing page and sent a page_view. The visitor might then open a booking tool on another domain, where the integration creates a CRM contact without UTM fields. GA4 still shows the campaign session while the CRM shows an unknown lead.
The reverse can happen as well. A form can pass stored UTMs into the CRM while GA4 misses the session because analytics consent was declined, a tag was blocked, or the event did not fire. The CRM record can contain useful source data even when GA4 reports little or nothing.
Timing also creates differences. GA4 can attribute a conversion event to the current session while the CRM preserves first-touch values from an earlier visit. Someone might first arrive from an organic result, return through a retargeting ad, and convert. Different channel labels do not automatically mean either platform failed; they can be answering different attribution questions.
Compare like with like: the test timestamp, landing URL, session behavior, consent state, and conversion event. In GA4, use DebugView or real-time reporting where available to confirm that the test event was collected. In the CRM, inspect raw fields and property history instead of relying only on a marketing report.
Do not expect every report to match line for line. Identity rules, reporting windows, ad-platform integrations, and data-processing delays differ. Define which system is authoritative for each decision: GA4 might be the source for onsite behavior and campaign traffic, while the CRM is the source for lead ownership and pipeline. The test should show that the handoff is understood and fit for its reporting purpose.
Test the messy journeys real visitors take
A clean first-session conversion is the baseline. Real visitors close tabs, return later, use multiple devices, open links in new tabs, and cross domains. Once the simple path passes, test the behavior your audience is likely to take.
Start with a return visit. Click the tagged link in a fresh browser, leave without converting, then return through a direct visit or an untagged link and submit the form. Check whether the CRM follows your intended first-touch or last-touch rule. This can expose short cookie lifetimes, session-only storage, and scripts that require UTMs on the conversion page.
Test a new tab as well. Some implementations write attribution data only after a page script finishes loading. If someone opens a call to action in another tab quickly, that tab might not receive the values expected by the form. Test a normal click and opening the destination in a new tab where that behavior is plausible.
Then test cross-domain movement. Visit the marketing site through the tagged URL, move to the application, booking, membership, or checkout domain, and convert there. Inspect URL parameters, browser storage on each domain, form payloads, and the final CRM or order record. Cross-domain analytics tracking is separate from passing campaign data into a form or order system, so test both when both matter.
Different-device tests reveal another limitation. Browser-based UTMs generally do not follow someone from phone to laptop by themselves. If a person clicks an ad on mobile and converts later on desktop, the actions might not be joined unless they authenticate, provide an email your systems can match, or use a platform-specific identity method. Build that limitation into attribution expectations rather than treating it as a bug.
Finally, test a delayed conversion. Return after the period that matters to your sales cycle and convert. You do not need to wait months for routine checks, but you should know the cookie expiry and persistence window your setup is intended to support. A result that works after five minutes but fails after a day is not a full pass if leads commonly take several days to decide.
Turn your findings into a simple monitoring routine
Once you know where attribution works or breaks, turn the test into a small operating routine. Tracking can fail after a new consent banner, redesigned form, redirect update, tag manager edit, CRM workflow, or replacement checkout tool. A repeatable test can catch those changes before they distort a month of reporting.
Keep a short test document with the expected result at every checkpoint. Include the exact test URL, expected stored values, form or checkout fields, CRM properties, and report where the result should appear. Assign an owner for each part: marketing might own campaign naming, web engineering redirects and scripts, operations CRM mappings, and a vendor the booking or checkout integration.
For every failure, document the first point where the value is missing. “UTMs are broken” is too broad to fix. “utm_campaign reaches the landing page and is stored in local storage, but the booking form submission does not include it” gives the responsible person a useful starting point.
Capture:
- Original tagged URL and timestamp.
- Screenshots of the landing URL and relevant browser storage.
- Network request details showing form or checkout payloads.
- CRM record link, property values, and history where available.
- Consent state, browser, device, and test account used.
- Expected behavior and observed behavior.
Rerun the core test after meaningful changes and on a cadence that reflects how often your site and stack change. High-volume paid campaigns or frequent releases usually justify more frequent checks than a stable, low-change site. Keep the same core test-link structure so results remain comparable, but rotate test identifiers so new evidence is not confused with old records.
The aim is not a giant audit document that nobody opens. It is a clear trail from click to record, with enough evidence to assign and fix a gap quickly.
Conclusion
Start with one fresh-browser test and one distinctive tagged URL. Follow the values from the first landing-page request through browser storage, the submitted form or checkout payload, and the final CRM or order record before comparing dashboards or debating attribution models. A useful result is specific: you know which values are stored, how long they persist, what consent choice changes, and which CRM fields represent first touch, last touch, and raw campaign data. If the test fails, record the first missing handoff and fix that point. That turns a vague reporting concern into a practical engineering or operations task.
Frequently Asked Questions
How do I know if UTMs are being captured correctly?
Use a unique test URL and inspect each handoff: the landing-page URL, browser storage, form or checkout submission payload, and resulting CRM or order record. UTMs are captured correctly only when the expected values reach the system used for campaign decisions under your defined attribution rules.
Why do UTMs disappear from the URL after I land on a page?
A site can intentionally remove UTMs after storing them in a cookie, local storage, or a server-side session. That can be fine, but confirm that the values were stored and passed into the conversion record before calling the test a pass.
Can GA4 show UTMs if my CRM does not?
Yes. GA4 can collect campaign parameters during a web session while a form, booking tool, checkout, or CRM integration fails to pass them into the lead record. GA4 session attribution and CRM source properties are separate mechanisms.
Do consent banners affect UTM persistence?
They can. Declining analytics or marketing cookies can block attribution storage, analytics collection, or both, depending on the setup. Test accepted and declined states separately, then check that the result matches your privacy and reporting rules.
How long should UTM values persist?
The right period depends on your sales cycle and attribution policy. A same-session form might need only session persistence, while a longer consideration cycle can require values to remain across return visits. Define the intended window and test a delayed conversion rather than assuming the setup supports it.