LW IT Solutions
« Blog Overview /Data Privacy / TCF Feature 3: When Google May Use...
This post in other languages:

TCF Feature 3: When Google May Use the IP Address to Identify a Device

Contents
  1. Four classes, two of them decisions
  2. Why it looks like nothing was decided
  3. What Google actually turned on
  4. What this means for a consent interface
  5. The part that stays unchanged

Google began switching on IP-based measurement and personalisation in the EEA, the UK and Switzerland on 3 August 2026. AdSense publishers had been told on 17 June. The notice was short, and the sentence carrying the weight named a field that most consent dialogues have never surfaced as anything a person could act on.

The field is TCF Feature 3. Understanding what changed means first understanding what a Feature is, because in the Transparency and Consent Framework it is not the same kind of object as a Purpose.

Four rows of numbered cells for TCF purposes, special purposes, features and special features, each annotated with the kind of user choice that applies; the third feature cell is highlighted and connected to a panel explaining what it declares
Only the first and last rows contain anything a person decides. Feature 3 sits in the third row, which is disclosed rather than chosen.

Four classes, two of them decisions

TCF v2.2 splits what a vendor declares into four groups, and they behave differently.

Purposes           11   consent or legitimate interest, per vendor
Special purposes    2   legitimate interest only, no user choice
Features            3   disclosure only, no separate user choice
Special features    2   explicit opt-in, off until ticked

Feature 3   "Identify devices based on information
             transmitted automatically"

  applies wherever the vendor has a valid basis for a purpose
  the feature was declared under
  never granted on its own, never refused on its own
  must appear in the disclosure the CMP presents

The distinction between a Feature and a Special Feature is the whole story. Precise geolocation is a Special Feature: it is off until someone ticks it, and a vendor without that tick may not use it. Feature 3 is an ordinary Feature. It is described in the interface, and it takes effect as a consequence of the purposes a vendor already has a basis for.

Why it looks like nothing was decided

Because nothing was, at least not directly. A person accepting a banner grants purposes. The features attached to those purposes come with them, and no toggle exists to separate them. That is by design: features describe how data is handled in service of a purpose rather than constituting a purpose of their own.

The practical result is that a change in what a vendor does under Feature 3 does not produce a new consent event, a new string value or a new count anywhere in reporting. The TC String records purposes and special-feature opt-ins. It does not record features, because there is nothing per-user to record.

What Google actually turned on

The processing concerns IP addresses that already arrive through existing site and app integrations. This is worth stating plainly, because the announcement was widely read as new collection. It is not: the addresses were already in the request. What changed is that they may now be used for device identification and for personalisation, subject to consent existing for at least one linked purpose.

Google describes three techniques as guarding the processing: computation on the device, trusted execution environments, and secure multi-party computation. Those are meaningful engineering commitments and they are also, from the outside, unverifiable. Nothing in the network trace distinguishes an IP address processed inside an enclave from one processed outside it.

What this means for a consent interface

The obligation that does land on publishers is disclosure. Google added Feature 3 to its TCF registration, and a consent interface that lists Google’s declared purposes and features has to list this one too. A CMP kept current handles that automatically; a CMP whose vendor data was last refreshed a year ago does not, and the gap is invisible from the front end.

Three checks are worth running once. Whether the CMP’s vendor list has been refreshed since June 2026. Whether the disclosure text presented for Google now names device identification from automatically transmitted information. And whether the purposes under which that feature is declared are ones the banner actually asks about, since that is what determines when it applies at all.

The part that stays unchanged

An IP address remains personal data, and none of this alters that. The GDPR obligations that attach to processing it are the same ones as before, and a technique that keeps the address inside an enclave changes the risk profile rather than the legal category.

What has changed is narrower and more concrete: a capability that was dormant is now active, it activates through a mechanism with no user-facing switch, and the only trace of it in a normal setup is a line of disclosure text that almost nobody reads. For anyone documenting a processing inventory, that line is now load-bearing.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

ALL ARTICLES & CATEGORIES

CCTV

Follow this category by RSS

Data Privacy

Follow this category by RSS

Digital Analytics

Follow this category by RSS

Digital Marketing

Follow this category by RSS

IT & Networks

Follow this category by RSS

Raspberry PI

Follow this category by RSS

Smart Home

Follow this category by RSS

Web Development

Follow this category by RSS

Wordpress Hacks

Follow this category by RSS