Pytania i odpowiedzi do webinaru Co musisz wiedzieć o Consent mode v2 na kanale ProstoDoKasy by Satisfly:
Artykuł dotyczy dynamicznie zmieniającej się technologii oraz regulacji prawnych i nie jest aktualizowany na bieżąco (ostatnia aktualizacja: 26 lutego 2024). W szczególności, kwestie prawne należy traktować poglądowo i każdorazowo weryfikować z prawnikiem lub Inspektorem Ochrony Danych.
Czy w związku z aktywacją Consent mode v2 (implementacja advanced) muszę wprowadzać jakieś poprawki w polityce prywatności? Jeśli tak, to czy można prosić o informację: jakie i w jakim zakresie?
To pytanie należy raczej zadać prawnikowi lub Inspektorowi Ochrony Danych. Niemniej, zmiany wersji v2 są bardzo drobne, więc jeśli ktoś już miał stosowany Consent mode, to moim zdaniem po przejściu z “v1” do wersji v2 nie są wymagane zmiany.
Natomiast sam Consent mode (advanced) wiąże się z przetwarzaniem pewnych ograniczonych danych do celów analitycznych (w tym do analizy skuteczności reklam) bez zgody użytkownika.
Stanowią one niewielką część danych zbieranych za zgodą, a sposób ich przetwarzania obejmuje anonimizację tych danych i ogranicza czy wręcz praktycznie uniemożliwia identyfikację użytkownika. Tak więc zakres przetwarzanych danych się nie zmienia, ale niektóre dane przetwarzane są bez zgody.
Warto też zwrócić uwagę, że dane przetwarzane w ramach Consent mode nie przekraczają danych zbieranych “normalnie” w logu serwera, co robi się w celu obserwacji działania witryny, tworzenia statystyk, identyfikacji błędów i prób naruszenia bezpieczeństwa. Czyli są to dane, które i tak zbieramy i przyjmuje się, że nie wymagają zgody. Robi to nawet UODO – zob. uodo.gov.pl/polityka-prywatnosci.
Głównym celem consent mode jest szacowanie wpływu odmów zgody na śledzenie na miarodajność statystyk uzyskanych w wyniku pomiaru zachowań użytkowników, którzy wyrazili zgodę i tworzenie ekstrapolacji tych danych, aby w sposób przybliżony, ale bliższy rzeczywistości odzwierciedlały aktywność użytkowników pochodzących z różnych źródeł i korzystających z różnych urządzeń.
Ocenę, na ile te informacje należałoby dodatkowo ująć w polityce prywatności, to pytanie dla prawnika. Ze swojej strony mogę powiedzieć, że choć dodanie informacji nigdy nie zaszkodzi, warto też zadbać, by polityka prywatności była zwięzła, czytelna i zrozumiała dla użytkownika.
Czy w polityce prywatności musimy wymienić szczegółowo wszystkie pliki cookies wraz z ich opisami czy wystarczy opisać kategorie wykorzystywanych plików?
Jest dobrą praktyką opisywanie plików. Platformy CMP zazwyczaj umożliwiają to przez automatycznie generowaną deklarację cookie, taką jak np. na końcu tej strony adequate.digital/polityka-prywatnosci – wkleja się odpowiedni kod i CMP go wygeneruje.
Najogólniej, użytkownik powinien mieć informację, w jaki sposób przetwarzane są dane i przez kogo – wg mojej wiedzy minimum to wskazanie firm, którym te dane są przekazywane. Znowu, jest to pytanie do prawnika lub Inspektora Ochrony Danych.
Warto też zauważyć, że nawet bez tej deklaracji w polityce prywatności, użytkownik może się zapoznać ze szczegółami plików cookie, wywołując ponownie widget platformy – ten sam, z którym mógł się zapoznać udzielając zgody. Deklaracja ma po prostu inną formę graficzną.
Czy jeśli na stronie nie mam żadnych cookies, to też muszę prezentować baner?
Jeśli strona nie stosuje cookies ani innych podobnych technologii (np. identyfikatorów przechowywanych w pamięci przeglądarki itd.), to nie trzeba żadnego banneru.
Tak jest na stronie bakoma.pl, która żadnych cookie nie stosuje i nie ma żadnego banneru.
Czy jeśli mam obecne zgody od dłuższego czasu wdrożone to czy jest możliwość że nie są one obecnie aktualne albo coś się „wysypało” i nie działają poprawnie?
Consent mode v2 wymaga zmian w systemie zarządzania zgodami. Są one drobne i czasem mają po prostu postać aktualizacji oprogramowania, ale są one konieczne. Więc chociażby to trzeba sprawdzić.
Natomiast co do zasady, jeśli na stronie nic się nie zmienia, to system CMP powinien działać.
W praktyce może się jednak wydarzyć wiele różnych rzeczy: ktoś może dodać nowy kod śledzący, ktoś może wpiąć nową wtyczkę do platformy, ktoś może osadzić treść na stronie i nie dokonać równolegle odpowiednich zmian w systemie zarządzania zgodami.
Co prawda niektóre CMP mają automatyczną blokadę skryptów i to w znacznej mierze uodparnia nas na takie przypadki, ale tak czy tak co jakiś czas warto sprawdzić, czy w dalszym ciągu system działa poprawnie.
Co ile ponawiać zgodę?
To pytanie także jest jednym z tych, które należy raczej skierować do prawnika lub IOD.
Zazwyczaj jest to okres z przedziału 6-12 miesięcy. Nie ma tu jednoznacznych regulacji, ale przede wszystkim nie powinno się uporczywie prosić o zgodę, ale z drugiej strony, zgoda nie powinna być na zbyt długi okres czasu, bo mogła się zmienić technologia, charakter przetwarzania itd. Przykładowo, irlandzki regulator danych osobowych uważa, że powinno to być 6 miesięcy (zarówno ważność zgody jak i czas po którym możemy ponownie prosić o zgodę).
Jeśli strona całkowicie zmieniła swój charakter, wprowadzone zostały nowe skrypty śledzące itd. – puryści pewnie uznaliby za zasadne natychmiastowe unieważnienie wszystkich zgód (bo obecne przetwarzanie danych nie jest tym, na co zgodził się użytkownik). Taką funkcję zazwyczaj udostępniają CMP. Jeśli to się zrobi, przy kolejnej wizycie każdy użytkownik zostanie ponownie zapytany o zgodę.
Czy jeśli wyłączę tag Google Analytics w GTM to wystarczy, by nie śledzić użytkowników?
Nie wiem czy dobrze zrozumiałem pytanie. Google Analytics jest tylko jednym z tagów, które mogą śledzić użytkownika.
Jak całkowicie od zera wdrożyć zgody na stronę?
Zalecaną metodą będzie skorzystanie z jednej z rekomendowanych przez Google platform CMP oraz Google Tag Managera (GTM).
Z grubsza proces wygląda następująco. Instalujemy CMP oraz umieszczamy wszystkie kody śledzące w GTM. Instalujemy tag CMP z szablonu integrującego platformę CMP z GTM, a następnie ustawiamy dla każdego z tagów śledzących odpowiednie warunki zgody (“wymagana dodatkowa zgoda”).
Dla kodów Google w Advanced consent mode wybieramy opcję “nie jest wymagana dodatkowa zgoda”, gdyż kody te wykorzystają status zgody przesłany z CMP i uruchomią się w odpowiednim trybie. Instrukcję instalacji znajdziemy w dokumentacji danej platformy CMP.
W basic consent mode, kody Google również należy w GTM uwarunkować dodatkową zgodą.
W sieci jest również wiele poradników dotyczących instalacji CMP i Consent mode.
Chciałbym podkreślić, że platformy spoza listy rekomendowanej przez Google są dopuszczalne i wiele z nich z pewnością obsługuje również Consent mode v2, natomiast trudno mi jest – bez podparcia się wiarygodną zewnętrzną weryfikacją – rekomendować rozwiązania, których działania nie znam.
Nie znaczy to, że jest to jedyny i zawsze najprostszy sposób wdrożenia zarządzania zgodami. Powyższy sposób implementacji jest moim zdaniem najbardziej uniwersalny i powinien się sprawdzić w większości przypadków.
Jak wdrożyć Consent mode v2 od Google, jeśli część danych dotyczących eCommerce (sprzedaż, dodanie do koszyka itp.) jest wysyłana przez measurement protocol? Natomiast cała reszta jak Hotjar, Google Ads itp. jest zaimplementowana przez GTM. Jakie rozwiązanie jest poprawne? Czy CMP sobie poradzi?
Generalnie, warto zadać sobie pytanie, czy na pewno ma sens, by dane eCommerce były wysyłane przez measurement protocol, w szczególności takie zdarzenia jak dodanie do koszyka. Co do zasady to, co się odbywa na stronie www, powinno być raczej raportowane ze strony, a measurement protocol należy stosować raczej do zdarzeń offline lub generalnie zachodzących poza stroną www.
Jeżeli mamy prawidłowo skonfigurowaną zgodę użytkownika to w razie odmowy zbierane dane nie będą wykorzystywały identyfikatora użytkownika, w związku z czym nie będzie możliwości, by dane wysłane do Analytics przez measurement protocol odniosły się do jakiegoś użytkownika, więc w tym sensie CMP sobie z tym “poradzi” i nie dojdzie do jakiegoś nieuprawnionego przetwarzania danych osobowych.
Niedawno wprowadzono oficjalnie możliwość przekazania statusu zgody poprzez measurement protocol: developers.google.com/protocol. Niemniej, domyślnie Google Analytics będzie korzystać z ustawień dotyczących zgody odebranych wcześniej od użytkownika powiązanego z danym identyfikatorem.
Tak więc ewentualne pobieranie statusu zgody odebranej na stronie wyłącznie w tym celu, by ponownie je wprowadzić w zdarzeniu measurement protocol nie ma sensu, bo będzie to to samo, co domyślnie (a nawet jest mała szansa że przez to będzie mniej aktualne).
Te zmienne będą miały zastosowanie są do sytuacji, w których stan zgody mógłby się zmienić między wizytą na stronie a konwersją, np. użytkownik podpisując umowę wyraził odpowiednią zgodę marketingową i chcemy ją uwzględnić w zdarzeniu konwersji measurement protocol.
W dokumentacji Google dotyczącej measurement protocol mowa jest wyłączenie o zgodzie reklamowej, ponieważ bez zgody analitycznej nie będziemy mieli możliwości użycia identyfikatora użytkownika (bo go nie będzie).
Pozostaje pytanie, co zrobić w przypadku gdy nie posiadamy zgody analitycznej. Teoretycznie możemy sami wygenerować losowy identyfikator (podobnie jak to się odbywa w Consent mode) i użyć takiego zdarzenia measurement protocol. Rzecz jasna, taka konwersja nie byłaby powiązana z żadnym użytkownikiem (Analytics nie byłby w stanie zidentyfikować jej źródła. Nie ma w tej kwestii jasnej odpowiedzi w dokumentacji, ale BYĆ MOŻE (MOŻNA SPRÓBOWAĆ) w takich przypadkach dodać parametry gcs=G100&gcd=13q3q3q3q5 dla wskazania, że są to dane bez zgody. Dzięki temu Google PRAWDOPODOBNIE mógłby jej użyć do modelowania (byłby to ping taki, jak ze strony w przypadku Consent mode). Podkreślę, że to nie jest oficjalnie wspierane rozwiązanie. Pozostaje czekać, aż Google oficjalnie się w tej kwestii wypowie.
To jeśli nie klikam nic – ani zgody, ani odmowy, to rozumiem, że dane sie nie zbierają?
Tak powinno to działać. Do czasu udzielenia zgody należy przyjąć, że zgody nie ma (zasada opt-in).
Jak zmierzyć ilość osób nie zgadzających się na cookie?
Większość platform CMP udostępnia takie statystyki.
Czy Microsoft (i np. Bing) może mieć swój Consent Mode, który różni się od Consent mode v2 od Google?
Obecnie Microsoft i Meta mają swój consent mode. Na dziś (luty 2024) działają one jednak w ten sposób, że w razie braku zgody dane nie są przesyłane, więc nie ma różnicy między uruchamianiem tych tagów po prostu wyłącznie po zgodzie bez tych parametrów.
Można więc w GTM zdefiniować te tagi w ten sposób, aby w zależności od statusu zgody również te tagi były odpowiednio uruchamiane. Na dziś to nic nie zmienia w sposobie przetwarzania .
Niewykluczone, by nie powiedzieć że prawdopodobne, że to się w przyszłości zmieni i pozostałe firmy technologiczne zastosują analogiczne rozwiązania jak Google i będą wymagać przesyłania statusu zgody przy każdym wywołaniu tagu.
Poradniki mówią, że tagi analityczne powinny być w Google Tag Managerze (a my u siebie mamy przez wtyczkę). Jakie są rozwiązania na preście w takiej sytuacji?
Wydaje się, że jeżeli wtyczka i platforma nie obsługują natywnie zarządzania zgodami i CMP lub nie działa to prawidłowo – najprostszym i uniwersalnym rozwiązaniem będzie jednak (mimo wszystko) przeniesienie kodu Analytics do Google Tag Managera.
Czy brak zgody oznacza, że i tak jakieś dane zostaną przekazane do Google? Wiemy jakie konkretnie? IP?
Google deklaruje, że IP po określeniu przybliżonej lokalizacji użytkownika jest kasowane. Google zbiera informacje o odwiedzonych stronach, konwersjach, kraju użytkownika, porze dnia, rodzaju urządzenia (smartfon, komputer) oraz typie przeglądarki. W tym artykule opisałem z grubsza, jakie dane są wykorzystywane.
Warto by pamiętać, że nie są one przetwarzane w kontekście identyfikatorów śledzących, ale grupowo dla wszystkich użytkowników, którzy zgody nie wyrazili.
Czy w Consent Mode v2 gcd zastępuje gcs? Czyli testując rozwiązanie, gcs może się nie pokazywać?
Na dziś obydwa parametry są przesyłane. Pamiętajmy, że te parametry są generowane są już przez sam tag Google na podstawie statusów zgody. Warto je znać wyłącznie po to, by móc łatwo sprawdzić, czy Consent mode działa poprawnie. Sami tych parametrów bezpośrednio nigdzie nie wstawiamy, nie robi tego też CMP.
Niewykluczone, że kiedyś Google uzna, że gcs jest zbędny, bo wszystkie potrzebne informacje są w gcd i wtedy tag Google przestanie go przesyłać, ale to będzie wyłącznie zmiana po stronie tagu Google.
Czy wiecie może czy flaga ad_personalization powinna być wysyłana przez API dla Import from Clicks lub dla Enhanced Conversions czy te usługi są tylko w zakresie flagi ad_user_data?
Nie do końca rozumiem kontekst pytania, ale być może to wyjaśnia: developers.google.com/consent.
Flaga ad_personalization jest do customer match, ad_user_data do enhanced conversions i import from clicks.
Jeśli nie wdrożymy Consent mode w ogóle, to czy GA4 zacznie domyślnie uznawać brak parametrów gcs/gcd za brak zgody? I czy w związku z tym powinniśmy się spodziewać ze GA4 przestanie zbierać dane w ogóle?
Wymóg Consent mode v2 obecnie dotyczy Google Ads i generalnie wykorzystania danych w reklamie Google. Analytics będzie zbierać dane normalnie, natomiast prawdopodobnie nie będą dostępne dla reklamy (czyli np. nie będą działać listy remarketingowe importowane z Analytics). Przynajmniej na razie Google nie zapowiada blokowania samego Analytics.
Pamiętajmy jednak, że w Analytics to my (właściciel strony) jesteśmy administratorami danych, a Google jest tylko procesorem – udostępnia program analityczny i go utrzymuje na swoich serwerach. Dlatego zbieranie wymaganej prawnie zgody (niekoniecznie w Consent mode) jest prawny obowiązkiem właściciela strony, zwłaszcza że w Analytics możemy przetwarzać spseudonimizowane dane osobowe 1st party, takie jak User ID lub ID transakcji.
Mamy sklep na Atomstore i część kodów jest wdrożonych bezpośrednio przez platformę sklepu, a część (dla których nie mieliśmy gotowych integracji) przez GTM. Czy wdrażając consent Mode 2.0 trzeba przenieść wszystkie kody do GTM, aby działało to poprawnie?
To pewnie pytanie do Atomstore, ale z tego co widzę, Atomstore oferuje natywną integrację zarówno z analytics jak i GTM i consent mode – pozostaje mieć nadzieję, że to zadziała (nie testowaliśmy).
My rekomendujemy działanie z CMP i GTM jako uniwersalne, natomiast nie jest to jedyne możliwe rozwiązanie.
W Advanced consent mode, Google uzyska bez zgody dostęp do informacji takich jak adres IP czy info o urządzeniu – co jak rozumiem też podpada pod ePrivacy. Czyli czy faktycznie tzw. „Zaawansowana Implementacja” pozwala nam zachować zgodność z ePrivacy czy właściwie jej polską implementacją? Czy raczej powinniśmy używać tzw. „Podstawowej Implementacji”?
To znowu pytanie do prawnika i IOD. W prezentacji wskazywałem na związane z tym wątpliwości i istotnie, adres IP jest tutaj co najmniej kontrowersyjny.
Google deklaruje, że IP jest usuwane po ustaleniu przybliżonej lokalizacji, co nie zmienia faktu, że jest przekazywane i odczytywane. Istnieje możliwość przetworzenia adresu IP po stronie serwera i wysłanie do Google wyłącznie informacji o lokalizacji, ale to jest również przetwarzanie IP i zachodzi również najczęściej na serwerze hostowanym przez… Google lub inną firmę hostingową. Moim zdaniem nie różni się to znacząco od przetwarzania po stronie Google Analytics, poza większą kontrolą nad danymi.
Oczywiście, implementacja podstawowa (basic consent mode) nie budzi takich wątpliwości. Osobiście czekam aż w tej kwestii wypowiedzą się regulatorzy.
Jakie mogą być konsekwencje, jeśli od początku tzn. w consent default ustawimy analytics_storage na granted?
Trudno mi powiedzieć jakie będą konsekwencje, ale to generalnie nie będzie prawidłowe (na pewno nie w przy pierwszej wizycie na stronie). Google otrzyma taką informację, że domyślnie mamy zgodę. Mogę tylko spekulować, że to może wzbudzić ich podejrzenia, że wprowadzamy ich w błąd, informując że zgodę posiadamy, podczas gdy jeszcze jej nie mamy.
Domyślny status zgody na granted – czy na pewno jest to niepoprawnie? Jeśli mamy sytuację że user zgodził się, odświeżył stronę, mamy więc info o zgodach = granted. Na logikę – default w takim przypadku mógłby być granted.
Standardowo implementuje się to w taki sposób, że na każdej stronie jest domyślny status odmowy, po czym na podstawie informacji o zgodzie (z cookie CMP), wykonywany jest update.
Owszem, na jednym z filmów instruktażowych Google pokazuje by gdy już posiadamy zgodę, status default był zgodą, czyli by generować domyślny stan zgody na podstawie aktualnie posiadanej zgody:
Niemniej, aktualna dokumentacja w tej kwestii mówi wyraźnie, że status default jest denied na każdej stronie: developers.google.com/consentmode.
Przemawiają za tym również kwestie wydajności. Sprawdzanie stanu zgody dla stanu default wymaga sprawdzenia wartości w cookie, co jest dodatkowym opóźnieniem strony. Pytanie też, po co w takim razie byłby robiony update, skoro stan zgody już został sprawdzony.
Podsumowując, prawidłowe rozwiązanie to zawsze default = denied, a następnie update.
Mam małą / prostą stronę stworzoną w gotowym programie typu Wix czy Carrd. Jak tam dodać consent mode?
Można sprawdzić w pomocy danej platformy czy nie obsługuje ona natywnie zarządzania zgodami i Consent Mode natywnie lub przez wtyczki. Coraz więcej platform to oferuje – ale trudno mi się wypowiadać na temat konkretnych rozwiązań.
Generalnie, uniwersalnym rozwiązaniem będzie dodanie do strony Google Tag Managera i wykorzystanie CMP, którą też można zaimplementować za pomocą samego Google Tag Managera.
Czyli jak nie używam GA na stronie i nie korzystam z reklam Google to nie muszę mieć CMP na stronie, np. na prostym blogu?
Jeśli strona wykorzystuje tylko cookie niezbędne do jej funkcjonowania, nie trzeba żadnych zgód.
Przykładem jest strona uodo.gov.pl, która używa tylko ciasteczek 1st party niezbędnych dla jej funkcjonowania. Są one jedynie opisane w polityce prywatności: uodo.gov.pl/polityka-prywatnosci
Pytanie więc, jakie cookie stosuje dana strona, bo zgoda nie dotyczy tylko tagów Google.
Można to sprawdzić wchodząc w przeglądarce w Narzędzia dla deweloperów > Aplikacja > Cookies.
Można też użyć dostępnych w sieci i często oferowanych przez przeglądarki skanerów cookie, które zeskanują więcej stron w naszej witrynie, bo może się okazać, że na niektórych z nich są skrypty, których nie ma np. na stronie głównej i one będą odpowiedzialne za cookies, które nie są niezbędne i wymagają zgody. Może się tak zdarzyć np. w przypadku osadzonych treści (np. wbudowany w stronę film YouTube).
Czy narzędzie dla programistów (narzędzie dla deweloperów) zwraca wszystkie cookies występujące na stronie? Skaner cookies z zewnętrznych narzędzi zidentyfikował mi więcej cookies niż identyfikuje mi to narzędzie.
Skaner zazwyczaj odwiedza więcej stron niż np. tylko stronę główną, więc możliwe że gdzieś jakieś podstrony umieszczają inne cookies. Natomiast narzędzie dla deweloperów jest źródłem „z pierwszej ręki”.
Czy w przypadku wdrożenia wymaganego obecnie Consent Management może zostać utracony referrer (przez co następuje zwiększenie ruchu przypisanego do direct)?
Niektóre implementacje powodują odświeżenie się strony po update i jeśli tego się nie uzupełni przekazaniem referrera, to taki efekt może mieć miejsce. Według mojej wiedzy taka implementacja (z odświeżaniem strony) jest tak czy tak nie jest poprawna.
Obserwujemy natomiast problem z not set w źródłach sesji w Analytics, co wynika z tego że po Consent update nie generuje się session start, który odpowiada za źródło sesji. Według mojej wiedzy Google pracuje nad rozwiązaniem tego problemu, bo to jest wyłącznie wina przetwarzania danych przez Analytics. Doraźnie można próbować ten efekt zmniejszyć manipulując czasem uruchamiania się skryptu, ale to z kolei rodzi rodzi ryzyko utraty niektórych danych. Tak więc to jest “wytrych” który za jakiś czas może się okazać zbędny i działać na naszą niekorzyść, i jest to rozwiązanie dla bardzo zaawansowanych i monitorujących na bieżąco sytuację administratorów.
Czy sposób włączania okna zmiany zgody (chodzi o ten pływający button w rogu) jest wymagany w takiej formie, czy można go np. usunąć i dodać link do zmiany zgód w stopce strony?
Można, a nawet osobiście to polecam. Zgodę zmienia znikomy procent użytkowników, a ten widżet moim zdaniem tylko przeszkadza w korzystaniu ze strony. Umieszczenie linku w widocznym i łatwo dostępnym miejscu* w stopce w niczym nie utrudnia zmiany zgody, jeśli ktoś sobie tego zażyczył. Ale w konkretnym przypadku to znowu pytanie do IOD/prawnika.
*) np. stopka nie „ucieka” w miarę przewijania lub wymaga długiego przewijania.
Co jeśli mamy wdrożone advanced Consent mode, ale nie spełniamy wymagań/limitów ruchu do modelowania? Modelowanie nie zadziała, czy będzie działało bardziej na zasadzie basic Consent mode?
Po prostu nie będzie danych modelowanych, będą raportowane tylko dane tych użytkowników, którzy zgodę wyrazili.
Nie porównywałbym tego do Basic consent mode, bo tam modelowanie w Google Ads ma miejsce i odbywa się na podstawie porównania liczby kliknięć w reklamę z liczbą wizyt ze zgodą.
Czy dla komercyjnych CMP jest jakaś alternatywa open source?
Nie chciałbym się wypowiadać w tej kwestii. Problem z takimi rozwiązaniami jest taki, że nie mam pewności, czy są zgodne z Consent mode, a nawet jeśli dziś są zgodne, to może się okazać, że twórcy tego oprogramowania nie zapewnią update przy kolejnej zmianie technologii.
To nie znaczy, że rozwiązania open source nie mogą być świetne, ale przypadku platform komercyjnych certyfikowanych przez Google takie ryzyko niezgodności lub zaprzestania aktualizacji jest znacznie mniejsze.
W GTM w Galerii szablonów społeczności widzę tylko dwa szablony. U Pana na slajdzie było ich znacznie więcej. Jakiś pomysł dlaczego widzę tylko dwa? Czy szablony się importuje z zewnątrz?
Myślę, że to kwestia użytego słowa do wyszukiwania: tagmanager.google.com/?q=consent.
Generalnie należy szukać szablonu platformy CMP, którą się wybrało do zarządzania zgodami używając jako słowa kluczowego jej nazwy. Ja celowo użyłem słowa consent, bo nie chcę faworyzować konkretnej CMP.
Czy dla kodów śledzących Meta, TikTok itp. w GTM trzeba ustawiać dodatkowe sprawdzanie zgody?
Google to nie interesuje, ale z prawnego punktu widzenia musimy zbierać zgody na wykorzystanie tych kodów i biorąc to pod uwagę, trzeba właśnie wybrać opcję “wymaga dodatkowej zgody”. Musi to być zgoda odpowiednia dla tych tagów (generalnie dla Meta i TikTok jest to marketing), a tagi te powinny być uruchamiane na zdarzeniu consent update.
Czy nie powinniśmy umieszczać googlesyndication w kategorii „Niezbędne”. Np. Cookiebot które widzę na adequate skanuje pod kątem ciastek i trackerów.
Cookie reklamowe nie są niezbędne. Prawdę mówiąc, nie wiem o jakie cookie chodzi (zob. adequate.digital/polityka-prywatnosci), natomiast “googlesyndication” odnosi się do sieci reklamowej Google.
Ja odbyłam aktualizację consent mode z pomocą techniczną Google, ale nie ukrywam że mam pewne wątpliwości. Mieliśmy to poprawnie wdrożone przez Cookiebota z integracją przez oficjalne połączenie CMP Cookiebot z GTM i brakowało nam jedynie tych nowych dwóch tagów, by było to aktualne do wersji 2.0. Pomoc techniczna zasugerowała mi wyłączenie danych w tej wtyczce Cookiebota i zaimplementowanie ich przez jakąś inną, na około. Z tego co zrozumiałam z tego szkolenia, to wystarczyło jedynie żebym zaktualizowała ten Cookiebot CMP. Czy to możliwe, ze pomoc techniczna Google tego nie wiedziała?
Trudno mi się odnosić do tej konkretnej sytuacji. W przypadku Cookiebot CMP z GTM, przeważnie wystarczy aktualizacja szablonu integracji z GTM.
W niektórych przypadkach jeśli sam update szablonu nie zadziała, trzeba usunąć tag Cookiebot z GTM i dodać go ponownie – powinno pomóc.
W niektórych implemantacjach (zależy jak to zrobiliście) skrypt Consent default umieszcza się w kodzie strony i wtedy trzeba jeszcze w tym kodzie dodać te dwie zmienne: 'ad_personalization’: 'denied’ i 'analytics_storage’: 'denied’.
Czy trzeba ustawiać baner cookie w takiej formie, że blokuje on dostęp do strony, czy może on być np. w rogu ekranu i użytkownik normalnie będzie miał możliwość przeglądać stronę, dodawać do koszyka itd. nawet bez wyrażenia zgody / odrzucenia cookie. W szczególności, jeśli mamy domyślnie ustawioną zgodę na „granted” to do momentu, jak użytkownik nie kliknie na banerze „brak zgody” to wszystko będzie się zbierać. Jest to wersja przetestowana z działem Google i podobno jest wszystko dobrze bo jak użytkownik nie wyraża zgody to parametry wysyłają się poprawnie.
Do czasu wyrażenia zgody musimy przyjmować, że jej nie ma. Użytkownik może korzystać ze strony bez zgody, ale wtedy może się zdarzyć, że wyrazi zgodę gdzieś w środku i wtedy możemy mieć zniekształcone statystyki stron docelowych w Analytics. Osobiście raczej polecam od razu na wejściu oczekiwać zgody/odmowy.
Z mojego doświadczenia nie wpływa to negatywnie na poziom zgód, a w niektórych przypadkach nawet poprawia współczynnik konwersji – prawdopodobnie dzięki temu, że ciągnący się za użytkownikiem widżet zgody zasłania część ekranu i pogarsza UX.
Status domyślny “granted” podczas pierwszej wizyty użytkownika jest na pewno błędny i nie jest to prawidłowo zbierana zgoda. Obowiązuje zasada opt-in, a nie opt-out. Technicznie to oczywiście może zadziałać, ale nie jest to prawidłowa implementacja i może spowodować uruchomienie „pełnego” Analytics bez zgody.
To jeszcze na koniec: Jak wiąże się przesyłanie danych w ramach customer match API z wyrażoną zgodą w ramach CMP? O ile się nie mylę, w ramach najnowszej wersji API dla customer match należy przekazywać status zgody. W jaki sposób przekazać status zgody na przesyłaną listę?
Status zgody przesyłamy przez API, zob: developers.google.com/customer-match.
Czy zgoda wyrażona w CMP może wystarczyć do customer match, to pytanie do prawnika/IOD.
Co do zasady, jeśli użytkownik wyraża zgodę na stosowanie identyfikatorów (cookie i podobnych technologii) do celów reklamowych to również hash emaila takim identyfikatorem jest (rozmawiałem kiedyś na ten temat z mec. Agnieszką Grzesiek-Kasperczyk w kontekście Enhanced Conversions). W ten sposób można się pokusić, by taką zgodę przekazać ze strony www do CRM podczas pozyskania adresu email i telefonu użytkownika i wykorzystywać ją do tworzenia listy klientów.
Można też ograniczyć się w customer match tylko do tych klientów, którzy wyrazili zgodę na wykorzystanie e-maila do tego celu poprzez zaznaczenie zgody w checkboxie już na stronie, np. przy transakcji. To przypuszczalnie powinien być oddzielny checkbox, bo użytkownik może chcieć dostawać maile, ale może nie chcieć oglądać wszędzie reklam naszego sklepu.
Te wszystkie kwestie należy uzgodnić ze swoim prawnikiem / IOD lub skorzystać z dodatkowej porady prawnej.
