Rubriky
Blog o webové analytice

Úvod: Cookieless analytika bez osobních údajů.

Disclaimer: Nejsem právník, takže vše na vlastní odpovědnost.

Úvod do problematiky správného měření bez cookies a osobních údajů

Toto je můj osobní pohled na věc, mnohým z vás se může zdát příliš tvrdý. Naučil jsem se s tímto přístupem k měření pracovat jak na úrovni implementace, tak na úrovni reportingu a zdá se mi, že čím dříve se na tuto cestu vydáte, tím to bude lepší.
Podobné, i když složitější řešení používám již několik let a s takto získanými daty se mi pracuje dobře.
Ano, je to velká změna. Musíte změnit pohled na data a změnit zavedené procesy, reálně to rozdělí data na anonymní zkrácená, kde je všechno. A klasická data vytvořená pomocí souborů cookie a identifikátorů, která sbírám pouze se souhlasem a jsou užitečná pro sledování cesty uživatele po webu.

Základní principy měření bez cookies a osobních údajů.

  • Nic si neukládám u uživatele v zařízení.
  • Nevyužívám data o zařízení uživatele.
  • Neshromažďuji informace, které nepotřebuji.
  • Shromažďuji pouze informace o obsahu.

Nic si neukládám u uživatele v zařízení.

Všichni mluví o souborech cookie, ale ve skutečnosti mluvíme o jakémkoli úložišti na straně uživatele. Cookies, localStorage, sessionStorage, cache, fav ikony, je jich mnoho. Toho dříve využíval evercookie, který vytvářel super trvanlivé identifikátory, které nebylo možné smazat a často fungovaly napříč různými prohlížeči a neustále se obnovovaly. Velmi ošklivá věc a to byl blackhat před 10 lety.

Výčet takový úložišť, co se dříve používaly:

https://en.wikipedia.org/wiki/Evercookie
Znáte nějaký jiný typ úložiště, který zde není uveden? Opravdu? Skvělé, takže i to je zakázáno, protože nejde o technologii, ale o princip.
Dále v článku se chystám příliš zjednodušit a všechna tato úložiště budu zkráceně nazývat cookies, i když mám na mysli jakékoli úložiště na straně uživatele.

Takže na webu nesmí být žádné “cookie” bez souhlasu? 

U uživatele si můžete ukládat věci pro fungungování webu takzvané “technické cookies” / “necessary cookies”

Co jsou technické “cookie”?

Například soubory cookie, které ukládají vaši návštěvu pro PHP, přihlašovací soubory cookie, soubory cookie, které se týkají toho, který server vám bude servírovat data webu, vyrovnávače zátěže atd… Pak jsou tu věci jako detekce chyb webu, bezpečnostní soubory cookie vyžadované zákonem, například bankami atd. Zde je důležité říci, že tyto soubory cookie musíte používat pouze k účelu, ke kterému jsou určeny.
V okamžiku, kdy je technický soubor cookie použit jako analytický nebo reklamní soubor cookie nebo pro personalizaci atd. atd. pak k tomu potřebujete souhlas. V okamžiku, kdy je technický/bezpečnostní soubor cookie použit k čemukoli jinému (analytika, reklama, personalizace …), stává se souborem cookie dané kategorie(analytika, reklama atd.) a k tomu již souhlas nepotřebujete.
Získal jsem informaci, že některé partnerské programy tvrdí, že je naprosto v pořádku tajně používat technický soubor cookie ke sledování uživatelů a vyhodnocování partnerů. Ne, to opravdu není. A možná vám dokonce dají nějaké prohlášení od svého placeného právníka, že je to v pořádku, ale pokutu za to dostanete vy, ne oni, takže si mohou říkat, co chtějí.

Nevyužívám data o zařízení uživatele.

V poslední době se v mé programátorské komunitě objevilo mnoho řešení, jak zachovat stejná měření Google Analytics a nepoužívat “cookies”. Ano, objevily se pokusy prostě je umístit do localStorage a další triky, jak ukládat data v zařízení, ale pak někdo dostal “skvělý” nápad použít místo cookies IP adresu uživatele. Ano, pak se objevily argumenty, ale já ty “špatné cookies” nepoužívám. Ano, nepoužíváte cookies, ale zákon to říká:

Každý, kdo hodlá používat nebo používá sítě elektronických komunikací k ukládání údajů nebo k získávání přístupu k údajům uloženým v koncových zařízeních účastníků nebo uživatelů, získá od těchto účastníků nebo uživatelů předem prokazatelný souhlas s rozsahem a účelem jejich zpracování. Tato povinnost neplatí pro technické ukládání nebo přístup výhradně pro potřeby přenosu zprávy prostřednictvím sítě elektronických komunikací nebo je-li to nezbytné pro potřeby poskytování služby informační společnosti, která je výslovně vyžádána účastníkem nebo uživatelem.

