Start here
Before You Fix It: What This Check Means
Reject-path controls ensure optional tracking stays off after someone says no. In plain terms, once someone rejects tracking, optional tracking should remain off. Scavo uses browser interaction evidence to evaluate one control.
Why this matters in practice: this signal influences reliability, trust, and diagnosability of your production setup.
How to use this result: treat this as directional evidence, not final truth. This result reflects what was observable at scan time and should be verified in your own production context. First, confirm the issue in live output: verify directly in live production output with browser/network tools Then ship one controlled change: Persist reject state before optional scripts can initialize. Finally, re-scan the same URL to confirm the result improves.
TL;DR: Trackers keep running after users click reject, directly violating GDPR consent requirements and triggering enforcement risk.
The EDPB Cookie Banner Taskforce confirmed that when users reject cookies, all third-party tracking must stop immediately (EDPB Report, 2023-2024). Sweden's data authority ruled in March 2025 that even making the "accept" button more visually prominent than "refuse" violates compliance rules. If your trackers persist after rejection, you're not just non-compliant — you're creating audit evidence against yourself.
What Scavo checks (plain English)
Scavo uses browser interaction evidence to evaluate one control:
LC-S3: after a reject action, do non-essential request or storage signals still appear?
How outcomes are assigned:
Fail: known non-essential hosts or tracking-style storage keys appear after rejectInfo/Inconclusive: browser probe or reject action could not complete reliablyPass: no high-confidence non-essential signals observed post-reject
In demo mode, Scavo warns that full interactive runtime validation is limited.
How Scavo scores this check
Scavo assigns one result state for this check on the tested page:
- Pass: baseline signals for this check were found.
- Warning: partial coverage or risk signals were found and should be reviewed.
- Fail: required signals were missing or risky behavior was confirmed.
- Info: Scavo could not gather enough reliable evidence on this run to score pass/fail confidently.
In your scan report, this appears under What failed / What needs attention / What is working for legal_post_reject_tracking, followed by Recommended next steps and Technical evidence (for developers) when needed.
- Scan key:
legal_post_reject_tracking - Category:
LEGAL_COMPLIANCE
Why fixing this matters
A reject button that does not hold under reload/navigation is one of the fastest ways to lose user trust.
It also creates compliance and support risk because your UI promise and runtime behavior diverge.
If you are not technical
- Test reject on a clean browser session and refresh the page.
- Ask your team for proof that optional trackers remain off after reject.
- Ensure the same behavior holds on high-traffic templates, not just homepage.
- Re-run Scavo and verify this check improves.
Technical handoff message
Copy and share this with your developer.
Scavo flagged Post-reject tracking controls (legal_post_reject_tracking). Please enforce reject state across frontend, tag manager, and storage paths so non-essential requests/identifiers remain blocked after reject (including reload/navigation). Share evidence and re-run Scavo.If you are technical
- Persist reject state before optional scripts can initialize.
- Ensure tag-manager triggers respect reject state across route changes.
- Block optional server-side event forwarding when reject is active.
- Re-apply consent state on hydration/reload in SPA frameworks.
- Add regression tests that simulate reject then reload.
How to verify
- In incognito, trigger reject and observe network/storage.
- Refresh and navigate to another route; verify reject still holds.
- Confirm no non-essential hosts fire after reject.
- Confirm tracking-style keys are absent post-reject.
- Re-run Scavo and review
LC-S3details.
What this scan cannot confirm
- It is not a legal determination for every jurisdiction.
- It may be inconclusive if interaction automation cannot complete.
- It cannot guarantee every hidden/in-house tracker pattern is recognized.
Owner checklist
- [ ] Assign owner for reject-state enforcement across stack layers.
- [ ] Include reject-flow regression tests in release QA.
- [ ] Review after CMP updates and tag-container edits.
- [ ] Keep a rollback path for consent regressions.
FAQ
Why can this fail even if pre-consent checks pass?
Because this check validates behavior after an explicit reject interaction, which is a separate control path.
What usually causes post-reject regressions?
Route transitions, late script injection, and server events that ignore current consent state.
Is one-page verification enough?
No. Verify on multiple key templates and at least one navigation step after reject.
What is the priority fix order?
Enforce reject in tag runtime first, then storage persistence, then server-side forwarding controls.
Sources
- EDPB Guidelines 05/2020 on Consent
- ICO: Cookies and similar technologies
- California AG: CCPA overview
- California Penal Code §631 (CIPA)
This guide is operational guidance, not legal advice.
