Five data points every WordPress form should capture (but usually does not)
Name and email tell you who enquired. These five tell you why, and what to do about it.
Every WordPress form collects a name and an email. That tells you who got in touch. It tells you nothing about why they did, which page convinced them, or whether the campaign you paid for had anything to do with it.
All of that is available in the browser at the moment the form is submitted. Almost every form plugin throws it away.
1. Traffic source
The channel that produced the visit — organic search, paid search, social, email, referral or direct.
This is the single most useful field you are not capturing, because it maps directly onto how you spend money. Without it, “we got 40 enquiries” cannot be turned into “we should spend more on X”.
It is also the field most people assume analytics already provides. Analytics gives it to you in aggregate; it cannot tell you which individual enquiry belonged to which channel.
2. UTM parameters
The five campaign tags on the landing URL: source, medium, campaign, term and content.
These are the only attribution signal you control directly. Everything else is inferred; UTM parameters are declared. When someone arrives on a link you tagged utm_campaign=spring-sale, that is not an estimate.
The catch is that they exist only on the landing page URL. By the time a visitor has read two pages and reached your contact form, they have disappeared from the address bar — which is why so many campaigns show clicks but no attributable leads. Covered in detail in capturing UTM parameters.
3. Landing page
The first page of the visit.
This is the page that earned the click, which is rarely the page holding the form. A form that records only its own URL credits /contact/ for everything and tells you nothing about what actually attracted anyone.
Knowing your landing pages tells you which content is doing acquisition work, as distinct from which content merely gets traffic.
4. Pages viewed before submitting
The sequence of pages read during the visit.
This is the most revealing of the five and the least commonly captured. It answers a question that is otherwise guesswork: what did they read before deciding to get in touch?
The pattern that shows up repeatedly is that a page which hosts no form at all — a comparison article, a pricing explainer, a case study — turns out to appear in most converting journeys. On a standard setup that page looks like a mid-performer, because it generates no conversions of its own. It is in fact doing the persuading.
You cannot deduce this from aggregate analytics. It requires the journey attached to the individual submission.
5. Device and browser
Whether the visitor was on mobile or desktop, and in what browser.
The value here is diagnostic rather than strategic. If your traffic is 60% mobile but your enquiries are 85% desktop, something on the mobile form is broken — a field that will not focus, a date picker that misbehaves, a submit button under a sticky footer.
That gap is invisible in aggregate reporting and obvious the moment device is recorded per submission.
What this looks like in practice
With all five recorded, an entry stops being a contact record and becomes a short account of a decision:
Maya Patel enquired on 24 July. She arrived from organic search on a blog post about UTM tracking, read the features page and the pricing page, then submitted the contact form on mobile. Campaign: brand-awareness.
That paragraph is the difference between knowing you received an enquiry and knowing what produced it.
Doing it without adding fields
The usual approach is hidden fields plus a JavaScript snippet. It works until someone edits the form, and it fails silently when it does.
Sense Forms captures all five automatically, along with browser, operating system, screen size and language. No hidden fields, no snippets, nothing to configure — and everything is stored in your own WordPress database rather than sent to a third party.
The privacy question
Recording more about visitors raises a fair question about proportionality.
Two things make this defensible. First, it is all first-party: the data describes visits to your own site, stored in your own database, with no third-party cookies and nothing shared. Second, it should be controllable — IP anonymisation, a retention period, honouring Do Not Track, and a consent field where appropriate.
What it needs from you is disclosure. Say in your privacy policy what you record and why. See GDPR settings for what to configure and what to write.