Segment disclosed vendors w TCF 2.3: co zawiera i jak odczytać go z ciągu TC

Spis treści
Segment disclosed vendors w ciągu TC zgłasza, których dostawców platforma zarządzania zgodami (CMP) deklaruje jako ujawnionych w interfejsie. Przejście na TCF 2.3 uczyniło ten wcześniej opcjonalny segment obowiązkowym dla nowo tworzonych ciągów. Ujawnienie nie jest zgodą ani niezależnym dowodem prawidłowego wyświetlenia banera.
Core zawsze występuje jako pierwszy. Pozostałe części są identyfikowane przez typy segmentów, dlatego Disclosed Vendors nie musi zajmować drugiej pozycji. Opcjonalny PublisherTC może znajdować się przed tym segmentem albo za nim. Artykuł dotyczy struktury obowiązkowej od 2.3; aktualna specyfikacja zawiera już także późniejsze zmiany.

Jaką niejednoznaczność usuwa zmiana
Zmiana dotyczy szczególnie dostawców deklarujących cele specjalne oraz cele oparte na uzasadnionym interesie. Wcześniej zero w sekcji uzasadnionego interesu dostawcy mogło oznaczać zarówno brak ujawnienia, jak i wniesiony sprzeciw. Osobna informacja o ujawnieniu rozróżnia te sytuacje. Nie stanowi ogólnego zezwolenia na wszystkie cele dostawcy.
Segment jest deklaracją CMP dotyczącą ujawnienia. Błędnie działająca CMP może również ustawić nieprawidłową wartość. Nadal potrzebna jest kontrola interfejsu, informacji o dostawcach, zapisanych wyborów i przekazywanych sygnałów. Obowiązkowe pole nie zapobiega automatycznie fałszywym deklaracjom ujawnienia.
Budowa: pole bitowe albo lista zakresów
Dodatkowe segmenty zaczynają się od trzech bitów typu. Disclosed Vendors ma typ 1, binarnie 001, a PublisherTC typ 3. Core nie rozpoczyna się osobnym trzybitowym polem typu. Pierwsze pole to sześciobitowa wersja kodowania, obecnie 2. Ta liczba nie jest numerem wersji frameworka „2.3”.
SegmentType 3 bits 001 = DisclosedVendors
MaxVendorId (M) 16 bits
IsRangeEncoding 1 bit 0 = BitField, 1 = Range
BitField: M bits, IDs 1..M
Range: NumEntries (12 bits), następnie wpisy:
IsARange 1 bit
StartOrOnlyVendorId 16 bits
EndVendorId 16 bits (tylko dla zakresu)
BitField: 20 + M bits
Range: 32 + 17*S + 33*R bitsMaxVendorId oznacza górną granicę identyfikatorów reprezentowanych w segmencie, a nie liczbę ujawnionych dostawców. Pierwszy bit pola odpowiada ID 1. Ustawiony bit sygnalizuje ujawnienie; bit nieustawiony nie przekazuje takiego sygnału. Końce zakresów są włączone do zbioru, natomiast pojedynczy ID nie ma pola końcowego.
We wzorze S oznacza liczbę wpisów pojedynczych, a R liczbę rzeczywistych zakresów. Wyniki obejmują nagłówek segmentu, lecz nie dopełnienie ani kodowanie tekstowe. Specyfikacja zaleca mniejszą reprezentację. Rozproszony zbiór nie oznacza jednak automatycznie przewagi pola bitowego: {1, 1200} zajmuje 1220 bitów jako pole, ale tylko 66 bitów jako dwa pojedyncze wpisy. Dla gęstych zbiorów korzystniejsze może być pole bitowe.
Termin przejścia i błąd Google 1.4
TCF 2.3 opublikowano 19 czerwca 2025 r. Okres przejściowy zakończył się pod koniec lutego 2026 r.; aktualna dokumentacja integracji Google wskazuje 1 marca 2026 r. jako termin obowiązywania wymogu dla nowo tworzonych ciągów. Starsze zapisane ciągi nie stają się przez to automatycznie nieważne z mocą wsteczną. Nadal obowiązują odpowiednie reguły przejściowe i pozostałe wymagania ważności.
Google opisuje kod 1.4 dla brakującego lub niemożliwego do przetworzenia segmentu disclosed vendors albo braku ujawnienia Google. Google Advertising Products ma identyfikator dostawcy 755. Bit ujawnienia nie zastępuje innych wymaganych sygnałów ani rzeczywistego ujawnienia. Samo dopisanie brakującego bitu Google bez odpowiedniego ujawnienia nie jest więc poprawną naprawą.
Według komunikatu Google odpowiednie żądania mogą otrzymać ograniczone reklamy lub zostać odrzucone. Nie wynika z tego stały wpływ na przychód. Aktualna pomoc umieszcza raportowanie błędów TCF w Policy center; nie jest to z definicji cicha i niemożliwa do zdiagnozowania awaria.
Odczyt rzeczywistego ciągu
Kompletny ciąg bez kropek nie zawiera dodatkowego segmentu. Same kropki nie dowodzą jednak poprawności disclosed vendors. Znaczenie mają typ, możliwość dekodowania i zawartość. Nieznanego lub przestarzałego dodatkowego typu nie wolno automatycznie uznawać za PublisherTC.
Poniższy lokalny moduł JavaScript korzysta z @iabtechlabtcf/core, przetestowanego w wersji 1.5.22. Po instalacji tej wersji pakietu w lokalnym projekcie testowym funkcja przyjmuje kompletny ciąg TC odczytany z rzeczywistej integracji. Odczyt nie zmienia pamięci CMP ani wyborów.
import { TCString } from "@iabtechlabtcf/core";
export function inspectDisclosure(tcString) {
if (typeof tcString !== "string" ||
!/^[A-Za-z0-9_-]+(?:\.[A-Za-z0-9_-]+)*$/.test(tcString)) {
throw new Error("Invalid segment syntax");
}
const alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_";
const segments = tcString.split(".");
if (alphabet.indexOf(segments[0][0]) !== 2) {
throw new Error("Expected encoding version 2");
}
const types = segments.slice(1).map(s => alphabet.indexOf(s[0]) >> 3);
if (types.some(type => type !== 1 && type !== 3) ||
new Set(types).size !== types.length) {
throw new Error("Unsupported or duplicate segment type");
}
const model = TCString.decode(tcString);
const present = types.includes(1);
return {
segmentPresent: present,
disclosedVendorIds: present ? [...model.vendorsDisclosed.values()].sort((a, b) => a - b) : null,
googleDisclosed: present ? model.vendorsDisclosed.has(755) : null,
encodingVersion: model.version,
policyVersion: model.policyVersion
};
}segmentPresent rozróżnia brak segmentu od obecnego segmentu bez danego ID. null oznacza tutaj brak segmentu, a nie potwierdzoną odmowę. disclosedVendorIds zawiera identyfikatory zakodowane jako ujawnione; nazwy pochodzą z Global Vendor List odpowiadającej ciągowi.
Kod sprawdza część błędów struktury i dekoduje zawartość. Wynik nie stanowi pełnej kontroli TCF, podstaw prawnych ani interfejsu. Nieaktualną wartość wersji polityki także można zdekodować. Kontrola obejmuje świeże i zapisane wybory, rzeczywiście załadowaną wersję CMP oraz ciąg docierający do odbiorcy.
Pytania i odpowiedzi
Czy CMP musi ponownie zapytać po aktualizacji?
Nie wyłącznie z powodu tego przejścia. Instrukcja IAB dopuszcza uzupełnienie istniejących ciągów na podstawie wcześniej zapisanych informacji o ujawnieniu, bez zmiany lastUpdated. Bez historycznych zapisów nie wolno wymyślać wcześniejszego pokazania dostawców. Nowy ciąg powstaje wtedy przy późniejszym odnowieniu lub zmianie wyboru. Aktualna wersja programu nie potwierdza migracji wszystkich zapisanych wartości.
Czy długość ciągu może być problemem?
Tak, zależnie od miejsca zapisu i limitów odbiorcy. Liczą się pełna długość tekstu ze wszystkimi segmentami oraz sposób transmisji. Mniejsza reprezentacja bitowa skraca ciąg, ale nie usuwa każdej granicy. Pojedyncza próbka potwierdza tylko sprawdzony przypadek; długie listy dostawców i inne konfiguracje wymagają osobnych testów.
Czy poprawne dekodowanie potwierdza poprawny interfejs?
Nie. Ciąg zapisuje wygenerowany sygnał. Porównanie z wyświetlonymi informacjami, wyborami i rzeczywistym przekazaniem danych jest osobną kontrolą. Panel CMP, osadzony kod i zapisany ciąg mogą mieć różne stany aktualizacji.
Źródła
- IAB Europe: Transition to TCF v2.3
- Google Ad Manager: Publisher integration with the IAB Europe TCF
- Google AdSense: Transition to IAB TCF v2.3
- Google AdSense: Publisher integration and transition deadline
- Google AdSense: TCF implementation errors and code 1.4
- IAB Tech Lab: TC string and vendor list format
- IAB Tech Lab: Core encoder and decoder library