https://www.zakonyprolidi.cz/cs/2005-127?text=D%C5%AFv%C4%9Brnost%20komunikac%C3%AD

Pak se můžeme zeptat, co je to IP adresa?
Je to informace, která je uložena/vytvořena na daném zařízení (“data nebo pro přístup k datům uloženým na koncových zařízeních”) a slouží k jeho identifikaci v rámci internetové/síťové komunikace.
Abychom se tedy mohli oficiálně dotknout těchto informací pro účely analýzy, marketingu, personalizace atd. Potřebuji k tomu souhlas.
V praxi se jedná o stejný případ jako u souborů cookie, jen jde o jinou technologii. A co hůř, použití tohoto identifikátoru se uživatel nemůže bránit. (I když budu používat VPN, stále budu mít IP adresu).

A rovnou říkám, že řešení Helgeho Kleina je špatné, používá IP adresu a to je informace ze zařízení.

https://helgeklein.com/blog/google-analytics-cookieless-tracking-without-gdpr-consent/.

Diskuze s lidmi, co již dané “řešení od Helgeho Kleina” implementovali:

První začnou argumentovat, že IP adresa není osobní údaj. Možná vytáhnout pár vyjádření soudu, kdy opravdu IP adresa nebyl osobní údaj, třeba ve spojení se serverem etc.

  • Což není pravda, IP adresa je osobní údaj ve spojení s návštěvníky webu / aplikace etc. https://ec.europa.eu/info/law/law-topic/data-protection/reform/what-personal-data_en .
  • Ano, existují případy, kdy soud v EU někde řekl, že v některých konkrétních případech IP adresa a adresa poskytovatele internetu není osobním údajem. Slovo NĚKDY je zde důležité, protože neznamená, že to nikdy není. Stejnou logikou se dá říct, že pokud se dva lidé mohou jmenovat “Jan Novák” tak nepoznám, který je který a tudíž žádné jméno již nikdy nebude osobním údajem… . Takhle to nefunguje, pokud se i pro super malou část uživatelů jedná o osobní údaj, pak s ním budu jako s osobním údajem zacházet vždy.
  • Jsou ale i místa, kde je povoleno přímo používání IP adresy v konkrétních případech na identifikaci zařízení jako je třeba bezpečnost bankách a nebo funkčnosti sítě internetu etc.
  • Pro mě osobně je to reálně ještě horší než soubory cookie, protože IP adresu je uživatel nemůže změnit, vypnout ani s nimi souhlasit a mohou být shromažďovány bez jeho vědomí nebo souhlasu.

Pak bude argument, že IP adresu nepoužívají, protože IP adresu zaHASHují (tjs. Transformují IP adresu na kratší řetězec znaků)

  • Zde se z pohledu práva nic moc nemění, stále byla použita informace z daného zařízení a jen vizuálně vypadá jinak se stejnou informační náplní o vlastně na to ani moc nezáleží, protože vše bylo porušeno prvním krokem a to použitím IP adresy.
  • HASHování není anonymizace dat, ale pseudonymizace. Takový řetězec znaků stále využívá informace z daného zařízení.
  • Zde může být diskuze o tom, že daného programátorovi se to “zdá” dostatečně anonymní. Problém je v tom, že takto to nefunguje. Nezáleží na tom co se někomu “zdá” dostatečné nebo “nezdá” dostatečné, ale to co je zákonech.

Pak bude argument, že to toho HASHe přidali i user-agent.

  • Přidali jste jen další údaj z daného zařízení, na což nemáte právo bez souhlasu.
  • Reálný cíl tohoto dobrovolného kroku není anonymizace uživatelů, ale lepší identifikace návštěvníka webu, protože IP adresa nemusí vždy stačit. Tolik tomuto “dobrému” úmyslu.

Pak dostanou nápad, že do HASHe přidají i doménu.

  • Tohle taky nic nemění z pohledu práva, ale je vidět, že si tvůrce kódu uvědomuje, že bez této úpravy tento identifikátor funguje přes různé weby aniž by weby byli propojený.

Pak řekne a já do HASHe přidám ještě tady pár znaků navíc, co budu měnit co 24hod. Aby se nestalo, že uživatel i za rok bude mít stejné “ID”.

  • Z pohledu práva se nic nemění. Tvůrce si připadá, že mu to stačí z pohledu soukromí jeho návštěvníků, má takový “pocit”. Reálně však to je jen pocit. Stále jste použili IP adresu a user-agenta z daného zařízení.

A když do toho člověk začne kopat, tak vymyslí, že zkrátí 24hod na 6hod.

  • Zde se opět nic nemění, protože v zákoně není výjimka, na to že můžete porušovat zákon jen 6hod. Nezáleží jestli to je 24hod nebo 30sec.

