- Use a fresh context for each scenario rather than reusing an accepted session.
- Confirm the interaction before interpreting an after-rejection result.
- Describe observations and uncertainty separately.
Define the page and the question
Start with a website you control or are authorized to test. Record the exact page, intended market and browser conditions. Decide what you need to learn: whether a known analytics host is contacted before a decision, whether rejection changes the requests, or whether a new release behaves differently.
A test of one landing page does not cover the whole site. Checkout, embedded media and authenticated sections may initialize different components. Write down these boundaries before interpreting the result.
Keep the three scenarios independent
Use fresh browser contexts for no choice, reject and accept. Browser contexts isolate state such as cookies and web storage, making it easier to avoid carrying an earlier choice into a later scenario. Reusing the same accepted session can make a rejection test misleading.
Use comparable observation windows and page actions. Waiting longer in one scenario creates a different opportunity to observe delayed requests. An independent context does not make geography, server experiments or network conditions identical.
Confirm what the banner interaction did
Record whether the relevant control was found and whether the interaction could be confirmed. Button text can differ by language, the control may sit inside a frame, or a preference panel may need an additional save action.
If the interaction fails, label that scenario untested. Do not rename it rejected simply because the automation attempted a click. This distinction prevents a technical failure from becoming a false positive about tracking after refusal.
Read the observations as evidence, not a verdict
Compare observed hostnames, cookie names and storage keys across the scenarios. A request before a decision is evidence that a destination was contacted in that run. It does not by itself establish the data payload, purpose, legal basis or every possible subsequent action.
The illustrative table below separates the interaction state from the observation. The failed acceptance attempt cannot support a conclusion about what acceptance enables.
| Scenario | Interaction | Observed outcome |
|---|---|---|
| No choice | Not attempted | analytics.example contacted |
| Reject | Confirmed | analytics.example not observed |
| Accept | Failed | Untested; no acceptance conclusion |
Turn the result into a reproducible issue
Give the engineer the page, scenario, time and relevant observation. Ask them to trace the initiating script or tag and compare it with the intended configuration. Confirm the result with a second controlled run after any change.
Keep uncertainty in the report: missed interactions, failed requests, limited waiting time and untested pages all affect coverage. TruCookie describes technical behavior; it does not certify a website as legally compliant.
Common questions
Does rejecting cookies mean no external request should occur? Not necessarily. Requests can support essential page functions and need contextual classification. The test should report the observation without automatically equating all external hosts with tracking.
Can I prove a site is tracker-free with one clean run? No. A run is bounded by the page, context, actions and observation window. A service might load only after another action or under different visitor conditions.