Lead Source in Ninja Forms: UTM Tracking Guide

A client forwards you a Ninja Forms notification: a fresh demo request, a real name, a real email. Their first question is the one you cannot answer from the entry itself — “Which campaign produced this lead?” Was it the Google Ads search campaign, the LinkedIn sponsored post, an organic blog article, or a referral from a partner site? The submission tells you who enquired. It says nothing about where they came from.

We run a digital ad agency, and this exact gap cost us real money before we fixed it. When you cannot attribute leads back to channels, you cannot tell which ad spend is working — so you either keep paying for campaigns that quietly do nothing, or you cut the ones secretly carrying the pipeline. This guide walks through the three practical ways to capture lead source and UTM parameters in Ninja Forms, with the honest trade-offs of each.

TL;DR — three ways to track lead source in Ninja Forms

  • Native hidden fields: add a Hidden field and populate its Default Value from the URL with the {querystring:utm_source} merge tag. Free and built in, but only captures data when the UTM is in the URL of the exact page holding the form.
  • JavaScript + cookies: a script reads the parameters on landing, stores them in a cookie, then writes them into hidden fields. Survives navigation, but breaks under page caching and Safari’s cookie limits.
  • Server-side capture (Lead Source): records the visitor’s source on their first server request, stores a first-party attribution record, and attaches it to every Ninja Forms submission automatically — no hidden fields to configure.

Why Ninja Forms doesn’t track lead source by default

Ninja Forms is a form builder. Its job is to collect the fields you place on the form — name, email, message — validate them, and save the submission. That is a deliberately scoped job, and it does it well. But “where did this person come from” is not a field anyone types in, so out of the box it is never recorded.

The information that answers the campaign question lives in the URL the visitor arrived on and in the browser’s referrer header — context that exists at the moment of the first click, long before the form is ever submitted. Unless you actively capture and carry that context through to submission time, it evaporates. Ninja Forms gives you the tools to do this, but you have to wire them up, and the native approach has real blind spots we will get into.

What “lead source” actually means

“Lead source” is shorthand for a few distinct signals. UTM parameters (utm_source, utm_medium, utm_campaign, utm_term, utm_content) are tags you add to links to label a campaign. Ad click IDs (like gclid) are appended automatically by ad platforms for precise click-level tracking. The referrer is the site the visitor came from; the landing page is the first page they hit on yours.

There is also first touch versus last touch — the very first campaign that introduced someone, versus the one active when they finally converted. Good attribution keeps both. If you want to go deeper, we cover the timing trade-offs in our guide to multi-touch attribution and conversion windows.

The three methods at a glance

  • Method 1 — Native hidden fields: use Ninja Forms’ own Hidden field and the {querystring:...} merge tag. Zero plugins, but loses data the moment the URL changes.
  • Method 2 — JavaScript + cookies: custom script captures parameters and persists them across pages, then injects them into hidden fields.
  • Method 3 — Server-side capture: the source is recorded server-side on the first request and attached to every submission automatically.

Method 1 — Native hidden fields in Ninja Forms

Ninja Forms can read URL query string parameters into a field using merge tags. This needs no add-ons and is the right starting point if you just want to prove the concept. Here is the accurate step-by-step using the current Ninja Forms interface.

  1. In WordPress admin, go to Ninja Forms and open the form you want to edit in the form builder.
  2. Click the + button to add a field, and choose the Hidden field type (it sits under the “Other” group of field types).
  3. Open the new field’s settings and find the Default Value setting.
  4. Click the merge tag icon to the right of the Default Value box, then choose Query String from the Other category in the merge tag list.
  5. This inserts {querystring:YOUR_KEY}. Replace YOUR_KEY with the parameter you want to capture — for example {querystring:utm_source}.
  6. Give the field a clear admin label (e.g. “UTM Source”), then repeat steps 2–5 for each parameter: utm_medium, utm_campaign, utm_term, utm_content.
  7. Publish the form. Submissions appear under Ninja Forms → Submissions — choose your form from the “Select a Form” dropdown to see the captured values.

To test, visit the form’s page with parameters appended, e.g. ?utm_source=google&utm_medium=cpc&utm_campaign=spring, submit, and check the entry. Note there is no checkbox called “Populate from URL” — the entire mechanism is the Default Value field plus the {querystring:...} merge tag.

