Next up: the changes that actually matter, what to sanity-check in your stack, and how CookieScript helps keep v2.3 running day to day with clean strings, clear choices, and audit-friendly consent logs.

What Is the IAB TCF and Why Does It Matter for GDPR?

The IAB’s Transparency & Consent Framework (TCF) is a shared signalling system for ad tech. A publisher collects choices in a CMP, the CMP encodes them into a TC string, and vendors downstream read that signal so they can decide whether they’re allowed to run a purpose on consent or legitimate interest (or not run it at all). It doesn’t make the legal decisions for you — it just makes sure everyone’s reading the same “yes/no/LI objection” map.

It matters for GDPR (and eprivacy) because most advertising setups touch two things at once: device access/storage (cookies, IDs, SDK storage) and GDPR duties like having the right legal basis and being transparent about who does what. Without a framework, every partner ends up inventing its own way to interpret consent, and you get a supply chain full of mismatched assumptions.

One line of v2.2 context: v2.2 pushed personalisation into a consent-only lane (by tightening which purposes can use legitimate interest), which is part of why v2.3 focuses less on changing the rules again and more on making the signals cleaner and harder to misinterpret.

What’s New in TCF v2.3 Compared to v2.2?

v2.3 exists because v2.2 left a gap that kept biting people in production: you could read the TC string and still not know one basic thing — was this vendor actually disclosed to the user? A “no” signal might be a real objection, sure.

Or it might be “this vendor never appeared in the CMP UI,” which means the user never had a chance to choose either way. v2.3 is the framework admitting that ambiguity isn’t workable and baking “proof of disclosure” into the signal.

The clean distinction:

• v2.2 = legal basis / policy tightening (especially around when Legitimate Interest is allowed).
• v2.3 = signal clarity + proof of who was disclosed.

What changes at a high level (no spec rabbit holes):

• “Disclosed Vendors” becomes mandatory in the TC string, so vendors can tell (from the signal) whether they were actually shown to the user.
• Less ambiguity for vendors (especially around Special Purposes), because “not disclosed” stops looking like “objected” or “no consent.”
• Better traceability for audits and disputes: instead of arguing “we were listed” vs “you weren’t,” you’ve got a concrete disclosure indicator to point at.
• Cleaner CMP responsibilities: if the UI shows a vendor, the disclosed-vendor signal needs to reflect that — no drift between what’s displayed and what’s encoded.
• Safer migrations in real stacks: the move to v2.3 is designed so you can adopt the new disclosure proof without automatically forcing a mass re-consent purely because the string format changed.

TCF v2.3 Deadlines, Enforcement, and Google Requirements

If your team likes clean launches, treat this like one. The date isn’t “FYI”. It’s a production deadline.

Mini-timeline (the dates that matter):

• 19 June 2025: TCF v2.3 is released and available.
• Mid-2025 → February 2026: transition / grace period while teams roll it out and partners tolerate a mix.
• 28 February 2026: cutoff date — new TC strings generated on/after this date need to be v2.3.

What happens if you keep generating v2.2 strings after the deadline

After 28 Feb 2026, the risk isn’t the old consent strings already sitting in users’ browsers. The risk is the ones you keep creating after that date. If you’re still issuing new v2.2 strings, you’re basically handing partners a signal they may treat as unsupported/invalid for “new traffic”.

That doesn’t always explode loudly. More often it leaks: fewer bids, odd partner behaviour, “why is this line item suddenly starving?” vibes.

For Google specifically, the consequence they call out is straightforward: if the TC string isn’t acceptable, the ad request may default to Limited Ads.

That “may” is annoying, because it means you won’t always reproduce it on demand — but it’s also why this ends up as a revenue mystery instead of a clean error.

One nuance that stops the panic spiral: v2.2 strings created before 28 Feb 2026 can still be accepted. So no, you don’t have to re-consent everyone on the cutoff day. You just can’t keep minting fresh v2.2 strings after the cutoff.

What you should have done by now (since v2.3 is live)

By now, you should know what your production setup is emitting, and it should be the same across the “forgotten” places: old templates, subdomains, in-app webviews, campaign landing pages.

You should also have a basic way to catch it when consent signalling slips — because this class of problem rarely shouts. It just quietly changes outcomes.

If you’re behind: the rescue priorities (top 3)

