UTM Form Submit Capture

UTM form submit capture is the step in the attribution stack most B2B SaaS marketing teams skip, and it is the step that decides whether your CRM shows blog-c4-attribution-2026-q2 or unknown next to every lead. Nearly 75% of B2B marketing and operations teams report that at least 10% of their lead data is inaccurate, outdated, or non-compliant, and more than 60% say poor-quality data disrupts lead handoffs (Integrate + Demand Metric, "State of Marketing Data 2025," n=200+, July 2025). Much of that gap traces to forms that submit contact information without the source context captured in the URL. This guide covers the complete wiring: hidden fields, the JavaScript reader, the sessionStorage persistence layer, the React and SPA pattern, the iframe workaround, and the end-to-end verification protocol. For the full per-post attribution architecture this wiring plugs into, start with The 44% Gap: Per-Post Attribution.

Why does UTM data disappear between the click and the CRM record?

UTM parameters in a URL exist only as long as that URL is visible in the address bar. When a visitor clicks a tagged link, the parameters land in window.location.search. When the same visitor submits a form, those parameters disappear unless something explicit captured and forwarded them. Standard HTML forms do not do this automatically: the form sends whatever fields you provide. If UTM fields are not in the form, UTM data is not in the submission.

The three points where UTM data drops

Attribution data drops at three predictable points. First: the form has no hidden fields for UTM parameters, so no UTM data is ever included in the POST body. Second: the form has hidden fields but the JavaScript that populates them runs after submission rather than before, so the fields are empty when the form fires. Third: the visitor landed on a UTM-tagged page, navigated to a second page before submitting, and the second page's URL contains no UTM parameters, so the reader finds nothing to capture. Each is a distinct failure mode with a distinct fix. Most teams fix the first and miss the second and third.

What the CRM shows when capture is broken

When UTM capture fails, the contact record shows the lead source as "direct," "unknown," or an empty string. In Salesforce, the Lead Source field defaults to its first picklist value. In CRM/email platform, the Original Source field reads "Direct Traffic." Within six months, "direct" typically becomes the largest single source in pipeline reports, not because direct drives that much, but because broken capture funnels every form submission with a missing source into the same bucket. Only 25% of marketers report strong confidence in the completeness of their tracking data (CRM/email platform 2026 State of Marketing, n=1,500+), and inaccurate source attribution is a primary driver of that gap.

What is the hidden-field pattern for UTM form submit capture?

The hidden-field pattern is the baseline implementation. Every lead-capture form gets five hidden fields, one for each standard UTM parameter. When the page loads, JavaScript reads the current URL's query string, extracts the UTM values, and writes them into those fields. When the form submits, the UTM values travel with the contact data in the POST body, and the backend writes them to the matching CRM properties.

Which UTM parameters to capture

Capture all five: utm_source, utm_medium, utm_campaign, utm_content, and utm_term. In B2B SaaS, utm_campaign carries the most signal because it encodes the specific asset that drove the visit. utm_source names the platform. utm_medium names the channel type. Capture utm_content even if you are not using it consistently today: once you start A/B testing creative variants, you will want historical data predating the test. utm_term captures the paid search keyword for google-ads sources and is often empty for others, which is acceptable.

Where to place hidden fields in the form HTML

Place each hidden field inside the form element with a name attribute that maps directly to the CRM property it will populate. Keeping the field name and the CRM property name identical eliminates a mapping step at the integration layer:

<input type="hidden" name="utm_source" id="utm_source" value="" />
<input type="hidden" name="utm_medium" id="utm_medium" value="" />
<input type="hidden" name="utm_campaign" id="utm_campaign" value="" />
<input type="hidden" name="utm_content" id="utm_content" value="" />
<input type="hidden" name="utm_term" id="utm_term" value="" />

CRM field names that survive the integration layer

Name your CRM contact properties utm_source, utm_medium, utm_campaign, utm_content, and utm_term exactly. In CRM/email platform, create five custom contact properties with those internal names. In Salesforce, create five custom Lead and Contact fields with identical API names. When the property names match the field names across the entire stack, form builders, custom integrations, and CRM exports all reference the same strings without a translation table. The backend handler reads each key from the POST body and writes it to the matching property. A single-character mismatch silently drops the value.

