The string behind the banner
On publisher sites running programmatic advertising, the consent banner does not just record a choice. It encodes that choice into a compact, standardized string, the Transparency and Consent Framework (TCF) consent string, and passes it down a chain of ad tech vendors. That string is the actual mechanism by which "the user said no to personalized ads" travels from your banner to the hundred companies bidding on the impression. Understanding it is the difference between having a consent banner and having consent that works.
The TCF is the IAB's framework for standardizing consent in digital advertising, currently in version 2.2. Its core idea is that consent choices need a common language, because the alternative is every vendor interpreting every banner differently, which is how you get technically present but functionally meaningless consent.
What the string encodes
A TCF consent string packs a surprising amount of information into a short encoded value: which consent management platform generated it, when it was created and last updated, which purposes the user consented to, which purposes the vendor claims legitimate interest for, which vendors received consent, and various flags about the context like whether the user was in the EU. Decode one with a public decoder and the user's entire consent state is readable.
The purpose list is the heart of it. TCF 2.2 defines a fixed set of purposes, from storing information on a device to creating personalized ad profiles, and the string records a yes or no for each. Legitimate interest is recorded separately, which matters because vendors can claim legitimate interest for some purposes even when the user withheld consent, a distinction your banner should explain honestly.
Why publishers should care
Publishers often treat the consent string as the CMP vendor's problem. It is not. The publisher chose the CMP, configured the purposes, and is the first party the regulator will question. Three publisher-level failures are common. First, the string does not match what the banner showed: the banner offered granular choice but the string records blanket consent, usually a CMP misconfiguration. Second, the string is generated before the user chooses: the default state is consent, and the banner is theater. Third, the string is stale: the user withdrew consent but the cached string keeps circulating.
All three are detectable. Decode your own site's consent string in a fresh session before interacting with the banner, after accepting, after rejecting, and after changing choices. The string should track the choices exactly. If it does not, the banner is decoration and the liability is yours.
The vendor list problem
TCF strings also carry the vendor list: which of the hundreds of registered vendors received consent. The framework's global vendor list has grown enormous, and banners that ask users to consent to hundreds of vendors individually are asking for something no human can meaningfully evaluate. TCF 2.2 reduced some of the worst excesses, but the structural issue remains.
The practical response is vendor minimization on your own stack. Audit which vendors actually bid on your inventory or provide real value, and cut the rest from the CMP configuration. Every vendor you remove is a consent decision your visitors no longer have to make and a data flow you no longer have to defend. The string gets shorter, the banner gets more honest, and the compliance story gets simpler.
What to check this month
Decode your consent string in the four states described above and confirm it matches the banner. Confirm your CMP is running a current TCF version, because older versions encode purposes that no longer match the current policy. And review your vendor list against actual value. The consent string is the part of your consent implementation that other companies read. Make sure it says what you think it says.