Works when: the visitor lands directly on the form’s page with the UTMs still in the URL and submits there and then. Breaks when: they navigate to another page first, the page is cached, the link strips parameters, or they arrived organically with no UTMs at all.

Why hidden fields lose most of your lead source data

The merge tag reads the current page’s URL at the moment the form renders. That single sentence is the source of nearly every gap in hidden-field attribution. Real visitor journeys rarely cooperate with it.

  • Navigation loss: someone clicks an ad and lands on /offer?utm_source=google, reads it, then clicks through to /contact to fill in the form. The contact page URL has no UTMs, so the hidden field captures nothing.
  • Page caching: caching plugins and CDNs serve a saved copy of the page. The query string can be missing from the cached render, so the merge tag has nothing to read.
  • Safari / ITP and stripping: privacy features and some redirects strip tracking parameters before the page even loads, leaving the field blank.
  • Organic and direct show blank: SEO traffic, direct visits and most referrals carry no UTMs by design. Hidden fields record nothing for them, so a huge slice of perfectly valuable leads come through with empty source fields.

This is the crux of the whole problem, and it is why we wrote a separate deep-dive on why UTM parameters disappear in WordPress. Hidden fields are not broken — they are simply doing exactly what they say, which is reading one URL at one moment. Most lead journeys have moved on by then.

Method 2 — JavaScript + cookies

The next step up is a client-side script. On the visitor’s first page, JavaScript reads the UTM parameters and click IDs from the URL and writes them into a browser cookie. Because the cookie persists, the values are still available when the visitor finally reaches the form page — and a second script copies them out of the cookie into the form’s hidden fields just before submission.

This solves the biggest weakness of Method 1: navigation loss. A visitor can roam your site for ten pages and the source still rides along in the cookie. It is the standard approach behind many tag-manager setups and third-party attribution scripts, and for landing-page-only campaigns it works fine.

Works when: JavaScript runs, cookies are allowed, and the visitor stays in the same browser session. Breaks when: page caching serves stale HTML before the script runs, Safari’s Intelligent Tracking Prevention caps client-side cookie lifetimes (often to seven days or fewer), an ad blocker or consent banner blocks the script, or the visitor clears cookies. You are also adding render-blocking work to the page and another script to maintain.

Method 3 — server-side capture with Lead Source

Here is the mechanism first, because the mechanism is the point. When a visitor makes their very first request to your site, that request reaches your server before any caching layer can swap in a saved page, before client-side JavaScript runs, and before Safari touches a cookie. At that moment, the full URL — UTMs, click IDs and all — plus the referrer header are present in the request itself. Lead Source reads them server-side at that instant and writes a first-party attribution record into your WordPress database.

From then on, the record travels with the visitor as a first-party cookie tied to that server-side store, surviving page navigation and page caching. When the visitor submits any form, Lead Source hooks the Ninja Forms submission save and attaches the captured source to the entry automatically. There are no hidden fields to add, no merge tags to wire up, and no per-form configuration — every form on the site inherits attribution the moment the plugin is active.

Because the capture happens server-side on the first request, it keeps both first touch (the campaign that introduced the visitor) and last touch (the campaign active at conversion), and it records source for organic, direct and referral visitors too — not just UTM-tagged ones. We built it in-house at our agency to solve our own attribution problem, then released it free. The broader approach is covered in our guide to tracking lead source in WordPress forms.

What server-side capture still can’t fix

Honesty matters here. Server-side capture is dramatically more reliable than hidden fields or cookies, but it is not magic. If a parameter is stripped from the URL before the request ever reaches your server — by a redirect chain, an aggressive privacy proxy, or a link that was shared without its UTMs — then nothing running on the server can recover what never arrived. Server-side capture wins because it reads the request at the earliest possible moment, not because it can reconstruct data that was deleted upstream. No tool, ours included, can.

Capturing ad click IDs

UTMs are only half the attribution story. Ad platforms append their own click identifiers automatically, and these are what let you reconcile leads against the platform’s reporting and feed offline conversions back for smarter bidding. Lead Source captures the full set on the first request:

  • Google Ads: gclid, plus gbraid and wbraid (the iOS / privacy-safe variants)
  • Meta (Facebook/Instagram): fbclid
  • Microsoft Advertising: msclkid
  • LinkedIn: li_fat_id
  • TikTok: ttclid

