O czym właściwie mówimy

Hasło „rozszerzone funkcje ochrony prywatności” brzmi jak nazwa jednego przełącznika, a w praktyce oznacza kilka niezależnych mechanizmów, które warto od siebie odróżnić.

Pierwsza grupa to mechanizmy zgody: zbieranie decyzji użytkownika i przekazywanie jej stanu do wszystkich narzędzi pomiarowych, tak żeby nie zapisywały danych, na które zgody nie ma.

Druga to przekazywanie danych własnych w formie nieodwracalnie zaszyfrowanej. Zamiast polegać na identyfikatorze z ciasteczka, przekazujemy skrót z adresu e-mail albo numeru telefonu, który klient sam nam podał przy zakupie. System reklamowy dopasowuje go po swojej stronie, jeśli ma taki sam skrót.

Trzecia to przeniesienie pomiaru na własną infrastrukturę: kontener po stronie serwera, wysyłka zdarzeń z systemu sprzedażowego, obsługa tagów z własnej domeny. Chodzi tu zarówno o odporność na blokady, jak i o kontrolę nad tym, co faktycznie wychodzi z naszego serwisu.

Te trzy rzeczy działają w innych warstwach i nie zastępują się wzajemnie. Wdrożenie skrótów danych bez uporządkowanych zgód to nie modernizacja pomiaru, tylko ryzyko prawne opakowane w język techniczny.

Warstwa zerowa: zgody i ich sygnalizowanie

Zaczynam zawsze tutaj i w większości projektów tu też znajduję największy problem.

Formalnie od marca 2024 roku, jeśli kierujemy reklamy na Europejski Obszar Gospodarczy i korzystamy z remarketingu albo pomiaru w Google Ads, wymagane jest przekazywanie stanu zgody w rozszerzonej postaci — z osobnymi sygnałami dla przechowywania danych reklamowych i dla samego użycia danych na potrzeby reklamy. Do tego dochodzi wymóg korzystania z certyfikowanego narzędzia do zbierania zgód.

Czego szukam przy audycie tej warstwy:

• Czy stan zgody jest naprawdę przekazywany, a nie tylko zapisywany w banerze. To najczęstszy błąd: narzędzie do zgód działa, wyświetla poprawne opcje, ale tagi nie dostają żadnego sygnału i zachowują się identycznie w obu przypadkach.

• Czy stan domyślny jest ustawiony przed załadowaniem tagów. Kolejność ma tu znaczenie absolutne. Sygnał wysłany po tagu nie cofa tego, co tag już zrobił.

• Czy odmowa jest równie łatwa jak akceptacja. To wymóg prawny, ale ma też wymiar praktyczny: baner, który utrudnia odmowę, generuje zgody wymuszone, a te bywają wycofywane albo podważane.

• Czy zgoda jest odnotowywana z datą i zakresem. Bez tego zapisu nie da się później udowodnić niczego ani porządnie obsłużyć wycofania.

Warto rozumieć, po co to robimy poza samą zgodnością. Przy poprawnie przekazywanych sygnałach systemy Google mogą uzupełniać brakujące zachowania modelowaniem. Bez sygnałów nie mają czego modelować i luka pozostaje luką — więc dobrze wdrożona warstwa zgód nie tylko zabezpiecza prawnie, ale też ratuje część danych.

Konwersje rozszerzone: skróty danych własnych

To mechanizm dostępny od kilku lat i wciąż, w moim doświadczeniu, najrzadziej poprawnie wdrożony spośród wszystkich opisywanych tu rzeczy.

Idea jest prosta. Przy konwersji użytkownik zwykle podaje adres e-mail albo telefon. Zamiast wysyłać te dane w postaci jawnej, przeglądarka albo serwer liczy z nich nieodwracalny skrót i wysyła sam skrót. Google porównuje go z danymi, które ma po swojej stronie, i jeśli trafi, przypisuje konwersję do kliknięcia — nawet gdy identyfikator z ciasteczka już nie istnieje.

Osobny wariant obsługuje pozyskiwanie kontaktów. Tam konwersja domyka się dopiero w systemie sprzedażowym, często po tygodniach, więc zdarzenie przesyła się później: razem ze skrótem danych z formularza i informacją o etapie, na którym kontakt się znalazł. To najlepszy znany mi sposób, żeby algorytm przestał optymalizować pod liczbę formularzy, a zaczął pod jakość kontaktów.

Rzeczy, na które uważam przy wdrożeniu:

• Normalizacja przed policzeniem skrótu. Małe litery, obcięte spacje, numer telefonu w formacie międzynarodowym. Bez tego skróty się nie zgodzą i wdrożenie „działa”, ale nic nie dopasowuje.

• Zgodność z zapisami w politykach. Przekazywanie danych klientów, choćby w formie skrótu, wymaga podstawy prawnej i opisania tego w dokumentach. To rozmowa z klientem, nie zadanie do zrobienia po cichu.

• Weryfikacja w panelu. Google raportuje stan wdrożenia i skuteczność dopasowania. Warto tam zaglądać po tygodniu, a nie zakładać, że skoro tag się uruchamia, to wszystko jest w porządku.

Pomiar po stronie serwera i tagi z własnej domeny

Trzecia warstwa jest najdroższa we wdrożeniu i dlatego stawiam ją na końcu, choć często jest omawiana pierwsza, bo brzmi najbardziej poważnie.

Kontener działający na serwerze przyjmuje zdarzenia z przeglądarki, a dopiero z serwera wysyła je dalej do systemów reklamowych. Daje to trzy rzeczy: mniej kodu wykonywanego u użytkownika, jedno miejsce, w którym widać i kontroluje się wysyłane dane, oraz odporność na część blokad działających w przeglądarce.

