{"id":10545,"date":"2026-09-01T07:20:00","date_gmt":"2026-09-01T05:20:00","guid":{"rendered":"https:\/\/www.lukaswojcik.com\/blog\/?p=10545"},"modified":"2026-08-31T15:18:41","modified_gmt":"2026-08-31T13:18:41","slug":"the-segment-that-was-allowed-to-be-missing","status":"publish","type":"post","link":"https:\/\/www.lukaswojcik.com\/blog\/en\/data-privacy\/the-segment-that-was-allowed-to-be-missing\/","title":{"rendered":"The Segment That Was Allowed to Be Missing"},"content":{"rendered":"

A TC string consists of segments separated by dots. The first is the core segment and carries the purposes, the legal bases and the vendors for which consent exists. The third is optional. The second – disclosed vendors – was allowed to be absent up to TCF 2.2 and has been required since 2.3.<\/p>\n

The difference sounds like bookkeeping, and it is. That is precisely why it works: without this segment there is no way to demonstrate that a vendor which received consent was ever shown to the person giving it.<\/p>\n

\n\"At
The same set of vendors, two encodings. Which one ends up in the string is decided solely by which comes out shorter.<\/figcaption><\/figure>\n

What the segment contains<\/h2>\n

Every segment after the core segment begins with three bits of segment type. The value 1 means disclosed vendors, the value 3 the publisher segment, the value 0 stands for the core segment. Sixteen bits for the highest vendor ID included follow, and then a single bit deciding how the set itself is encoded.<\/p>\n

Layout of the \"disclosed vendors\" segment\n\n  SegmentType        3 bits   value 1\n  MaxVendorId       16 bits   highest vendor ID included\n  IsRangeEncoding    1 bit    0 = bit field, 1 = ranges\n\n  at 0    bit field    MaxVendorId bits, one per vendor,\n                       1 = shown, 0 = not shown\n\n  at 1    NumEntries  12 bits\n          per entry    IsARange              1 bit\n                       StartOrOnlyVendorId  16 bits\n                       EndVendorId          16 bits, only if IsARange = 1\n\n  segment types   0 = core   1 = disclosed vendors   3 = publisher TC<\/code><\/pre>\n
Both forms describe the same set. The specification merely requires choosing the one that produces the smaller output for the given set. A contiguous selection made of a few blocks fares much better with ranges; a selection scattered across the whole list tips the arithmetic towards the bit field, because every single value costs seventeen bits there and only one in the field.<\/p>\n
What the segment is aimed at<\/h2>\n
The gap it closes has a name: vendors appearing in the signal without ever having appeared in the interface. A consent banner could show a handful of names while the string it produced recorded consent for a considerably larger number of vendors. To whoever received the string the two cases were indistinguishable, because the information about what had been shown was simply not in it.<\/p>\n
That is exactly the charge levelled at the framework in European proceedings, and the answer to it is unusually direct. Instead of a rule of conduct there is now a mandatory field in the data format. A party that does not disclose can no longer claim to have done so, because the field would stay empty and validation sees it.<\/p>\n
What has been happening since the end of February<\/h2>\n
TCF 2.3 was published on 19 June 2025 and the transition ran until the end of February 2026. Google has required version 2.3 for all newly generated TC strings since 28 February 2026; the framework’s own binding deadline fell on 1 March. Validation went live in early March, and reports agree that the error report has carried a dedicated code since then for requests in which the segment is missing, malformed, or does not include Google.<\/p>\n
The consequence is not a warning in an interface but a decision at ad delivery: the request is served limited ads or dropped. That hits a site’s revenue directly and silently, because a dropped request leaves no message in the consent tool.<\/p>\n
Where the fault actually sits<\/h2>\n
What stands out about this change is how little it has to do with the site it affects. The string is written by the consent solution, and whether version 2.3 is produced depends on that solution’s version and configuration. A site can leave its banner untouched, meet every deadline, set every option correctly – and still emit invalid strings, because the embedded solution is still writing 2.2.<\/p>\n
The reverse holds as well: a current solution produces the segment by itself. The effort lies in establishing which of the two cases applies, and that can be read off a single string.<\/p>\n
How to read it off a string<\/h2>\n
The quickest route runs through the dots. A string without a dot consists of the core segment alone and therefore cannot contain the disclosure. A string with at least one dot has further segments, and the first three bits of each name its type. If the value 1 appears nowhere, the disclosure is missing too – the additional segment present is then the publisher segment.<\/p>\n
Where a decoder is at hand the matter takes a minute: take the string from the banner or from the network panel, split it, read the segment types. Where none is at hand, counting the dots is enough for a first suspicion. If the count stays at zero the finding is unambiguous, and the question is addressed not to the site but to the vendor of the consent solution.<\/p>\n
\n
Sources<\/h2>\n