DEV Community

Cover image for How We Tested What an Ecommerce Website Loads After Cookie Consent Is Declined
Auditzo
Auditzo

Posted on • Originally published at auditzo.com

How We Tested What an Ecommerce Website Loads After Cookie Consent Is Declined

#privacy #webdev #security #cookie

A cookie banner can display an Accept button and a Decline button.

That does not automatically tell you whether the website’s scripts, tags, cookies, browser storage, and third-party requests actually respect those choices.

To verify the implementation, you have to test what the browser does in each consent state.

For a US ecommerce beauty website, we compared three isolated browsing sessions:

Session A: No consent choice made
Session B: Accept selected
Session C: Decline selected
Enter fullscreen mode Exit fullscreen mode

Each session followed the same ecommerce journey:

Homepage
  → Product page
  → Cart
  → Checkout before payment
Enter fullscreen mode Exit fullscreen mode

We then compared:

  • Cookies
  • localStorage
  • sessionStorage
  • Network requests
  • Third-party domains
  • Screenshots
  • Journey timing
  • Consent-state behavior

The declined session showed a materially smaller cookie footprint than the accepted session.

However, some browser storage entries, cookies, and third-party network requests were still observed after Decline.

That did not automatically mean the website was tracking users unlawfully.

It meant those items needed to be classified by purpose, vendor, consent category, and journey stage.

Why a Cookie Scanner Was Not Enough

Automated cookie scanners are useful for discovery.

They can often identify:

  • Cookie names
  • Cookie domains
  • Expiration periods
  • First-party and third-party cookies
  • Known analytics or advertising vendors
  • Possible cookie categories

But a scanner may not clearly explain:

  • Whether a cookie appeared before consent
  • Whether it appeared only after Accept
  • Whether it remained after Decline
  • Which page triggered it
  • Whether a cart or checkout action created it
  • Whether the site used browser storage instead
  • Whether a third-party request occurred without setting a cookie
  • Whether the result can be traced back to evidence

For ecommerce websites, page context matters.

A homepage may load a consent platform and basic site functionality.

A product page may activate recommendation, analytics, or advertising services.

A cart may introduce persistence and ecommerce-measurement systems.

Checkout may activate payment, security, tax, fraud-prevention, shipping, and session-continuity services.

A homepage-only scan can therefore miss important behavior.

The Consent-State Test Model

We treated consent testing as a state-comparison problem.

Conceptually, the audit model looked like this:

Consent state
    ×
Journey stage
    ×
Storage mechanism
    ×
Vendor
    ×
Evidence
Enter fullscreen mode Exit fullscreen mode

The three consent states were tested separately.

Session Consent state Objective
Session A No choice made Establish the pre-consent baseline
Session B Accept selected Observe behavior after full acceptance
Session C Decline selected Identify what was suppressed and what remained

Each session used the same journey so that the results could be compared more consistently.

Why Clean Browser Sessions Matter

Reusing the same browser session can produce misleading results.

For example:

  • A cookie from an accepted session may remain in the browser.
  • A consent value may persist in localStorage.
  • A service worker may continue influencing requests.
  • Cached scripts may not behave the same way during the next test.
  • Session data may remain active.
  • Previous checkout or cart state may affect later observations.

If you test Accept and then click Decline in the same session, some accepted-state artifacts may remain.

That can make it look like they were created after Decline when they were actually inherited from the previous state.

Each test session should therefore begin from a clean environment.

A practical setup may include:

✓ New incognito/private session
✓ DevTools opened before navigation
✓ Preserve Log enabled
✓ Browser cache disabled
✓ Ad and tracker blocking disabled
✓ Separate HAR export
✓ Separate cookie snapshot
✓ Separate storage capture
Enter fullscreen mode Exit fullscreen mode

The goal is not to create a perfectly artificial browser.

The goal is to reduce contamination between test states.

Evidence Collected During Each Session

The review used several evidence types because no single source explained the complete behavior.

1. Cookie snapshots

Cookie snapshots were captured during defined stages of the journey.

This made it possible to compare:

Cookies before consent
Cookies after Accept
Cookies after Decline
Cookies added during product browsing
Cookies added during cart activity
Cookies added during checkout
Enter fullscreen mode Exit fullscreen mode

A simplified comparison could look like this:

const beforeConsent = new Set(preConsentCookies);
const afterAccept = new Set(acceptedCookies);
const afterDecline = new Set(declinedCookies);

const addedAfterAccept = [...afterAccept].filter(
  cookie => !beforeConsent.has(cookie)
);

const addedAfterDecline = [...afterDecline].filter(
  cookie => !beforeConsent.has(cookie)
);

const suppressedAfterDecline = [...afterAccept].filter(
  cookie => !afterDecline.has(cookie)
);
Enter fullscreen mode Exit fullscreen mode

This is useful as an initial comparison, but matching only by cookie name is not enough.

A real review should also consider:

Cookie name
Domain
Path
Expiry
Session or persistent state
Secure attribute
SameSite attribute
Journey stage
Consent state
Likely vendor
Likely purpose
Enter fullscreen mode Exit fullscreen mode

A cookie with the same name can behave differently across domains or paths.

2. HAR network captures

A HAR file records browser network activity.

It can help identify:

  • Request URLs
  • Request timing
  • Request and response headers
  • Third-party domains
  • Redirects
  • Cookies sent with requests
  • Cookies returned in responses
  • Scripts or endpoints activated during a journey

HAR evidence was important because:

No new cookie does not mean no network activity.
Enter fullscreen mode Exit fullscreen mode

A browser can contact an analytics, advertising, payment, security, or ecommerce endpoint without creating a new visible cookie.

However, HAR evidence also requires careful interpretation.

A domain appearing in a HAR file proves that a request occurred.

It does not automatically prove that:

  • Personal information was shared
  • Cross-site tracking occurred
  • A new identifier was stored
  • The request was unnecessary
  • A legal violation occurred

The request must be reviewed in context.

3. localStorage

Modern websites frequently use localStorage for persistent browser-side values.

These values may relate to:

  • Consent state
  • Cart persistence
  • Vendor configuration
  • Analytics identifiers
  • Feature flags
  • Journey history
  • Session restoration
  • Marketing systems

A cookie scanner may not capture these entries.

You can inspect them in browser DevTools under:

Application
  → Storage
  → Local Storage
Enter fullscreen mode Exit fullscreen mode

During consent testing, useful questions include:

  • Which keys exist before consent?
  • Which keys appear after Accept?
  • Which keys remain after Decline?
  • Which vendor created each key?
  • Does the value contain an identifier?
  • Is the value required for site functionality?

4. sessionStorage

sessionStorage is limited to the current browser tab or session, but it can still influence consent and journey behavior.

It may contain:

  • Checkout state
  • Page-flow information
  • Temporary vendor configuration
  • Consent-related values
  • Session identifiers
  • Form or cart state

It should be reviewed separately from localStorage.

The two mechanisms have different persistence behavior.

5. Screenshots

Screenshots helped document the visible and technical state of each session.

Useful screenshots included:

  • The cookie banner before any choice
  • The selected consent action
  • The current page or journey stage
  • The cookie table
  • localStorage
  • sessionStorage
  • Relevant network requests
  • Cart and checkout state

Screenshots are especially useful when several teams need to review the findings later.

They provide context that may not be obvious from a raw CSV or HAR file.

6. Timeline evidence

The sequence of events matters.

A timeline can record:

10:00:00 — Clean session opened
10:00:12 — Homepage loaded
10:00:25 — Decline selected
10:00:40 — Cookie snapshot captured
10:01:10 — Product page opened
10:01:35 — Storage captured
10:02:20 — Item added to cart
10:03:05 — Checkout opened
10:03:40 — HAR exported
Enter fullscreen mode Exit fullscreen mode

This helps reviewers understand whether an item appeared:

  • Before consent
  • Immediately after the consent choice
  • During product browsing
  • After adding an item to the cart
  • Only at checkout

Without timing information, it can be difficult to determine what triggered an observation.

What Happened After Accept?

After the visitor selected Accept, the website’s cookie footprint expanded.

Additional identifiers appeared while moving through:

Homepage
Product page
Cart
Checkout
Enter fullscreen mode Exit fullscreen mode

Some identifiers appeared consistent with:

  • Analytics
  • Advertising
  • Marketing
  • Ecommerce measurement
  • Conversion tracking
  • Performance monitoring

This was not treated as a problem by itself.

If a visitor accepts non-essential technologies, analytics and marketing services may be expected to become active.

The implementation still needed to be reviewed for questions such as:

  • Were the scripts correctly categorized?
  • Were they properly disclosed?
  • Were they blocked before consent?
  • Did the CMP pass the correct consent state?
  • Did the tag manager respond correctly?
  • Were all vendors mapped to the appropriate category?

The accepted state provides a useful reference for understanding what the website is capable of loading.

What Happened After Decline?

After Decline, many identifiers seen during the accepted journey were no longer present.

The declined session had a materially smaller cookie footprint.

That was a positive technical observation.

It suggested that the consent mechanism was suppressing a meaningful portion of accepted-state activity.

However, some items remained.

These included certain:

  • Cookies
  • Browser storage entries
  • Third-party requests
  • Vendor-related network activity

Those observations required classification.

Possible operational purposes included:

Security
Bot protection
Cart continuity
Checkout functionality
Payment support
Fraud prevention
Localization
Currency selection
Consent-state storage
Session continuity
Core ecommerce functionality
Enter fullscreen mode Exit fullscreen mode

Other items could still require analytics, marketing, or advertising review.

The important point is that:

Observed after Decline ≠ automatically non-compliant
Enter fullscreen mode Exit fullscreen mode

