Finding reference

Non-essential tracking continued after reject

Retained runtime evidence showed a reject-style consent interaction followed by classified non-essential request or storage activity in the observed scan scope. Review the evidence context, methodology, common causes, and reviewer questions for this CertScore finding.

Selected finding

Non-essential tracking continued after reject

HighGood evidenceDirect observationConsentSeen on ~1% of scanned top sites

This pattern appears less often in the calibration set, but it can be higher-priority when observed because it concerns behavior after an explicit reject-style interaction rather than only initial consent timing.

Benchmark frequency is directional market context only. It is not a compliance benchmark, legal conclusion, or severity score. Rare findings may be top-ranked only when retained evidence is strong; common findings may remain medium when evidence is automated or context-dependent. Rarity is not severity, and prevalence is not compliance risk.

Observed

Retained runtime evidence showed a reject-style consent interaction followed by classified non-essential request or storage activity in the observed scan scope.

Why this matters

When non-essential tracking or storage continues after a reject-style interaction, reviewers may need to confirm whether the reject action succeeded, whether consent state propagated correctly, and whether downstream tags or vendors honored the intended choice. For engineering and privacy teams, this signal can help identify CMP-to-tag-manager wiring, consent-mode propagation, queued beacons, or vendor-suppression issues.

Detection methodology

CertScore records consent interaction events, consent-state observations, runtime requests, cookie/storage activity, vendor classification, and coverage context where available. This finding is surfaced when retained evidence shows a reject-style interaction followed by a classified non-essential request or storage artifact after that interaction within the observed scan scope. CertScore treats post-reject tracking evidence as a review signal. The scanner does not determine legal status, consent validity, vendor responsibility, or compliance status. Reviewers should confirm the reject interaction succeeded, whether the activity began before or after the reject action, whether the post-reject artifact was non-essential, whether queued or delayed beacons explain the timing, and whether CMP, consent-mode, tag-manager, or vendor configuration affected the result.

Confidence semantics: Good when retained runtime evidence includes a reject-style interaction, post-reject timing, classified non-essential request or storage artifact, stable runtime anchor, and usable coverage; stronger when retained evidence also includes interaction success, consent-state transition, pre/post comparison, vendor attribution, repeated examples, and enough detail for manual verification. Manual review is still needed for reject success, queued beacons, purpose, necessity, CMP configuration, and remediation quality.

Top-finding calibrationWhat must be retained to surface, top-rank, demote, or suppress this finding.

Minimum to surface

Reject interaction plus post-reject classified non-essential request or storage.

High confidence requires

Reject success, pre/post sequence, and artifact classification.

Top ranking requires

Post-reject advertising, replay, identifier sync, or repeated post-reject artifacts.

Demote or suppress when

Reject button present but not clicked.
Unknown essentiality.
Queued pre-reject beacon likely.

These rules describe ranking calibration for already-projected findings. They do not create findings from raw signals.

Example evidence

Post-reject runtime artifact

artifact=req_002
role=finding_supporting_artifact
url=https://example.com/
reject_action_timestamp_ms=2600
reject_action_observed=true
reject_interaction_status=observed [manual_review_recommended]
post_reject_request_timestamp_ms=4120
request_origin=https://analytics.example
request_path=/collect [query_redacted=true]
vendor_category=analytics
essentiality=non_essential
review_caveat=manual review should confirm reject success, queued-beacon timing, purpose, necessity, and CMP/vendor configuration

Review context

pre_reject_activity_observed=true
post_reject_activity_observed=true
consent_state_transition=manual_review_recommended
possible_source=cmp_to_tag_manager_propagation
coverage_status=usable
manual_review_needed=true

What should not count by itself

reject_button_present=true [insufficient_without_interaction]
vendor=Example Analytics [insufficient_without_post_reject_artifact]
post_reject_request_unknown_purpose [audit_only_until_classified]
tracking_before_reject_only [insufficient_for_persistence]

View redacted sample JSON

Redacted sample JSON

