Dwa sygnały, którymi steruje cały mechanizm

Techniczny rdzeń jest zaskakująco mały. Tagi Google przyjmują dwa parametry zgody: jeden dotyczy przechowywania danych na cele reklamowe, drugi na cele analityczne. Każdy z nich przyjmuje jedną z dwóch wartości — przyznana albo odmówiona.

Co robi tag przy odmowie? Nadal się uruchamia, ale nie czyta i nie zapisuje plików cookie, nie przekazuje identyfikatorów pozwalających powiązać wejście z konkretną osobą i wysyła żądanie pozbawione tych danych. Ta różnica jest sedno całego rozwiązania: zdarzenie zostaje zarejestrowane jako fakt, bez tożsamości.

Warto wiedzieć, że parametrów zgody obsługiwanych przez platformę tagów jest więcej — dotyczą one między innymi personalizacji i przechowywania danych funkcjonalnych. W praktyce dla konta Google Ads i pomiaru ruchu liczą się te dwa pierwsze i na nich koncentruję wdrożenie.

Jest jeszcze jedna decyzja projektowa do podjęcia na starcie: czy stan domyślny ustawiasz globalnie, czy dla wybranych regionów. Konfiguracja pozwala podać stan domyślny osobno dla listy krajów. Sklep sprzedający wyłącznie w Polsce może mieć jeden zestaw wartości, serwis międzynarodowy — inny dla obszaru objętego europejskimi przepisami i inny dla pozostałych rynków. To ustawienie robi się raz i potem nikt do niego nie wraca, więc warto je przemyśleć.

Kolejność wykonania decyduje o wszystkim

Jeśli miałbym z tego tekstu zapamiętać jedno zdanie, brzmiałoby ono tak: stan domyślny musi zostać ustawiony wcześniej niż uruchomi się jakikolwiek tag Google.

Powód jest prozaiczny. Tag, który wystartuje przed odebraniem informacji o stanie zgody, zachowa się jak w trybie pełnym — zapisze pliki cookie i wyśle identyfikatory. Nie zobaczysz błędu w panelu, nie dostaniesz ostrzeżenia. Wszystko będzie wyglądało na skonfigurowane, a mechanizm będzie martwy.

W praktyce oznacza to twardy wymóg: skrypt narzędzia do zbierania zgód, który ustawia stan domyślny, musi znajdować się w kodzie przed wywołaniem tagu Google i musi ładować się synchronicznie. Wstawienie go na końcu sekcji nagłówka albo z atrybutem odkładającym wykonanie psuje całość.

Do tego dochodzi parametr określający, jak długo tagi mają czekać na aktualizację stanu zgody. Ustawia się go w milisekundach i chodzi w nim o obsłużenie sytuacji, w której użytkownik klika w banerze niemal natychmiast po wejściu. Zbyt krótka wartość powoduje, że część zdarzeń wysyła się w trybie ograniczonym, choć zgoda została udzielona. Zbyt długa opóźnia pomiar. Zaczynam od wartości rzędu kilkuset milisekund i dopiero na tej podstawie zawężam.

Ostatni element to aktualizacja stanu po decyzji użytkownika. Wysyła ją narzędzie do zbierania zgód i musi to zrobić bez przeładowania strony. Jeśli wdrożenie wymaga odświeżenia, żeby tagi przeszły w tryb pełny, tracisz zdarzenia z pierwszej odsłony i całą ścieżkę wejścia.

Droga przez Menedżera tagów Google

To wariant, który wybieram w większości projektów, bo pozwala trzymać logikę w jednym miejscu i nie wymaga wdrożeń po stronie działu IT przy każdej zmianie.

Kolejność pracy wygląda następująco. Najpierw sprawdzam, czy narzędzie do zbierania zgód ma gotową integrację z menedżerem tagów — większość dojrzałych rozwiązań ma szablon w galerii albo własną instrukcję. Ten element odpowiada za ustawienie stanu domyślnego i późniejszą aktualizację.