Nie jest to rozwiązanie darmowe ani bezobsługowe. Trzeba utrzymać środowisko, monitorować je i pamiętać, że błąd w jednym miejscu psuje pomiar wszystkich narzędzi naraz. Przy małym koncie ta cena bywa wyższa niż zysk.

Osobno warto wspomnieć o nowszym podejściu, które Google przedstawiło wiosną tego roku: obsłudze skryptów pomiarowych z własnej domeny reklamodawcy poprzez warstwę pośredniczącą, bez budowania pełnego kontenera serwerowego. Cel jest ten sam — sprawić, żeby żądania pomiarowe wyglądały jak żądania do własnego serwisu, a nie do zewnętrznego dostawcy. To rozwiązanie świeże i podchodzę do niego ostrożnie, ale kierunek jest jasny: pomiar przenosi się na infrastrukturę pierwszej strony.

Niezależnie od wybranej drogi zasada jest ta sama. Przeniesienie wysyłki na serwer nie zwalnia z respektowania zgód. Zdarzenie wysłane z serwera mimo odmowy jest dokładnie tym samym naruszeniem, co zdarzenie wysłane z przeglądarki, tylko trudniejszym do wykrycia z zewnątrz.

Listy klientów i dane, których nie wolno wysyłać

Ostatni element to przekazywanie zbiorów danych, a nie pojedynczych zdarzeń: list klientów do kierowania i wykluczania.

Tu obowiązują dwie reguły, których pilnuję bez wyjątków. Pierwsza: dane muszą być zebrane w sposób, który pozwala je do tego użyć — czyli z odpowiednią zgodą albo inną podstawą, opisaną w polityce. Druga: adresy i telefony wysyłamy wyłącznie jako skróty, policzone po normalizacji, najlepiej po naszej stronie, zanim opuszczą naszą infrastrukturę.

Czego nie wysyłam nigdy, niezależnie od tego, jak wygodne by to było: danych, z których wynika stan zdrowia, sytuacja finansowa, orientacja, poglądy albo przynależność do grup szczególnie chronionych. Dotyczy to również pośrednich śladów, na przykład nazw zdarzeń albo etykiet kampanii ujawniających kategorię produktu medycznego. Regulaminy systemów reklamowych są tu jednoznaczne, a konsekwencją jest zablokowanie konta, nie upomnienie.

Trzecia rzecz, praktyczna: listy trzeba odświeżać. Zbiór wgrany raz i zapomniany traci dopasowanie z każdym miesiącem, a przy wykluczeniach zaczyna szkodzić — reklamy wracają do osób, które już kupiły.

Kolejność wdrożenia i najczęstsze błędy

Ustalona kolejność ma tu większe znaczenie niż w większości projektów, bo kroki wzajemnie się warunkują.

Najpierw zgody: narzędzie, przekazywanie sygnałów, zapis decyzji, weryfikacja w trybie diagnostycznym. Dopiero potem konwersje rozszerzone dla witryny, bo wcześniej wysyłalibyśmy skróty danych bez podstawy. Trzeci krok to zdarzenia domykane w systemie sprzedażowym, jeśli firma prowadzi sprzedaż z udziałem handlowca. Czwarty, opcjonalny, to przeniesienie pomiaru na serwer albo obsługa tagów z własnej domeny. Piąty to listy klientów.

Błędy, które widzę najczęściej, są zawsze te same. Wdrożenie skrótów danych bez sprawdzenia normalizacji, przez co dopasowanie jest zerowe, a nikt tego nie zauważa. Pozostawienie starego tagu obok nowej konfiguracji, co daje podwójne liczenie i psuje uczenie algorytmu. Sygnał zgody wysyłany z opóźnieniem względem tagów. Kontener serwerowy postawiony raz i nigdy nieaktualizowany. I wreszcie brak jakiejkolwiek dokumentacji, przez co po zmianie osoby prowadzącej konto nikt nie wie, co gdzie się wysyła.

Dlatego każde takie wdrożenie kończę jedną stroną notatek: co wysyłamy, skąd, na jakiej podstawie i kto to zmienił ostatni raz. Brzmi to jak biurokracja, a jest jedyną rzeczą, która ratuje projekt przy audycie albo przy pierwszej awarii.

Czego to wszystko nie naprawi

Na koniec granice, bo bez ich nazwania łatwo obiecać klientowi zbyt wiele.

Żadne z tych wdrożeń nie przywróci pełnego obrazu ścieżki użytkownika. Odbudowują część brakujących dopasowań i pozwalają algorytmom uczyć się na lepszych danych, ale luka pozostaje i będzie rosła wraz z odsetkiem osób odmawiających zgody. Wolę powiedzieć wprost, że pracujemy na próbce z modelowaniem, niż raportować liczby jak wynik pełnego pomiaru.

Nie naprawią też błędów w samym pomiarze. Konto z konwersjami zdefiniowanymi jako kliknięcie w numer telefonu na każdej podstronie po wdrożeniu tych mechanizmów zacznie po prostu dokładniej mierzyć rzecz bez znaczenia. Kolejność jest zawsze taka sama: najpierw ustalić, co jest konwersją, potem dbać o to, żeby docierała.

I ostatnia obserwacja z tego roku. Skoro plan wycofania ciasteczek zewnętrznych z Chrome został porzucony, kusi, żeby całą tę pracę odłożyć. Nie odkładałbym. Zmiany, które faktycznie zabrały nam dane, wynikają z decyzji użytkowników i z regulacji, a te nie wycofały się nigdzie. Zestaw propozycji technicznych, które miały zastąpić ciasteczka, do dziś nie stał się branżowym standardem i nie widzę podstaw, żeby na nim budować plan. Fundament, który zostaje, to zgoda uzyskana uczciwie i dane, które klient dał nam sam.