What the IAB TCF Collects for Ads, and Why It Matters

When you tap “Accept all” on a consent banner, a Consent Management Platform records your choice and sends it through the IAB Transparency and Consent Framework (TCF). The system may store a TC string for up to 390 days and can be read by dozens of vendors on one page load, shaping how personal data is used in advertising.

What the IAB Transparency and Consent Framework (TCF) is

The Interactive Advertising Bureau Europe’s Transparency and Consent Framework is a technical standard for exchanging privacy choices between websites, apps, consent managers, and ad-tech vendors. Its goal is to let publishers and vendors signal a user’s choices in a consistent format instead of building a separate consent system for every partner. That matters because a single page can involve 20, 50, or even 100+ supply-chain participants, and each one needs a clear signal about whether it may store information, build profiles, or measure ads.

The framework first launched in 2018, then moved to TCF 2.0 in 2019 and TCF 2.2 in 2023. TCF 2.2 is important because it removed legitimate interest as a basis for personalized advertising, making consent the only option for profile-based ad targeting within the framework. In practice, that means a site cannot rely on a vague “we have a legitimate interest” notice for personalisation purposes; it needs an affirmative opt-in signal.

TCF is not a privacy law by itself. It is a standard designed to help companies implement GDPR and ePrivacy requirements. Its main building blocks are the Consent Management Platform (CMP), the Global Vendor List (GVL), and the Transparency and Consent string (TC string). The GVL is the registry of vendors that declare which purposes they support and which legal basis they rely on. The CMP collects the choice. The TC string carries that choice to vendors in a compact, machine-readable form.

Why this matters: the TCF is used across a large advertising ecosystem, so one consent decision can affect multiple actors at once. Compared with a simple first-party cookie notice, it creates a shared signal that can govern dozens of downstream ad requests, audits, and analytics calls on the same page.

How data is collected and transmitted through the TCF system

A typical TCF flow begins when a page loads and the CMP checks whether a valid consent record already exists. If not, the user sees a banner or preference center. The CMP presents the purposes, vendors, and sometimes special features that can be accepted or rejected. Once the user makes a choice, the platform converts it into a TC string. That string is usually saved in browser local storage or a first-party cookie so the site can recognize the same choice later.

The TC string is compact but information-rich. It can encode the consent state for up to 10 standard purposes, vendor-level permissions from the GVL, and signals linked to special purposes or features. In a busy ad-supported page, that signal may be read by 10, 20, or 40+ vendors, including ad servers, bidders, measurement partners, and data-management tools. Each vendor checks the string before deciding whether it can process the request. This happens in milliseconds during an ad auction, but the consent decision itself can persist for much longer.

The common storage window is up to 390 days, which is just over 12 months. That is about 5% longer than a 365-day year. The long duration is useful because it reduces banner reappears on repeat visits, but it also means the consent record can outlive short-term campaigns, making auditing and refresh cycles important. If the user changes preferences, the CMP updates the stored string and vendors should receive the new version on the next page view or ad request.

Why this matters: the TCF is not just a notice layer; it is a transmission layer. Compared with an ordinary cookie setting that stays inside one website, the TC string can be consumed across a broader ad-tech chain, which is why accuracy, expiration, and vendor syncing are central to compliance.

What kinds of data and identifiers may be involved

The TCF itself does not define every item of personal data a company might collect, but it governs how consent is signaled for many common ad-tech data types. These can include IP addresses, device identifiers, browser characteristics, cookie IDs, approximate location, and interaction data such as page views, clicks, video completion, or time on page. In combination, these data points can become highly identifying even when each one seems ordinary on its own.

For ad delivery, the first layer is often contextual. A site about sports may show sports ads based only on the page category, the time of day, and the ad placement. That approach uses a narrow set of signals, typically a few contextual fields rather than a persistent user profile. The second layer is audience or profile-based advertising, which uses prior activity to infer interests. For example, a user who visited five cycling pages, viewed two product comparison charts, and clicked one bike-accessory ad can be placed into a segment associated with cycling interest. Those signals can remain useful for 30, 60, or 90 days depending on the ad stack.

