Google Consent Mode – czyli jak poradzić sobie z utratą danych z powodu ciastek

fot. depositphotos.com

Czym jest Google Consent Mode?

W zarządzaniu plikami cookies pomóc nam może Consent Management Platform (w skrócie CMP).  Gdy już skonfigurujemy wybrane przez nas CMP, a skrypt zostanie umieszczony w kodzie strony internetowej (lub za pomocą Google Tag Managera), to kolejnym naturalnym krokiem jest zintegrowanie jej działania ze skryptami analitycznymi (tzw. tagami). Tutaj bardzo pomocnym okazuje się Google Consent Mode.

Google Consent Mode polega na przekazaniu informacji o statusie zgód użytkowników z systemu zarządzania cookies do Google Tag Managera (w skrócie GTM). Ta informacja rzutuje na to, czy dla danego użytkownika aktywowane zostaną między innymi skrypty analityczne i remarketingowe oraz na działanie i uczenie się algorytmów uczenia maszynowego zaimplementowanych w GA4.

Dbanie o poprawność działania tego mechanizmu jest niezwykle istotna, ponieważ wpływa na ilość i jakość danych, które są przekazywane do narzędzi analitycznych takich jak Google Analytics lub Google Ads. Temat jest wielowątkowy i obejmuje parę narzędzi, natomiast finalnie otrzymamy spójną ścieżkę, która określi nam, w jaki sposób przekazywane są informacje o użytkowniku.

Modelowanie behawioralne i modelowanie konwersji

Google Consent Mode zawiera też przydatne funkcje w kontekście samego Google Analytics 4 (w skrócie GA4). Są nimi modelowanie konwersji oraz modelowanie behawioralne, które działają w taki sposób, że gdy użytkownicy odmawiają zgody na cookies, to do serwerów Google wysyłane zostają sygnały (tak zwane pingi), które przekazują zanonimizowane informacje o użytkowniku, jego aktywnościach lub o tym, że dokonana została konwersja, natomiast te zdarzenia nie są wtedy łączone bezpośrednio z żadnymi użytkownikami. Następnie dane te służą do trenowania modeli uczenia maszynowego, których predykcje zapełniają luki w gromadzeniu danych spowodowane brakiem wyrażenia zgody na cookies przez użytkowników.

Łącze symetryczne czy asymetryczne? Kto odczuje różnicę?

W przypadku modelowania behawioralnego predykcja dotyczy między innymi liczby sesji, liczby aktywnych użytkowników, źródeł ich pochodzenia oraz ich zachowań użytkownika na stronie. Natomiast w przypadku modelowania konwersji, predykcji podlega liczba konwersji oraz jej atrybucja i inne zmienne, które są z nią powiązane.

Warto tutaj zaznaczyć, że abyśmy mogli zobaczyć dane będące wynikiem modelowania behawioralnego dla naszej usługi GA4, to muszą zostać spełnione pewne warunki:

• Co najmniej 1000 eventów w GA4 dziennie powinno zostać zablokowane ze względu na brak zgody użytkownika na analityczne cookies przez minimum 7 dni z rzędu.
• Powinniśmy mieć co najmniej 1000 użytkowników dziennie, którzy zaakceptowali analityczne cookies przez co najmniej 7 z poprzednich 28 dni*.
• Tryb Consent Mode powinien zostać wdrożony na naszej domenie.

* Google dodaje, że okres, o którym mowa w drugim warunku, może ulec wydłużeniu.

Wymogi te wynikają z faktu, że aby predykcja dokonywana przez modele machine learningowe była wiarygodna, potrzebna jest odpowiednio duża próbka danych statystycznych, która posłuży do ich wyuczenia. Dodatkowo, systemy Google testują jakość uzyskanych modeli, sprawdzając ich działanie na danych pochodzących od użytkowników, którzy wyrazili zgody na ciastka. Wyniki zwracane przez model dla tych danych mogą zostać porównane z realnymi danymi zebranymi przez GA4 – przykładowo szacowana liczba konwersji określona przez model dla grupy realnych użytkowników może zostać porównana z realną liczbą konwersji wśród tych samych użytkowników. W ten sposób Google upewnia się, że wartości, które zostają zwrócone przez modele behawioralne oraz modele konwersji, nie są przeszacowane lub niedoszacowane.

Aby sprawdzić, czy modelowanie behawioralne jest włączone na naszej usłudze GA4, należy wejść w panel Admin, a następnie w Reporting Identity. Ta funkcja jest dostępna tylko, gdy wybierzemy opcję „Blended”. W momencie pisania tego artykułu jest ona wciąż w fazie beta, więc w wielu przypadkach może być jeszcze niedostępna, mimo spełniania powyższych warunków.

Aktywacja Consent Overview

Wracając do GTM-a, istotnym elementem konfiguracji Google Consent Mode jest aktywacja Consent Overview, który pozwala określić, jakie typy zgód są wymagane dla każdego tagu znajdującego się w naszym GTM-ie.

Aby włączyć Consent Overview, należy wejść w zakładkę Admin -> Container Settings -> Enable consent overview.

