How to Keep UTM Parameters After the First Page

You tag every campaign link with UTM parameters. Someone clicks, lands, reads two more pages, and fills in your contact form. The lead arrives in your CRM with no source at all.

The tags were correct. The problem is that UTM parameters only exist in the URL of the landing page, and nothing on most websites is built to remember them once the visitor clicks somewhere else. The lead gets filed as direct or unknown, and the campaign that paid for the click never gets credit for it.

Why do UTM parameters disappear after the first page?

Because they are part of the URL, and the URL changes on the next click. Unless something on the page reads the parameters and stores them, they are gone the moment the visitor navigates.

A visitor lands on yoursite.com/services?utm_source=linkedin&utm_medium=paid_social&utm_campaign=q3_demo. Your analytics tag reads the parameters and records the session source. Then the visitor clicks through to yoursite.com/contact. That URL has no parameters, and your form has nothing to read.

GA4 copes with this inside a single session because it keeps the session source internally. Your form, your CRM and your sales team do not have access to that. If the lead record is supposed to carry the source, your site has to hold on to it separately, from the first page until the form is submitted, which may be days or weeks later.

This is what it means to persist UTM parameters: capture them on arrival, keep them somewhere that survives navigation, and hand them to the form when it matters.

Where should I store UTM parameters: cookie, localStorage or sessionStorage?

Use a first party cookie or localStorage. Both survive page changes, closed tabs and return visits. sessionStorage is the weaker option because it only lives in a single tab and is cleared when that tab closes.

First party cookies are set on your own domain by your own script. You control the name, the expiry and the domain scope, so a cookie set at the root domain can be read on www.yoursite.com and app.yoursite.com alike. Cookies are also sent to your server with each request, which matters if your forms are processed server side or you run server side tagging.

localStorage holds values in the browser for your domain with no built in expiry, so you store a timestamp alongside each value and check its age yourself. It is simple to read and write from JavaScript and does not add weight to every request. It is scoped to the exact origin, so www and a subdomain do not share it.

sessionStorage looks convenient and fails quietly. It is scoped to one tab. If the visitor opens your pricing page in a new tab, that tab starts with empty storage. If they close the tab and come back tomorrow from a bookmark, the values are gone. Many B2B buyers do exactly this, which is why sessionStorage based setups tend to capture sources for fast converters and lose them for the considered purchases that are usually worth more.

Should I store first touch or last touch UTMs?

Store both, in separate keys. First touch is written once and never overwritten. Last touch is overwritten every time the visitor arrives with new parameters.

The two answer different questions. First touch tells you which campaign introduced the lead. Last touch tells you which campaign brought them back to convert. If you only keep one, you are choosing an attribution model by accident, and whoever built the script made that choice for you.

The practical rule for last touch: only overwrite when the new landing URL actually carries campaign parameters or a click ID. A visitor who returns by typing your URL should not wipe out the paid social campaign that brought them two days earlier. Otherwise your last touch fields fill up with blanks and you are back where you started.

Store a timestamp with each set. Knowing that the first touch was forty days before the conversion and the last touch was yesterday is useful context when you later compare campaigns.

How long should I keep UTM parameters?

Ninety days is a sensible default for most businesses. It matches Google Ads' window for importing offline conversions against a click and covers a typical B2B consideration period.

If your sales cycle is short, thirty days is fine. If it is long, you can keep first touch longer, but remember what the data is for. A click ID older than the import window cannot be sent back to the ad platform anyway, so there is little value in holding it past that point.

Also be aware that browsers limit how long script set cookies last. Safari in particular caps cookies written by JavaScript, and localStorage written by script is subject to similar limits there. Returning visitors on those browsers will sometimes arrive with empty storage regardless of the expiry you set. Cookies set by your server in an HTTP response are treated more generously, which is one of the practical reasons teams move this capture server side.

Do I need consent before storing UTM parameters?

In opt in regions such as the EU and UK, storing campaign data for marketing attribution will usually need the visitor's consent first, whether you use a cookie or localStorage. The storage method does not change the legal question. What you do with the data does.

That creates a timing problem. If your script waits for consent and the visitor accepts the banner on their second page, the landing URL with the parameters is already gone. The fix is to read the parameters on the first page load, hold them in memory, and write them to storage once consent is granted in the same page view. If consent is never granted, the values are discarded.

In regions where your policy does not require prior consent, the script can store on arrival. Either way, make the behavior deliberate and documented, and confirm it with whoever owns your privacy policy. A setup that silently skips storage for everyone who ignores the banner will make a large share of your leads look sourceless, and that shows up as campaigns underperforming when they are not.

How do I get UTM parameters into my CRM?

Add hidden fields to every lead form and fill them from storage when the form is submitted. Then map each hidden field to a matching field on the CRM record.

