This page explains how SmartDingo Form Tracker handles consent, exactly what data it stores
(and where), how long it keeps it, and what removing the plugin cleans up. It closes with
practical GDPR guidance — decision support, not legal advice.

Note SmartDingo Form Tracker captures visitor and campaign data in the browser. On its own
that data is fairly anonymous, but as soon as it is attached to a submitted form (a name, an
email, a phone number) it becomes personal data. Treat the whole capture-and-store path as
in-scope for privacy law.

The three consent modes

Choose a consent mode on the Privacy page. It controls when the tracker is allowed to write
data to browser storage. All three modes are available on every plan.

Off

Tracking runs the moment the page loads, with no consent check. Fast and simple, but it stores
visitor data for everyone.

GDPR “Off” is the least compliant option. If you are in the EU/UK or otherwise subject to
consent rules, pick one of the consent modes below. The Privacy page shows a warning banner while
“Off” is selected.

WP Consent API

The tracker waits for the standard WordPress Consent API to report statistics consent
(wp_has_consent('statistics')), and also recognizes Complianz’s native signal as a fallback. It
listens for the consent-change event and polls briefly as a safety net, so tracking begins the
instant the visitor accepts. This mode is compatible with Complianz, CookieYes,
Cookiebot, and any other plugin that implements the WordPress Consent API.

Warning This mode only works if a compatible consent plugin is actually active on the site.
If none is present, consent is never detected, and nothing is ever tracked or stored. Verify with
the Debug overlay (Tools) that consent flips to granted after you accept your banner.

Manual

The tracker checks for a cookie you name, and starts only when that cookie equals the value you
specify (for example, cookie cookie_consent with value accepted). Enter both on the Privacy
page under Manual.

Warning Manual mode fails closed: if you leave the Cookie Name blank, consent can
never be satisfied and tracking never starts. Always fill in both the name and the value, and
confirm they match exactly what your banner writes.

How data is buffered before consent

When a consent mode is active and consent has not yet been granted, the tracker still reads
UTM parameters and other signals from the URL — but instead of writing them to browser storage, it
holds them in an in-memory buffer. The moment consent is granted, the buffer is flushed:
the values are written to storage, and any mapped form fields are re-filled so nothing is lost for
that visit.

Because the buffer lives only in page memory, it is not persisted. If the visitor closes or
reloads the page before granting consent, the buffered values are discarded (on reload the tracker
simply reads the URL again). Nothing reaches storage or your database until consent is granted.

What is stored, where, and for how long

In the visitor’s browser

Captured tracking values are kept in the visitor’s own browser storage, each key prefixed with
sdft_ (for example sdft_utm_source, sdft_landing_page). Which store is used depends on your
plan and setting:

Note Regardless of the store you select, the visitor identifier (sdft_visitor_id) and
the visit counter (sdft_visit_count_total) always use localStorage. They have to persist
across sessions to recognize returning visitors and deduplicate leads. If you choose
sessionStorage for privacy reasons, be aware these two keys are still long-lived.

If a browser blocks storage entirely (for example Safari private mode), the tracker falls back to a
temporary in-memory store that vanishes on navigation.

In your WordPress database (Starter)

When lead tracking is enabled on a paid plan, each submission of a mapped form is written as a
row in the wp_sdft_leads table (the prefix matches your install). A row holds:

• Contact details detected in the form: email, name, phone, plus a JSON copy of the other
  visible fields the visitor filled in.
• Attribution: UTM parameters (last- and first-touch), referrer category, landing page, device
  type, form name, and the page the form was on.
• A visitor identifier and a created_at timestamp.

GDPR The stored JSON can contain anything the visitor typed into visible form fields —
including free-text messages. Only submit-buttons, hidden fields, and password fields are skipped.
Factor this into your privacy notice and your data-subject-access process.

What is not stored

• No raw IP address. For rate limiting the plugin computes a one-way hash of the IP and keeps it
  only in a short-lived transient (a few minutes to an hour). The hash is never written to the leads
  table and cannot be reversed to the original address.
• No user-agent string. The browser’s user agent is read on the visitor’s device only to
  classify the device as desktop / mobile / tablet; the raw string is never sent or stored.

Lead retention / auto-delete (Starter)

On the Privacy page, set Auto-delete leads after N months:

• 0 (the default) — never auto-delete; leads are kept until you remove them manually.
• 1–120 — a daily cleanup task deletes any lead older than that many months.

GDPR Storing personal data “just in case” is hard to justify. Set a retention period that
matches how long you genuinely use leads (for many sites 12–24 months is reasonable), so old data
is pruned automatically.

What uninstalling removes

Deleting the plugin (not just deactivating it) triggers a full cleanup:

• All plugin options — tracking fields, form configurations, storage type, consent mode and
  the manual cookie name/value, lead-tracking and retention settings, and chart colors.
• The wp_sdft_leads table is dropped, removing every stored lead.
• The daily cleanup task is unscheduled and per-user dashboard preferences are removed.

Note Deactivating the plugin changes nothing — all settings and leads are preserved so you
can reactivate without loss. Only Delete performs the cleanup above.

Warning Uninstall cannot reach data that lives in your visitors’ browsers. sessionStorage
keys clear when the tab closes; localStorage keys (including sdft_visitor_id) remain in each
visitor’s browser until they clear it. This is normal for client-side storage and holds no
personal data on your server.

Practical GDPR guidance

This is decision support, not legal advice — confirm specifics with your own advisor.

• Pick a consent mode deliberately. If EU/UK visitors can reach your forms, prefer WP Consent
  API (or Manual) over Off, and verify consent actually gates tracking with the Debug
  overlay.
• Document the plugin in your privacy policy. Disclose that you capture campaign/visitor data
  and store form submissions as leads, and name your retention period.
• Set a retention period. Don’t leave auto-delete at 0 unless you have a reason to keep leads
  indefinitely.
• Honor data-subject requests. Leads are searchable by email, name, and phone on the Leads page,
  so you can find and delete an individual’s records — see
  Managing leads.
• Minimize what you capture. Only enable the tracking fields you actually use; every extra field
  is more personal data to justify.

Next steps

• Capturing leads
• Managing leads
• Before you go live
• Settings reference