Potem korzystam z reguły uruchamiającej inicjalizację zgody. To specjalny typ reguły, który wykonuje się przed wszystkim innym w kontenerze i jest właściwym miejscem dla tagu ustawiającego stan domyślny. Wpisywanie tego w zwykłą regułę wczytania strony jest najczęstszym błędem tej konfiguracji, bo nie daje gwarancji kolejności.

Trzeci krok to ustawienia zgody na poziomie pojedynczych tagów. Tagi Google mają wbudowane sprawdzanie zgody i same wiedzą, czego potrzebują. Dla tagów firm trzecich — pikseli społecznościowych, narzędzi do nagrywania sesji, czatów — trzeba to ustawić samodzielnie, wskazując wymagane typy zgody. Przegląd zgód w menedżerze pokazuje, które tagi mają to skonfigurowane, i jest dobrym punktem kontrolnym przed publikacją.

Czwarty krok to publikacja wersji z opisem tego, co zmieniono i dlaczego. Za pół roku ktoś inny będzie się zastanawiał, po co ta reguła istnieje.

Droga przez kod strony

Wariant dla serwisów, które nie używają menedżera tagów albo mają tag wpisany bezpośrednio w szablon.

Tu wszystko sprowadza się do dwóch wywołań funkcji tagu. Pierwsze deklaruje stan domyślny wraz z czasem oczekiwania na aktualizację i opcjonalnie listą regionów. Drugie, wywoływane po decyzji użytkownika, aktualizuje stan na przyznany dla tych kategorii, na które klient się zgodził.

Trzy rzeczy, o których trzeba pamiętać przy tej drodze.

• Miejsce w kodzie — deklaracja stanu domyślnego idzie w tym samym bloku skryptu co inicjalizacja tagu, przed konfiguracją identyfikatorów pomiaru.

• Zapamiętywanie decyzji — po powrocie użytkownika na stronę trzeba odtworzyć jego wcześniejszy wybór z własnego magazynu i wysłać aktualizację od razu, zamiast pytać ponownie.

• Jedna implementacja dla całego serwisu — jeśli sklep ma osobne szablony dla koszyka i strony produktu, kod musi trafić do obu, inaczej pomiar w kluczowym momencie ścieżki zachowa się inaczej niż na resztę witryny.

Przy pomiarze po stronie serwera schemat się nie zmienia: informacja o zgodzie nadal jest ustalana w przeglądarce i nadal musi wyprzedzać wysłanie zdarzenia. Przeniesienie kontenera na własną domenę nie zwalnia z pytania o zgodę i nie jest sposobem na jej ominięcie — to wyjaśniam klientom regularnie, bo bywa sprzedawane jako obejście.

Dwa dodatkowe przełączniki, o których mało kto pamięta

Poza samym stanem zgody konfiguracja daje dwa ustawienia, które w Europie mają realne znaczenie.

Pierwsze to redakcja danych reklamowych. Włączone powoduje, że przy braku zgody na cele reklamowe żądania do serwerów reklamowych są dodatkowo pozbawiane informacji mogących służyć identyfikacji, a identyfikator kliknięcia nie jest zapisywany w plikach cookie. Traktuję to jako ustawienie domyślnie włączane w serwisach europejskich.

Drugie to przekazywanie identyfikatora kliknięcia w adresie URL. Skoro przy braku zgody nie ma plików cookie, informacja o źródle wejścia ginie przy przejściu między podstronami. Ta opcja sprawia, że identyfikator jest dopisywany do adresów w obrębie witryny, co pozwala zachować przypisanie konwersji do kampanii bez zapisywania czegokolwiek na urządzeniu.

