LW IT Solutions logo LW IT Solutions logo LW IT Solutions
« Przegląd bloga /Data Privacy / Segment disclosed vendors w TCF 2.3: co...
Ten artykuł w innych językach:

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

Segment disclosed vendors w TCF 2.3: co zawiera i jak odczytać go z ciągu TC
Spis treści
  1. Jaką niejednoznaczność usuwa zmiana
  2. Budowa: pole bitowe albo lista zakresów
  3. Termin przejścia i błąd Google 1.4
  4. Odczyt rzeczywistego ciągu
  5. Pytania i odpowiedzi
  6. Źródła

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.

Disclosed Vendors jest rozpoznawany po typie 1, a nie po pozycji. Rzadki zbiór ilustruje rozmiar pola i listy zakresów.
Core jest pierwszy; dwa dodatkowe typy mogą wystąpić w dowolnej kolejności. Liczba bitów opisuje kodowanie, a nie dowód zgody.

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”.

Tekst
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 bits

MaxVendorId 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.

JavaScript
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.

Lukas Wójcik

Lukas Wójcik

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.

Kontakt

Masz pytanie lub pomysł na projekt internetowy? Napisz krótko, o co chodzi. Formularz korzysta z reCAPTCHA do ochrony przed spamem.

Napisanie komentarza

Obserwacje z innych wdrożeń, zastrzeżenia i pytania są tu mile widziane.

Adres e-mail nie jest publikowany. Pola obowiązkowe oznaczono gwiazdką.