From a data-governance perspective, the risk is less about one field and more about accumulation. A single IP address may change daily for mobile users, but when combined with a device ID, a consent record, and repeated event logs, the system can link multiple sessions. That is why regulators treat the TC string itself as personal data when it is combined with identifiers or can be tied to an individual device.

Why this matters: users often think “cookie data” means one harmless file, but modern ad systems typically combine 3 to 7 identifiers and event streams. Compared with a purely contextual campaign, profile-based advertising can rely on many more data points, which is why consent scope and vendor access need to be precise.

Purposes, special purposes, and special features in the framework

The TCF divides processing into standardized purposes so users can see what they are authorizing. The framework defines 10 main purposes. The most privacy-sensitive ones are Purpose 3, creating a personalized ads profile, and Purpose 4, selecting personalized ads. Purpose 5 and Purpose 6 cover personalized content, while Purpose 7 and Purpose 8 cover measuring ad and content performance. Purpose 9 and Purpose 10 are used for audience insights, product development, and service improvement.

There are also special purposes that are usually treated as essential. Special Purpose 1 covers security, fraud prevention, and debugging. Special Purpose 2 covers technically delivering content or ads. Special Purpose 3, added after recent court developments, covers saving and communicating privacy choices. This is important because the consent record itself is now treated as data that needs a legal basis for storage and exchange.

The framework also includes special features that can be asked for separately. These typically include precise geolocation and actively scanning device characteristics for identification. Precise geolocation is much narrower than approximate location: a GPS signal can be accurate to within a few meters, while city-level location may be accurate to several kilometers. Device scanning can involve browser or device traits that, when combined, may increase identifiability.

Why this matters: the TCF is granular, but not all purposes are equal. A measurement purpose may involve far less privacy impact than a profile-building purpose, even though both sit inside the same consent interface. Compared with a binary “accept cookies” choice, the TCF can separate at least 10 standard purposes plus special items, giving users and companies a much more specific compliance map.

Consent versus legitimate interest after TCF 2.2

Under GDPR, processing needs a legal basis. In advertising, the two most discussed bases are consent under Article 6(1)(a) and legitimate interest under Article 6(1)(f). Before TCF 2.2, some vendors used legitimate interest for a wider set of ad-tech activities, including parts of targeting and personalization. That changed in 2023.

TCF 2.2 removed legitimate interest for personalized advertising and personalized content within the framework. As a result, Purpose 3 and Purpose 4 now depend on consent rather than a balancing test. This was a major shift because consent must be freely given, specific, informed, and unambiguous, while legitimate interest requires a documented assessment that the business need outweighs the user’s rights and expectations. Those are very different compliance burdens.

The practical effect is visible in opt-in rates. On many sites, “Accept all” remains the dominant choice, often around 70% to 80% of users when the banner design is prominent. “Reject all” can be much lower, often 5% to 15%, and customization tends to fall in the 10% to 20% range. Those differences matter because a change in legal basis can alter how many impressions are eligible for personalized bidding, retargeting, and frequency capping.

For vendors, the change also reduces ambiguity. Instead of trying to justify ad personalization under legitimate interest, they must collect a clearer consent signal. For publishers, that means CMP settings, vendor lists, and purpose descriptions must be updated so the banner reflects the actual legal basis in use.

Why this matters: TCF 2.2 tightened the rules where the privacy impact is highest. Compared with a system that allowed broader legitimate-interest claims, it forces more ad-tech activities into an explicit opt-in model, which usually reduces the amount of usable tracking unless the consent rate is high.

How long consent lasts and how storage works

Consent under the TCF is typically stored for up to 390 days. That figure is slightly longer than one calendar year and is commonly used so repeat visitors do not see a banner on every visit. In practical terms, it means a user who visits a site monthly could avoid 11 extra consent prompts over a 12-month period, assuming the record stays valid and unchanged.

The TC string usually sits in first-party storage controlled by the publisher or CMP. Some implementations use local storage, others use cookies, and many use both for resilience. The key point is that the stored record is not just a yes/no flag; it also contains timestamps and versioning information. Those fields help vendors know whether the consent is current, whether it was set under TCF 2.0 or 2.2, and whether it should be refreshed.