These IDs are long, opaque and easy to lose with the hidden-field approach because they are even more prone to navigation loss than UTMs. Capturing them server-side is the reliable path — there is more detail in our guide to tracking ad click IDs in WordPress.

Comparing the three methods

CapabilityHidden fieldsJS + cookiesLead Source (server-side)
Captures UTMs on landing pageYesYesYes
Survives page navigationNoYesYes
Survives page caching / CDNNoOften noYes
Resists Safari / ITP limitsN/ANoYes
Records organic / direct / referralNoPartialYes
Captures ad click IDs reliablyWeakPartialYes
Keeps first AND last touchNoPartialYes
Per-form setup requiredYes (every field)YesNo
CostFreeFree / dev timeFree

Which method should you use?

Your situationRecommended method
One landing page, one campaign, quick testNative hidden fields
Visitors browse several pages before convertingServer-side capture (Lead Source)
You run paid ads and need click IDs backServer-side capture (Lead Source)
You need organic and direct leads attributed tooServer-side capture (Lead Source)
Heavy Safari / mobile trafficServer-side capture (Lead Source)
You have a developer and a strict no-plugin policyJavaScript + cookies
Multiple forms across the whole siteServer-side capture (Lead Source)

For most agencies and businesses running real campaigns, the honest answer is server-side capture. The hidden-field method is a fine way to understand the mechanics, but it quietly under-reports, and under-reporting is worse than no data because it looks like data.

Setup checklist

  • Decide which signals you need: UTMs, click IDs, referrer, landing page, first vs last touch.
  • Standardise your UTM tagging so values stay clean and consistent across campaigns.
  • Choose your method: hidden fields for a quick test, server-side for production attribution.
  • If using hidden fields, add one Hidden field per parameter with the matching {querystring:...} merge tag.
  • If using Lead Source, install and activate the plugin — no per-form fields required.
  • Test with a real tagged URL, navigate around, then submit and confirm the source lands on the entry.
  • Check submissions under Ninja Forms → Submissions and confirm organic/direct leads are attributed too.

Frequently asked questions

Does Ninja Forms track UTMs by default?

No. Ninja Forms saves the fields on your form, but it does not capture UTM parameters, referrer or landing page unless you add hidden fields with query string merge tags, or use a plugin that captures the source for you.

How do I add a hidden field in Ninja Forms?

Open the form in the builder, click the + to add a field, and pick the Hidden type under “Other”. In its settings, find Default Value, click the merge tag icon, choose Query String, and replace YOUR_KEY with your parameter, e.g. {querystring:utm_source}. Then publish.

Why are my hidden fields blank?

Almost always because the UTM was not in the URL of the page the form was on. If the visitor navigated away from the landing page, the page was cached, the parameter was stripped, or they arrived without UTMs, the merge tag has nothing to read. Server-side capture avoids this by recording the source on the first request.

How do I attribute organic and direct leads?

Organic, direct and referral visits carry no UTMs, so hidden fields leave them blank. Server-side capture reads the referrer and landing page on the first request, so even untagged traffic gets a meaningful source rather than an empty field.

Will this slow my site down?

The JavaScript + cookie method adds client-side script that can compete with page rendering. Server-side capture with Lead Source runs as part of the normal request and writes a small record to the database, so the visitor-facing impact is negligible — there is no render-blocking script to load.

Is this GDPR-friendly, and can I send it to my CRM?

Lead Source uses first-party data stored in your own WordPress database — nothing is shared with a third party — which is a clean position for privacy compliance, though you should still reflect attribution tracking in your privacy policy and consent setup. Because the source is attached to the submission, it flows through whatever Ninja Forms action you use to push entries into your CRM, email tool or spreadsheet.

Stop guessing where your leads come from

If you only ever answer “which campaign produced this lead?” with a shrug, you are flying your ad budget blind. Native hidden fields will get you started, but they quietly drop most of your real journeys. Server-side capture closes that gap by recording the source at the one moment it is guaranteed to exist — the first request.

Install Lead Source free, activate it, and every Ninja Forms submission from that point on arrives with its lead source attached — no hidden fields, no merge tags, no per-form fiddling. It is the tool we built to fix our own attribution, and it now does the same for any WordPress site running Ninja Forms.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *