Somebody in your pipeline review will eventually ask the question: "which campaign did this lead actually come from?" If your website runs on Salesforce web-to-lead forms, the honest answer is usually "whatever the rep typed into Lead Source" — which is to say, nobody knows. The campaign data was right there in the URL when the visitor arrived, in the UTM parameters your ads and emails appended, and the form silently threw it away. Capturing it takes five custom fields, five hidden inputs, and a short script. Here is the whole build, including the two steps that most write-ups skip: where the cryptic field IDs come from, and the mapping that keeps your data alive after conversion.
The five fields Salesforce doesn't give you
There are five standard UTM parameters — utm_source, utm_medium, utm_campaign, utm_term, and utm_content — and Salesforce has a standard field for none of them. So the first step is Setup work: on the Lead object, create five custom fields of type Text (255), one per parameter. Name them plainly (UTM Source, UTM Medium, and so on); resist the urge to get clever with picklists. UTM values arrive as free text from dozens of tools and campaigns, and a picklist that doesn't recognize a value will reject the very data you're trying to save.
Find your field IDs with a throwaway form
Web-to-lead forms don't reference custom fields by their names — they use org-specific IDs that look like 00N5800000Bew3F, and Salesforce doesn't exactly advertise where to find them. The reliable trick: generate a form you never intend to use. Go to Setup → Web-to-Lead → Create Web-to-Lead Form, add your five new UTM fields to the selection, and click Generate. The HTML that comes back contains an input per field, and each input's name attribute is the field ID you need. Copy the five IDs, discard the generated form, and note one gotcha for later: these IDs are per-org, so a form built against your sandbox will not write to production.
Add the hidden inputs
In the form your site actually uses, add one hidden input per UTM field, with the Salesforce field ID as the name and an id you can address from JavaScript:
<input type="hidden" id="utm_source" name="00Nxxxxxxxxxxxx" />
Repeat for the other four. Visitors never see these fields; they exist so the browser can smuggle attribution data along with the name and email the visitor typed.
Populate them from the URL
A few lines of JavaScript read each parameter out of the page's query string and drop it into the matching hidden field before submit:
function getParam(p){ var m = location.search.match('[?&]' + p + '=([^&]+)'); return m ? decodeURIComponent(m[1].replace(/\+/g, '%20')) : ''; }
['utm_source','utm_medium','utm_campaign','utm_term','utm_content'].forEach(function(p){ var el = document.getElementById(p); if (el) el.value = getParam(p); });
The decode step matters: values arrive URL-encoded, with plus signs standing in for spaces, and skipping it fills your CRM with strings like spring%20promo. Run the script on page load, submit the form, and the lead record lands in Salesforce with its campaign attribution attached.
The persistence problem — and picking your touch
The plain-URL version has one blind spot worth knowing about: it only works while the UTMs are still in the address bar. A visitor who lands on your ad page, browses three other pages, and converts on your pricing page has a clean URL by then — and the script above returns empty strings. The fix is to persist the first UTM set you see into a first-party cookie (Google Tag Manager's "Persist Campaign Data" template is a common route) and have the form read from the cookie instead of the URL. That choice also forces a policy decision: overwrite the cookie on every new campaign visit and you're tracking last touch; write it once and keep it, and you're tracking first touch. Either is defensible — what ruins reporting is not choosing, and letting the implementation decide for you. Decide, write it down, and keep it consistent with how your ad platforms report.
Map the fields before your first conversion
Here's the failure mode that surfaces months later: the UTM fields fill reliably on every lead, and the moment a rep converts the lead to a contact and opportunity, the attribution stays behind on the frozen lead record. Custom lead fields only carry through conversion if an admin has mapped them to corresponding fields on the contact or opportunity. Create matching UTM fields on your target object, then set the mapping from the Lead object's field-mapping page in Setup. Do it when you create the fields — before the first real conversion, not after the quarter's pipeline report comes up empty. Once the data survives conversion, it can do real work, like the segmentation in our guide to lead tracking for multiple product lines in Salesforce.
Know web-to-lead's ceiling
One operational limit to file away: Salesforce caps web-to-lead at 500 submissions per day. Past that, extra leads aren't dropped — the captured information is emailed to the Default Lead Creator set in your web-to-lead settings, for manual entry. If your campaigns are generating volume anywhere near that ceiling, ask Salesforce support to raise the limit before launch week, not during it.
Thirty minutes, permanent payoff
This entire build is perhaps thirty minutes of admin work, and it converts every future campaign report from anecdote to evidence. It pairs naturally with disciplined UTM tagging on the sending side — if you're driving traffic from paid campaigns like the ones in our Google Ads targeting guide, the parameters are already on your URLs, just waiting for a form that bothers to catch them. The pattern to avoid is the common one: meticulous tagging on every ad, and a CRM that discards it all at the front door.