Nowa wersja Trybu uzyskiwania zgody (consent mode v2), wprowadzona na początku roku 2024 jest wynikiem dostosowania się Google do wymogów Digital Markets Act.
W zasadzie najistotniejszą zmianą w stosunku do wcześniejszej wersji jest to, że dotychczas zalecany, consent mode będzie wymagany dla wszystkich korzystających z narzędzi reklamowych Google Marketing Platform, np. Google Ads – począwszy od marca 2024 r.
Brak consent mode będzie skutkować zablokowaniem reklam spersonalizowanych (np. remarketingu), a w dalszej kolejności Google zapowiada zablokowanie również pomiaru (śledzenia konwersji).
Pozostałe zmiany można określić jako niewielką modyfikację techniczną. Nie powinny mieć zauważalnego wpływu na jakość danych.
Dla tych, którzy mieli wdrożony consent mode, dostosowanie się do wersji v2 będzie wymagało co najwyżej drobnych prac serwisowych (zob. akapit Obowiązkowy status danych) – ale też jest obowiązkowe.
O ile nie zostało to wyraźnie zaznaczone, opisane w tym artykule kwestie odnoszą się do consent mode w ogólności (w tym do jego wcześniejszej wersji).
Zanim przejdziemy do omówienia tematu, warto usystematyzować terminologię i odróżnić consent mode od consent management – pojęcia te są często z sobą mylone.
Consent management, czyli zarządzanie zgodami
Consent management to proces pozyskiwania, przechowywania i zarządzania zgodą użytkowników na gromadzenie i przetwarzanie ich danych, w ramach którego dostosowuje się sposób przetwarzania danych tak, by respektować indywidualne zgody, odmowy i sprzeciwy.
W procesie zarządzania zgodami zazwyczaj wykorzystuje się oprogramowanie SaaS, zwane platformą zarządzania zgodami (CMP, Consent Management Platform), takie jak np. stosowany na tej stronie Cookiebot. Platformy te przy wizycie na stronie generują okienko zapytania o zgodę i umożliwiają udzielenie odpowiednich zgód. Systemy te sterują też działaniem kodów śledzących (np. za pośrednictwem menedżera tagów Google Tag Manager).
Consent management to inaczej zarządzanie zgodami użytkownika.
Wprowadzenie takiego systemu jest wynikiem wymogów prawnych, których interpretacja z 2019 roku nakazała uzyskiwanie uprzedniej, wyraźniej zgody na przetwarzanie danych w pewnych celach, np. w celach marketingowych. Do momentu uzyskania zgody, nie wolno danych w tych celach przetwarzać.
Consent mode, czyli tryb uzyskiwania zgody
Consent mode to tryb uruchamiania kodów śledzących Google w taki sposób, że do kodu przekazywany jest aktualny status zgody użytkownika, dzięki czemu system (np. Google Ads) wie, w jakim zakresie może dane przetwarzać.
Consent mode to szczególny tryb uruchamiania kodu śledzącego – w ramach zarządzania zgodami.
Dzięki consent mode nie musimy blokować całkowicie przesyłania danych w sytuacji, gdy użytkownik odmówił przetwarzania danych w celach marketingowych i nie sprzeciwił się przetwarzaniu danych w celach analitycznych. W takiej sytuacji status zgody przekazany w kodzie poinformuje system, by w przypadku tego użytkownika używać funkcji analitycznych i nie używać funkcji reklamowych.
Digital Markets Act
Akt o rynkach cyfrowych to regulacja Unii Europejskiej, której celem jest uregulowanie w sposób uczciwy europejskich rynków cyfrowych przy jednoczesnym zapewnieniu ich konkurencyjności (zob. też informacje na stronie Komisji Europejskiej).
Tworzy ona specjalną kategorię podmiotów, tzw. strażników dostępu (gatekeepers), takich jak duże wyszukiwarki internetowe, platformy social media, komunikatory – którzy ze względu na swoją skalę będą musieli przestrzegać pewnych zakazów i będą mieli określone obowiązki.
Do strażników dostępu zostały zaliczone (styczeń 2024) takie podmioty jak Alphabet (m.in. Google, YouTube), Amazon, Apple, ByteDance (TikTok), Meta (m.in. Facebook, Instagram, WhatsApp), Microsoft (Bing, LinkedIn).
Za złamanie przepisów Digital Markets Act grożą dotkliwe kary – nawet do 20% rocznego przychodu.
Jednym z obowiązków nałożonych na strażników dostępu jest zapewnienie, że dane nie będą przetwarzane bez wymaganej zgody.
Obowiązkowy status zgody
By dochować obowiązku zapewnienia zbierania zgód, Google oczekuje od właściciela strony jasnej deklaracji, jaką zgodę użytkownika posiada.
Dlatego w kodzie śledzącym musimy umieścić parametry określające, jaki jest status zgody danego użytkownika.
Nie będzie więc już sytuacji, że właściciel strony nie zwrócił uwagi na zmianę przepisów, nie zbiera zgód i przesyła dane nieaktualnym kodem śledzącym, w którym status zgody jest nieokreślony, a Google bierze to za dobrą monetę.
W kodzie śledzącym przekazywane będą cztery statusy zgody na określony zakres (cel) przetwarzania danych:
- zgoda analityczna – analytics_storage
- zgoda na pomiar skuteczności reklam – ad_storage
- zgoda na wykorzystanie danych użytkownika przez Google do celów reklamowych (enhanced conversions) – ad_user_data
- zgoda na reklamę spersonalizowaną (remarketing) – ad_personalization
Dwa ostatnie parametry zostały wprowadzone w consent mode v2.
Grafika na podstawie materiałów Google
W praktyce, ta zmiana sama z siebie nie będzie miała większego wpływu na zbierane dane i ich jakość, bo użytkownicy w większości przypadków albo zgadzają się na wszystko, albo dają maksymalną odmowę.
Reklamodawcy, którzy na swoich stronach mieli zaimplementowane consent mode „v1” z wykorzystaniem platformy zarządzania zgodami – partnera Google, w zasadzie nie będą musieli dokonywać większych zmian. Platformy uaktualnią sposób zbierania zgód i przekazywania danych do Google.
W niektórych konfiguracjach konieczne może być ręczne zainicjowanie update’u czy uzupełnienie kodu.
Dlatego warto upewnić się, czy consent mode na pewno działa, np. narzędziem Analytics Debugger.
Oznaczenia statusów zgody
Za przekazanie do Google informacji o statusie zgody odpowiadają parametry tagu Google gcs i gcd.
Parametr gcs (o wartości np. G111) odpowiada za status ad_storage i analytics_storage:
| Znak | ad_storage | analytics_storage |
|---|---|---|
| G100 | Odmowa | Odmowa |
| G101 | Odmowa | Zgoda |
| G110 | Zgoda | Odmowa |
| G111 | Zgoda | Zgoda |
| G1– | Zgoda nie jest wymagana | Zgoda nie jest wymagana |
Dodatkowe zmienne wprowadzone w wersji v2 (ad_user_data i ad_personalization) definiuje parametr gcd (np. 11r1r1r1r5). Zawiera on informację jaka była wartość domyślna i jaka była po wyrażeniu odmowy lub zgody przez użytkownika (update). Zmienna ta ma następującą składnię:
13<ad storage>1<analytics_storage>P<ad_user_data>2<ad_personalization>5<X>1Cyfry separatorów mogą też mieć inną wartość (np. 1, 2, 3, 5). Może też się pojawić litera P w miejsce cyfry przed <ad_user_data>, która oznacza, że stan ad_user_data został zmapowany ze stanu ad_storage. Ich znaczenie jest z naszego punktu widzenia drugorzędne.
Ostatni parametr <X> prawdopodobnie określa wymogi dla lokalizacji użytkownika, w celu weryfikacji zgodności pozostałych stanów z tymi wymogami.
Na dziś brak oficjalnie dostępnej dokumentacji w tym zakresie.
Statusy zgody oznaczane są literami o następującym znaczeniu:
| Litera | Status domyślny | Status po update |
|---|---|---|
| l (małe L) | Brak consent mode | Brak consent mode |
| m | Brak statusu domyślnego | Odmowa |
| n | Brak statusu domyślnego | Zgoda |
| p | Odmowa | Nie było update |
| q | Odmowa | Odmowa |
| r | Odmowa | Zgoda |
| t | Zgoda | Nie było update |
| u | Zgoda | Odmowa |
| v | Zgoda | Zgoda |
Na podstawie tych wartości Google uzyskuje informację, czy został zaimplementowany consent mode i czy strona nie zakłada domyślnej zgody – co obecnie (styczeń 2024) nie jest prawidłowym ustawieniem dla żadnego z zakresów przetwarzania danych.
Można przyjąć, że w prawidłowo skonfigurowanym consent mode i przy założeniu domyślnej odmowy powinny pojawiać się wyłącznie wartości p, q i r. Pozostałe wymagają uwagi.
Jak sprawdzić, czy masz poprawnie zaimplementowany consent mode v2?
Możesz łatwo sprawdzić, czy masz wdrożony consent mode v2, korzystając z samej przeglądarki.
- Najpierw zamknij wszystkie karty (w szczególności karty z otwartą Twoją stroną).
- Następnie wyczyść dane przeglądania (w szczególności pliki cookie i inne dane witryn – w Chrome > Wyczyść dane przeglądania – opcja „od początku”). Dzięki temu Twoja następna wizyta na Twojej stronie będzie wizytą użytkownika, który jeszcze zgody wcześniej nie wyraził.
- Teraz otwórz kartę przeglądarki i wejdź w Narzędzia dla deweloperów. W Chrome znajdziesz je w menu Widok > Deweloper.
- W Narzędziach dla deweloperów wejdź na kartę Sieć (Network).
- Wejdź teraz na swoją stronę, ale nie reaguj na razie na okno CMP (nie dawaj zgody ani odmowy w banerze cookie).
- W polu filtra wpisz „gcd” i otwórz kartę Ładunek (Payload)
- Sprawdź parametry gcs i gcd dla każdego z zapytań.
- Wyraź zgodę lub odmowę w CMP Twojej strony i sprawdź teraz, jak wyglądają parametry CMP zapytań.
Będą tam zapytania do różnych usług google, np. analytics.google.com, googleads.g.doubleclick.net, google.pl/ads itd. Prawdopodobnie wszystkie będą miały taki sam gcd, ale warto sprawdzić każdy z nich.
Można przyjąć, że w prawidłowo skonfigurowanym Advanced consent mode (przy założeniu domyślnej odmowy) powinny pojawiać się wyłącznie wartości p, q i r. Pozostałe wymagają uwagi.
Przed wyrażeniem zgody każda literka w gcd powinna być „p” (w niektórych implementacjach będzie to „q”, co choć oznacza odmowę, zanim została wyrażona, w praktyce oznacza to samo). Po odmowie, literki te powinny się zmienić na „q”, a po zgodzie – na „r”. Jeśli tak masz, to znaczy że masz prawidłowo wdrożony consent mode v2.
Co jeśli widzisz inne literki?
- Literka „l” (małe „L”) oznacza, że w ogóle nie jest skonfigurowany consent mode (jeśli masz „l” tylko w dwóch ostatnich polach, to znaczy że nie masz nieaktualny consent mode).
- Literki „t”, „u”, „v” oznaczają, że w naszym consent mode została zdefiniowana domyślna zgoda, co nie jest prawidłowe na pierwszej stronie, na którą wchodzi użytkownik.
- Literki „m” i „n” oznaczają brak domyślnego stanu zgody.
W przypadku Basic consent mode, przed zgodą nie zostaną wysłane żadne zapytania do Google. Domyślny status powinien być stosowany na wszystkich stronach również w Basic consent mode, choć na dziś brak jednoznacznej informacji, czy Google uzna statusy „m” i „n” w Basic consent mode za błędne.
Jak działa consent mode dla kodów Google
Consent mode w Google działa dla kodów Google Ads, Analytics i Floodlight (Google Marketing Platform) i jest zgodny z tagiem łączącym konwersje.
Poza wyraźną informacją dla Google o statusie zgody użytkownika, consent mode wpływa na sposób zbierania i przetwarzania danych, przez co poprawia jakość i kompletność danych analitycznych oraz precyzję optymalizacji reklam.
Jeśli zgoda jest udzielona, dane zbierane przez kody są w pełni przetwarzane. Ciekawsze rzeczy dzieją się, gdy zgody nie ma.
Advanced consent mode
Kody śledzące działające w tzw. Advanced consent mode w razie braku zgody wciąż będą przesyłać pewne dane. Nie będą jednak wykorzystywane pliki cookie ani inne podobne technologie identyfikujące urządzenie, co oznacza, że nie są one przypisywane do konkretnego użytkownika.
Advanced consent mode to nowa nazwa standardowego trybu uzyskiwania zgody. Człon „advanced” został dodany dla odróżnienia od okrojonej wersji „basic”.
Google zbiera więc łączne dane o aktywności wszystkich użytkowników, którzy nie wyrazili zgody: liczbę wizyt, odsłon odwiedzanych stron, konwersje oraz generowane przychody – bez powiązania z konkretnym użytkownikiem, ale w podziale takie segmenty jak typ przeglądarki, kraj, porę dnia.
Źródło: materiały Google
Dzięki tym danym, Google uzyskuje dodatkowe informacje na temat:
- liczby użytkowników, którzy nie wyrazili zgody oraz
- łącznej aktywności użytkowników, którzy zgody nie wyrazili – w podziale na pewne segmenty.
Basic consent mode
Dla tych, którzy z różnych powodów nie chcieliby przesyłać żadnych danych do Google bez zgody użytkownika, przygotowano okrojony tryb uzyskiwania zgody – basic consent mode.
W trybie basic consent mode w razie odmowy użytkownika Google nie zbiera żadnych danych i żadna informacja nie jest wysyłana do Google (nawet informacja o otrzymaniu odmowy).
Basic consent mode polega po prostu na tym, że tag Google nie jest uruchamiany do czasu wyrażenia zgody. Nie ma tu żadnych dodatkowych parametrów.
Modelowanie danych w consent mode
Spójrz na ilustrację poniżej – bez consent mode, kampanie A i B raportują tę samą skuteczność – na podstawie danych użytkowników, którzy wyrazili zgodę na śledzenie.
Źródło: materiały Google
Faktyczna skuteczność kampanii jest inna, chociażby dlatego, że w kampaniach tych może być inny procent odmów.
Modelowanie w advanced consent mode
Użytkownicy, którzy nie dali zgody, najczęściej konwertują gorzej. W advanced consent mode Google nie musi tego zgadywać, bo łączna liczba konwersji „bez zgody” jest znana. Trzeba tylko oszacować, jaka część tych konwersji pochodzi z danego źródła, co jest tym łatwiejsze, że łączna liczba wizyt „bez zgody” per źródło też jest znana.
Posiadając te informacje, Google może szacować faktyczne konwersje w poszczególnych kampaniach:
Modelowanie konwersji w advanced consent mode. Źródło: materiały Google
Zbierane dodatkowe dane o użytkownikach, którzy nie wyrazili zgody – takie jak kraj, przeglądarka itd. pozwalają Google zwiększyć precyzję oszacowań zachowań użytkowników, którzy zgody nie wyrazili – przez analogię do podobnych użytkowników, o których dane są zbierane.
To wszystko wyliczane jest na podstawie w pełni anonimowych danych, bez śledzenia użytkownika.
Modelowanie w basic consent mode
W trybie basic Google porówna liczbę wszystkich kliknięć reklamy z liczbą wizyt z reklamy dla użytkowników, którzy dali zgodę. Różnica będzie przybliżoną liczbą użytkowników bez zgody.
Dzięki temu Google będzie w stanie szacować, choć znacznie mniej precyzyjnie, liczbę konwersji osób, które zgody nie dały i odnośnie których nie została zebrana żadna informacja (zob. ilustracja poniżej).
Modelowanie konwersji w basic consent mode. Źródło: materiały Google
W trybie uzyskiwania zgody basic modelowanie dotyczy tylko konwersji raportowanych w Google Ads (w Analytics nie ma czego modelować, bo nawet procent odmów nie jest znany).
Inne dane modelowane
Systemy reklamowe, w tym Google Ads i Facebooka, a także Google Analytics w domyślnej konfiguracji już od dłuższego czasu wykorzystują dane modelowane, gdyż to, co możemy zmierzyć systemami śledzącymi wykorzystującymi wyłącznie pliki cookie, już od dawna nie oddaje pełnego obrazu ścieżki użytkownika.
Dlaczego śledzenie jest coraz mniej skuteczne?
- Regulacje prawne wymuszają na właścicielach stron i aplikacji zbieranie zgód przed uruchomieniem śledzenia, a na platformach korzystających z tych danych (Google, Meta, Microsoft itd.) – egzekwowanie tego obowiązku od tychże właścicieli stron i aplikacji.
- Ścieżki konwersji są coraz dłuższe, a użytkownicy korzystają z coraz większej liczby urządzeń, aplikacji i przeglądarek (cross-device, x-device).
- Technologie, na czele z ITP (Apple) czy ETP (Firefox), wychodząc naprzeciw rosnącym oczekiwaniom użytkowników w zakresie prywatności i w trosce o bezpieczeństwo własnych danych – ograniczają pliki cookie i ich czas trwania. Wraz z pełną implementacją Privacy Sandbox w Chrome roku 2024 pliki cookie 3rd party zostaną praktycznie całkowicie wyeliminowane, parametry „wstrzykujące” identyfikatory kliknięcia do plików 1st party będą coraz częściej ucinane, a przenoszące je pliki – kasowane.
Brakujące dane trzeba uzupełniać wykorzystując modelowanie matematyczne, dokonując ekstrapolacji tych wartości, które śledzić możemy. Są to wartości szacowane, ale z pewnością bliższe prawdy niż gdybyśmy zupełnie zignorowali luki w danych.
Dzięki modelowaniu konwersji uzyskujemy przybliżony, ale bardziej odpowiadający rzeczywistości obraz skuteczności kampanii.
Opisane wyżej modelowanie w consent mode uzupełnia luki wynikające z odmów użytkowników.
Natomiast niezależnie od tego, Google modeluje dane o konwersjach uzupełniając je o przybliżone dane cross-device i uzupełnia luki będące skutkiem z blokowania cookie przez technologię, jak w poniższej tabeli.
Na podstawie materiałów Google
Google Ads przypisuje konwersjom modelowanym wartość równą domyślnej wartości konwersji z ustawień konwersji. Warto sprawdzić, czy jest ustawiona poprawnie. Zob. też ten post na LinkedIn.
Czy Advanced consent mode jest zgodne z prawem?
Advanced consent mode to w zasadzie to samo, co znany od kilku lat „zwykły” consent mode. Dwa dodatkowe statusy zgody nie wprowadzają tu w zasadzie nic nowego.
Przy braku zgody, Advanced consent mode i tak uruchamia skrypt i przesyła pewne dane do Google. Zakres ich przetwarzania zależy od zakresu odmowy. Na podstawie tych szczątkowych danych Google będzie modelować zachowanie się użytkowników, którzy zgody nie wyrazili.
Artykuł ten nie jest opinią prawną i jego celem jest wyłącznie naświetlenie istoty zagadnienia. W każdym indywidualnym przypadku należy zasięgnąć porady prawnika lub osoby z odpowiednimi kwalifikacjami.
Czy można tak bez zgody?
Przepisy w tym zakresie to ePrivacy (via Prawo telekomunikacyjne) oraz RODO, które odnoszą się do przetwarzania danych osobowych, identyfikatorów użytkownika i innych informacji zapisanych na urządzeniu lub w aplikacji: plików cookie, adreów IP, numerów seryjnych.
Bez zgody można przetwarzać informacje niezbędne do funkcjonowania strony, zapewniające bezpieczeństwo strony i świadczonych przez nią usług.
Jeśli projekt ePrivacy w obecnym kształcie (styczeń 2024) wejdzie w życie, to zgoda na (własną) analitykę także nie będzie potrzebna.
Jakie dane przetwarza Advanced consent mode?
W razie braku zgody w Advanced consent mode:
- Nie są instalowane pliki cookie ani podobne identyfikatory w pamięci przeglądarki;
- Można zablokować przekazanie informacji o gclid do Google Ads przez ads_data_redaction = true;
- Zbierane są zagregowane informacje o przeglądarce, kraju, godzinie – ale nie jest tworzony fingerprint;
- Adres IP jest usuwany po określeniu kraju (można to też zrobić samodzielnie przez server-side i wysłać do Google sam kraj);
- Jeśli ustawimy url_passthrough = true, do adresów URL wewnątrz witryny (przy przejściach za strony docelowej na dalsze strony w witrynie) będzie doklejany dodatkowy parametr, który bez zapisywania informacji na urządzeniu (np. w cookie) pozwoli połączyć ze sobą kolejne odsłony w ramach sesji.
Aktywność użytkowników, którzy nie wyrazili zgody trafia „do jednego worka”, posegmentowanego na bardzo generalne kategorie.
Czy nie ma tu żadnych wątpliwości?
Consent mode został stworzony po to, by umożliwić pomiary i działania marketingowe chroniąc prywatność użytkownika i zminimalizować zniekształcenie danych wynikające z konieczności respektowania odmów użytkownika.
Najnowsze zmiany zostały wprowadzone, by dostosować systemy Google do Digital Markets Act i zmniejszyć ryzyko kar po stronie Google w konsekwencji przetwarzania danych bez wymaganej zgody. Może to być przesłanką do uznania, że dla firm korzystających z tych technologii ryzyko prawne też jest przynajmniej do pewnego stopnia ograniczone.
Niemniej faktem jest, że w advanced consent mode bez zgody użytkownika przesyłamy na serwery Google informacje, co zawsze może budzić pewne obawy.
Adres IP
Adres IP jest identyfikatorem, który może zidentyfikować użytkownika, urządzenie lub abonenta sieci. Google deklaruje, że w consent mode adres IP jest używany do określenia lokalizacji, a następnie jest niszczony. Nie zmienia to faktu, że dochodzi do wysłania adresu IP.
Istnieje możliwość przetworzenia IP na własnym serwerze (server-side) i wysłania do Google samej lokalizacji. Ale nawet jeśli to będzie serwer hostowany in-house i Google otrzyma tylko lokalizację, to i tak ma tu miejsce przetwarzanie adresu IP w celu, który nie jest niezbędny. Strona może przecież działać bez analityki.
Inna sprawa, że obecnie regulatorzy coraz częściej uznają analitykę za prawnie uzasadniony cel i do pewnego stopnia za niezbędną do administrowania stroną, w podobnym kierunku idą też planowane zmiany w ePrivacy. Warto też zauważyć, że równolegle IP będzie tak czy tak przez nas przetwarzane w celu wyświetlenia strony.
Identyfikatory kliknięć
Adresy URL mogą zawierać identyfikatory takie jak gclid czy fbclid i ich przetwarzanie bez zgody może być problematyczne.
Możliwa jest jednak taka konfiguracja consent mode, w której idenyfikatory te nie są przetwarzane (wspomniany wcześniej parametr ads_data_redaction). To jednak nie zablokuje przetwarzania identyfikatorów spoza Google (np. fbclid czy identyfikatory 1st party, jak np. parametry kliknięć marketing automation). Takie dane trzeba blokować samodzielnie.
User ID
Consent mode nie wpływa również na blokowanie funkcji User ID (dane 1st party). Oznacza to, że dane związane User ID w Analytics będą zbierane, jeśli strona przekaże w parametrze tagu.
Dla użytkowników, którzy nie wyrażają zgody na przetwarzanie danych w celach analitycznych, należałoby zablokować przekazywanie tych parametrów do tagu śledzącego, np. przez stworzenie dodatkowych warunków (stan zgody) w GTM na przekazywanie tej wartości z warstwy danych do tagu.
Fingerprinting
Poza lokalizacją, Google zbiera informacje o odwiedzanych stronach i zdarzeniach konwersji, a także o parametrach przeglądarki.
Precyzyjne dane o urządzeniu, zwłaszcza dla małej miejscowości, mogą tworzyć tzw. fingerprint. Określona kombinacja parametrów w danej lokalizacji może być na tyle unikalna, że de facto stanie się identyfikatorem niemalże tak precyzyjnym, jak cookie.
Im więcej takich parametrów się zbiera, w tym większej grupie użytkowników i w szerszym obszarze geograficznym mogą one potencjalnie stanowić unikalny identyfikator.
Google deklaruje, że w ramach consent mode identyfikator fingerprint nie jest tworzony, a lokalizacja wykorzystywana jest do celów modelowania wyłącznie na poziomie kraju (zob. artykuł pomocy Google), zastrzegając, że przetwarzanie IP dla celów gromadzenia danych w Analytics (których administratorem jest właściciel strony) odbywa się według standardowych zasad.
Jakie dane zbiera Analytics?
Oto jakie dane można było zobaczyć w grudniu 2023 roku w danych w BigQuery dla Analytics z consent mode dla użytkowników, którzy nie wyrazili zgody:
- Najmniejsze miejscowości mają po kilka tysięcy mieszkańców
- Choć gclid w większości przypadków był zastępowany wbraid, to zdarzały się przypadki, że gclid się przemycał czy to jako parametr czy też w zapisanym adresie URL.
- Identyfikatory spoza Google, jak fbclid czy mscclkid nie są usuwane z adresu URL.
Niewykluczone, że w przypadku niewielkiej części użytkowników takie zbierane dane mogłyby utworzyć fingerprint.
Ponadto, przetwarzanie identyfikatorów bez zgody może rodzić pytania na gruncie prawnym. Identyfikator wbraid, jak deklaruje Google nie identyfikuje (konkretnego kliknięcia) użytkownika i odpowiada standardom prywatności Apple (trzeba przyznać, naprawdę wysokim) – ale to niekoniecznie jest tożsame z regulacjami prawnymi.
Nie można jednak utożsamiać danych zbieranych w Google Analytics z danymi przetwarzanymi przez Google w ramach consent mode do celów reklamowych – są to oddzielne systemy.
W przypadku danych w Analytics, administratorem danych jest właściciel strony, a Google przetwarza te dane jako procesor w ramach powierzenia przetwarzania.
Google deklaruje, że do modelowania konwersji w ramach consent mode do celów pomiaru skuteczności reklam wykorzystywane są wyłącznie zagregowane dane, które nie umożliwiają identyfikacji użytkownika.
Źródło: Google
Warto zauważyć, że modelowanie consent mode działa dopiero po przekroczeniu pewnego progu użytkowników, co zmniejsza szansę, że wykorzystanie tych informacji może de facto oznaczać śledzenie pojedynczego użytkownika lub niewielkiej grupy.
Wydaje się więc, że raczej można wierzyć Google w intencje zachowania reguł prywatności w consent mode, ale więksi gracze być może powinni rozważyć uszczelnienie tego systemu poprzez server-side tracking, który pozwala na swobodne redagowanie danych przed wysłaniem ich do Google.
Zob. też artykuł pomocy Google na temat consent mode.
Czy consent mode szanuje prywatność?
Istotą ochrony prywatności jest ochrona przed niekontrolowanym zbieraniem informacji w odniesieniu do indywidualnego użytkownika. Tak długo, jak nie są stosowane identyfikatory lub fingerprint (kraj i przeglądarka to naprawdę żadne informacje identyfikujące), trudno mówić o realnych zagrożeniach prywatności, bo zidentyfikowanie w ten sposób konkretnego użytkownika i uzyskanie na jego temat jakichkolwiek istotnych informacji jest praktycznie niemożliwe.
Wyobraźmy sobie tłum idący ulicą miasta. Śledzenie to przyklejanie każdej z tych osób kartki z numerem (cookie), legitymowanie (device ID) lub robienie zdjęć (fingerprint) i ewidencjonowanie tego wszystkiego. Robienie tego bez zgody to deptanie prywatności.
To, co robi consent mode, można porównać do liczenia osób idących poszczególnymi ulicami w podziale na płeć, kolor włosów i oczu.
Dla tych, którzy jednak widzą w tym problem (prawny lub etyczny), jest basic consent mode, który po prostu zablokuje skrypt w razie braku zgody.
Oznacza to, że bez zgody użytkownika na serwery Google nie są przesyłane żadne dane. Tak więc o użytkownikach, którzy zgody nie wyrazili, Google nie wie nic. Może co najwyżej porównać liczbę kliknięć wszystkich użytkowników i wizyt na stronie docelowej tych, którzy wyraziki zgodę. Modelowanie danych na tej podstawie jest więc szczątkowe.
*) Ilustracja na bazie materiałów Google. Dane modelowane są przybliżonymi oszacowaniami. Google deklaruje, że stara się odzyskać jak najwięcej danych stosując zabezpieczenia, które przeciwdziałają nadmiernie optymistycznym oszacowaniom.
Czy trzeba wdrażać consent mode?
Consent mode pozwala na zminimalizowanie zniekształceń danych wynikających z konieczności uzyskiwania zgody użytkownika na śledzenie. Jego zastosowanie powinno poprawić jakość danych analitycznych i precyzję optymalizacji konwersji w Google Ads.
Co więcej, firmy które korzystają z Google Ads nie mają wyboru: Google wymaga, aby kody śledzące działały w consent mode i w przeciwnym wypadku począwszy od marca 2024 r. grozi zablokowaniem remarketingu i śledzenia konwersji, bez którego w zasadzie nie ma mowy o optymalizacji efektywności kampanii innej, niż maksymalizacja liczby kliknięć lub widoczności reklam.
Konieczność ochrony prywatności użytkowników i uzyskiwania zgody na przetwarzanie danych stała się standardem w usługach cyfrowych i wydaje się, że w tym zakresie nie ma odwrotu.
Wdrażanie consent managementu i rozwiązań takich, jak consent mode jest koniecznością, zwłaszcza jeśli chce się prowadzić efektywne działania marketingowe i móc je optymalizować.
Jeśli potrzebujesz wsparcia we wdrażaniu zarządzania zgodami i consent mode, skontaktuj się z nami.
Na czym polega wdrożenie consent mode?
Najprostszym sposobem wdrożenia zarządzania zgodami z consent mode v2 jest wykorzystanie platformy zarządzania zgodami (CMP) rekomendowanej przez Google. Instalację platformy na stronie należy przeprowadzić zgodnie z dokumentacją danej platformy.
Następnie należy zintegrować CMP z Menedżerem tagów Google, w którym umieszczone będą wszystkie tagi śledzące. Integrację CMP z Managerem tagów umożliwi szablon dostępny w Galerii szablonów społeczności Menedżera tagów Google odpowiedni dla danej platformy zarządzania zgodami.
W ustawieniach poszczególnych tagów należy następnie dodać odpowiednie ustawienia zgody.
W przypadku tagów, dla których dostępny jest consent mode (tagi Google), należy wybrać ustawienie „Brak wymogu dodatkowej zgody”, a w przypadku pozostałych tagów – „Wymagaj dodatkowej zgody na uruchomienie tagu”, wymieniając zgody, które są niezbędne do uruchomienia danego tagu.
Aby zastosować basic consent mode, opcję „Wymagaj dodatkowej zgody na uruchomienie tagu” należy wybrać również dla tagów obsługujących consent mode.
Użycie platformy zarządzania zgodami nie jest obowiązkowe. Generalne zasady konfiguracji przybliży ten film od Google:
Jaka jest przyszłość zarządzania zgodami?
Komisja Europejska zauważa, że aktualne przepisy w tym zakresie doprowadziły do zalewu próśb o zgodę „na cookie”, którymi użytkownicy są zmęczeni i które często akceptują bez zrozumienia.
Z drugiej strony, utrudnia to stosowanie uprawnionych technologii, które nie naruszają prywatności i powoduje wysokie koszty po stronie właścicieli stron.
Dlatego obecny (styczeń 2024) kształt projektu regulacji ePrivacy postuluje centralne zbieranie zgody przez przeglądarkę.
Nie oznacza to jednak, że zarządzanie zgodami i consent mode stracą rację bytu – wręcz przeciwnie.
Planowane w projekcie ePrivacy zwolnienie własnej analityki (1st party) z obowiązku uzyskania zgody spowoduje, że tym bardziej korzystne będzie sterowanie poszczególnymi funkcjami kodów śledzących tak, by odmowa udzielenia zgody nie ograniczała danych analitycznych, które bez zgody możemy zbierać.
Być może zmieni się sposób zbierania zgody i ograniczy się konieczność wykorzystywania rozbudowanych systemów zarządzania zgodami.
Dlatego w przyszłości możemy spodziewać się pewnych uproszczeń zarządzania zgodami i modyfikacji działania consent mode, ale rozwiązania te najprawdopodobniej pozostaną z nami na dobre.
A co z pikselem Meta i tagiem Microsoft?
Pozostałe firmy technologiczne również wdrażają podobne rozwiązania. Niewykluczone, że wkrótce również one będą wymagać bezwzględnie przekazywania statusu zgody przy każdym wywołaniu tagów, choć na dziś (styczeń 2024) nie jest to wymagane.
Wygląda na to, że określenie „consent mode” choć zostało stworzone przez Google dla swojej technologii, będzie używane również w odniesieniu do innych rozwiązań.
Facebook consent mode
Piksel Meta (Facebook) również posiada swój tryb przekazywania statusu zgody (zob. artykuł pomocy Meta). Obecnie (styczeń 2024) działa on w sposób podstawowy – w razie braku zgody żadne dane nie są przesyłanie na serwery Meta.
Microsoft UET consent mode
Również kod śledzący Microsoft można skonfigurować w consent mode. Zob. artykuł pomocy Microsoft Advertising.
Warto przeczytać
Artykuł Simo Ahavy o consent mode v2 – jest w nim więcej szczegółów technicznych i implementacyjnych.