1. Stop generating new v2.2 strings. Flip output to v2.3 first. Fix the last 10% right after.
2. Test the money routes. Start with Google and your biggest demand partners. Confirm acceptance and watch for Limited Ads / reduced demand behaviour.
3. Check disclosure alignment. Make sure the vendors you actually show in the UI match what the v2.3 disclosure signal says. If those two drift apart, you’ll end up arguing with dashboards instead of shipping fixes.

• Cutoff: 28 February 2026
• Rule: TC strings generated on/after this date must be TCF v2.3
• Google: new non-v2.3 strings may default to Limited Ads
• Still OK: v2.2 strings created before the cutoff can still be accepted
• Quick check: if you’re generating new strings and there’s no Disclosed Vendors signal, you’re not outputting v2.3 correctly

How TCF v2.3 Changes Things for Publishers, Advertisers, and Vendors

v2.3 is where “it probably means X” turns into “show me.” Less interpretation. More checks.

Publishers: what to check now

• Map your v2.3 output properly. Not just the homepage — include subdomains, old templates, campaign landers, AMP, in-app webviews, the stuff nobody QA’s.
• Vendor list discipline. If a vendor is there “because maybe,” that’s not a reason. Keep what you actually use (and can explain without squinting).
• UI honesty. What users see in the CMP needs to match what the site/app loads. If your tag manager fires one set of vendors and the UI discloses another, fix the mismatch.
• Partner audit on the money paths. Pick Google + your top SSP/DSP partners and do a quick acceptance/behaviour check (warnings, fallbacks, demand going quiet).
• Make it someone’s job. Vendor adds/removes, CMP config changes, periodic QA — owned by a person/team, not “shared responsibility.”

Advertisers / marketing teams: what to watch

• Treat consent signals as a quality filter. Inventory where disclosure/signals look inconsistent should get flagged, not shrugged off.
• Measurement impacts show up in boring places first. Watch audience sizes, match rates, conversion modelling inputs — CPM usually lags behind.
• Use the reduced ambiguity in partner chats. Ask “were you disclosed?” and push for a straight answer instead of another screenshot debate.
• Check tag dependencies. If your setup assumes IDs/storage, make sure delivery and measurement don’t fall apart when consent is missing or limited.

Vendors / ad tech: what to update

• Update TC string parsing and gating. Reading the string isn’t enough — your decisioning has to handle disclosed-vendor logic properly.
• Kill “best guess” behaviour. If you’re not disclosed, don’t process like you were. That rule needs to be enforced in code, not in policy docs.
• Keep Special Purposes in their lane. Don’t use them as a convenient parking lot for things that should be consent-based.
• Refresh the internal playbook. Compliance notes, partner FAQs, support macros, escalation steps — bring them into v2.3 reality.
• Test against real CMP outputs. Real strings, real vendor lists, real edge cases — not a clean sample you generated for a demo.

The New “Disclosed Vendors” Segment Explained

TCF v2.3 adds a mandatory “Disclosed Vendors” segment inside the TC string. It’s basically a checklist that says: these are the vendors the user was actually shown in the CMP UI. Not “available in the global vendor list.” Not “configured somewhere.” Shown.

Before v2.3, a vendor could look at a “0” and still be stuck guessing. Did the user object? Or was the vendor never disclosed, meaning the user never had a chance to choose? That’s the ambiguity v2.3 is trying to kill. With Disclosed Vendors present and mandatory, vendors can stop doing interpretive dance with the signal.

How it fits into the TC string (high-level, no spec rabbit hole):

• The TC string is still dot-separated segments.
• The core segment comes first (always).
• After that, v2.3 requires an additional segment: Disclosed Vendors.
• You may also see other segments (like a publisher segment), but the key point for v2.3 is: core first, disclosure is no longer optional.

Real-world example (how this changes decisions):

Scenario A — Vendor wasn’t shown:

A vendor reads the TC string and sees they’re not in the Disclosed Vendors segment.

Result: they shouldn’t “assume” anything. No “maybe the user would’ve said yes.” No “we’re probably covered.” If you weren’t disclosed, you weren’t disclosed.

Scenario B — Vendor was shown + user choice exists:

A vendor checks the Disclosed Vendors segment and sees they were disclosed.