Nesbírám informace o uživateli, co nepotřebuji.

Dejme si ruku na srdce a řekněme si, že z Google analytics reálně využíváme informace o zdroji návštěvnosti, stránce, události a případně ecommerce. Tím jsem právě pokryli 95% potřeba všech uživatelů a přitom jsme nemuseli použít informace ze zařízení uživatele.
Takže se podíváme na normální data co se navíc posílají do Google Universal Analytics:…

Příklad je třeba zde… zobrazení jedné stránky a takto vypadají odeslané data do Google analytics:
https://www.google-analytics.com/j/collect?v=1&_v=j96&aip=1&a=71919854&t=pageview&_s=1&dl=https%3A%2F%2Fwww.tvojedoména.cz%2F&ul=en-us&de=UTF-8&dt=titulek&sd=24-bit&sr=2560×1440&vp=2468×769&je=0&_u=6ChAAAAAAAC~&jid=6547603&gjid=166103367&cid=51322772.1643395360&tid=UA-000000-1&_gid=179993225.1643395364&_r=1&gtm=2wg00VVHFM&gcu=1&gcut=2&z=1992819357
Nyní tyto odeslané data rozsekáme na jednotlivé kousky informací, je jednotlivé parametry a vysvětlíme si jejich účel.

Data potřebná pro měření zobrazení stránky.

tid=UA-000000-1

t=pageview

  • Hit type
  • Zde se říká o typu měření události v našem příkladu jde zde zobrazení stránky.

dl=https%3A%2F%2Fwww.tvojedoména.cz%2F

  • Document location URL
  • Zde říkám, která stránka byla zobrazena,dle URL
  • Pozor i v URL adrese mohou být osobní údaje a identifikátory. Nutné ošetřit.

dt=titulek

  • Document Title
  • Zde se dozvíme titulek dané stránky. Nepovinný parametr.
  • Pozor i titulek může obsahovat osobní údaje.

z=112819357

  • Cache Buster
  • Zde je bonusový nepovinný parametr, co brání cachování tohoto analytického dotazu, je to náhodné číslo.

v=1

  • Protocol Version
  • Verze measure protokolů odesílající data do Google analytics. U Universal analytics “1”, pro GA4 “2”.

Všimněte si, že v těchto vyjmenovaných datech není nic o uživateli nebo jeho nastavení prohlížeče, jen informace o obsahu stránky.

Data odesílaná o při měření zobrazení stránky obsahující informace ze zařízení uživatele.

cid=1382753028.1642265937

  • Client ID
  • ID uživatele z pohledu Google, klasicky informace uložená v souboru cookies.

_v=96

  • SDK verze Javy
  • Informace ze daného zařízení.

a=124596931

  • Adsense Link Code

_s=1

  • ID sekvence odesílaných dat.
  • Data uložená v javascriptové proměnné v daného okně stránky.

ul=en-us

  • User Language
  • Nastavení jazyku
  • Informace z daného zařízení.

de=UTF-8

  • Nastavení kódování.
  • Informace z daného zařízení.

sd=24-bit

  • Nastavení barev
  • Informace z daného zařízení.

sr=2560×1440

  • Rozlišení obrazovky.
  • Informace z daného zařízení.

vp=2468×337

  • Velikost viewportu, zde je krásně vidět, že je to krásně unikátní.
  • Informace z daného zařízení.

je=0

  • Podpora Javy
  • Informace z daného zařízení.

_u=YEAAAQBB~

  • verifikáční kód

_gid=969150771.1642265937

  • Krátkodobé ID uživatele.
  • Informace uložená v souborech cookies.
  • Informace z daného zařízení.

_jid=969150771.1642265937

  • ID pro reklamní službu DoubleClick
  • Informace uložená v souborech cookies.
  • Informace z daného zařízení.

IP adresa

  • Data získané z měřícího hitu.
  • Odesílaná s každým hitem do Google, ano to je důvod, proč se to nelíbí Rakousku a Francii.
  • Informace z daného zařízení.

User-agent

  • Data získané z měřícího hitu.
  • Odesílaná s každým hitem do Google, ano to je důvod, proč se to nelíbí Rakousku a Francii.
  • Informace z daného zařízení.

A další parametry najdete zde, ale nejsou tam všechny https://developers.google.com/analytics/devguides/collection/protocol/v1/parameters
Z těchto dat navázaných na zařízení prohlížeče může všechny s výjímkou ClientID vynechat.

