Kontekst: dlaczego W3C porządkuje prywatność w sieci właśnie teraz
Presja regulacyjna i decyzje organów nadzorczych
Nowy standard W3C dotyczący prywatności w sieci nie pojawia się w próżni. Jest odpowiedzią na rosnącą presję regulacyjną: RODO, dyrektywę ePrivacy, wytyczne EROD, decyzje krajowych organów nadzorczych oraz głośne sprawy dotyczące nielegalnego śledzenia użytkowników. Organy ochrony danych coraz częściej wprost wskazują, że dotychczasowe praktyki reklamowe i analityczne naruszają zasady minimalizacji, ograniczenia celu oraz legalności przetwarzania.
W praktyce oznacza to, że model „zbieramy wszystko, co się da, a potem znajdziemy dla tego zastosowanie” staje się nie do obrony. Wiele dużych firm otrzymało kary lub nakazy zmian za nieprzejrzyste wykorzystywanie ciasteczek, profilowanie bez ważnej zgody, łączenie danych z wielu źródeł bez podstawy prawnej czy brak realnej możliwości sprzeciwu. Standardy W3C mają w tym kontekście wprowadzić techniczne minimum zgodne z tym kierunkiem regulacyjnym.
Jeżeli regulacje wymuszają ograniczenie śledzenia, a narzędzia pozostają otwarte i bez kontroli, to konflikt interesów jest nieunikniony. Standard techniczny ma za zadanie spiąć te dwa światy: biznesu i prawa. Dla zespołów analitycznych i marketingowych jest to sygnał, że zmiany nie są już kwestią interpretacji prawnika, lecz będą „wbudowane” w przeglądarkę.
Jeśli dziś działasz na granicy prawa, licząc na brak kontroli, standard W3C sprawi, że część praktyk po prostu przestanie być technicznie możliwa – niezależnie od Twojej interpretacji przepisów.
Działania przeglądarek: blokada third‑party cookies i śledzenia
Drugi kluczowy wektor zmian to działania producentów przeglądarek. Safari (ITP), Firefox (ETP) i wreszcie Chrome zaczęły blokować lub drastycznie ograniczać third‑party cookies, fingerprinting i inne techniki śledzenia. Nie chodzi wyłącznie o same ciasteczka – blokowane są całe klasy żądań sieciowych, mechanizmy przechowywania danych w przeglądarce oraz możliwość korelacji użytkownika między wieloma stronami.
Bez wspólnego standardu każde środowisko mogłoby wprowadzać własne, niekompatybilne mechanizmy. Dla analityków i marketerów oznaczałoby to chaos: inne API w każdej przeglądarce, różne modele atrybucji, niespójne dane. W3C wchodzi tu jako arbiter: definiuje, co wolno, co ma sens, a co należy uznać za śledzenie wysokiego ryzyka.
Jeśli Twoje raporty już dziś różnią się znacząco między przeglądarkami, to jest to wyraźny sygnał ostrzegawczy. Po wejściu i adopcji nowych standardów W3C rozjazd bez odpowiedniej adaptacji może zamienić się w realną utratę danych i nieporównywalność wyników w czasie.
Chaos prywatnych rozwiązań platform reklamowych
Platformy reklamowe nie czekały na W3C. Każdy duży gracz zaczął proponować własne „privacy‑friendly” rozwiązania: serwerowe tagowanie, identyfikatory logowania, probabilistyczne modele atrybucji, cross‑device ID oparte na loginie. Problem w tym, że są to mechanizmy prywatne, tworzone pod interes danego vendora, często trudne do audytowania i porównania między sobą.
Brak wspólnego standardu oznaczałby, że każda organizacja musiałaby utrzymywać kilka równoległych integracji, różne modele liczenia konwersji i osobne procesy audytu dla każdego ekosystemu reklamowego. To nie skaluje się ani operacyjnie, ani kosztowo. Co ważne – część z tych prywatnych rozwiązań balansuje na granicy zgodności z prawem, np. poprzez nadmierne łączenie danych w chmurach vendora.
Standard W3C jest próbą postawienia „szyn”, po których mogą poruszać się poszczególne systemy reklamowe i analityczne. Jeśli vendor nie mieści się w tych ramach, to dla inspektora ochrony danych i zespołu compliance jest to jasny sygnał, że ryzyko jest podwyższone.
Kim jest W3C i jakie interesy spotykają się przy jednym stole
W3C (World Wide Web Consortium) to organizacja standaryzacyjna, w której zasiadają zarówno duże firmy technologiczne (przeglądarki, platformy reklamowe, dostawcy narzędzi analitycznych), jak i organizacje społeczne, środowisko akademickie oraz przedstawiciele administracji. Oznacza to, że standardy dotyczące prywatności są wynikiem negocjacji wielu interesów, a nie jednostronną deklaracją konkretnego vendora.
W obszarze prywatności istotną rolę odgrywają m.in. Privacy Community Group, Improving Web Advertising Business Group, czy W3C Technical Architecture Group. To tam rozstrzygane są szczegóły: jak zdefiniować tracking, jakie limity zastosować dla nowych API, jakie sygnały prywatności powinny być respektowane przez przeglądarkę i serwer.
Dla praktyków istotne jest jedno: standardy W3C nie są „prawem”, ale w praktyce stają się nim w warstwie technicznej. Przeglądarki implementują je często jako domyślną politykę. W efekcie to, co dziś jest „opcją”, jutro staje się domyślną konfiguracją użytkownika.
Grupy robocze W3C zajmujące się prywatnością i śledzeniem
Na mapie W3C kilka grup jest szczególnie ważnych dla analityki i marketingu:
- Privacy Community Group – analizuje ryzyka prywatności i proponuje ogólne zasady oraz wytyczne projektowania API.
- Improving Web Advertising Business Group – zajmuje się wpływem standardów na reklamę, proponuje kompromisy techniczne (np. ograniczenia, progi, modele agregacji).
- Web Application Security Working Group – definiuje zasady bezpieczeństwa aplikacji webowych, często powiązane z prywatnością (np. ograniczenia dla skryptów third‑party).
- Technical Architecture Group (TAG) – ocenia spójność nowych propozycji z architekturą sieci i zasadami privacy by design.
Śledzenie prac tych grup to dobry punkt kontrolny dla każdej organizacji poważnie traktującej przyszłość swojej analityki i reklamy. Wiele decyzji, które zauważasz dopiero jako zmianę w przeglądarce, było wcześniej miesiącami dyskutowanych właśnie tam.
Wniosek kontrolny: przeglądarka jako nowy strażnik prywatności
Jeżeli przeglądarka staje się głównym strażnikiem prywatności, to standard W3C dotyczący prywatności w sieci przestaje być ciekawostką dla developerów. Staje się nową warstwą wymagań technicznych, którą trzeba uwzględnić w projektowaniu każdego procesu: od tagowania strony, przez konfigurację narzędzi analitycznych, po dobór partnerów reklamowych.
Jeśli Twoje strategie opierają się na „dogadaniu się” z vendorami, a nie na zrozumieniu, co będzie technicznie możliwe na poziomie przeglądarki, to punkt startowy jest zły. Minimum to przyjęcie założenia, że to standard W3C wyznacza granice gry, a nie pojedyncza platforma reklamowa.
Co dokładnie reguluje nowy standard W3C dla prywatności
Zakres: jakie operacje na danych i jakie interfejsy obejmuje standard
Nowy standard W3C dla prywatności w sieci koncentruje się na operacjach, które umożliwiają śledzenie użytkownika w różnych kontekstach: między stronami, sesjami, urządzeniami i aplikacjami. Nie ogranicza się do ciasteczek – dotyczy całego spektrum mechanizmów pozwalających na identyfikację lub rozpoznawanie tej samej osoby w czasie.
Zakres obejmuje w szczególności:
- dostęp do mechanizmów przechowywania danych w przeglądarce (cookies, localStorage, sessionStorage, IndexedDB, cache),
- interfejsy sieciowe pozwalające na wysyłanie i odbieranie danych do serwerów third‑party,
- API udostępniające informacje o urządzeniu, przeglądarce i środowisku (tzw. powierzchnia fingerprintingu),
- mechanizmy raportowania konwersji, zdarzeń, atrybucji oraz targetowania reklam.
Kluczowym elementem jest rozróżnienie pomiędzy operacjami niezbędnymi do dostarczenia usługi (np. zapamiętanie zawartości koszyka) a działaniami służącymi do profilowania lub śledzenia między serwisami. Standard wprost preferuje te pierwsze, a drugie próbuje objąć ramami i ograniczeniami.
Definicje: tracking, first‑party, third‑party, party context
Bez spójnych definicji nie ma mowy o sensownej regulacji technicznej. Standard W3C bardzo mocno opiera się na pojęciach first‑party, third‑party i party context. To od nich zależy, czy dana operacja będzie traktowana jako śledzenie wysokiego ryzyka, czy jako akceptowalny element działania serwisu.
W uproszczeniu:
- first‑party – podmiot, którego domena jest widoczna w pasku adresu i z którym użytkownik wchodzi w bezpośrednią relację (właściciel serwisu),
- third‑party – każdy inny podmiot osadzony na stronie (skrypty, iframy, zasoby z innych domen), który nie jest tym bezpośrednim właścicielem kontekstu,
- party context – konkretny zestaw domen i podmiotów, które wspólnie tworzą jeden „kontekst relacji” z użytkownikiem (np. domeny należące do tej samej organizacji, jasno komunikującej tę grupę).
Tracking w standardzie jest rozumiany jako zdolność do rozpoznawania użytkownika lub jego urządzenia w wielu kontekstach i czasie, zwłaszcza gdy obejmuje to różne first‑party. Im większy zasięg i czas życia identyfikatora, tym wyższa kategoria ryzyka.
Jeżeli Twój proces wymaga identyfikowania użytkownika poza Twoją własną domeną lub łączenia go z danymi z innych serwisów, to nowy standard klasyfikuje to jako tracking wymagający mocnych ograniczeń lub alternatywy.
Mapowanie standardu na istniejące mechanizmy: cookies, storage, fingerprinting
Standard W3C nie zakazuje ciasteczek ani localStorage samych w sobie. Wprowadza jednak powiązanie tych mechanizmów z kontekstem party oraz celem operacji. Z perspektywy praktyka oznacza to konieczność przełożenia istniejącej architektury danych w przeglądarce na nowy model:
- cookies – ściśle powiązane z domeną first‑party; ciasteczka third‑party są ograniczane lub wygaszane, a ich użycie do śledzenia cross‑site jest technicznie blokowane,
- localStorage / sessionStorage / IndexedDB – traktowane jako potencjalne źródło identyfikatorów; wykorzystywanie ich do śledzenia poza first‑party kontekstem jest klasyfikowane jako tracking wysokiego ryzyka,
- fingerprinting – łączenie informacji o urządzeniu, przeglądarce i zachowaniu w celu stworzenia trwałego identyfikatora jest wprost wskazywane jako praktyka nieakceptowalna; standard promuje zmniejszanie „powierzchni fingerprintingu” poprzez ograniczanie dostępnych parametrów.
W praktyce to, co dotąd było „sprytnym obejściem” blokady cookies, będzie formalnie uznane za naruszenie zasad prywatności w sieci. Zespół techniczny nie może już traktować alternatywnych storage’ów jako bezpiecznej przystani dla śledzenia.
Mechanizmy ograniczane i te z „korytarzem bezpieczeństwa”
Nowy standard nie jest tylko listą zakazów. Wprowadza strukturę: operacje całkowicie niedozwolone, operacje tolerowane w minimalnym zakresie oraz operacje promowane. W uproszczeniu:
- oczywiście ograniczane: długoterminowe identyfikatory cross‑site, fingerprinting, przekazywanie identyfikatorów do podmiotów niebędących częścią kontekstu party, synchronizacja ID między systemami reklamowymi (tzw. cookie matching),
- „korytarz bezpieczeństwa”: krótkotrwałe identyfikatory na potrzeby pomiaru konwersji, agregowane raporty skuteczności kampanii, targetowanie oparte na szerokich kategoriach (np. Topics), ograniczone remarketingowe listy tworzone w przeglądarce,
- preferowane: analityka zagregowana po stronie serwera first‑party, reklama kontekstowa, funkcje personalizacji oparte na deklaracjach użytkownika w ramach jednej domeny.
„Korytarz bezpieczeństwa” nie jest dowolny. Standard narzuca tam mechanizmy minimalizacji danych, dodawania szumu (noise), progów raportowania (np. minimalna liczba użytkowników w kohorcie), a także ograniczenia czasowe. Te parametry są kluczowe przy projektowaniu nowej architektury pomiaru.
Praktyki wysokiego ryzyka w świetle standardu – lista kontrolna
Na etapie audytu szczególnie należy prześwietlić następujące obszary:
- wykorzystywanie third‑party cookies do profilowania na wielu domenach,
- wielosystemowa synchronizacja identyfikatorów użytkownika (ID sync),
- zapisywanie trwałych identyfikatorów w localStorage lub IndexedDB dla potrzeb reklamowych,
- generowanie „device ID” na podstawie zestawu parametrów przeglądarki (fingerprinting),
- wstrzykiwanie skryptów analitycznych i reklamowych poprzez CNAME cloaking i serwer‑side proxy, aby „udawały” first‑party.
Jeśli Twoje procesy opierają się na rozpoznawaniu użytkownika pomiędzy serwisami, to nowy standard W3C wprost dotyka fundamentów Twojego modelu działania. Minimum to lista takich praktyk oraz decyzja: wyłączamy, przekształcamy, czy zastępujemy nowymi API.
Konsekwencje dla ciasteczek: koniec śledzenia third‑party w dotychczasowej formie
Jak dziś działają third‑party cookies w reklamie i analityce
Third‑party cookies były przez lata podstawą ekosystemu reklamy online. Pozwalały na:
- budowę profili użytkowników na wielu stronach (behavioral targeting),
- retargeting – „śledzenie” użytkownika po opuszczeniu strony,
Dlaczego third‑party cookies znikają z „pola gry”
Third‑party cookies w naturalny sposób trafiły na listę praktyk wysokiego ryzyka. Łączą kilka krytycznych cech, które z perspektywy W3C i regulatorów są nie do zaakceptowania w długim horyzoncie:
- działają w tle, bez czytelnego dla użytkownika wskazania, kto zbiera dane i w jakim celu,
- umożliwiają budowę długotrwałych profili zachowań na wielu serwisach jednocześnie,
- pozwalają na masową wymianę identyfikatorów pomiędzy vendorami (ID sync, cookie matching),
- trudno je powiązać z realną kontrolą użytkownika – zgoda na jednym serwisie często „ciągnie się” za nim wszędzie.
Nowy standard W3C podpina third‑party cookies pod najwyższą kategorię ryzyka w zakresie śledzenia cross‑site. Przeglądarki dostają wprost zielone światło do ich systemowego wygaszania: od domyślnego blokowania, przez skracanie czasu życia, po całkowite usunięcie wsparcia dla tradycyjnego modelu third‑party.
Jeżeli Twoja analityka, DMP lub platforma reklamowa opiera się na globalnym identyfikatorze z ciasteczka third‑party, to mówimy o fundamencie zagrożonym, a nie o kosmetycznej zmianie konfiguracji.
Zmiana roli first‑party cookies i skrócenie horyzontu danych
Wraz z odcięciem third‑party rośnie znaczenie ciasteczek first‑party, ale ich rola także jest redefiniowana. Standard przesuwa akcent z „jak najdłużej i jak najwięcej” na „tyle, ile realnie potrzeba dla danej usługi”. To dotyczy zarówno zakresu danych, jak i czasu ich przechowywania.
Typowe zmiany projektowe, które wymusza nowy porządek:
- segregacja funkcji – osobne identyfikatory (i często osobne cookies) do utrzymania sesji, osobne do personalizacji, osobne do pomiaru; jeden „super‑ID” do wszystkiego to sygnał ostrzegawczy,
- ograniczenie czasu życia – zamiast lat przechowywania tego samego ID w przeglądarce – miesiące, tygodnie, a dla części funkcji nawet dni,
- powiązanie z deklaracją użytkownika – ID używane do celów wykraczających poza stricte niezbędne (np. remarketing) musi być logicznie związane z wyborem użytkownika, a nie „przy okazji” logowania.
Jeżeli wszystkie kluczowe funkcje marketingowe opierają się na jednym długotrwałym identyfikatorze first‑party, łatwo tę konfigurację zaklasyfikować jako wysokie ryzyko i cel do przebudowy w stronę rozdzielenia ról i skrócenia retencji.
Punkt kontrolny: jak rozpoznać krytyczne zależności od ciasteczek
Przed decyzją o migrowaniu do nowych API potrzebny jest porządny audyt samego wykorzystania ciasteczek. Minimum to inwentaryzacja techniczna, a nie tylko przegląd banera zgód. Krytyczne pytania kontrolne to m.in.:
- które systemy zewnętrzne zapisują lub odczytują cookies na Twojej domenie i po co,
- czy istnieją mechanizmy ustawiania cookies third‑party „przebranych” za first‑party (np. przez CNAME lub proxy),
- jak długo żyją kluczowe identyfikatory i do ilu systemów są przekazywane,
- czy da się wskazać konkretne funkcje serwisu, które przestaną działać bez tych identyfikatorów.
Jeżeli nie jesteś w stanie precyzyjnie odpowiedzieć na powyższe pytania, to oznacza brak kontroli nad podstawową warstwą danych w przeglądarce, a tym samym wysokie ryzyko niezgodności z nowym standardem i kolejnymi krokami przeglądarek.
Modele śledzenia, które de facto znikają
Nie chodzi wyłącznie o sam mechanizm cookies, ale o całe scenariusze śledzenia, które były na nich zbudowane. W szczególności:
- „globalny user ID” third‑party – jeden identyfikator wykorzystywany na setkach serwisów, utrzymywany przez years, powiązany z profilem w DMP,
- retargeting oparty na pikselach third‑party – typowy scenariusz: odwiedzasz sklep X, piksel Y stawia ciasteczko, które następnie „podąża” za Tobą po całej sieci,
- „lookalike” budowany zewnętrznie – vendor bierze Twoje listy, miesza je z własnym globalnym ID i tworzy podobne grupy na bazie śledzenia między setkami innych serwisów,
- pomiar cross‑site w jednym narzędziu third‑party – jedno narzędzie zewnętrzne mierzy zachowania użytkownika na wielu domenach, dzięki temu, że rozpoznaje go po tym samym ciasteczku third‑party.
Jeżeli kluczowe wskaźniki biznesowe (np. ROAS, LTV) są kalibrowane na danych z takich modeli, to wymagana jest zmiana metodologii pomiaru, a nie tylko „patch” techniczny na poziomie implementacji.
Nowe mechanizmy W3C dla prywatności: logika „privacy by default”
Nowy zestaw rozwiązań, do którego często wrzuca się hasło „Privacy Sandbox”, ma wspólny mianownik: śledzenie użytkownika w wielu kontekstach ma być technicznie utrudnione, a w wielu przypadkach wręcz niemożliwe, natomiast agregowane statystyki i reklama oparta na sygnałach z przeglądarki – nadal osiągalne.
Architektura opiera się na kilku zasadach:
- przeglądarka jako mediator – to ona decyduje, jakie dane i w jakiej postaci wychodzą do zewnętrznych serwerów,
- agregacja zamiast surowych eventów – dane o konwersjach czy zainteresowaniach użytkowników są łączone w zbiory, a nie raportowane z osobna,
- noise i progi raportowania – do części danych dodawany jest kontrolowany „szum”, a raport pojawia się dopiero powyżej określonej liczby użytkowników,
- kontekst lokalny – przeglądarka przechowuje część informacji lokalnie, a nie wypycha ich do chmury vendora.
Jeżeli dotąd strategia pomiaru i targetowania sprowadzała się do „zainstaluj skrypt od X i daj mu wszystko, co może zebrać”, to nowy model jest kompletnie odwrotny: najpierw określ, jakiej agregacji potrzebujesz, a dopiero potem zobacz, które API W3C to umożliwia.
Privacy Sandbox: główne komponenty z perspektywy analityki i reklam
Privacy Sandbox nie jest jednym narzędziem, ale rodziną interfejsów. Z punktu widzenia praktyka reklam i analityki kluczowe są:
- Topics API – mechanizm umożliwiający targetowanie reklam na poziomie zainteresowań, ale bez osobistych profili per użytkownik,
- Protected Audience (dawniej FLEDGE) – system budowania grup odbiorców i remarketingu, w którym listy użytkowników są przechowywane i przetwarzane w przeglądarce,
- Attribution Reporting API – nowy sposób raportowania konwersji i atrybucji kampanii bez dostępu do surowych, identyfikowalnych logów kliknięć i wyświetleń,
- Fenced Frames i inne mechanizmy izolacji – nowe typy kontenerów na reklamy i skrypty, które ograniczają dostęp do danych z otoczenia strony.
Jeżeli plan wdrożenia nie mapuje jasno istniejących use case’ów (remarketing, atrybucja, segmentacja) na konkretne interfejsy Privacy Sandbox, to znaczy, że projekt działa „po omacku” i trudno będzie później ocenić skutki biznesowe migracji.
Topics API: targetowanie bez pełnego profilu
Topics API przenosi część funkcji dotychczasowego profilowania do przeglądarki. Zamiast ciągłego śledzenia użytkownika na wszystkich stronach, przeglądarka okresowo przypisuje mu kilka ogólnych kategorii zainteresowań, wywnioskowanych z odwiedzanych domen. Te kategorie są następnie udostępniane ograniczonej liczbie podmiotów, które mogą je wykorzystać do doboru reklam.
Dla praktyka kluczowe parametry to:
- limit liczby tematów, które można odczytać w danym oknie czasowym,
- poziom ogólności tematów – to nie są „mikrosegmenty”, tylko szerokie kategorie,
- brak trwałego identyfikatora użytkownika związanego z konkretną listą tematów.
Jeżeli Twoje kampanie opierają się na bardzo szczegółowych segmentach zachowań, Topics API wymusi przeskalowanie strategii do szerszych wiader oraz sprawdzenie, czy obecne kryteria targetowania da się w ogóle przenieść na poziom dostępnych tematów.
Protected Audience: remarketing i aukcje „wewnątrz” przeglądarki
Protected Audience zmienia sposób, w jaki buduje się listy remarketingowe i przeprowadza aukcje reklam. Zamiast wysyłać identyfikatory użytkowników do zewnętrznego systemu, przeglądarka przechowuje informacje o tym, że dany użytkownik spełnił kryteria w danym „interesie” (interest group). Gdy dochodzi do aukcji reklam, logika wyboru jest wykonywana lokalnie, bez przekazywania pełnych danych na zewnątrz.
To ma kilka konsekwencji operacyjnych:
- listy remarketingowe są technicznie ograniczone do tych użytkowników i urządzeń, gdzie Protected Audience jest dostępne i włączone,
- pięknie spięte, cross‑device’owe scenariusze remarketingowe stają się trudniejsze, bo brakuje jednego zewnętrznego ID,
- testy A/B różnych wariantów aukcji wymagają innego podejścia, bo część logiki nie opuszcza przeglądarki.
Jeżeli Twoje obecne listy remarketingowe żyją w zewnętrznym DMP/CRM i są synchronizowane przez cookie matching, to migracja oznacza przeprojektowanie całego łańcucha: od definicji segmentu, przez sposób jego zapisu, po mechanizm wyświetlania kreacji.
Attribution Reporting API: pomiar konwersji bez globalnych ID
Attribution Reporting API zastępuje klasyczne modele atrybucji oparte na łączeniu kliknięć i konwersji za pomocą jednego identyfikatora w ciasteczku. Zamiast tego, przeglądarka rejestruje zdarzenia powiązane z reklamą (klik, wyświetlenie) oraz potencjalne konwersje, a następnie raportuje je w formie zanonimizowanych danych – event‑level lub agregowanych.
Kluczowe zmiany z punktu widzenia analityka:
- brak możliwości swobodnego łączenia danych o pojedynczych użytkownikach na poziomie logów,
- limity dotyczące liczby sygnałów, jakie można powiązać z jedną konwersją,
- opóźnienia i szum dodawany do raportów, aby utrudnić odtworzenie ścieżki konkretnej osoby.
Jeżeli dotąd analiza efektywności kampanii opierała się na dokładnych ścieżkach użytkownika między kanałami i domenami, Attribution Reporting wymusi przesunięcie akcentu z indywidualnych ścieżek na modele statystyczne oraz testy eksperymentalne (np. geo‑testy, holdouty).
Sygnały z przeglądarki zamiast surowych danych: nowy język współpracy z vendorami
Nowy standard de facto zmienia kontrakt między właścicielem serwisu a vendorami analityczno‑reklamowymi. Dotychczas głównym „produktem”, który strona przekazywała na zewnątrz, były surowe dane o zachowaniach użytkownika (eventy, identyfikatory, parametry urządzenia). Teraz rośnie rola przetworzonych sygnałów dostarczanych przez przeglądarkę.
Dla projektowania architektury oznacza to m.in.:
- przegląd obecnych integracji – które z nich oczekują surowych ID i logów, których wkrótce nie będzie można legalnie lub technicznie dostarczyć,
- redesign umów z vendorami – od „dostarczymy dane X i Y” do „będziemy mogli korzystać z sygnałów A, B, C poprzez konkretne API”,
- zmianę KPI – zamiast oceniać vendorów po ilości zbieranych danych, sensowniej oceniać ich po tym, jak efektywnie potrafią wykorzystać ograniczone sygnały.
Jeżeli partner technologiczny nie ma jasnej odpowiedzi, jak jego produkt działa w środowisku pozbawionym third‑party cookies i opartym na Privacy Sandbox, to jest to silny sygnał ostrzegawczy na etapie wyboru lub renegocjacji współpracy.
Punkt kontrolny: jak przygotować architekturę danych na nowe API
Adaptacja do nowego standardu to w dużej mierze ćwiczenie z projektowania architektury danych „od końca”. Nie zaczyna się od wdrożenia konkretnego API, tylko od odpowiedzi na pytanie: ja