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.
Do 6 marca zostało kilka dni i jest to termin, który po raz pierwszy od dawna traktuję poważniej niż zwykłe „Google coś zmienia”. Nie chodzi o nową funkcję w panelu, którą można przetestować za miesiąc. Chodzi o warunek, po którego niespełnieniu część mechanizmów w koncie po prostu przestanie się zasilać danymi.
Komisja Europejska wyznaczyła w zeszłym roku wielkie platformy — w tym Alphabet — jako podmioty objęte obowiązkami Digital Markets Act i dała im sześć miesięcy na wdrożenie. Ten czas kończy się 6 marca. Google przełożyło część tych obowiązków na reklamodawców: jeżeli wysyłasz do Google dane użytkowników z Europejskiego Obszaru Gospodarczego i Wielkiej Brytanii, musisz udowodnić, że masz na to zgodę, i przekazywać tę informację razem z danymi.
Poniżej lista, którą przechodzę teraz na każdym prowadzonym koncie. Ułożyłem ją tak, jak to robię w praktyce: od rzeczy, których nie da się nadrobić po terminie, do tych, które są uciążliwe, ale odwracalne.
Warto rozdzielić dwie rzeczy, bo w rozmowach z klientami mieszają się nagminnie.
Pierwsza to obowiązki samego Google wynikające z regulacji: rozdzielenie danych między usługami, pytanie użytkowników o zgodę na łączenie danych z Wyszukiwarki, YouTube i pozostałych serwisów, a także zmiany w wynikach wyszukiwania w Europie. Na to nie mam żadnego wpływu i nie ma sensu tego optymalizować — mogę tylko obserwować, co się stanie z ruchem.
Druga to wymagania, które Google przenosi na reklamodawców. Tutaj jest cała robota. Google wymaga, żeby przy ruchu z EOG i Wielkiej Brytanii razem z danymi trafiały do niego dwa dodatkowe sygnały: zgoda na wykorzystanie danych użytkownika do celów reklamowych oraz zgoda na personalizację reklam. Bez nich konto nadal będzie działać, ale traci dostęp do wszystkiego, co wymaga danych o pojedynczej osobie.
Trzecia sprawa, o której nie zapominam przy planowaniu: to nie jest jednorazowe zadanie techniczne. Zgoda musi być zbierana i przekazywana codziennie, więc jeżeli coś się rozjedzie w marcu przy okazji przebudowy strony, dowiesz się o tym z opóźnieniem i po utracie danych.
Zaczynam od platformy zgody, bo wszystko dalsze jest jej pochodną.
Jeżeli klient używa wtyczki, która nie ma aktualizacji od miesięcy, to teraz jest moment na zmianę dostawcy, nie w połowie marca.
Sam banner nic nie da, jeśli jego decyzja nie dociera do tagów. Sprawdzam więc łańcuch od początku do końca.
Interesuje mnie, czy stan zgody jest ustawiany przed załadowaniem tagów Google, a nie po. Kolejność decyduje o tym, czy pierwsze odsłony w sesji są mierzone poprawnie. Drugie pytanie: czy wdrożenie jest w wariancie podstawowym, w którym tagi nie uruchamiają się wcale do momentu akceptacji, czy w rozszerzonym, gdzie tag ładuje się od razu, ale bez identyfikatorów. Wariant rozszerzony daje Google podstawę do modelowania brakujących konwersji, więc tam, gdzie to możliwe, wybieram właśnie jego — ale to decyzja, którą trzeba świadomie podjąć i uzgodnić z osobą odpowiedzialną za zgodność prawną, nie ustawić po cichu.
Trzecia rzecz to zakres geograficzny. Wymóg dotyczy EOG i Wielkiej Brytanii, ale w praktyce łatwiej i bezpieczniej jest ustawić domyślne odrzucenie dla całego ruchu niż utrzymywać reguły regionalne, w których po pierwszej zmianie na stronie nikt się nie orientuje.
Ta lista jest krótka, ale kosztowna, i warto pokazać ją klientowi przed terminem, nie po.
Bez przekazanych zgód przestają się zasilać listy remarketingowe — nie znikną, ale nowi użytkownicy nie będą do nich dopisywani. Przestaje działać dopasowanie danych z własnych baz, bo nie ma podstawy do przetwarzania adresów e-mail. Ograniczone zostają funkcje odbiorców oparte na sygnałach Google. Znika też część możliwości modelowania konwersji, czyli szacowania tych ścieżek, których nie da się zmierzyć bezpośrednio.
Co zostaje: kampanie działają, licytacja działa, konwersje z akceptacją zgody są mierzone normalnie. To nie jest scenariusz „konto przestaje działać”. To scenariusz „konto traci najbardziej dochodową część swojego arsenału i nikt tego nie zauważa przez sześć tygodni”.
Konta, które opierają część wyników na listach klientów, mają najwięcej do stracenia, więc traktuję je osobno.
Sprawdzam, czy w regulaminie i polityce prywatności jest podstawa do przekazywania danych kontaktowych do Google w celach reklamowych, i czy zgoda marketingowa w formularzu odpowiada temu, co faktycznie robimy z danymi. Zdarza się, że sklep od lat wysyła do Google listę wszystkich kupujących na podstawie zgody, która mówi wyłącznie o newsletterze.
Osobna rzecz to konwersje importowane z systemu CRM. Jeżeli konto podbija stawki na podstawie leadów domykanych offline, to ich import również musi być objęty zgodą przekazywaną razem z danymi. Widzę tu najwięcej luk, bo integracje CRM zwykle budował ktoś inny niż osoba prowadząca kampanie i nikt ich od tego czasu nie przeglądał.
Nawet przy wzorowym wdrożeniu marcowe raporty będą wyglądać inaczej i to jest normalne.
Robię więc dwie rzeczy zawczasu. Po pierwsze, zapisuję stan wyjściowy: liczbę użytkowników, konwersji i wielkość list odbiorców na koniec lutego. Bez tego w kwietniu nie odróżnię efektu wdrożenia zgód od zwykłej sezonowości. Po drugie, uprzedzam klienta pisemnie, że część danych będzie odtąd szacowana, a listy odbiorców mogą się zmniejszyć — lepiej powiedzieć to teraz niż tłumaczyć się z tego przy raporcie miesięcznym.
Warto też pamiętać o szerszym kontekście. Od stycznia Chrome ogranicza ciasteczka third-party u pierwszego procenta użytkowników, a Google utrzymuje, że w drugiej połowie roku obejmie tym wszystkich. Marcowy termin to tylko pierwszy z kilku momentów, w których pomiar będzie się psuł.
Gdybym miał dziś tylko kilka godzin na jedno konto, zrobiłbym to w tej kolejności.
Najpierw sprawdzam, czy narzędzie do zbierania zgody jest aktualne i czy przekazuje nowe sygnały — to jedyny punkt, którego nie da się zrobić od strony Google Ads. Potem weryfikuję w przeglądarce, czy stan zgody zmienia się po kliknięciu w banner, bo wdrożenie „na słowo dostawcy” zawiodło mnie już kilka razy. Następnie przeglądam listy odbiorców i integracje z bazami klientów pod kątem podstawy prawnej. Na końcu zapisuję stan wyjściowy raportów i wysyłam klientowi krótką notkę, czego się spodziewać w marcu.
Czego bym nie robił: nie przebudowywałbym w tym tygodniu struktury kampanii ani nie zmieniałbym strategii stawek. Przy zmianie, która sama z siebie wpłynie na dane konwersji, dorzucanie drugiej zmiennej to najprostszy sposób, żeby przez kolejny miesiąc nie wiedzieć, co się właściwie stało.
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 |