A visitor can grant analytics or advertising consent, arrive with campaign parameters, and later revoke that consent before submitting a WPForms form. If localStorage, sessionStorage, cookies, hidden fields, data-layer values, and analytics libraries keep using the original identifiers, the visible consent change does not control the actual data path. The test needs a written retention rule for each field rather than deleting everything or keeping everything by habit.
Use this for WPForms lead forms that capture UTM values, click IDs, landing pages, referrers, visitor IDs, or consent state in browser storage and hidden fields.
Quick answer
Define each attribution field by purpose, consent category, storage location, expiry, and lawful retention rule. Grant consent, populate a known canary journey, revoke consent, then inspect storage, hidden fields, network requests, form entries, and analytics events. Disallowed identifiers must be removed or suppressed before the next submission. The form can retain required operational evidence only when the policy explicitly allows it.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
| Consent granted | Campaign visit with known UTM and click ID | Approved fields populate storage, hidden inputs, and allowed destinations |
| Revoke before submit | Same session after consent withdrawal | Disallowed identifiers are purged or suppressed before entry creation |
| Return visit | New tab and browser restart after revocation | Revoked state persists and old identifiers do not reappear |
| Essential evidence | Form submission fields required for service delivery | Only documented necessary fields remain and are not sent to advertising tools |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence to collect | How to verify |
| Approve the per-field collection and revocation policy. | Inventory UTM parameters, gclid, gbraid, wbraid, fbclid, landing page, referrer, session ID, visitor ID, and consent timestamp. | Revocation removes or suppresses every field marked disallowed in each mapped location. |
| Centralize storage reads and writes behind the current consent state. | Map each field to cookie, localStorage, sessionStorage, JavaScript memory, hidden input, server session, form entry, CRM, and analytics destination. | A return visit cannot restore old campaign or click identifiers from another storage layer. |
| Purge or suppress disallowed values on revocation before hidden fields are populated. | Document whether revocation deletes, blanks, expires, pseudonymizes, or stops future use for each location. | The WPForms entry and CRM record contain only fields permitted for the post-revocation state. |
| Block downstream analytics and advertising requests that still contain revoked identifiers. | Run grant, revoke, page refresh, new tab, return visit, and form-submit branches with a unique canary value. | Analytics and ad requests stop or omit restricted values before the next page or form event. |
What to check first
- Inventory UTM parameters, gclid, gbraid, wbraid, fbclid, landing page, referrer, session ID, visitor ID, and consent timestamp.
- Map each field to cookie, localStorage, sessionStorage, JavaScript memory, hidden input, server session, form entry, CRM, and analytics destination.
- Document whether revocation deletes, blanks, expires, pseudonymizes, or stops future use for each location.
- Run grant, revoke, page refresh, new tab, return visit, and form-submit branches with a unique canary value.
- Inspect network requests and destination records, not only browser storage or the visible consent banner.
Field notes
- Have counsel or the business owner approve the retention rule. This test verifies implementation, not legal sufficiency.
- Use synthetic campaign values and test identities that can be deleted cleanly.
- Treat browser, form, CRM, analytics, and ad platforms as separate storage locations with separate proof.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
field,purpose,consent_category,browser_action,form_action,destination
gclid,ads,marketing,delete,blank,do_not_send
utm_source,analytics,analytics,delete,blank,do_not_send
landing_page,service,essential,retain,retain,crm_only
consent_state,compliance,essential,retain,retain,audit_log
Why this usually happens
- Consent tools often block tags but do not know about custom localStorage or hidden-field scripts.
- A page may hydrate hidden fields before the consent state is available or after a stale cache response.
- First-touch logic can deliberately preserve values forever unless revocation is part of its state machine.
Decision rule
Pass only when every disallowed value is absent from browser state, hidden fields, outgoing requests, form entries, and downstream destinations after revocation, while approved essential evidence follows its documented retention rule.
Production verification checklist
- Revocation removes or suppresses every field marked disallowed in each mapped location.
- A return visit cannot restore old campaign or click identifiers from another storage layer.
- The WPForms entry and CRM record contain only fields permitted for the post-revocation state.
- Analytics and ad requests stop or omit restricted values before the next page or form event.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Approve the per-field collection and revocation policy.
- Centralize storage reads and writes behind the current consent state.
- Purge or suppress disallowed values on revocation before hidden fields are populated.
- Block downstream analytics and advertising requests that still contain revoked identifiers.
- Retest grant, revoke, return, and submit paths, then delete the synthetic records.
Mistakes to avoid
- Do not change several production layers at once. Preserve the failing evidence and isolate one variable per test.
- Do not use a successful status or screen message as the only proof. Verify the business outcome and the underlying record.
- Do not leave debug logging, broad credentials, test orders, or temporary exceptions active after the review.
- Do not close the incident without recording the fixture, timestamps, owner, result, and rollback point.
Questions teams ask during testing
Can this be tested on staging?
Start on staging with production-like versions, cache, data shape, and integrations. Finish with one controlled production fixture when the result depends on real routing, provider, or edge behavior.
What evidence should be retained?
Keep the smallest useful set: stable IDs, UTC timestamps, sanitized request or log excerpts, expected result, actual result, version inventory, and the final verification.
When should the change be rolled back?
Roll back when a core revenue, privacy, security, or publishing path fails and the cause cannot be isolated inside the approved maintenance window.
What to tell the client or owner
Give the owner the affected versions, exact fixture, stable IDs, UTC timeline, before and after evidence, decision, rollback point, unresolved risks, and next review date.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, audit WPForms consent and attribution.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Start a clean record after consent regrant
After withdrawal and purge, run the WPForms UTM consent regrant session test so a later grant creates a new permitted record without restoring the withdrawn campaign.
Helpful references