How publishers debug a broken TCF consent string

Decode the TC string and read it literally: which purposes are consented, which vendors are listed, and whether the string matches what the banner promised. Most broken strings come from a stale vendor list or a CMP and banner disagreeing about legal basis.

Decode it first

Paste the tc string into a decoder and read the fields instead of guessing. Check the purposes consented, the vendor consents, the vendor legitimate-interest disclosures, and any publisher restrictions. A surprising number of debugging sessions end here, because the string plainly says something different from what everyone assumed it said.

Check the vendor list version

A consent string built against an old Global Vendor List fails validation downstream. Vendors update their declarations, purposes change, and a stale GVL means the string references entries that no longer exist in the current list. Sync the GVL in the CMP and regenerate the string before chasing more exotic causes.

Match purposes to the banner

If the banner tells visitors their choice covers personalized ads under consent, but the string records legitimate interest for that purpose, downstream SSPs will reject or misbehave. The banner and the string have to tell the same story about legal basis. When they disagree, fix the CMP configuration, not the string, because the string is just reporting what it was told.

When the string looks right but buyers still complain, check the CMP version itself. Vendors validate against the current TCF specifications, and a CMP running an outdated version can generate strings that decode fine locally but fail partner validation. The CMP changelog is boring reading, but it is usually where the answer is.