{
  "findingId": "reject_tracking_persists_after_reject",
  "label": "Non-essential tracking continued after reject",
  "category": "Consent",
  "criticality": "high",
  "evidenceConfidence": "good",
  "directVsInferred": "direct_observation",
  "evidence": {
    "summary": "Retained runtime evidence showed a reject-style consent interaction followed by classified non-essential request or storage activity in the observed scan scope.",
    "examples": [
      {
        "title": "Post-reject runtime artifact",
        "lines": [
          "artifact=req_002",
          "role=finding_supporting_artifact",
          "url=https://example.com/",
          "reject_action_timestamp_ms=2600",
          "reject_action_observed=true",
          "reject_interaction_status=observed [manual_review_recommended]",
          "post_reject_request_timestamp_ms=4120",
          "request_origin=https://analytics.example",
          "request_path=/collect [query_redacted=true]",
          "vendor_category=analytics",
          "essentiality=non_essential",
          "review_caveat=manual review should confirm reject success, queued-beacon timing, purpose, necessity, and CMP/vendor configuration"
        ]
      },
      {
        "title": "Review context",
        "lines": [
          "pre_reject_activity_observed=true",
          "post_reject_activity_observed=true",
          "consent_state_transition=manual_review_recommended",
          "possible_source=cmp_to_tag_manager_propagation",
          "coverage_status=usable",
          "manual_review_needed=true"
        ]
      },
      {
        "title": "What should not count by itself",
        "lines": [
          "reject_button_present=true [insufficient_without_interaction]",
          "vendor=Example Analytics [insufficient_without_post_reject_artifact]",
          "post_reject_request_unknown_purpose [audit_only_until_classified]",
          "tracking_before_reject_only [insufficient_for_persistence]"
        ]
      }
    ]
  }
}

Regulatory review context

Consent effect: tracking persisted after reject

Retained runtime evidence showed post-reject request or storage signals that may be relevant to consent enforcement, cookie/tracker, storage/access, transparency, and vendor-governance review. Applicability depends on reject success, timing, purpose, consent state, necessity, exemptions, jurisdiction, and manual review.

ePrivacy cookie/storage refusal effect reviewGDPR consent effect and withdrawal reviewCCPA/CPRA opt-out honoring reviewEU GDPR/ePrivacy post-reject tracking reviewUK PECR / ICO post-reject cookie reviewU.S. privacy opt-out effect review

View applicability notes

Legal and regulatory frameworks

ePrivacy cookie/storage refusal effect reviewRetained evidence suggests non-essential cookies, storage, or similar technologies may remain active after a refusal or reject action.
GDPR consent effect and withdrawal reviewConsent-effect review may be relevant where consent is used for personal-data processing and a refusal or withdrawal should affect downstream processing.
CCPA/CPRA opt-out honoring reviewThe reject or opt-out interaction may affect sale, sharing, or cross-context behavioral advertising choices for California users.

Jurisdictional contexts

EU GDPR/ePrivacy post-reject tracking reviewEU/EEA users and cookies, tracking, analytics, advertising, or profiling may be in scope depending on purpose, consent state, jurisdictional context, and manual review.
UK PECR / ICO post-reject cookie reviewUK users and non-essential cookies or similar technologies may be in scope depending on purpose, consent state, jurisdictional context, and manual review.
U.S. privacy opt-out effect reviewThe flow claims to honor privacy choices, sale/share opt-outs, targeted-advertising opt-outs, or GPC-style signals.

This finding does not determine legal status, consent validity, vendor responsibility, necessity, exemption status, or compliance status. Review the retained interaction evidence, post-reject runtime anchors, vendor purpose, queued-beacon timing, consent-state propagation, regional configuration, and applicable exemptions.

Evidence standard

Strong

Retained evidence includes a reject-style interaction event with timestamp or interaction-state context.
Retained evidence includes a classified non-essential request or storage artifact after the reject interaction.
Evidence includes stable runtime anchors such as URL origin and path with query redacted, cookie or storage key with value redacted, resource type, vendor or category, and timestamp.
Evidence distinguishes post-reject activity from activity that began or was queued before the reject action where available.
Coverage context indicates the interaction and post-reject observation were not materially blocked or unreliable.

Good

Retained evidence shows a reject-style interaction and post-reject non-essential artifact, but interaction-success confirmation or pre/post comparison is less complete.
The retained example is enough for a reviewer to inspect timing, vendor or category, and artifact details manually.
The evidence is likely relevant to reject-enforcement review, but queued beacons, strictly necessary activity, purpose, and CMP propagation require manual review.