Storage duration is not the same as retention by every vendor. The CMP may keep the consent record for 390 days, but downstream vendors may retain logs or audit traces for shorter or longer periods depending on their own policies. For example, a publisher may keep consent logs for 13 months to support audits, while an ad vendor may retain event-level logs for 90 days and aggregated reports for 24 months. That difference is why people often confuse the banner’s storage period with broader data-retention obligations.

Why this matters: a long consent window improves usability, but it also increases the importance of version control and expiry checks. Compared with a 30-day retention model, a 390-day window reduces banner fatigue by more than 12 times, yet it requires stronger governance to ensure outdated choices are not treated as current.

Legal challenges, court rulings, and the framework’s evolution

The TCF has not evolved smoothly; it has been tested by enforcement and court scrutiny. In 2022, the Belgian Data Protection Authority found that IAB Europe’s older TCF design did not meet GDPR standards in several areas, including transparency, accountability, and the legal status of the TC string. The authority also imposed a fine of 250,000 euros. That case mattered because it showed the framework itself could be treated as part of the compliance problem, not just a neutral technical wrapper.

A later European court ruling in 2024 reinforced that TC strings can qualify as personal data when they can be linked to an identifiable person or device. That interpretation has direct operational effects. It means the consent record is not merely a technical token; it is regulated information that needs a legal basis, retention controls, and clear disclosure. The addition of Special Purpose 3 reflects that shift by creating an explicit category for storing and communicating privacy choices.

The evolution from TCF 1.0 to 2.0, then 2.2, shows how privacy engineering changes under regulatory pressure. TCF 1.0 introduced the basic vendor and purpose structure. TCF 2.0 expanded user transparency and control. TCF 2.2 removed legitimate interest for personalization and improved clarity around vendor declarations. A future revision, often discussed as 2.3, would likely focus on implementation details, not a wholesale redesign.

Why this matters: legal rulings can change product requirements within months, not years. Compared with a static banner system, the TCF has to absorb court decisions, DPA guidance, and vendor-list updates across multiple countries, which is why CMPs and publishers need continuous maintenance rather than one-time setup.

How to review consent banners and choose a CMP

For users, the practical step is to inspect what the banner actually offers. A compliant banner should show the number of vendors, the categories of purposes, and a clear reject path. If a banner buries rejection behind multiple clicks while putting acceptance on the first screen, it may still be legally risky even if it is technically functional. Users should look for a preference center that allows at least purpose-level control and vendor-level review.

For site owners, choosing a CMP is partly a compliance decision and partly an operating-cost decision. Entry-level tools can start around 0 to 10 euros per month for small sites, while mid-market plans often run from 7 to 90 euros monthly depending on page views, subpages, or sessions. Enterprise tools can begin around 827 dollars per month and rise beyond 10,000 dollars per year. That is a difference of more than 100 times between low-end and enterprise pricing, so traffic and feature needs matter.

Functionally, CMP selection should consider scan frequency, language support, consent-mode integrations, audit logs, and custom banner design. A small site with 10,000 page views per month may need little more than a standard banner and a vendor list. A larger publisher with 1 million monthly visits may need geo-targeting, multi-language support, and APIs for ad-stack sync. The higher the traffic, the more important it is to test banner load time, because a 1-second delay on every page view can add up to many hours of user waiting across a month.

Why this matters: a consent tool is not just a legal widget; it is part of the site’s conversion and revenue flow. Compared with a static cookie notice, a well-managed CMP can reduce friction, support audits, and keep ad integrations working across changing regulations.

This article provides general informational purposes only and does not constitute legal, financial, or professional advice. Privacy regulations and technical standards change over time, and implementation details can vary by jurisdiction, vendor, and website configuration. Readers should consult qualified legal and privacy professionals for advice tailored to their circumstances.

Sources

What Is IAB TCF? Complete Guide – ConsentBit [OneTrust Pricing: How Much Does OneTrust Cost? [It’s Increasing!] – Enzuzo](https://www.enzuzo.com/blog/onetrust-pricing-for-compliance) Usercentrics Review: Price, Features, Pros, Cons – TermsFeed What is IAB TCF? (Transparency and Consent Framework) – CookieYes IAB TCF 2.2: What You Need to Know | Resources – OneTrust What Is the IAB TCF? – Termly IAB special features (GDPR TCF) – Sourcepoint What is the IAB framework – Cookie Information