Debug Quantcast Choice in Chrome DevTools

What Quantcast Choice traffic looks like

Quantcast Choice is a TCF-first CMP, popular with publishers because the framework is what ad-tech partners expect. That shapes the debugging: the decision does not live in a vendor-specific cookie with readable category names, it lives in an encoded IAB consent string.

Endpoint pattern

The CMP loads from cmp.quantcast.com; quantcast.mgr.consensu.org is the IAB-hosted domain used for cross-site consent under the framework

Transport

Script load plus the framework's own calls. Most of the interesting state is on the page rather than in a request

Cookies

euconsent-v2 holds the TCF consent string, a base64-encoded bitfield rather than readable flags. Purpose consents have to be decoded to mean anything

Window API

The standard window.__tcfapi interface, queried with getTCData

Data layer object

The shared codebase behind Quantcast Choice and InMobi CMP pushes __cmpConsents and __cmpLoaded, and a cookie_consent_update push carrying TCF markers such as tcString or purposeConsents

Debugging Quantcast Choice with Event Watcher

• The consent state is read through the framework rather than through a Quantcast-specific parser: the extension decodes the euconsent-v2 string and queries __tcfapi, then maps TCF purposes onto its three categories.
• That mapping is explicit and worth knowing when reading a verdict: Purpose 1 is treated as functional, Purposes 2 to 6 as marketing, and Purposes 7 and 8 as analytics.
• The consent pushes are recognized as coming from the InMobi and Quantcast shared codebase. Because cookie_consent_update is also a name other CMPs use, the extension only attributes it here when TCF markers are present in the payload, which avoids mislabelling a different CMP's push.
• The practical benefit is not having to decode a consent string by hand. The extension does it, and every other event in the session carries a granted, denied, or pre-consent verdict derived from it.

Quantcast Choice and consent

Quantcast Choice 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 it.

The TCF-specific thing to watch is that the framework's purposes and a CMP's visible category toggles are not the same model. A banner can present three friendly categories while the string underneath records eleven purposes and a vendor list, and the mapping is a configuration choice. When a verdict looks wrong, the question is which purposes were granted, not what the banner appeared to say.

Common debugging scenarios

• A vendor fires despite a denial. TCF consent is per-purpose and per-vendor. A tag can be legitimately allowed under one purpose while the category the site thinks it denied covers another.
• The consent string exists but nothing is gated. Under TCF, the string is a signal; enforcement is the site's and each vendor's responsibility. Presence of euconsent-v2 proves the CMP ran, not that anything acted on it.
• Consent does not persist across sites. Check whether consensu.org traffic appears. Cross-site consent runs through that domain.
• Which push carried the decision? Look for __cmpConsents or a cookie_consent_update with TCF markers, then use which script pushed this dataLayer event to see what listened.
• Full pre and post-consent inventory. Run the pixel audit with the banner unanswered and then answered, and compare what the publisher stack does in each state.