Why “After Decline” Needs Careful Wording

Suppose a cookie appears during the declined checkout journey but was not present during the initial pre-consent homepage capture.

It would be inaccurate to immediately call it a “Decline-only cookie.”

There are several possibilities:

  1. It may also appear during the accepted journey.
  2. It may be triggered by checkout rather than the consent decision.
  3. It may support security or cart functionality.
  4. It may be created by the consent platform.
  5. It may require closer marketing or analytics classification.

A more accurate finding would be:

This cookie was observed during the declined-consent journey but was not present in the initial pre-consent homepage baseline.

That statement describes the evidence without making an unsupported conclusion.

A Third-Party Request Does Not Automatically Mean Tracking

HAR analysis needs the same caution.

Consider this finding:

A request to a third-party domain occurred after Decline.
Enter fullscreen mode Exit fullscreen mode

This means the browser contacted that domain.

It does not automatically mean:

A tracking cookie was created
Personal data was transmitted
Advertising tracking occurred
The request was unnecessary
The website violated a law
Enter fullscreen mode Exit fullscreen mode

A proper review may need to inspect:

  • Vendor ownership
  • Request URL
  • Query parameters
  • Request method
  • Request headers
  • Response headers
  • Cookies sent
  • Cookies returned
  • Request payload
  • Journey stage
  • Consent category
  • Business purpose

Network activity is evidence, but it still needs interpretation.

Why Checkout Was Reviewed Separately

Checkout is a different technical environment from a homepage.

It may activate:

  • Payment providers
  • Fraud-prevention services
  • Tax calculation
  • Shipping services
  • Address validation
  • Security tools
  • Session continuity
  • Cart persistence
  • Ecommerce platform infrastructure
  • Conversion measurement

Some services may be necessary to provide checkout functionality.

Others may be analytics or marketing related.

Treating every checkout request as a marketing tracker would produce misleading findings.

For this reason, checkout behavior should be classified separately from homepage behavior.

A Practical Comparison Structure

A useful comparison table might look like this:

Item Before consent After Accept After Decline Journey stage Review status
Consent-state cookie Yes Yes Yes Homepage Likely necessary
Analytics identifier No Yes No Homepage Suppressed after Decline
Cart cookie No Yes Yes Cart Functional review
Payment-domain request No Yes Yes Checkout Operational review
Marketing storage key No Yes No Product Suppressed after Decline

The objective is not simply to count Yes and No values.

The objective is to connect each observation to:

Consent state
Journey stage
Vendor
Purpose
Evidence
Recommended action
Enter fullscreen mode Exit fullscreen mode

Common Mistakes During Consent Testing

Testing Accept and Decline in the same session

This can leave accepted-state cookies and storage values behind.

Looking only at the homepage

Product, cart, and checkout stages may activate additional services.

Checking only cookies

You may miss localStorage, sessionStorage, network requests, or script execution.

Assuming every third-party request is tracking

Some third-party infrastructure may support security, payments, or essential functionality.

Classifying cookies only by name

Cookie names may be ambiguous or reused across systems.

Treating scanner labels as final conclusions

Automated classifications should be verified against actual vendor and implementation details.

Ignoring the timing of evidence

Without a timeline, it may be unclear what caused an item to appear.

Making the Evidence Reviewable

Raw technical files are useful, but they are not always easy for broader teams to understand.

The evidence was therefore organized into:

  • Cookie comparison data
  • Third-party domain summaries
  • Browser storage observations
  • A chronological timeline
  • An evidence manifest
  • A findings register
  • Supporting screenshots
  • HAR network captures

Each important observation was connected to its source evidence.

That made the results useful for:

  • Developers
  • Privacy teams
  • Ecommerce teams
  • Marketing operations
  • Consent-platform owners
  • Vendor-management teams
  • Legal and compliance reviewers

Key Takeaways

A reliable cookie consent review should:

  1. Test pre-consent, Accept, and Decline separately.
  2. Use clean browser sessions.
  3. Follow the same user journey in every session.
  4. Review cookies, storage, and network requests together.
  5. Include product, cart, and checkout behavior.
  6. Classify items by vendor and purpose.
  7. Avoid treating every post-decline request as tracking.
  8. Connect every important finding to evidence.
  9. Separate technical observations from legal conclusions.
  10. Retest after implementation or CMP changes.

Final Thought

The most useful question is not:

Did anything load after Decline?
Enter fullscreen mode Exit fullscreen mode

It is:

What loaded after Decline?
Why did it load?
Which journey stage triggered it?
Which vendor was involved?
Which evidence supports the observation?
Enter fullscreen mode Exit fullscreen mode

That approach produces findings that are more accurate, reproducible, and useful than a basic cookie inventory.

A deeper breakdown of the anonymized audit methodology, findings, deliverables, and limitations is available in the original ecommerce cookie consent case study.

Top comments (0)