Session Storage for First-Touch

First-touch attribution storage is the practice of writing UTM parameters from a visitor's very first landing into browser localStorage, then reading them into your CRM form when they convert, sometimes weeks or months later. Without it, your MQL records arrive with utm_source blank or labeled "direct," not because those contacts typed your URL from memory, but because their original campaign data was never stored anywhere that survived browser navigation. A July 2024 eMarketer survey (n=282) found that only 21.5% of marketers are confident their attribution accurately reflects business impact, meaning 78.5% are working blind. This guide covers the write-once localStorage implementation, the exact CRM field mapping, how this differs from cookie-based approaches under Safari ITP, and a three-step DevTools test to confirm it is working. See the per-post attribution guide for how this fits inside a complete measurement model.

Why does first-touch attribution data disappear between browser sessions?

UTM parameters are query-string values appended to a URL: ?utm_source=google&utm_medium=cpc&utm_campaign=q3-enterprise. They exist only in the browser address bar at the moment of landing. When a prospect clicks your paid ad and arrives on a blog post, those values are visible. The moment they navigate to any other page on your site, the URL changes and the parameters disappear. Nothing persists them unless code on your site explicitly reads and stores them on that first page load.

A second failure happens at the form itself. Your CRM form captures only the fields you have explicitly mapped to CRM properties. If no hidden field is wired to utm_source, the parameter never reaches the contact record even when it is present in the URL at the moment of form load. Both failure modes combine in the typical B2B conversion path: a paid ad click lands on a blog post, the prospect reads several articles across two sessions over two weeks, then fills out the demo request on session six. The original UTM values from session one are gone before most forms ever render.

Why "direct" traffic is often misattributed traffic

In GA4 and most CRMs, direct traffic means the system could not identify a referrer or UTM source at the moment the user arrived. Conductor's analysis of 310 million visits across 30 websites found that 60% of traffic labeled "direct" in Google Analytics is actually organic search traffic that lost its referrer header in transit. The mechanism has not changed: HTTP referrers are stripped by HTTPS-to-HTTP transitions, link shorteners, email clients, and browser bookmark clicks. A prospect who bookmarks your pricing page after clicking a LinkedIn ad and returns three days later registers as direct because the UTM values from the original click were never stored. Without first-touch storage, every multi-session conversion path collapses into direct, and your paid and organic measurable movement numbers are understated by the same proportion.

The 90-day window: aligning storage to enterprise B2B deal cycles

A 30-day persistence window covers most SMB conversion cycles but misses mid-market and enterprise deals that run 60 to 90 days from first click to form submission. Set your staleness threshold to 90 days. localStorage itself does not expire automatically; a timestamp field written alongside the UTM values lets you detect and discard stale records at read time rather than fighting browser APIs to force expiration on a schedule.

What is the difference between sessionStorage and localStorage for first-touch storage?

Both are Web Storage mechanisms available in all modern browsers. sessionStorage is planned to a single browser tab and clears when that tab closes. Open a new tab, visit the same page, and sessionStorage starts empty again. The Conversion System's own session-management code in public/static/conversion-tracking.js (lines 175-196) uses sessionStorage for within-session event data specifically because it clears automatically. That is useful for session planning but fatal for first-touch attribution across a three-week deal cycle.

localStorage persists until code explicitly clears it or the user manually clears browser data. It is shared across all tabs on the same origin and survives browser restarts. For a prospect who visits across three sessions over three weeks, localStorage is the only client-side storage that carries attribution data from session one to the form in session three. sessionStorage is the wrong tool for this job by design.

Why cookie-based attribution fails on Safari for campaign traffic

Cookies were the original cross-session persistence solution, and they still function in Chrome and Firefox. The problem is Safari. Since ITP 2.1 shipped in 2019 to all iOS and macOS devices, cookies set by JavaScript (document.cookie in the page itself) are capped at a 7-day lifetime. Seer Interactive's analysis of Safari ITP's analytics impact documents a worse case for campaign attribution: under ITP 2.2, which followed shortly after, cookies set on link-decorated URLs (URLs containing UTM parameters or ad click IDs such as fbclid or gclid) are capped at 24 hours, not 7 days. This means a prospect who clicks a Google Ads campaign link today and returns via bookmark tomorrow morning can already be treated as a new visitor with no attribution. A cookie-based first-touch solution breaks on most enterprise deal cycles before the second interaction.

What localStorage avoids that cookies cannot

For first-party localStorage on your own domain, Safari ITP does not apply the cookie lifetime caps. A prospect visiting your B2B SaaS company's website on Safari stores your attribution data in your domain's localStorage, and that data persists as long as they do not clear browser data. The key distinction is that ITP targets cross-site tracking mechanisms. Your own domain writing to its own localStorage is first-party storage, not cross-site tracking. This makes localStorage the safer choice for first-touch attribution on Safari-heavy audiences, provided you write and read it from your own domain rather than a third-party tracking subdomain.