Audit-only

Reject control was present but not clicked or no reject-style interaction was retained.
Post-reject request exists but essentiality, purpose, or timing relative to reject is unclear.
Vendor name, CMP configuration, or policy text suggests possible persistence, but no retained post-reject runtime artifact supports it.

Insufficient

Reject button exists but was not interacted with.
Failed or ambiguous reject interaction without post-interaction runtime evidence.
Tracking observed only before reject.
Vendor name alone.
Snapshot boolean without post-interaction timeline and retained runtime anchors.
Post-reject request with unknown essentiality and no purpose classification.
Claims about legal status, compliance status, consent validity, vendor responsibility, or tracking lawfulness based only on automated evidence.

Evidence levels explain how CertScore treats retained runtime artifacts. They are not legal conclusions.

Common causes

Reject event is not propagated from CMP to tag manager or vendor scripts.
Previously loaded scripts continue sending queued or delayed beacons after reject.
Consent mode is configured after vendor tags initialize.
Cookies or storage are not cleared, suppressed, or scoped after rejection.
Region, language, returning-user state, or CMP configuration changes reject behavior.

Common remediation approaches

Teams commonly replay the reject path with the browser network panel open and compare pre-reject and post-reject request timing.
CMP-to-tag-manager propagation is often reviewed to confirm that reject state reaches the data layer, consent mode, and vendor trigger conditions.
Queued or delayed beacons may need special review because a request can fire after reject even if it was initiated before the choice.
Cookie and storage behavior should be reviewed to confirm whether non-essential identifiers are cleared, suppressed, or not written after reject.
Regional CMP variants should be tested separately where reject behavior differs by jurisdiction or language.

Limitations and cautions

This finding is an automated reject-enforcement review signal, not a legal conclusion, certification, compliance determination, or determination of consent validity.
Automated evidence may not fully determine whether the reject interaction succeeded, whether a beacon was queued before reject, or whether a vendor was responsible for post-reject activity.
Some post-reject activity may be strictly necessary, security-related, fraud-prevention, load-balancing, or otherwise context-dependent.
Consent state can vary by region, browser state, prior choices, A/B tests, CMP configuration, login state, and page path.
Automated evidence may miss server-side behavior, later user-triggered behavior, blocked resources, or vendor behavior outside the scan scope.
Manual review is needed to confirm reject success, purpose, necessity, consent-state propagation, vendor configuration, and remediation quality.
CertScore redacts or avoids retaining full query strings, cookie values, identifiers, and sensitive payloads while preserving stable anchors needed for review.
Automated findings may contain errors and should be reviewed with the retained evidence.
Not detected means not observed in the scan scope; it is not proof of absence.
Findings are runtime evidence and public-surface observations for review, not legal conclusions.

Reference notes

CertScore uses findings, evidence, signals, and observations consistently: signals are raw runtime or page-surface events, evidence is retained support, observations are interpreted evidence context, and findings are promoted review items.
Findings are runtime evidence and public-surface observations for review. Observed signals may surface possible concerns, but review is recommended before operational or legal reliance.
Finding reference content is reviewed periodically and updated when material guidance changes. CertScore monitors guidance families such as EDPB consent and ePrivacy materials, ICO cookie guidance, CNIL tracker recommendations, FTC privacy and dark-pattern materials, and relevant accessibility guidance where applicable.
EDPB consent guidance is relevant to consent quality and affirmative indication where consent is relied upon.
EU ePrivacy cookie/tracker principles are relevant to storing information or gaining access to information on user terminal equipment.
ICO cookie and similar technologies guidance is relevant to active consent, clear explanation, and essential-cookie exceptions.
CNIL cookie/tracker and analytics guidance is relevant to tracker consent and limited analytics exemptions.
FTC dark-pattern and commercial-surveillance materials may be relevant to hidden tracking or unclear user-choice review, but this finding does not determine deception, unfairness, or legal status.
Prevalence labels use the Tranco top 1-2500 calibration set, an approximately 2,505-scan directional calibration set.

Non-essential tracking continued after reject