Modelowane listy odbiorców nie zawierają konkretnych osób, tylko prawdopodobieństwa. Wyjaśniam, jak powstają, gdzie ich szukać w panelu i jak czytać ich raporty.
Privacy Sandbox jest jednym z tych tematów, o których wszyscy w branży słyszeli i o których mało kto potrafi powiedzieć coś konkretnego. Rozumiem to: projekt trwa od 2019 roku, zmieniał nazwy komponentów, jedną technologię wycofał w trakcie testów, a terminy przesuwał trzy razy. Łatwo przestać śledzić.
W zeszłym tygodniu Google poinformowało, że ograniczanie ciasteczek stron trzecich w Chrome nie zacznie się w tym roku, a na początku przyszłego — powodem są rozbieżne opinie branży i kalendarz brytyjskiego urzędu antymonopolowego, który nadzoruje cały proces. To dobry moment, żeby spokojnie zrozumieć, o czym właściwie mówimy, zamiast reagować na kolejny nagłówek.
W tym tekście tłumaczę, czym te interfejsy są, jak działa każdy z trzech najważniejszych i co realnie zmieni się w sposobie, w jaki kierujemy reklamy do odbiorców. Bez przewidywań, bo w tym projekcie przewidywania starzeją się w ciągu miesiąca.
To nie produkt reklamowy i nie coś, co włącza się w panelu Google Ads. To zestaw interfejsów programistycznych wbudowanych w przeglądarkę Chrome — plus ich odpowiednik w systemie Android — które mają realizować część funkcji dzisiejszej reklamy internetowej bez udostępniania komukolwiek historii przeglądania pojedynczej osoby.
Kluczowa zmiana architektury polega na tym, że dane o użytkowniku przestają wędrować na serwery firm reklamowych, a zaczynają być przetwarzane lokalnie, w przeglądarce. Przeglądarka udziela odpowiedzi na pytania w rodzaju „czym ta osoba jest zainteresowana” albo „która reklama wygrała aukcję”, nie oddając danych źródłowych.
Najważniejsze elementy trafiły do Chrome w połowie 2023 roku i są dziś dostępne, choć ciasteczka wciąż działają, więc rynek z nich praktycznie nie korzysta. Wcześniejsza propozycja o nazwie FLoC, testowana w 2021 roku, została wycofana po krytyce i zastąpiona rozwiązaniem opisanym niżej — to jedyny raz, kiedy Google przyznało się do porzucenia całego pomysłu.
Czego Privacy Sandbox nie robi: nie zastępuje pomiaru na naszej własnej stronie, nie ma nic do rzeczy z ciasteczkami własnymi i nie dotyczy Safari ani Firefoxa, które ograniczyły ciasteczka stron trzecich po swojemu i bez żadnej rekompensaty dla reklamodawców.
Topics to następca FLoC i najprostszy do wyjaśnienia element całej układanki.
Chrome na podstawie odwiedzanych stron przypisuje użytkownikowi kilka tematów z listy przygotowanej przez ludzi — kilkuset szerokich kategorii w rodzaju „sprzęt fitness” albo „podróże lotnicze”. Lista jest jawna, wykluczono z niej kategorie wrażliwe, takie jak zdrowie, religia, orientacja czy pochodzenie. Tematy są liczone w cyklu tygodniowym i po kilku tygodniach wygasają, a witryna pytająca o nie dostaje tylko wąski wycinek — kilka tematów, nie profil.
Dla reklamodawcy najważniejsza konsekwencja jest taka, że rozdzielczość kierowania spada drastycznie. Dziś w sieci reklamowej można kierować reklamy na dość precyzyjnie opisaną intencję. Tam, gdzie zadziała Topics, dostępna będzie szeroka kategoria zainteresowań, bez historii i bez szczegółów. Bliżej temu do targetowania kontekstowego niż do tego, co branża nazywa behawioralnym.
Użytkownik ma nad tym kontrolę w ustawieniach Chrome — może zobaczyć swoje tematy, usunąć je albo wyłączyć mechanizm. Warto o tym pamiętać, planując, jak dużej części ruchu będzie to w ogóle dotyczyć.
Ten interfejs, znany wcześniej pod nazwą FLEDGE, obsługuje przypadek, który dla reklamodawców jest najcenniejszy: dotarcie do osób, które już były na naszej stronie.
Mechanizm jest odwrócony względem dzisiejszego remarketingu. Nie tworzymy listy identyfikatorów na serwerze reklamowym — to przeglądarka zapisuje u siebie informację o przynależności do „grupy zainteresowań” założonej przez reklamodawcę. Gdy użytkownik trafia na stronę wydawcy, aukcja odbywa się wewnątrz przeglądarki: skrypty kupującego i sprzedającego wyliczają stawki, a wynik jest wyświetlany w izolowanej ramce, z której nie da się wyciągnąć danych na zewnątrz.
Skutki praktyczne dla osoby prowadzącej kampanie są dwa i oba są niewygodne. Po pierwsze, nie ma czegoś takiego jak podejrzenie zawartości listy ani jej wyeksportowanie — informacja żyje w przeglądarkach użytkowników, nie w naszym systemie. Po drugie, obowiązują progi minimalnej liczebności grupy, żeby nie dało się zidentyfikować jednej osoby, więc bardzo wąskie segmenty przestają być możliwe. Kto lubi remarketing do dwustu osób z konkretnego produktu, będzie musiał się przestawić.
Trzeci element odpowiada za pomiar, czyli za powiązanie kliknięcia lub wyświetlenia z późniejszą konwersją, gdy dzieje się to między dwiema różnymi domenami.
Interfejs oferuje dwa rodzaje raportów. Pierwszy przypisuje konwersję do zdarzenia reklamowego, ale w formie mocno ograniczonej: niewiele bitów informacji, opóźnienie w czasie i celowo dodany szum. Drugi to raporty zbiorcze, przetwarzane w osobnej usłudze agregującej, w których widać sumy dla grup zdarzeń, nie pojedyncze przypadki.
Wniosek, który powtarzam klientom od dawna, brzmi: pomiar poza własną domeną przestaje być dokładny i to jest stan docelowy, nie awaria. Nikt tego nie naprawi, bo to nie błąd, a założenie projektowe. Raporty będą pokazywać wielkości szacowane, z modelowaniem i szumem, a różnice między systemami staną się normą.
Dlatego już dziś przestawiam rozmowy o wynikach z „ile dokładnie konwersji zrobiła ta kampania” na porównania okresów, testy z grupą kontrolną i pilnowanie sprzedaży w systemie klienta. Kto przez ostatnie lata nauczył się patrzeć na dane w ten sposób, przejdzie tę zmianę spokojnie.
Stan na koniec kwietnia 2024 jest następujący i warto go znać dokładnie, bo w branżowych dyskusjach mieszają się trzy różne rzeczy.
Trzy przesunięcia terminu w ciągu czterech lat nauczyły mnie, żeby nie planować pracy na konkretną datę. Planuję na kierunek, bo kierunek jest niezmienny od 2019 roku, a data była zmienna zawsze.
Rozdzielmy dwie sytuacje, bo od tego zależy, ile pracy nas czeka.
Jeśli kupujesz reklamy przez Google Ads, większość tych mechanizmów zostanie ukryta pod maską. Platforma sama zdecyduje, z których interfejsów korzysta, i nie będzie w panelu przełącznika „używaj Topics”. Zauważysz raczej skutki: mniejszą precyzję kierowania w sieci reklamowej, mniej stabilne rozmiary grup odbiorców, słabsze ograniczanie liczby wyświetleń tej samej osobie w różnych serwisach i większy udział wartości modelowanych w raportach.
Jeśli natomiast pracujesz po stronie technologii reklamowej albo dużego wydawcy, to jest zadanie inżynierskie na kwartały, nie temat na artykuł.
Dla kampanii w wyszukiwarce i produktowych zmiana będzie najmniej odczuwalna — tam intencja jest w zapytaniu, a nie w historii przeglądania. Najbardziej odczują to kampanie zasięgowe, remarketing display i wszystko, co polegało na łączeniu zachowań użytkownika z wielu witryn.
Nie polecam wdrażania niczego z Privacy Sandbox bezpośrednio, jeśli nie jesteś dostawcą technologii reklamowej. Polecam trzy rzeczy, które i tak trzeba zrobić, a które przy tej zmianie stają się pilniejsze.
Pierwsza: policzyć, jaka część wyników konta zależy od rozpoznawania użytkownika poza własną domeną. W sklepie z krótką ścieżką zakupu może to być kilka procent, w kampanii wizerunkowej dużej marki — większość. Ta liczba mówi, ile faktycznie ryzykujesz.
Druga: dokończyć porządki w pomiarze własnym. Poprawny tryb zgody, pełne dane o konwersjach z własnej strony, wartości transakcji, serwerowe wysyłanie zdarzeń tam, gdzie ma to sens. Nudne, znane od dwóch lat i nadal zrobione w mniejszości kont, które przejmuję.
Trzecia: przyzwyczaić siebie i klienta do oceny wyników na poziomie całości, nie pojedynczej konwersji. Porównania okresów, udział kanałów w przychodzie z systemu sprzedażowego, okresowe testy z wyłączeniem części budżetu. To umiejętność, która przyda się niezależnie od tego, kiedy i w jakiej formie Chrome domknie sprawę ciasteczek.
Używamy plików cookies, aby ułatwić Ci nawigację oraz wykonywanie określonych funkcji. Szczegółowe informacje o wszystkich plikach cookies znajdziesz w każdej kategorii zgody poniżej.
Pliki cookies oznaczone jako "Niezbędne" są przechowywane w Twojej przeglądarce, ponieważ są one kluczowe dla zapewnienia podstawowych funkcji strony.
Używamy również plików cookies firm trzecich, które pomagają nam analizować, w jaki sposób korzystasz z tej strony, zapamiętują Twoje preferencje oraz dostarczają treści i reklamy odpowiednie dla Ciebie. Te pliki cookies będą przechowywane w Twojej przeglądarce tylko za Twoją uprzednią zgodą.
Możesz zdecydować, czy chcesz włączyć lub wyłączyć niektóre bądź wszystkie te pliki cookies, jednak wyłączenie niektórych z nich może wpłynąć na Twoje doświadczenia podczas przeglądania strony.
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __cf_bm | 13 minutes | Cloudflare bot management — distinguishes humans from bots. |
| rc::* | Persistent | Google reCAPTCHA — localStorage holding anti-bot challenge state. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| wpEmojiSettingsSupports | Session | WordPress — sessionStorage flag caching whether the browser can render emoji (feature detection). |
| ytidb* | Persistent | YouTube — IndexedDB storing playback/search state for embedded videos. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| _ga_* | 400 days | Google Analytics 4 — persists session state per property. |
| _ga | 400 days | Google Analytics — distinguishes unique users via a client id. |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| NID | 183 days | Google — stores preferences for personalized ads. |
| fr | 90 days | Meta — encrypted Facebook id and browser id for ads. |
| _gcl_au | 90 days | Google AdSense/Ads — experiments with advertising efficiency (conversion linker). |
| Cookie | Czas przechowywania | Opis |
|---|---|---|
| __Secure-YNID | 180 days | |
| YSC | Session | |
| __Secure-ROLLOUT_TOKEN | 180 days | |
| VISITOR_INFO1_LIVE | 180 days | |
| VISITOR_PRIVACY_METADATA | 180 days | |
| datr | 400 days | |
| sb | 400 days | |
| wd | 7 days |