Result: now the rest of the TC string becomes meaningful: consent signals and objections can be interpreted as actual user choices, not as a side-effect of not being listed. In other words: the vendor can treat the signal like a decision, not a mystery.

Legitimate Interest and Special Purposes Under TCF v2.3

Quick reset: v2.3 doesn’t change v2.2’s consent-only stance for personalisation. If you’re doing personalised ads/content-style processing, you’re still in the consent lane, not the LI lane.

Now, Special Purposes are a different beast. Think things like security, fraud prevention, and fixing errors — the stuff vendors argue they need to do to keep systems from being abused or broken. In TCF terms, vendors declare Legitimate Interest for Special Purposes, and these aren’t handled like normal “toggleable” purposes inside the Framework UI.

Users are typically informed about them, but they don’t get the same on/off choice inside the TCF controls (that doesn’t erase GDPR rights in general — it just means the TC string doesn’t carry an objection toggle for Special Purposes).

Here’s the v2.3 nuance: this is where the mandatory Disclosed Vendors segment matters most. It removes the “were we even disclosed?” uncertainty, which is exactly the kind of ambiguity that caused pain for vendors leaning on Special Purposes. It doesn’t magically approve processing — it just removes the guesswork about whether disclosure happened.

Common mistakes (the ones that cause messy partner calls):

• Assuming disclosure happened because you’re on the global vendor list or “in the CMP config somewhere.”
• Mixing up LI and consent in implementation logic (or UI copy) and ending up with signals that don’t match what you actually do.
• Treating Special Purposes like normal purposes — as if they’re just another toggle — or worse, using them as a convenient hiding place for consent-based activity.
• Letting vendors drift: what’s declared vs what runs in tags vs what the UI discloses slowly stop matching, and nobody notices until an audit (or a platform) forces the issue.

UX and Transparency Expectations for Consent Banners in v2.3

Your consent banner has, what, three seconds to land. After that, people click the thing that gets them back to the page and move on.

So “good UX” here isn’t about pretty gradients or clever layouts — it’s about not messing people around: say what you’re doing in plain language, give a straight yes/no option, and don’t turn “vendors” into a weird side tunnel you fall into by accident.

v2.3 makes the disclosure part harder to fudge, so banners that rely on confusion don’t age well. The ones that work? They’re kind of boring. Good.

And the failure modes are always the same. “Reject” is there… technically… just not where anyone will see it. Purpose text is all fog and vibes (“enhance your experience” — okay, but how?).

Vendor info becomes an endless scroll with zero context, like you’re punishing curiosity. If the first layer boils down to “Accept” or “go fight the settings screen,” people clock it. Partners clock it too — especially when the signal you send doesn’t match what the UI looked like on the surface.

Running TCF v2.3 Day to Day With a CMP

A CMP isn’t “the banner.” The banner is just the part users see. The real job is keeping your consent setup from drifting while your ad stack keeps changing underneath it.

Here’s what the CMP ends up owning in day-to-day reality:

• Showing the UI (and letting people get back to it). It’s not enough to pop a banner once. Users need an obvious way to reopen settings later, or you’re basically saying “choose now and never touch this again.”
• Vendor setup is constant housekeeping. New partner? Old vendor removed? Someone flips a purpose? The CMP has to reflect it — otherwise you disclose one thing and run another.
• Generating the TC string partners actually use. And in v2.3 that includes the mandatory Disclosed Vendors signal, so “were we shown?” isn’t a guessing game anymore.
• Keeping a paper trail you can defend. Who chose what, when they chose it, and what configuration was live at the time. (This is the bit you’ll want the moment someone asks awkward questions.)
• Catching problems early. Missing/invalid strings, sudden consent-rate swings, vendor mismatches, partner warnings — the CMP should help you notice before it turns into a revenue or compliance incident.

And yeah: this is ongoing. Vendor lists change. SSPs come and go. People add tags in a manager without telling anyone. If you treat TCF as a one-time “migration project,” you’ll end up with a setup that slowly rots.

A simple operating rhythm that works in production:

1. Weekly: quick scan for anything weird — consent rate swings, spikes in missing/invalid strings, partner alerts, sudden demand changes.
2. Monthly: vendor list review + light tag audit (what’s loading vs what’s disclosed), plus rescan/verify any new scripts.
3. Quarterly: deeper cleanup — vendors you can drop, purpose/legal-basis mapping, UI wording check, and a sanity check on the biggest monetisation paths.