How do you read UTM parameters from the URL in JavaScript?

The URLSearchParams API reads query string parameters from the current page URL without any library dependencies. It is supported in all modern browsers and Cloudflare Workers runtimes. The pattern is three steps: parse window.location.search, call get() for each UTM key, and write the result into the corresponding hidden field's value. If a parameter is absent from the URL, get() returns null, and the field stays empty rather than writing the literal string "null."

The URLSearchParams approach

The reader function attaches to the DOMContentLoaded event so it runs once the form HTML is in the DOM, before the visitor interacts. If the event has already fired when the script loads, the callback still executes immediately. The function queries each hidden field by name attribute, checks that the element exists before writing to avoid null-reference errors, and writes an empty string when a parameter is absent.

A 10-line reader function

document.addEventListener('DOMContentLoaded', () => {
  const params = new URLSearchParams(window.location.search);
  const utmKeys = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_content', 'utm_term'];
  utmKeys.forEach(key => {
    const el = document.querySelector('[name="' + key + '"]');
    if (el) {
      el.value = params.get(key) || '';
    }
  });
});

This function is the complete implementation for a visitor who arrives directly on the form page from a tagged link. It fixes the first failure mode. The second and third failure modes require the persistence layer described next.

How do you persist UTM values when visitors navigate before converting?

A visitor who clicks a tagged blog post, reads it, follows an internal CTA to a landing page, and then submits the form will have no UTM parameters in the landing page URL. The reader above will find nothing to write. The fix: capture UTM values on the first tagged page load and store them in session storage. The form page reads from session storage as its primary source and falls back to the current URL only when storage is empty.

sessionStorage for same-session persistence

Session storage persists for the lifetime of the browser tab and clears when the tab closes. It is the right default for B2B SaaS lead capture because most form submissions happen within the same session as the originating click. The write runs on every page load: if UTM parameters are present in the current URL, write them to session storage under their standard keys. If they are absent, skip the write so the first-touch values are preserved across subsequent navigations. The form reader checks session storage first, then the current URL, then falls back to an empty string.

When to write a first-touch cookie instead

Use a 30-day first-touch cookie when your sales cycle is long enough that prospects routinely close the browser between first visit and form submission. Set the cookie as Secure, SameSite=Lax, and HttpOnly=false (it must be readable by JavaScript). The write condition is "this cookie does not yet exist." Never overwrite an existing cookie: doing so converts a first-touch store into a last-touch store. For the attribution model implications of first-touch vs. last-touch storage, see First-Touch vs. Last-Touch Attribution in B2B SaaS.

How do you wire UTM capture into a React or SPA form?

In a React form or single-page application, there is no page reload between route navigations, which means DOMContentLoaded fires once at app load, not again when the user navigates to the form route. The hidden-field pattern still works, but the reader must run when the form component mounts rather than on a document event. The useEffect hook with an empty dependency array is the correct place: it runs once after mount, equivalent to the DOMContentLoaded timing on a traditional page.

The useEffect pattern for SPA forms

In a controlled React form, store UTM values as component state rather than writing directly to hidden DOM elements. Initialize five state variables to empty strings. In the useEffect, read from session storage or window.location.search and call the state setters. Render those state values as hidden input elements in the form JSX. On submit, the serialized data object includes the UTM state values automatically, whether you use controlled inputs or FormData serialization.

Handling route changes without a full page reload

If the user navigates away from the form and back to it, the component unmounts and remounts. The useEffect runs again, re-reading from session storage and repopulating state. This is correct behavior. The session storage write should happen in the app-level component that renders on every route, not inside the form component: UTM values may have been set on a completely different route, and writing only inside the form component means the write never happens if the user never visits the form before navigating.

How do you pass UTMs through an embedded iframe form?

Third-party embedded forms in iframes present two complications: the iframe URL may be on a different domain, and the parent page's session storage is not accessible inside the iframe's JavaScript context. There are two approaches, each suited to a different level of access.

Adding UTM parameters to the iframe src attribute