The usual set of hidden fields is:

• utm_source
• utm_medium
• utm_campaign
• utm_term
• utm_content
• gclid
• fbclid

If you keep first and last touch, duplicate the set with a prefix for each. Add a landing page field and a capture date if your form tool allows it.

The script that fills the fields should read from your stored values, not from the current URL. This is the single most common mistake. A script that reads the URL works perfectly on the landing page, so it passes a quick test, and returns empty for everyone who browsed before converting.

Then check the other end. Every hidden field needs a mapped field in the CRM, and if your CRM converts leads into contacts and deals, the values have to carry across. A source that sits on the lead record but never reaches the closed deal cannot tell you which campaign produced revenue.

Isn't the gclid already stored in Google's _gcl_aw cookie?

It is stored there, but for Google's use, not yours. The Conversion Linker tag writes the click ID into the _gcl_aw cookie so Google Ads conversion tags on later pages can connect a conversion to the click.

That is useful for online conversions measured by Google's own tags. It does not put the gclid on your lead record. Your form does not read that cookie unless you tell it to, and the CRM never sees it. When you later want to send qualified leads or closed deals back to Google Ads as offline conversions, you need the gclid sitting on the record, and the _gcl_aw cookie is no help once the visitor has left your site.

You can read the value from _gcl_aw in a pinch, but its format is Google's to change. Capturing the gclid from the URL yourself, into storage you own, is the more reliable route. The same logic applies to fbclid and Meta's _fbc cookie.

Can I rely on another tool's cookie for the original source?

You can, but you are depending on something you do not control. Some tools already record the referrer or landing parameters for their own purposes, for example an A/B testing tool that keeps a referral cookie to target experiments by traffic source.

It is tempting to read that cookie in your form and call the job done. The risks are practical. The vendor can rename the cookie, change its format or shorten its lifetime in an update. If you cancel the tool, your attribution stops working on the same day, and nobody connects the two events. The cookie may also be blocked by your consent banner under a different category from the one you assume.

A cookie you own, set by your own script with a name and format you documented, will outlast any vendor relationship. It costs a small amount of code and removes a dependency that usually only surfaces after the data has already been lost.

How do I test that UTM parameters persist?

Arrive with test parameters, move to a second page, confirm the values are in storage, then submit a real form and check the CRM record. All three steps matter, because each one catches a different failure.

1. Open a private browser window and load a landing page with obvious test values, such as ?utm_source=test_source&utm_medium=test_medium&utm_campaign=persist_check&gclid=test123.
2. Click through to a different page so the parameters are no longer in the URL.
3. Open DevTools, go to the Application tab, and look under Cookies and Local Storage for your domain. Your stored values should be there, with the expiry or timestamp you expect.
4. Close the tab, open a new one on the same site, and check again. This is where sessionStorage setups fail.
5. Submit a test lead through each form type you run, then open the record in your CRM and confirm every field arrived with the right value.

Repeat the test with the consent banner declined and then accepted, and on Safari as well as Chrome. An audit or scan can check whether your forms carry the hidden fields at all, but only an end to end submission proves the values reach the record.

FAQ

What does it mean to persist UTM parameters?

It means capturing the UTM values from the landing page URL and storing them so they are still available after the visitor moves to other pages. UTMs normally exist only in the landing URL. Persisting them in a first party cookie or localStorage lets your forms read them at submission, so the lead record carries its source even when the visitor converts days later on a different page.

Is localStorage or a cookie better for storing UTMs?

Both work. A first party cookie can be shared across subdomains, is sent to your server with each request, and has a built in expiry. localStorage is easy to use from JavaScript but is limited to one exact origin and needs you to manage expiry yourself. Choose based on whether your forms or tagging run server side and whether visitors cross subdomains.

Why are my UTM hidden fields empty in the CRM?

Usually because the script fills the fields from the current URL instead of stored values, so only visitors who convert on the landing page get a source. Other causes include using sessionStorage, which is lost when the tab closes, consent settings that block storage, and hidden fields that were never mapped to CRM fields. A test submission from a second page shows which one applies.

Should I capture gclid and fbclid as well as UTMs?

Yes. UTMs identify the campaign, but click IDs identify the individual click, and that is what ad platforms need to match offline conversions such as qualified leads or closed deals. Google's _gcl_aw cookie holds the gclid for Google's tags, but it does not put the value on your lead record, so capture both click IDs into storage you own.

Do UTM parameters need cookie consent?

In opt in regions such as the EU and UK, storing campaign data for marketing attribution will generally need consent, whether you use cookies or localStorage. A good setup reads the parameters on the first page, holds them in memory, and writes them to storage once consent is given. Confirm the approach with whoever is responsible for your privacy policy.