ClientID je povinný parametr, bez něhož Google analytics nic nezměří. Ale i to se dá vyřešit, místo ID uloženého v cookie se do něj prostě zapíše konstanta, já používám hodnotu “555”, která se k tomuto účelu neoficiálně používala v dokumentaci.
Můžete tam také poslat hodnotu náhodného čísla a vytvořit tak nového uživatele s každým naměřeným zásahem analytiky. Osobně se mi však toto řešení nelíbí, protože vytváří identifikátor a také zpomaluje samotnou službu Google analytics. Pokud se použije pouze jedno ID, reporty se načítají rychleji. (Má to vliv na přehled návštěvnosti, kde se více přímých návštěv generuje s jedinečným ID a ne bez něj).
Pokud tedy tento údaj odstraníte, nebudete znát barevný rozsah prohlížeče návštěvníka, ale v datech nebudete mít žádné údaje o uživateli.
Pak pro ořezání IP adresy a User-Agent musíte udělat více kroků, jednodušší, ale nedokonalý je přepsat tyto hodnoty pomocí &uip=0.0.0.0&ua=notset a doufat, že Google tyto údaje přepíše, ale dále v návodu je také metoda, jak tam tyto údaje neposílat.

Existují z mého pohledu i informace co bych do těchto analytických dat přidal a některé tyto údaje jdou i právně obhájit.

  • Zkratka země (ISO 3166 country codes) návštěvníka, což je informace, která mi říká, jak se k danému uživateli mám chovat, podle jakých zákonů etc. Tjs přeložit si IP adresu návštěvníka na serveru na stát a to pak vepsat do stránky. Což není lehké a tato funkce potřebuje údržbu, takže to v návodu nebudu ani ukazovat. U tohoto údaje by šlo argumentovat, že je potřebný ke správě souhlasu a práce se uživateli a chování se k nim dle jejich zákonů.
  • Nastavení jazyku (ga parametr “ul”), které mi říká jestli s návštěvníkem při komunikaci třeba kolem souhlasu mluvím ve správném jazyku.

Sbírám jen informace o obsahu.

Takže co budu sbírat?

  • Pageview + URL stránky. + document.referral, pokud máte tak consent group a další informace o obsahu. Třeba typ postu, datum vydání článku, kategorie článku, štítky článku, autora článku etc. Bacha! Page URL může obsahovat osobní údaje a další identifikátory,
  • Události co se staly na stránce. Bacha, aby v eventLabel nebylo ID uživatele nebo jiný osobní údaj v datech. Třeba event o přečtení článku je v pořádku. Event že se stala registrace do newsletteru je v pořádku. 
  • Ecommerce.. Zobrazení produktu na webu, přidání zboží do košíku etc. vše je o obsahu na webu a ne o uživateli. Bacha! Nutné ošetřit třeba transaction ID.

Ono se to nezdá, ale tohle bude opravdu stačit 90%uživatelů. To co jistě bude chybět je zdroj návštěvy, co si přesně nakoupil etc. o to se reálně přijdete. A i tak vám zůstane u první stránky, odkud uživatel na váš web přišel.

Šedá zóna aneb unikátní parametry v URL.

Parametry v URL, umožňující měřit cestu uživatele přes webu ze strany serveru.
Příklad, už při načtení stránky se do každého interního odkazu přidá unikátní parametr označující danou návštěvu. Tento parametr se pak předává s v každém odkazů s každou navštívenou stránkou uživatele webu.
Pro:

  • Informace není na straně uživatele.
  • Může to fungovat plně na straně serveru.
  • Jde pak měřit efektivnost kampaní, pokud je parametr správně propagován přes web.
  • Právně to jde opřít o oprávněný zájem měření kampaně. V ČR jsem to ještě neviděl, ale v pár státech se o to pokoušeli.

Proti:

  • Může to brutálně rozbít SEO, zvláště když takový parametr je zaindexován.
  • Může to rozbít PPC, protože ty nebudou počítat s tolika unikátními URL.
  • Sdílení URL, aneb jeden link na sociálních sítích a hned je půlka internetu jeden uživatel.
  • Při nevyčištění tohoto parametru z URL to brutálně zpomalí Google analytics reporting u uživatelů, kteří dali souhlas s měření, protože Universal analytics nejsou dělané na vysoké počty unikátní URL.
  • Může to být komplikace u různých státu, které si vykládají různé ePrivacy a GDPR.

Google na to má funkci, která předává UTM URL parametry v ramci odkazů.
Nastavení Gtag:  gtag(‘set’, ‘url_passthrough’, true); https://developers.google.com/tag-platform/devguides/consent#passing_ad_click_client_id_and_session_id_information_in_urls
Jak říkám, za mě šedá zóna, co může nějaké věci vyřešit i dost zkomplikovat. Já nevyužívám.

Pokračování v dalších článcích.  🙂
Chtěl jsem to trochu nasekat.

 

 

.