Debug CookieYes in Chrome DevTools

What CookieYes traffic looks like

CookieYes keys everything to a client id that appears in the script path, and stores the decision in a single flat cookie that is unusually easy to read by eye compared with most CMPs.

Endpoint pattern

The banner script loads from cdn-cookieyes.com/client_data/<client id>/script.js, with the client id identifying the site; app.cookieyes.com serves the application side and log.cookieyes.com receives consent logging

Transport

Script load plus consent-log calls when a decision is recorded

Cookies

cookieyes-consent holds the decision as comma-separated key-value pairs, for example consentid:…,consent:yes,action:yes,analytics:yes,functional:no,performance:no,advertisement:no. No encoding, no nesting, readable directly in the Cookies section

Window API

window.getCkyConsent() returns the live state

Data layer object

A cookieyes_consent_update push signals that the decision changed

Debugging CookieYes with Event Watcher

• CookieYes is one of the CMPs with complete detection coverage in the extension: the cookie is parsed, the window API is read, the dataLayer push is recognized, and the category names are mapped.
• The category mapping is explicit rather than guessed. CookieYes's analytics maps to the analytics category, advertisement to marketing, and functional to functional. The performance flag is also treated as analytics, so a site using performance rather than analytics is read correctly.
• The action field is what separates a real decision from an untouched banner, which matters because "denied" and "not answered yet" produce very different expectations for the rest of the page.
• The consent-update push is captured as a dataLayer event with stack-trace attribution, so you can see which script reacted to it.

CookieYes and consent

CookieYes is the consent source, not a subject of the consent check. Its own requests are not measured against a consent state, because they are what establishes that state.

Everything else captured in the session is then marked granted, denied, or pre-consent against what CookieYes reported, with the total shown in the violations counter. That makes the accuracy of the reading load-bearing: if the cookieyes-consent cookie says advertisement:no and marketing pixels are still firing, the verdicts on those events are the finding, and CookieYes is simply the reference.

Common debugging scenarios

• Tags fire despite a denial. Read the cookie to confirm which categories are actually denied, then group by Consent Category to list the tags ignoring it. Scripts added directly in a tag manager without the CookieYes blocking configuration are the usual culprits. Start with GA4 fires before consent.
• Consent looks denied but was never asked. Check the action field. Without it, the banner has not been answered and every category defaults to no.
• Auto-blocking is not catching a script. CookieYes blocks by rewriting script tags it recognizes. Compare what still loads pre-decision against what the blocking configuration claims to cover.
• Which script reacted to the consent change? Use which script pushed this dataLayer event on the cookieyes_consent_update push.
• Full pre and post-consent inventory. Run the pixel audit once with the banner unanswered and once accepted, then compare.