Kiedy Consent Overview zostanie już włączony, to w zakładce Tags będziemy mogli zobaczyć charakterystyczną ikonę tarczy.

Po jej kliknięciu zostaniemy przeniesieni do konfiguracji Consent Overview, ale zanim do niej przejdziemy, to powinniśmy zrozumieć pojęcie Consent State. 

Czym jest Consent State?

Consent state to struktura danych, która przechowuje dane o statusie zgód cookies udzielonych przez użytkownika. W przypadku, gdy korzystamy z CMP, który zawiera integrację z GTM-em, mamy możliwość bezpośredniego przekazywania do niego informacji o tych zgodach. Mówimy tu o zgodach, które zostały określone za pomocą banera cookies – są one przekazywane w Consent State po tym, gdy użytkownik określi swoją decyzje dotyczącą ciastek (lub ją zmodyfikuje).

Sama struktura danych prezentuje się w następujący sposób:

Słowo „storage”, które występuje w nazwie każdego z powyższych typów zgód, odnosi się do pozwolenia na przechowywanie danych konkretnego typu, natomiast w praktyce można rozumieć to jako kategorie cookies wraz z informacją o tym, czy użytkownik wyraził na nią zgodę („granted” w kolumnie Status oznacza przyznanie zgody).

• Ad _storage odnosi się do cookies marketingowych,
• analytics_storage – do cookies analitycznych,
• functionality_storage – do cookies wspierających funkcjonalność strony internetowej/aplikacji,
• personalization_storage – do cookies związanych z personalizacją (np. systemy rekomendacyjne),
• security_storage – do cookies odpowiadających za przechowywanie danych związanych z bezpieczeństwem (np. funkcje uwierzytelniania). 

Działanie Consent State możemy sprawdzić, korzystając z Preview Mode w GTM-ie – mamy tam dedykowaną zakładkę Consent, gdzie z poziomu każdego eventu (lub każdej otwartej przez nas strony) możemy sprawdzić aktualny stan zgód użytkownika.

Zobacz obraz w pełnym rozmiarze

Skoro jesteśmy już przy Preview Mode, to w kontekście integracji GTM-a z CMP warto wspomnieć o eventach związanych ze zgodami cookies, które pojawiają się w GTM-ie w momencie, gdy nasz CMP jest z nim kompatybilny.

Za każdym razem, gdy użytkownik określi zgody na cookies, GTM wysyła event „consent” albo „consent_update” (te nazwy mogą się lekko różnić w zależności od CMP) i w momencie pojawienia się tego eventu aktualizowany jest Consent State. Często GTM wysyła również eventy, których nazwy odnoszą się bezpośrednio do kategorii cookies, na które zgodził się użytkownik, co daje dodatkowe możliwości przy konfigurowaniu triggerów naszych tagów w GTM-ie.

Kiedy już wiemy, czym jest Consent State, możemy powrócić do konfiguracji Consent Overview.

Konfiguracja tagów w Consent Overview

Po kliknięciu w ikonę tarczy zostajemy przeniesieni do Consent Overview:

Zawiera ono 2 sekcje:

• Consent Not Configured, w którym znajdziemy tagi, które nie zostały skonfigurowane pod kątem consent mode,
• Consent Configured, w którym znajdują się skonfigurowane tagi.

• 

Możemy zaobserwować, że niektóre tagi mają Built-In Consent z przypisanymi typami consentu. Oznacza to, że zostaną one aktywowane tylko, gdy użytkownik wyrazi zgodę na odpowiednie kategorie cookies – wtedy typy consentu występujące w Built-In Consent dla danego tagu będą miały status „Granted”.

Built-In Consent dotyczy wyłącznie tagów takich jak tagi Google Analytics, Google Ads oraz Floodlight. 

W przypadku tagów Google Analytics sprawdzany jest status dla ad_storage oraz analytics_storage, ponieważ te tagi wymagają akceptacji użytkownika na marketingowe i analityczne pliki cookies. Dla porównania, w przypadku tagów Google Ads automatycznie sprawdzane jest tylko ad_storage bo wymagana jest wyłącznie zgoda na marketingowe ciastka.

Dla tagów, które nie mają określonego Built-In Consent, musimy skonfigurować go ręcznie. Najpierw wybieramy tagi, które nas interesują i klikamy w ikonkę tarczy.

Następnie otwiera nam się okno konfiguracyjne.

Mamy tutaj trzy możliwości:

• Not set, które jest ustawieniem domyślnym i wskazuje na to, że tag nie jest jeszcze skonfigurowany – tagi, które posiadają to ustawienie, pozostaną w sekcji Consent Not Configured w Consent Overview.
• No additional consent required, które wskazuje na to, że tag nie wymaga dodatkowej konfiguracji – to ustawienie warto zastosować w przypadku tagów z Built-In Consent.
• Require additional Consent for tag to fire, które pozwala na dodanie warunków dla consentu na aktywację tagu.

Po określeniu warunków dla Additional Consent, skonfigurowane tagi zostają przeniesione do sekcji Consent Configured.

