This page is the reference for what SmartDingo Form Tracker captures in the browser: the full list
of tracked fields per plan, how first-touch and last-touch attribution differ, how the referrer
channel is worked out, and where the data is stored. For mapping these values into your form, see
Field mapping & auto-fill.

How tracking works

Everything is captured client-side by the tracker script (sdft-tracker.js) that loads on your
pages. On each page view it reads the URL query string, the referrer, and the browser environment,
then writes the enabled values into browser storage under an sdft_ key prefix. When a mapped form
is submitted, the stored values are filled into your form fields (and, on paid plans, sent to the
Leads page).

Only enabled fields are captured — turn fields on under SmartDingo Form Tracker → Settings →
Tracking Fields. Fields above your plan are shown but locked.

Note Because capture happens in the browser, values only exist once the tracker has run and
(if you use a consent mode) consent has been granted. Until then, data is buffered in memory and
written once consent arrives. See GDPR & consent.

First-touch vs last-touch

Attribution decides what happens when a value is already stored and a new page view brings a new
one:

• Last-touch — overwritten by the most recent visit. The five standard UTMs plus utm_id are
  rewritten together whenever any UTM parameter is present in the URL (parameters missing from
  the new URL are blanked). Ad click IDs and ref/affiliate_id are overwritten only when that
  specific parameter is present; otherwise the stored value is preserved.
• First-touch — written once and never overwritten, so it preserves the visitor’s original
  entry point across their whole history. This covers the first_utm_* set, landing page, device
  type, visit timestamp, referrer URL, search term and referrer category.
• Cumulative / at-submit — recomputed as the visitor browses (visited pages, page and visit
  counts) or calculated at the moment of submission (conversion page, session duration).

Tracked-field reference

12 fields on Free, +14 on Starter, +8 on Pro (34 total). Badges show the plan a field
requires; unbadged fields are on every plan.

Note The Visited Pages list is capped at 10 (Free) / 30 (Starter) / 50 (Pro) entries;
once full, the oldest paths drop off.

How the referrer category is derived

Referrer Category (Starter) turns the raw referrer and URL into one marketing channel. It is
evaluated in this order:

1. email — if utm_medium is email or e-mail.
2. Paid vs organic — a “paid” signal means any of these click IDs is on the URL:
   gclid, gbraid, wbraid, msclkid, fbclid, li_fat_id, twclid, ttclid, gad_source.
3. No referrer — paid_search if a paid signal is present, otherwise direct.
4. Search engine referrer (Google, Bing, Yahoo, DuckDuckGo, Baidu, Yandex, Ecosia, Ask) —
   paid_search with a paid signal, otherwise organic_search.
5. Social referrer (Facebook, Instagram, X/Twitter/t.co, LinkedIn, Pinterest, TikTok, Reddit,
   YouTube, Snapchat, Threads) — paid_social with a paid signal, otherwise organic_social.
6. Anything else — referral.

So the possible values are email, paid_search, organic_search, paid_social,
organic_social, referral and direct. Categorisation is based on a built-in list of well-known
domains; a niche search engine or network not on the list is reported as referral.

Device detection & search-term limitations

Be realistic about these two fields — both are best-effort.

Warning Device Type is inferred from the browser user-agent string. It is a coarse
desktop / mobile / tablet guess, not a device database: spoofed or unusual user agents, and
some tablets that identify as desktop, can be misclassified.

Warning Search Term only works when the referring URL actually contains a q= or p=
query parameter. Modern search engines (Google in particular) strip the query from the referrer
for privacy, so this field is frequently empty even for genuine organic-search visits. Treat a
populated value as a bonus, not something to rely on.

Where data is stored

The tracker uses one of two browser stores, chosen on the Settings page:

On the Free plan localStorage is locked, so tracking is forced into sessionStorage.
Starter and Pro can pick either backend.

Note Two values are the exception and always use localStorage, even when sessionStorage
is selected: the visitor identifier and the visit-count total. That is what lets
Visitor Type and Visit Count recognise a returning visitor across sessions.

If the browser blocks storage entirely — Safari Private mode, hardened privacy settings — the
tracker falls back to an in-memory store so the current page still works. That fallback holds
nothing between page loads.

What persists vs what’s lost

• With localStorage (Starter+): first-touch attribution, visit counts and returning-visitor
  detection survive across sessions, tabs and browser restarts. This is what makes multi-visit
  attribution meaningful.
• With sessionStorage (Free, forced): everything except the always-localStorage visitor
  identifier and visit-count total is wiped when the session ends. First-touch values effectively
  mean “first page of this session”, and a visitor returning in a new session starts fresh.
• With the in-memory fallback: data lives only for the current page load and is gone on the next
  navigation or reload.

GDPR Stored visitor data becomes personal data once it is tied to a submitted form. Pick a
storage backend and consent mode deliberately — see
GDPR & consent.

Next steps

• Field mapping & auto-fill
• Supported form plugins
• Managing leads
• GDPR & consent