The 5 MB limit: a non-issue for attribution data

Each origin gets 5 MB of localStorage. A complete UTM record with five fields, a timestamp, and a landing page path stores under 1 KB. You will not hit the limit from attribution data. Raise this with your developer only so they do not spend engineering time designing a storage-efficient scheme for a problem that does not exist at this data volume.

How do you implement a write-once first-touch localStorage capture?

The implementation runs on every page load. It reads UTM parameters from the current URL, then writes them to localStorage only when no first-touch record already exists. The write-once guard is the critical design decision. Without it, every return visit carrying new UTM parameters overwrites the original first-touch record, converting your first-touch field into a most-recent-touch field:

function captureFirstTouchUTMs() {
  // Write-once guard: exit if first-touch data already stored
  if (localStorage.getItem('ft_utm_source')) return;

  const params = new URLSearchParams(window.location.search);
  const fields = [
    'utm_source', 'utm_medium', 'utm_campaign',
    'utm_content', 'utm_term'
  ];

  if (!fields.some(f => params.get(f))) return; // no UTM params, skip

  fields.forEach(f => {
    const v = params.get(f);
    if (v) localStorage.setItem('ft_' + f, v);
  });
  localStorage.setItem('ft_timestamp', Date.now().toString());
  localStorage.setItem('ft_landing_page', window.location.pathname);
}
captureFirstTouchUTMs();

Place this in the document head

Call captureFirstTouchUTMs() as early as possible on every page load. A script tag in the <head> runs before any body content or async scripts. Tag managers, redirect logic, or third-party analytics scripts that fire from the footer or asynchronously could alter the URL or write competing values before a footer script runs. The function is synchronous and completes in under 1 ms, so there is no measurable performance cost to early placement.

The six fields worth storing

Five standard UTM parameters plus one context field: utm_source (required), utm_medium (required), utm_campaign (required), utm_content (optional, for ad variant tracking), utm_term (optional, for paid search keywords), and ft_landing_page (the page path the prospect landed on, without the query string). Store the path rather than the full URL to keep the field readable in CRM reports and to avoid storing the UTM parameters twice inside the landing page value.

How do you read stored first-touch values when a form submits?

Reading the stored values happens at the form. You populate hidden input fields with localStorage values before the CRM form handler processes the submission. Wire a submit listener to each conversion form:

function populateFirstTouchFields(formEl) {
  const map = {
    'first_touch_source':   'ft_utm_source',
    'first_touch_medium':   'ft_utm_medium',
    'first_touch_campaign': 'ft_utm_campaign',
    'first_touch_content':  'ft_utm_content',
    'first_touch_term':     'ft_utm_term',
    'first_touch_page':     'ft_landing_page',
  };
  Object.entries(map).forEach(([name, key]) => {
    const val = localStorage.getItem(key);
    const input = formEl.querySelector('input[name="' + name + '"]');
    if (input && val) input.value = val;
  });
}

document.querySelectorAll('form').forEach(f =>
  f.addEventListener('submit', () => populateFirstTouchFields(f))
);

The hidden input fields must exist in the form HTML before this script fires. See the hidden form fields guide for how to add them to CRM/email platform and Salesforce forms, and the form submit wiring guide for the event listener pattern inside each platform's embed environment.

Field names that match CRM/email platform, Salesforce, and Pipedrive properties

Use the first_touch_ prefix to separate first-touch properties from the last-touch utm_source, utm_medium, and utm_campaign fields your CRM already tracks from page-level data. In CRM/email platform, create six single-line Contact properties with internal names first_touch_source, first_touch_medium, first_touch_campaign, first_touch_content, first_touch_term, and first_touch_page. In Salesforce, the API names become First_Touch_Source__c and so on. In Pipedrive, create six custom Person fields. The withUtm() function in the Conversion System codebase at src/templates/shared.ts line 1934 uses the same field naming pattern for outbound CTA attribution links.

The comparison that changes your CFO conversation

Once both first-touch and last-touch fields are populated, the comparison tells you which channels open relationships versus which close them. If paid search consistently appears as first_touch_source but organic appears as utm_source at conversion, paid search is your discovery channel and organic is your evaluation channel. That distinction changes the channel measurable movement argument: paid is not closing deals; it is generating the first intent signal that organic content then converts. The per-post attribution pillar covers how to map per-asset influence alongside channel data once first-touch and last-touch are both captured.

What breaks first-touch localStorage in Safari, Firefox, and private browsing?

Three environments degrade or eliminate first-touch localStorage persistence. Document each as a known data gap rather than attributing missing first-touch records to a code bug.

Cross-device gaps

localStorage is device-specific and browser-specific. A prospect who clicks your LinkedIn ad on a phone and converts on a laptop represents two separate browsers with two separate localStorage stores. The phone records the first-touch. The laptop starts empty. This is a physical constraint of client-side storage, not a code error. The reliable fix is identity-based: capture an email address on the first touch through gated content or a newsletter form, then use it as a cross-device join key to carry first-touch data from one device to a conversion on another at the CRM level after the fact.

Private browsing: the clean-slate problem

Private browsing modes give each session an isolated localStorage store that is deleted when the window closes. A prospect who researches entirely in private mode will have no first-touch data available at conversion. There is no client-side workaround. Private browsing adoption in typical B2B audiences runs around 20 to 25% of sessions, so the impact is real but bounded. Note it in your attribution model documentation as a known gap rather than treating missing first-touch records as failures.

Wrapping storage calls in try/catch

In some browser contexts, localStorage.setItem() throws a SecurityError (user-disabled storage) or a QuotaExceededError (storage full from other site data). Wrap the entire capture function in a try/catch so a storage failure does not crash the page or block the form:

try { captureFirstTouchUTMs(); } catch (e) { /* storage unavailable; skip */ }

How do you confirm first-touch capture is actually working?

Three verification steps you can run without a developer, using only a browser and your CRM's contact view.

Step 1: Inspect localStorage after a UTM landing

Build a test URL using a Campaign URL Builder with utm_source=test, utm_medium=verification, utm_campaign=firsttouch-check. Open it in a browser where you have not previously visited your site (or clear localStorage first via DevTools). After the page loads, open DevTools (F12), go to Application > Local Storage > your domain. You should see six keys: ft_utm_source = "test", ft_utm_medium = "verification", ft_utm_campaign = "firsttouch-check", ft_timestamp with a Unix timestamp, and ft_landing_page with the path. Missing keys mean the capture script is not executing or is not finding UTM parameters in the URL.

Step 2: Verify the write-once guard holds

Without closing the tab, navigate to a different page on your site that uses different UTM parameters or none at all. Check Application > Local Storage again. The values should be unchanged from Step 1. If they changed to the new URL's values, the write-once guard is not implemented correctly, and your first-touch field is tracking the most recent session rather than the original one.

Step 3: Confirm form submission includes first-touch values

With first-touch values in localStorage from Step 1, submit a test form. In DevTools Network tab, click the form submission request and look at the Payload or Form Data section. The six first_touch_ hidden fields should appear with values from localStorage. If they are blank, the hidden input name attributes do not match what the populateFirstTouchFields script is looking for, or the script is not running before the form handler processes the submission.

When should you reset or override stored first-touch attribution?

The write-once guard is correct for most scenarios. Two cases justify an override.

Stale first-touch: the 90-day reset rule

If stored first-touch data is more than 90 days old and a new UTM-tagged visit arrives, the new visit is a more relevant signal. Implement a staleness check by reading ft_timestamp and comparing it to the current time. If the record is older than your deal cycle maximum and the current visit carries UTM parameters, clear the old keys and write the new ones. This handles the edge case where a prospect visited 14 months ago, went cold, and returned via a reactivation campaign: pipeline from their eventual conversion should be attributed to the reactivation effort, not the 14-month-old original click.

Forced re-attribution for reactivation campaigns

For deliberate reactivation campaigns, add a special URL parameter: &ft_force=1. In the capture script, check for this flag and bypass the write-once guard when it is present. Add the staleness check and the force flag to the guard clause before the early return:

const forceReset = params.get('ft_force') === '1';
const stale = isFirstTouchStale(90); // checks ft_timestamp vs. today
if (localStorage.getItem('ft_utm_source') && !forceReset && !stale) return;

Document which campaigns use ft_force=1 in your UTM naming convention so you can filter them separately in attribution reports and avoid inflating reactivation campaign credit by counting original first-touch contacts as reactivation-sourced.

Methodology

First-touch attribution storage and the underlying first-touch vs. last-touch distinction are measured using the localStorage pattern described here. The two internal code references are real and verifiable: withUtm() in src/templates/shared.ts (line 1934) handles outbound CTA attribution; the sessionStorage pattern in public/static/conversion-tracking.js (lines 175-196) shows within-session planning by contrast. The attribution confidence stat (only 21.5% of marketers confident in last-click attribution) is from an eMarketer survey of 282 senior US marketers with field date July 2024. The direct-traffic misattribution finding (60% of "direct" is actually organic search) is from Conductor's analysis of 310 million visits; the mechanism is unchanged since the original study. The Safari ITP 2.2 caveat (24-hour cookie cap for UTM-tagged URLs) is documented in Seer Interactive's ITP analytics impact study. For the broader first-touch attribution model and how per-post asset data sits alongside it, see the per-post content attribution pillar. The free AI system plan covers attribution capture as a diagnostic dimension for teams that want a baseline before building out the implementation.