Additional consent można określić też przy tworzeniu tagów w sekcji More Settings.

Konfiguracja triggerów 

Dla tagów posiadających Built-In Consent nie musimy w żaden sposób modyfikować triggerów. Przykładowo dla tagu konfiguracyjnego GA4 możemy ustawić trigger na aktywację tagu na wszystkich podstronach domeny (trigger All Pages) bez potrzeby tworzenia dodatkowych warunków na akceptację analitycznych i marketingowych plików cookies przez użytkownika. Spełnienie tego warunku jest sprawdzane automatycznie przez GTM-a, a następnie aktywowany jest tag.

W przypadku tagów posiadających Built-In Consent ważne jest, że nawet jeśli użytkownik początkowo nie zgodzi się na cookies analityczne i marketingowe, ale po jakimś czasie zmieni zdanie, to zmiana zgody zostanie wykryta i tag się odpali.

Natomiast, ten mechanizm nie zadziała w taki sam sposób dla tagów, które mają skonfigurowany Additional Consent, ale nie posiadają Built-In Consent. Przykładem takiego tagu jest Meta Pixel (wcześniej nazywany Facebook Pixelem) posiadający trigger All Pages. Jeśli użytkownik najpierw odrzuci marketingowe pliki cookies (co blokuje aktywację tagu), ale po jakimś czasie zmieni zdanie, otworzy ponownie baner cookies i je zaakceptuje, to taki tag nie odpali się ponownie. Sprawi to, że stracimy możliwość zebrania danych, mimo że w consent state będziemy mogli zobaczyć, że zgoda została przyznana. W takim przypadku należy stworzyć nowy trigger, który uruchamia się w momencie, gdy pojawi się event typu „consent update” (nazwa eventu może się trochę różnić w zależności od CMP). Event ten jest wysyłany przez CMP za każdym razem, gdy użytkownik wyrazi zgodę na cookies lub ją zmodyfikuje, więc nie wystąpi tutaj utrata danych analitycznych dla użytkownika, który zmienił zdanie odnośnie zgód.

Warto omówić przypadek tagu, który ma aktywować się, gdy użytkownik wchodzi bezpośrednio na konkretny landing page, listę lub stronę produktową i, będąc na którejś z nich, zobaczy baner i będzie musiał podjąć decyzję o ciastkach.

Poniżej przykład tagu Meta Pixel, który aktywuje się przy wejściu na stronę produktu. W tym przypadku ważne jest, aby zmodyfikować trigger, w taki sposób, aby tag odpalił się, gdy spełniony jest warunek wejścia na stronę produktową (na obrazku poniżej nazywa się productDetail) oraz gdy podjęta została decyzja odnośnie zgód na cookies (Consent Update). Stosujemy Trigger Group, który sprawia, że tag uruchamia się dopiero, gdy oba te warunki są spełnione. Gdybyśmy zostawili tutaj sam trigger productDetail, a nasz użytkownik wszedłby bezpośrednio na stronę produktową, to trigger zostałby aktywowany zanim użytkownik podjąłby decyzję odnośnie cookies, a tag zostałby automatycznie zablokowany ze względu na brak odpowiednich zgód w momencie aktywacji triggera. 

Podsumowanie

Finalnie cała ścieżka informacji o zgodach, którą wspiera Google Consent Mode, wygląda następująco:

1.  Użytkownik wyraża zgody na określone kategorie ciastek za pomocą banera cookies, który jest połączony z CMP (który został wcześniej skonfigurowany).
2. CMP tworzy własne cookie, w którym zawarte są informacje o kategoriach ciastek, na które wyrażona została zgoda.
3. Przy integracji CMP z GTM-em, w momencie wyrażenia (lub zmiany zgód) w GTM-ie pojawi się event typu „consent update” i jednocześnie informacje o zgodach dotyczących konkretnych kategorii ciastek przekazywane są do Consent State w GTM-ie.
4. Przed odpaleniem każdego taga, GTM sprawdza określone dla niego Built-In Consent oraz Additional Consent. Następnie sprawdzane jest, czy Consent State przypisany do użytkownika zawiera zgody potrzebne do odpalenia tego tagu – jeśli Consent State zawiera odpowiednie zgody, to tag zostaje aktywowany. Natomiast gdy odwiedzający odmawiają zgody to, tagi są blokowane, ale wysyłają sygnały (tak zwane pingi) do serwerów Google i na podstawie tych sygnałów trenowane są modele konwersji oraz behawioralne, które uzupełniają luki w danych w GA4.

Google Consent Mode może wydawać się zagadnieniem wielowątkowym i często nieoczywistym, ale korzyści jaki nam oferuje, sprawiają, że nie powinniśmy być wobec niego obojętni. Zrozumienie tej funkcjonalności pozwoli nam stworzyć sprawny system aktywacji tagów analitycznych w GTM-ie, ułatwi nam ich konfigurację oraz odkryje przed nami potencjał płynący z modeli uczenia maszynowego zaimplementowanego w GA4.