How CookieScript Supports IAB TCF v2.3

CookieScript is the kind of tool you want in the middle when TCF stops being “a banner” and turns into ongoing ops.

• TCF-ready consent UI + vendor workflows so you can actually manage who shows up, not just dump a list and hope.
• TC string generation via IAB TCF integration. v2.3 adds the mandatory Disclosed Vendors signal, so the practical requirement is: your CMP output needs to include that segment when you’re generating v2.3 strings.
• Consent logs with timestamps so you can answer the annoying questions (“what did the user see, what did they choose, when?”) without guesswork.
• Reporting that helps you spot breakage — sudden opt-in drops, odd spikes, missing-signal situations, the stuff that turns into revenue/support tickets.
• geo-targeting + multilingual banners (40+ languages) so EU and non-EU flows don’t get mixed up, and users aren’t forced into English legalese.
• Automated scanning/rescans to keep your “what’s on the site” reality aligned with what you disclose (because tag drift is real).
• Google Consent Mode v2 support where it matters — the CMP can help keep Google tags behaving correctly when consent is missing or partial.

By Spring 2025, CookieScript had picked up its fourth G2 badge in a row in the CMP category. And on the Google side, it’s listed as a Gold-tier, certified CMP — basically a signal that the product meets Google’s bar for consent-mode integration and support (not a magic “you’re compliant now” stamp).

Conclusion

If you’re still treating TCF v2.3 like a cosmetic update, it’s going to bite. The point is boring but important: cleaner signals, and vendor disclosure you can actually prove (not “we think we did”).

Why care? Because when consent signalling is off, it usually doesn’t crash — it leaks. Partners get cautious, bids thin out, and on Google paths you can slide into Limited Ads once you’re past the cutoff and still emitting strings that don’t meet expectations.

CookieScript fits as the tool you keep running in the background: manage the config, pull timestamped consent logs when someone asks “what happened?”, and spot breakage before it turns into another week of “why did fill drop?”

Frequently Asked Questions

What’s the main difference between TCF v2.2 and v2.3?

v2.2 was the big policy/legal-basis shift; v2.3 is the cleanup: clearer signals and provable vendor disclosure. In practice, that means your CMP has to keep what’s shown in the Cookie Banner aligned with what’s encoded in the TC string. CookieScript helps by running an IAB TCF 2.2 integration today (and supporting the operational move to v2.3), plus User consents recording and Advanced reporting so you can see what’s happening instead of guessing.

Do we have to move if we’re still on v2.2?

Yes — especially for new strings after the cutoff. The safe approach is to treat the shift as ops work: update config, test your monetisation paths, then roll out. CookieScript makes this less painful with Automation, Automatic script blocking, Third-party cookie blocking, and Automatic monthly scans so your disclosures don’t drift as tags change.

Does the Disclosed Vendors segment change what users see?

Not automatically. It mainly changes what the signal can prove: which vendors were actually disclosed to the user. CookieScript helps you keep the front-end experience clean and consistent with geo targeting and 42 languages, so the right people see the right version of the Cookie Banner, and your User consents recording matches what was shown.

What happens if consent strings are invalid or partners reject them?

Usually you don’t get a nice red error banner — you get the silent stuff: demand gets conservative, fill drops, and troubleshooting turns into a blame game. CookieScript helps you catch this earlier with Advanced reporting, plus Automatic script blocking / Third-party cookie blocking so “Reject” actually means reject in execution, not just in wording.

How do we avoid Limited Ads with Google?

You avoid it by making sure the consent signal Google sees is valid and consistent across your site/app — and by testing the real Google paths before you flip everything live. CookieScript supports Google Consent Mode v2 and is a Google-certified CMP, which helps keep the Google side of the stack behaving correctly when consent is missing or partial.

How does CookieScript help in practice once v2.3 is live?

It’s the day-to-day toolkit: a cookie banner that you can manage and reuse via cookie banner sharing, plus geo targeting, 42 languages, and User consents recording for audits and partner questions. On the technical side you get Automation, Automatic monthly scans, Third-party cookie blocking, and Automatic script blocking to keep tags and disclosures aligned, and Advanced reporting to spot drop-offs and errors before they turn into revenue incidents.