How to Track Lead Source in Elementor Forms (2026 Guide)

A client emails you the question every agency dreads: “These twelve leads last month — which campaign actually produced them?” You open their Elementor form submissions in WordPress, and every entry looks identical. A name, an email, a message. No campaign. No source. No way to tell whether that enquiry came from a $40 Google Ads click or a free organic search. You’re running the ads, but you can’t prove which ones worked.

We’re a digital agency, and we lived with that blind spot for years. Elementor builds beautiful forms — what it doesn’t do is record where the person came from before they filled one in. This guide walks through every realistic way to fix that, from the native hidden-field method most articles stop at, to why that method quietly loses most of your data, to the server-side approach we eventually built to get reliable answers.

Why Elementor Forms don’t track lead source by default

Elementor Forms is built to collect submissions, not to explain them. When someone completes a form, Elementor stores the field values they typed — and nothing about the journey that brought them there. There’s no column for traffic source, no campaign name, no record of the ad they clicked three pages ago.

That’s not an oversight so much as a boundary. Form builders capture what a person submitted. Attribution — the why and the where from — is a separate problem, and every tool that claims to solve it for Elementor does so by adding tracking on top. The question is how reliably that bolt-on tracking actually works, because the popular method has a failure rate most guides never mention.

What “lead source” actually means

Lead source is the marketing origin of an enquiry — the channel, campaign, and click that led a real person to your form. In practice it’s assembled from a handful of signals: the UTM parameters in the URL (utm_source, utm_medium, utm_campaign, utm_term, utm_content), the ad click ID a platform appends to paid clicks, the referrer (the site the visitor arrived from), and the landing page they first hit. Capture those on the visit and attach them to the submission, and a faceless lead becomes “Google Ads, brand campaign, this exact ad.”

There’s also a timing dimension. First-touch attribution credits the campaign that originally brought the visitor to your site; last-touch credits whatever brought them back the day they finally converted. A lead who clicks a LinkedIn ad on Monday and returns via organic search two weeks later has a different story depending on which you record. Good tracking keeps both. (We go deeper on that in our guide to multi-touch attribution and conversion windows.)

The three methods at a glance

• Method 1 — Hidden fields + Actions After Submit: native to Elementor Pro, no code, but only captures UTMs present in the URL at the moment the form page loads.
• Method 2 — JavaScript + cookies: stores the source on arrival and rehydrates the hidden fields later; more robust, but you own and maintain the script.
• Method 3 — Server-side capture (Lead Source): records lead source on the first visit and attaches it to every Elementor submission automatically, surviving the things that break the other two.

Method 1: Hidden fields with Elementor’s Actions After Submit

This is the method nearly every other article describes, and it’s the right place to start because it’s native and free of code. The idea: add hidden fields to your Elementor form, tell each one to read a URL parameter, and Elementor stores whatever value was on the URL when the page loaded.

Step 1: Add a hidden field for each parameter

Edit your form, click the + to add a field, and set its Type to Hidden. Give it a clear label such as utm_source. Repeat for each value you want to capture — typically the five UTM fields plus gclid and fbclid.

Step 2: Pull the value from the URL

With the hidden field selected, open its Advanced settings and find Default Value. Click the dynamic-tags icon beside it and choose Request Parameter (a Pro dynamic tag; older versions label it “Get value from URL/POST”). Set Type to GET and enter the exact query-string key in the Parameter Name box — for example utm_source. Now when a visitor lands on yoursite.com/?utm_source=google, Elementor drops google into that field. Repeat for every hidden field.

Step 3: Make sure the data goes where you’ll see it

Open the Actions After Submit section of the form. Hidden fields are saved automatically to Elementor > Submissions in your WordPress dashboard. To get the values into emails, add an Email action and include the field shortcodes in the message body. To push them into a CRM, add a Webhook action (or your integration of choice) so the hidden fields map across to the right CRM properties.

Step 4: Test it

Open your form page in an incognito window with parameters appended — ?utm_source=test&utm_medium=cpc&utm_campaign=demo — submit it, and check Elementor > Submissions. If the values are there, the wiring works. Keep that incognito tab open, though, because the next test is where Method 1 starts to fall apart.

Why hidden fields lose most of your lead source data

Here’s the test the tutorials skip. Land on your site with UTM parameters, then — before submitting — click to another page, the way a real visitor reads your services page, your pricing, your about page. Now open the form and submit. The hidden fields come through blank.

That’s not a bug you’ve introduced. It’s the fundamental limit of the method, and it shows up in four ways:

• UTMs vanish on navigation. The parameters only exist in the URL of the landing page. The moment a visitor clicks an internal link, the clean URL takes over and the values are gone. Since most people don’t convert on the first page they see, most of your submissions arrive empty. This is the single biggest reason agencies think their tracking “works” in testing but reports near-zero in production — we cover the mechanics in why UTM parameters disappear in WordPress.
• Page caching serves stale values. Caching plugins and CDNs serve a saved copy of the page. A hidden field whose default was baked in at cache time can hand every visitor the same stale value — or none at all.
• Click IDs and UTMs can be stripped before they’re saved. Even on the landing page, some browsers and privacy modes remove tracking parameters from the URL. Safari, for instance, strips parameters like gclid, fbclid, and msclkid in Private Browsing. If the parameter never reaches the page, no method that reads the URL can save it.
• Organic and direct leads show as “nothing.” A visitor from an unpaid Google search arrives with no UTMs at all. The hidden fields stay blank, and the lead looks sourceless — even though “organic search” is itself a perfectly good answer the form never records.

One smaller quirk worth knowing: Elementor decodes a + in a URL parameter to a space (it’s a long-standing, unresolved encoding bug, not a misconfiguration on your end), so values containing one can arrive subtly mangled. None of this means Method 1 is useless — it captures first-page paid clicks fine. It means you should expect it to miss every lead who looked around first, which, for most sites, is the majority.

Works when: visitors convert on the same paid landing page they arrived on, with the UTMs still in the URL. Breaks when: anyone browses to another page first, your pages are cached, or the visitor came from organic or direct traffic.

Method 2: JavaScript and cookies

The JavaScript approach exists specifically to fix Method 1’s navigation problem. A script runs as soon as a visitor lands, reads any UTMs and click IDs from the URL, and saves them to a first-party cookie. On every later page — including the one with your form — a second script reads the cookie and writes the values back into the hidden fields just before submission. The source survives browsing because it’s no longer relying on the URL staying put.

This genuinely works, and if you’re comfortable maintaining a little code it’s a real upgrade. You also gain control: you can choose first-touch (only write the cookie if it’s empty) or last-touch (overwrite on each visit), and set how long the cookie persists.

Works when: you have someone to own the script, your forms all use a consistent hidden-field naming scheme, and you keep the capture and write-back logic in sync. Breaks when: the cookie is short-lived. Browser privacy controls — Safari’s Intelligent Tracking Prevention chief among them — cap cookies that JavaScript sets to roughly seven days (and as little as 24 hours for flagged trackers). A lead with a three-week consideration window loses their first-touch source before they convert. You’re also now maintaining custom code across theme updates, caching layers, and consent tools, and debugging it when a form silently submits blanks.

If you want to build it yourself, our walkthrough on capturing UTM parameters with JavaScript and cookies has the full code. Method 2 trades Method 1’s data loss for a maintenance burden and a cookie-lifetime ceiling. Method 3 removes both.

Method 3: Capture lead source server-side with Lead Source

The reason Methods 1 and 2 leak data is that both do their work in the browser, where URLs change and privacy rules shrink cookies. Server-side capture moves the job to where those rules don’t apply. Here’s the mechanism, because it’s worth understanding even if you never install a plugin.

When a visitor first arrives, the request hits your WordPress server with the UTMs and click IDs still on it. The plugin reads them there, on the server, before any caching or browser policy can interfere, and writes them into a first-party attribution record tied to that visitor. That record persists for the whole visit and across return visits. When the person later submits an Elementor form, the plugin hooks the submission as it’s saved — via Elementor’s elementor_pro/forms/new_record event — looks up the stored attribution, and attaches it to the entry. The visitor never had to land on the form page with parameters intact, because the source was banked on arrival.

That’s what Lead Source does. Practically, it means:

• No hidden fields to add. You don’t edit your forms at all. The plugin works with your existing Elementor forms — and with Contact Form 7, Gravity Forms, WPForms, and the other major builders — out of the box.
• It survives navigation and caching. Because the source is captured on the first request and stored server-side, a visitor browsing five pages before converting keeps their attribution.
• It isn’t capped by Safari’s cookie limits. A first-party record written server-side isn’t subject to the seven-day ITP ceiling that truncates JavaScript-set cookies, so longer consideration windows stay intact.
• It keeps first-touch and last-touch. Both the original campaign and the converting one are recorded, so you can attribute either way.
• The data stays on your site. Everything is stored in your WordPress database, under your control — no third-party tracking script, no external dashboard required.

What server-side capture still can’t fix

Because no method is magic: if a parameter is stripped from the URL before the request ever reaches your server — a click ID removed by the browser at source — then nothing server-side can recover what never arrived. Server-side capture beats the client-side failure modes that lose the vast majority of real-world data; it doesn’t conjure signals the browser deleted before sending. In practice that’s a rare edge case next to the everyday navigation-and-caching losses it eliminates.

Capturing ad click IDs, not just UTMs

UTMs are only as good as the discipline behind them — forget to tag one campaign and those leads go dark. Ad click IDs are the safety net. Every major platform appends a unique identifier to paid clicks automatically, and capturing it lets you reconcile your form leads against the platform’s own reporting, lead-by-lead. The ones worth storing:

• gclid — Google Ads. (Google also uses gbraid and wbraid for privacy-preserving iOS/Safari clicks, and those survive some browser stripping that removes gclid — worth capturing all three.)
• fbclid — Facebook and Instagram (Meta).
• msclkid — Microsoft Advertising (Bing).
• li_fat_id — LinkedIn Ads.
• ttclid — TikTok Ads.

This matters across all three methods: hidden fields and JavaScript can capture click IDs too, but they inherit the same fragility described above. Server-side capture stores them on arrival alongside the UTMs, which is the most reliable place to catch the ones that are easiest to lose.

Comparing the three methods

Capability	Method 1: Hidden fields	Method 2: JS + cookies	Method 3: Server-side (Lead Source)
Setup effort	Low (no code)	High (custom code)	Low (install plugin)
Survives page navigation	No	Yes	Yes
Survives page caching	No	Partial	Yes
Beats Safari/ITP cookie limits	n/a	No (≈7-day cap)	Yes
Captures ad click IDs	If on landing URL	If on landing URL	Yes, on arrival
First- & last-touch	No	If coded	Yes
Ongoing maintenance	Low	High	None
Edit every form?	Yes	Yes	No

For context, most of the tools that rank for this topic — Attributer, WhatConverts, HandL UTM Grabber and similar — are variations on Methods 1 and 2: they add hidden fields and fill them client-side. They work, with the caveats above. The distinction with a server-side approach is where the capture happens, and that’s what determines how much data you keep.

Which method should you use?

Your situation	Best fit
Single landing page, paid traffic converts on arrival, low volume	Method 1 — hidden fields are enough
You have a developer and want to avoid new plugins	Method 2 — but budget for upkeep and accept the ~7-day cookie cap
Visitors browse before converting, or you run multi-week campaigns	Method 3 — navigation and long windows are exactly where it wins
You run multiple forms or multiple client sites	Method 3 — no per-form editing, works across builders
You need to reconcile leads against Google/Meta/LinkedIn reporting	Method 3 — server-side click-ID capture is the most complete

Setup checklist

• Confirm you’re on Elementor Pro (the Form widget requires it).
• Decide which signals you need: the five UTMs, click IDs, referrer, landing page.
• Pick a method using the table above — match it to how your visitors actually behave, not just how testing behaves.
• For Method 1, set each hidden field’s Default Value to Request Parameter with the exact parameter name.
• Test the realistic path: land with UTMs, browse to another page, then submit. Check whether the source survives.
• Confirm the data flows to where you need it — Submissions, notification emails, and your CRM via webhook or integration.
• Decide whether you need first-touch, last-touch, or both, and make sure your method preserves it.

Frequently asked questions

Does Elementor track UTM parameters by default?

No. Elementor Forms stores the fields a visitor fills in, but it doesn’t record UTM parameters, referrer, or lead source unless you add tracking yourself — via hidden fields, JavaScript, or a server-side plugin.

How do I add a hidden field in Elementor Forms?

Edit the form, add a field, and set its Type to Hidden. In the field’s Advanced settings, set Default Value to “Request Parameter” and enter the URL query key (e.g. utm_source) in Parameter Name. This requires Elementor Pro.

Why are my Elementor hidden fields coming through blank?

Almost always because the visitor navigated to another page before submitting, so the UTM parameters were no longer in the URL when the form loaded. Page caching and browser parameter-stripping cause the rest. Server-side capture avoids this by recording the source on the first visit.

Can I track organic and direct leads, not just paid?

Yes — but only if your method records the referrer and landing page, not just UTMs. Organic visitors arrive with no UTM tags, so a UTM-only setup leaves them blank. Capturing the referrer lets you label them “organic search,” “direct,” or by referring domain.

Will lead-source tracking slow my site down?

Server-side capture adds negligible overhead — it reads request parameters that are already there. The client-side methods add a small script; keep it lightweight and load it early so it captures the landing visit.

Is capturing lead source GDPR-compliant?

Storing campaign attribution against a form a person chose to submit is generally low-risk first-party data, but consent and privacy rules vary by jurisdiction and what you store. Keep the data first-party, document it in your privacy policy, and align it with your consent banner. Treat this as general information, not legal advice.

Does it work with my CRM or Zapier?

Yes. However you capture the source, you can pass it onward through Elementor’s Actions After Submit — a Webhook to Zapier or Make, or a native CRM integration — mapping the attribution fields to your CRM’s properties so the source lands on the contact record.

Stop guessing which campaign produced each Elementor lead

Hidden fields are a fine place to start, and JavaScript will get you further. But if you’re running real money through ads and need to know — lead by lead — which campaign earned each enquiry, the client-side methods will keep losing the visitors who browse before they convert. That’s the problem we kept hitting as an agency, and it’s why we built Lead Source: install it, and every Elementor submission arrives with its true source attached, no form edits and no script to babysit.

See how Lead Source tracks lead source in Elementor →