Recognised tracking cookie in a captured page response with a supported consent signal
ShipReady found a recognised tracking-cookie name in a Set-Cookie header on the captured successful page response and also found a supported consent-mechanism signal in the available evidence.
Why it matters
When a response cookie and a supported consent signal co-occur in the evidence, it is useful to review whether that behavior matches the product's intended consent and tag-loading design.
How ShipReady detects it
What it inspects
ShipReady reads Set-Cookie header names from the final successful page response and static fetch-bearing markup, executable inline code, static markup identity values, and captured response cookie names for supported consent-mechanism signals.
What triggers a finding
The rule triggers when a recognised tracking-cookie name appears in a Set-Cookie header and a supported consent-mechanism signal is also found in the available evidence.
What the evidence shows
The named response cookie and a supported consent-mechanism signal co-occurred in evidence captured by ShipReady.
Limits of this check
ShipReady does not establish that a consent interface was displayed, observe a visitor's choice, infer chronological ordering between an interface and a cookie, inspect later JavaScript, or evaluate legal compliance. It does not prove that any interface ignores rejection or that consent is invalid.
How to fix it
Review when the identifier is set
Confirm the integration's cookie-setting behavior matches the product's intended consent and tag-loading design.
Test available consent states
Use a controlled browser session to compare first visit, available choices, withdrawal where supported, and revisits.
How to verify the change
Use a fresh browser profile
Inspect response headers before interaction and repeat the observation after each available consent action.
Expected: Tracking-cookie behavior matches the product's intended consent-state design.