If you control the iframe source (your own Calendly page, a custom form endpoint, or a Typeform with a URL parameter feature), append UTM parameters to the iframe's src attribute at load time. Read the UTM values from the parent page's session storage or URL, construct the query string, and set iframe.src = baseUrl + '?' + queryString before the iframe renders. The form inside the iframe then reads from its own URL using the standard reader, and the submission includes the UTM values because they were in the iframe's URL at load.

The postMessage approach for cross-origin frames

If you do not control the iframe source code, use window.postMessage to send the UTM object from the parent page to the iframe. The iframe must have a message event listener that receives the object and populates its hidden fields. Both sides must specify the target origin explicitly: the parent names the iframe's origin in the postMessage call, and the iframe verifies event.origin before writing to the DOM. Skipping origin validation is an XSS vector. In practice, postMessage requires the iframe publisher's cooperation and is rarely practical for forms you do not own.

How do you verify that UTM form submit capture is working?

Verification has two layers: confirming that hidden fields are populated in the browser before submission, and confirming that the CRM stores the values after submission. Both are required. A field can be populated in the browser and then dropped by a backend handler, or the backend can receive the values and fail to write them due to a field-name mismatch.

The network tab inspection method

Open developer tools, go to the Network tab, and filter for XHR or Fetch requests. Load a form page with UTM parameters appended manually (for example, ?utm_source=test&utm_campaign=wiring-test). Fill out the form and submit. Inspect the request payload: all five UTM fields should appear in the POST body. If any are empty strings, the reader is not running or is targeting the wrong element name. Check the console for JavaScript errors and confirm that each hidden field's name attribute matches the corresponding key in the reader function.

CRM field spot-check protocol

After confirming the network layer, submit a second test form with a unique utm_campaign value you can search for in the CRM. Find the contact record and verify that the five UTM properties contain the expected values. If the contact was created but the UTM properties are empty, the backend received the values but did not write them to the CRM. Verify field-name alignment across the POST handler, the CRM property internal names, and the integration mapping. Run this spot-check after any form rebuild, CRM migration, or backend change. For schema design conventions, see UTM Campaign Naming Convention: Schema Design.

How does captured UTM data close the per-post attribution loop?

UTM form submit capture is the input side of the attribution loop. The withUtm() helper in the site template is the output side: it appends utm_source and utm_campaign to every internal CTA link at render time. The input side captures those parameters from the URL and passes them through the form to the CRM. When both sides are wired, the path from published post to closed-won opportunity is traceable at the asset level, not just the channel level. That is the gap between "organic search drove 40% of Q1 pipeline" and "these 12 blog posts drove 40% of Q1 pipeline."

From form field to first-touch CRM property to pipeline report

Once a UTM value is written to a contact's first-touch property, it must not be overwritten by a later form submission. In Salesforce, use a field update rule or trigger that checks whether the existing value is blank before writing. In CRM/email platform, set the property mapping to "contact create only." When a deal closes, join the opportunity to its associated contacts and read their first-touch utm_campaign values. Each value names a specific marketing asset. The pipeline report reads asset names, not channel buckets. Run the AI Marketing Maturity Benchmark to see which attribution dimension your team currently scores and where the largest gaps sit. First-party form data collected this way is also the most privacy-durable signal available as third-party tracking erodes, as Harvard Business Review noted in May 2026: robust first-party data collection converts privacy constraints into a measurement advantage rather than an obstacle.

Methodology

This guide covers UTM form submit capture implementation for B2B SaaS teams running Cloudflare Workers, React, and standard server-side HTML form stacks. The hidden-field pattern, the URLSearchParams reader, and the useEffect wiring reflect the production implementation used on this site, where the withUtm() helper in src/templates/shared.ts generates the output-side tagged links that this capture layer receives. Session-storage persistence and the first-touch cookie write condition are standard first-party tracking patterns documented in the W3C specification.

Statistics cited: Integrate + Demand Metric "State of Marketing Data 2025" (n=200+ senior marketing operations and demand generation professionals, July 2025), sourced via Demand Gen Report. CRM/email platform 2026 State of Marketing (n=1,500+ global marketers). Adverity "Fixing the Foundation: State of Marketing Data Quality 2025" (global survey, September 2025), sourced via Demand Gen Report. All statistics confirmed via independent multi-source search corroboration; direct page fetches are blocked from this container by Cloudflare Bot Fight Mode, consistent with prior sessions.