Ta druga funkcja ma jednak skutki uboczne, o których trzeba wiedzieć zawczasu. Adresy stron zaczynają zawierać dodatkowy parametr, co w niektórych konfiguracjach potrafi zaburzyć raporty ruchu, mechanizmy pamięci podręcznej albo wewnętrzne przekierowania. Przed włączeniem sprawdzam więc, jak serwis reaguje na obce parametry w adresie, i uprzedzam osobę odpowiedzialną za pozycjonowanie.

Weryfikacja: co dokładnie sprawdzam w przeglądarce

Odbiór wdrożenia robię zawsze w oknie prywatnym, z otwartą kartą sieci w narzędziach dla programistów, i zawsze w trzech przebiegach.

Przebieg pierwszy — bez decyzji. Wchodzę na stronę i nie klikam w banerze. Filtruję żądania po adresie serwerów pomiarowych i szukam parametru opisującego stan zgody. Wartość dla obu kategorii odmówionych ma postać ciągu z jedynkami i zerami, w którym zera oznaczają brak zgody — istotne jest to, że parametr w żądaniu jest obecny. Jego brak oznacza, że mechanizm nie działa wcale. Przy okazji patrzę na zakładkę z plikami cookie: nie powinno tam być cookie reklamowych ani analitycznych.

Przebieg drugi — odmowa. Klikam odmowę i sprawdzam dwie rzeczy: czy stan w parametrze się nie zmienił i czy kolejne odsłony nadal wysyłają żądania w tym samym trybie. Zdarza się, że baner po odmowie ustawia zgodę na cele funkcjonalne w sposób, który omyłkowo obejmuje analitykę.

Przebieg trzeci — akceptacja. Klikam zgodę i sprawdzam, czy parametr zmienił wartość bez odświeżenia strony oraz czy pojawiły się właściwe pliki cookie. Dodatkowo przechodzę na kolejną podstronę i wykonuję zdarzenie konwersji testowej, żeby zobaczyć, że dochodzi ona do celu.

Na koniec zaglądam do podglądu w menedżerze tagów i do widoku zdarzeń w narzędziu analitycznym. Nie zastępuje to obserwacji żądań, ale pozwala zobaczyć, jak zgoda wygląda z drugiej strony — od tagu, nie od przeglądarki.

Kontekst prawny i usterki, które wracają najczęściej

Techniczne wdrożenie nie rozstrzyga kwestii prawnych i nie chcę zostawiać co do tego wątpliwości. W Polsce zgoda na pliki cookie wynika z prawa telekomunikacyjnego, a przetwarzanie danych osobowych z RODO. Do tego dochodzą decyzje organów w Austrii, Francji i — od czerwca — we Włoszech, które dotyczyły transferu danych do Stanów Zjednoczonych przy korzystaniu z narzędzi analitycznych. Ten temat jest otwarty i wymaga rozmowy z prawnikiem, nie z osobą od kampanii.

Z mojej strony zostaje lista usterek, które w odbiorach wdrożeń widzę najczęściej:

• Stan domyślny po tagach albo ustawiony tylko na stronie głównej — całość wygląda poprawnie i nie działa.

• Baner blokujący skrypty i równocześnie przekazujący zgodę — tagi nie uruchamiają się wcale, więc nie ma sygnału do wykorzystania.

• Jedna kategoria zgody na wszystko — bez rozdzielenia celów reklamowych i analitycznych nie da się przekazać stanów oddzielnie.

• Tagi firm trzecich pominięte — narzędzie do nagrywania sesji uruchamiające się przed zgodą jest problemem tej samej wagi co piksel reklamowy.

• Regresja po wdrożeniu na stronie — nowa wersja szablonu wypycha skrypt banera w inne miejsce i mechanizm cicho przestaje działać.

Ostatni punkt jest powodem, dla którego test w narzędziach przeglądarki wpisuję na stałą listę czynności po każdym większym wdrożeniu na witrynie klienta. Zajmuje kwadrans i oszczędza tygodnie danych, których nikt już nie odtworzy.