SmartDingo Form Tracker fails silently — a stale cache, an ungranted consent, or a
mismatched selector all look identical to “the plugin is broken.” This page is organized as
symptom → likely cause → fix so you can jump straight to what you’re seeing.

Note Your first move for almost any tracking problem is the Debug overlay. Turn it on
under SmartDingo Form Tracker → Tools → Debug Mode, then reload the form page while logged
in as an administrator. The overlay (visible only to admins) shows the storage type, consent
status, how many fields are buffered, every stored value, and — per mapping — whether the target
element was FOUND or NOT FOUND. Most causes below are visible at a glance there.

Tracking isn’t recording anything

No values are stored and the Debug overlay doesn’t appear at all.

The Leads page is empty / no leads appear

Tracking works (values are stored and auto-filled), but submissions don’t turn into leads.

1. Lead capture isn’t available or isn’t on. Lead capture is a paid feature. On the free
   plan the toggle is shown but disabled. (Starter)
   • Confirm your Starter/Pro license is active, then tick Enable lead tracking on the
     Privacy page.
2. A cache is freezing the security token. Each submission is authenticated by a one-time
   HMAC token that is only valid for 5 minutes. On a full-page-cached site that token is
   frozen in the cached HTML, so every visitor POSTs an already-expired token and the server
   rejects it.
   • Purge every cache (page cache and CDN). The plugin fetches a fresh token right before
     each submission, but only once visitors are served the new, un-cached script.
3. The form plugin’s success event isn’t recognized. Leads are captured when your form
   plugin fires its “submission succeeded” event. This is reliable for the supported AJAX form
   plugins and best-effort for everything else. Redirect-style confirmations (the page navigates
   away on submit) are caught by a sendBeacon safety-net but cannot be guaranteed.
   • Confirm your form plugin is on the supported list and submits via AJAX. See
     Supported form plugins.
4. The form isn’t mapped. Only forms that contain a mapped selector are logged (see the last
   section on this page).
5. Consent wasn’t granted at submission time — no consent means no stored data to attach to
   the lead.

Warning Always confirm with one real test submission before assuming leads are working:
submit with ?utm_source=sdft-test, check the Leads page, then delete the test lead.

Auto-fill isn’t populating my field

A tracking value is stored (visible in the Debug overlay) but your form field stays empty.

My license won’t activate

License activation is handled by Freemius on the connection screen shown after activation.

• Paste the key into SmartDingo’s own activation field only — it’s in your purchase email and
  on your account page. Never enter it into an unrelated form or a URL.
• Activation needs to reach the Freemius servers. A strict firewall, security plugin, or WAF
  can block that outbound call. Temporarily relax it, or ask your host, and retry.
• The key may already be in use on another site. Deactivate it on the old site first, then
  activate here. See Licenses & plans.
• After a successful activation the screen shows your plan name and the paid features unlock. If
  the plan still reads as Free, reload the admin and re-check the connection.

Third-party plugins or a WAF are interfering

Caching, optimization, and security layers are the most common cause of “it worked yesterday.”

• Caching / optimization plugins (LiteSpeed, WP Rocket, WP Super Cache, host or CDN cache)
  freeze the 5-minute lead token in cached HTML, causing rejected submissions and empty Leads
  pages. Purge all caches after every deploy or settings change, then confirm the current
  ?ver= script is being served.

• ModSecurity / a WAF returning “406 Not Acceptable” can block two things:

  • Saving the Settings page (the settings payload trips a WAF rule), or
  • loading the tracker asset URLs.

  Ask your host to whitelist the plugin’s requests (exclude the offending rule ID from the WAF
  audit log for your admin and for the frontend/js/ asset paths).

Note After changing any WAF or cache setting, re-run the end-to-end test in
Before you go live.

Some submissions are rejected

A visitor reports their form “didn’t go through,” or leads are intermittently missing.

• Per-IP rate limiting. To prevent abuse, the lead endpoint accepts a maximum of
  5 submissions per minute and 20 per hour per IP address. Beyond that, submissions are
  rejected with a “too many submissions” response.
• This mainly affects shared office networks and NAT’d connections, where many people share
  one public IP. It only limits lead logging — the visitor’s form still submits normally through
  your form plugin; only the lead record is skipped.
• A rejected lead can also mean an expired or already-used token (see the caching section
  above) or a tripped honeypot (bot-like submissions are dropped by design).

Only some of my forms are tracked

This is expected behavior, not a bug.

• Only mapped forms are logged. A form with no configuration pointing at it — and no mapped
  selector present on it — is simply ignored. Add a configuration (or a hidden field such as
  input[name="utm_source"]) for each form you want to capture.
• One configuration per form. Configurations don’t stack on a single form; if you need to
  track several forms, create a separate configuration for each, with selectors unique to that
  form.
• Remember the per-plan limit on form configurations: 1 (Free) / 5 (Starter) / 25 (Pro).
  Configurations above your plan’s limit are ignored on the frontend.

Next steps

• Before you go live
• Supported form plugins
• Field mapping & auto-fill
• FAQ