Od cookies k 100 % dát: Ako zaznamenávať štatistiky na serveri

Od zavedenia GDPR v máji 2018 sa mnohým prevádzkovateľom webov zhoršil zber štatistických dát o návštevnosti a aktivite používateľov na webe. Avšak k postupnému prepadu získaných údajov dochádalo už aj predtým. My sme napríklad už v roku 2015 zisťovali, že dáta o predajoch (transakciách) reportovanými v Google Analytics (vtedy ešte Universal) nesedia s údajmi, ktoré nám poskytoval na kontrolu klient.

Kde sa tieto dáta strácajú? A ako tento nesúlad riešiť? Klienti predsa očakávajú (alebo aspoň ešte pred pár rokmi určite očakávali), že ak sa pozrú do online systémov ako Google Analytics, uvidia zhodné dáta s tými o predajoch z ich interných systémov.

V článku sa dozviete, ako dáta zachrániť a aké sú varianty implementácie zberu štatistík na serveri.

Prečo v Google Analytics chýbajú transakcie?

Pred rokom 2018

Dôvodov pre chýbajúce dáta v digitálnej analytike je viacero. Pred májom 2018 a všeobecným zavedením cookie líšt to mohli byť najmä tieto:

• nesprávna inštalácia analytických kódov,
• neskoré spúšťanie kódov (napríklad návštevník stihol zavrieť stránku predtým, ako na pozadí došlo k reportovaniu transakcie),
• alebo blokovanie analytických kódov rozšíreniami ako uBlock.

GDPR a cookie lišty

Všeobecné vyžadovanie súhlasov na záznam štatistických a iných dát od mája 2018 (GDPR) spôsobilo ďalší prepad zaznamenaných údajov v systémoch ako Google Analytics. Zatiaľ čo pred májom 2018 sa stratené údaje pohybovali maximálne v jednotkách percent, od mája 2018 stratené štatistické údaje o návštevnosti dosahujú niekoľko desiatok percent. Pri niektorých typoch webov to je dokonca viac ako polovica dát, čím už relevantnosť získaných údajov prudko klesá.

Zákon o elektronických komunikáciách

Relevantným nariadením nie je len samotné GDPR, ale aj jeho rozšírená implementácia cez Zákon o elektronických komunikáciách. Práve ten vyžaduje od prevádzkovateľov webov získavanie explicitného súhlasu pre ukladanie dát do zariadenia používateľa. Výnimkou sú dáta, ktoré sú nevyhnutné pre fungovaniu webu, často označované ako nevyhnutné alebo funkčné cookies (napríklad prihlásenie, jazyková preferencia a podobne). Pre ukladanie dát na iné účely (štatistika alebo remarketing) sú potrebné samostatné súhlasy.

Sú zvyškové dáta stále relevantné?

Zvyškové dáta sú v menšine a je otázka, či môžu tvoriť relevantný podklad pre diskusiu a marketingové rozhodnutia.

Väčšina systémov pre získavanie súhlasov na ukladanie cookies poskytuje aj informáciu o tom, koľko používateľov – návštevníkov súhlas poskytlo. Percentuálna strata dát je preto taktiež známou hodnotou. Dôležitou otázkou je potom to, či môžeme stratené dáta dopočítať alebo aproximovať na základe získaných dát a znalosti percentuálneho výpadku. A môžu ešte takto dopočítané dáta naplniť mieru štatistickej významnosti? Inak povedané: môžeme ich považovať za spoľahlivé?

First-party data a problém atribúcie

Prečo ale riešime výpadok dát, keď spoľahlivé dáta máme priamo z interných systémov? Veď predajca musí vedieť, kto uňho nakupuje, kam má objednávku doručiť a akým spôsobom bola uhradená. To sú tie dáta  „z prvej ruky“ alebo first-party data.

To sú fakty, avšak zásadná chýbajúca informácia je táto: odkiaľ prišli návštevníci, respektíve zákazníci či zákazníčky, ktorí nakúpili? Primárne teda riešime napojenie dát od obchodníka na dáta o atribúcii. A práve dáta o atribúcii, teda zdroji návštevy, sú často tie chýbajúce. Prišiel zákazník z organického vyhľadávania Google, videl a klikol na niektorú z bežiacich kampaní alebo prišiel z emailového newsletteru?

Zákaznícka cesta k nákupu

Akokoľvek návštevník prišiel, musel sa o značke obchodníka nejakým spôsobom dozvedieť. Vieme, že cesta k nákupu je málokedy priamočiara. Naopak, častokrát vedie cez viacero stretávacích bodov či momentov rozhodovania. Či už pohyb návštevníka zasadíme do frameworku See-Think-Do-Care alebo inej metodiky, návštevník postupuje od všeobecného vyhľadávania cez porovnanie produktov s konkurenciou až k rozhodnutiu o nákupe a jeho realizácii. 

Po ceste vidí značku webu či produktu viackrát, viackrát zvyčajne aj web navštívi, skúma, porovnáva, pozerá iné možnosti. Ak poskytne súhlas pre štatistické účely, máme údaje od prvej návštevy až po moment nákupu – transakciu. Ak poskytne súhlas aj na marketingový účel, máme možnosť mu po ceste pripomenúť sa niektorou z dobre cielených kampaní, napríklad presne podľa produktovej kategórie, o ktorú mal záujem či dokonca zobrazením konkrétneho produktu.

Ak súhlas nemáme, nemáme ani dáta. Ako vieme využiť dáta z prvej ruky pre digitálne analytické nástroje? Vieme nejako poslať štatistické dáta o transakciách (predajoch na webe) do Google Analytics 4?

Na scénu prichádza Measurement Protocol

Čo keby sme dáta o predajoch začali posielať zo servera vtedy, keď sa udejú (v reálnom čase)? 

Measurement Protocol je spôsob, ako to docieliť. Pomáha obohatiť dáta posielané z prehliadačov používateľov, ktorí poskytli súhlas a zároveň môže doplniť chýbajúce dáta pre návštevníkov, ktorí súhlasy na ukladanie cookies neposkytli. Measurement Protocol (alebo Merací protokol) poskytuje jednoduché API, teda rozhranie pre automatizované posielanie dát.

Zjednodušene povedané stačí, aby programátori poslali na Measurement Protocol dáta a tie sa objavia v reportoch Google Analytics 4.

Záznam na serveri

Measurement Protocol spadá pod širšiu kategóriu, ktorú nazývame server tracking alebo backend tracking, po slovenský záznam na serveri. Oba tieto názvy sú protikladom frontend alebo browser trackingu, teda posielania údajov z prehliadača návštevníka cez Javascript.

Narozdiel od prehliadača, kde poslanie údajov môže rôznym spôsobom zlyhať, komunikácia medzi servermi (web / e-shop a GA4) je rýchla a bezproblémová. Výhodou je, že dáta sú posielané bez ohľadu na to, či návštevník stránku opustí alebo dôjde ku chybe v prehliadači. Navyše server tracking umožňuje dáta posielať aj s odstupom času, ak je to potrebné. O takom prípade si povieme viac v časti príkladov, ako dokážete backend tracking využiť.

Ako zistíme vplyv digitálnych kampaní na nákupy v predajniach?

Pred rokmi sme riešili takýto problém: klient mal predajne nábytku, avšak web bol len prezentačný katalóg bez e-shopu. My sme pre klienta zabezpečovali digitálne kampane. Klient bol spokojný, zákazníci chodili do predajní a nakupovali nábytok. Naše kampane však ukazovali nulu.

Keďže predaj sa uskutočnil na pobočke, digitálne kampane nemali ako tieto transakcie zachytiť a vykazovali nulové konverzie.

Zamysleli sme sa, preskúmali možnosti a objavili práve Measurement Protocol. Vtedy ešte v beta verzii a pre Universal Analytics. Dáta o predajoch sme teda dokázali posielať do Google Analytics, stále sme ale nemali informáciu o atribúcii, teda kde sa daní zákazníci o predajniach dozvedeli. Aké bolo naše riešenie? Bolo by zbytočné vymýšľať koleso, preto sme využili jednoduchý spôsob – kupón s kódom.

Tento kupón, za ktorý zákazník pri kúpe obdržal malý darček, sme návštevníkom zobrazili na webe. Kód kupónu bol náhodne generovaný a unikátny vždy pre jedného návštevníka (respektíve konkrétne zariadenie a prehliadač návštevníka, to ale nemalo vplyv na naše čísla). Zároveň sme pre daný kód zaznamenali client ID, identifikátor Google Analytics. Zákazník si kód odfotil alebo opísal, prišiel do predajne, kúpil si postel či gauč a pri platbe ho ukázal predavačom. Kupón bol priradený k nákupu a platbe.

Ostávalo tieto dáta nejako dostať do Google Analytics. V lepšom prípade sme od klienta obdržali sheet s niekoľkými stĺpca o predaji a kódom kupónu, v horšom prípade naskenované bloky s ručne dopísanými kódmi kupónov. Pointou tohto vtipného príbehu je práve využitie Measurement Protocolu na uloženie informácií o predajoch a atribúcii do Google Analytics. Na to nám poslúžil práve jedinečný identifikátor client ID.

Zrazu sme mali digitálne kampane, ktoré nám presne priraďovali predaje na pobočkách ku konkrétnym preklikom v online priestore. Klientovi sme dokázali reportovať práve dopad kampaní na predaje na pobočkách. Na rok 2016 to bol prelomový spôsob, ako prepojiť offline a online dáta.

Dnes tento procesne naivný spôsob nahrádzajú QR kódy alebo vernostné aplikácie.

100 % transakcií v Google Analytics

Measurement Protocol použijeme na to, aby sme v Google Analytics 4 videli 100 % dát o nákupoch. Implementovať je možné aj ostatné konverzie ako odoslania formulárov či iné získavanie kontaktov – leadov.

Ako implementovať posielanie dát?

Google nám poskytuje podrobnú dokumentáciu k Measurement Protocolu. Programátori musia doplniť posielanie dát cez Measurement Protocol o transakciách do Google Analytics 4. V admine GA4 si v časti Data streams vyberieme konkrétny dátový zdroj, pre ktorý chceme nakonfigurovať Measurement Protocol. Po kliknutí na Measurement Protocol API secrets sa nám zobrazí detail, kde vieme vytvoriť nový tajný token (niečo ako heslo), ktorý programátori neskôr využijú pri posielaní dát.

Cesta sa nám ale rozdeľuje pri atribúcii, kde nám môže chýbať identifikátor návštevníkov – client ID a návštevy – session ID.

Ak súhlas s cookies návštevník poskytol

Tento spôsob je jednoduchý. Informáciu o nákupe (transakciu, udalosť purchase) nebudeme posielať z Google Tag Managera, ale poslanie presunieme na server. Získané identifikátory z Google Analytics cookies využijeme a pošleme ich zároveň s transakciou cez Measurement Protocol.

Ak súhlas s cookies návštevník neposkytol

Identifikátor nemáme k dispozícii, o dáta by sme pri reportingu z Google Tag Managera prišli. Identifikátory client ID a session ID si vygenerujeme a takéto vygenerované ich pošleme spolu s transakciou.

O presnom postupe pre každý z variantov si povieme nižšie.

Ako získať existujúce client ID?

Cookie Google Analytics 4 je nazvané _ga. Ukážka jeho obsahu:

GA1.1.40032303.1671533621

Nás bude zaujímať časť od druhej bodky, konkrétne 40032303.1671533621, čo tvorí práve pre nás potrebné client ID.

Nezabudnite na identifikátor návštevy

Identifikátor návštevy session ID je podmienkou funkčného reportingu, aby transakcie (alebo iné udalosti) boli správne priradené existujúcej návšteve a správne atribuované. V prípade neudelenia súhlasu s cookies si ju podobne ako client ID vygenerujeme.

Ako získať existujúce session ID?

Ďalšie cookie Google Analytics 4 je nazvané _ga_XXXXXXXX, kde XXXXXXXX je identifikátor tzv. streamu GA4, ktorý nájdete v admine GA4 a má formát G-XXXXXXXX. Session ID začína od druhej bodky a končí pred tou treťou: GS1.1.1695219825.1.1.1695219916.32.0.0.

V našom prípade to bude časť 1695219825, ktorá je identifikátorom návštevy.

Generovanie client ID

Ak návštevník súhlasy s cookies neposkytol, client ID potrebujeme vygenerovať. Je na programátoroch, akú metódu generovania semi-unikátneho identifikátora zvolia. Zvyčajne je možné využiť kombináciu hlavičiek z prehliadača a anonymizovanej IP adresy, ktorú očistíme o jej posledný oktet. Pre doplnkovú anonymizáciu môžete reťazec zahashovať napríklad použitím algoritmu SHA256.

Ukážka vygenerovaného client ID: ad8457b86528275094aa317058ac92e194aad973ae91678a53c37ed5208e4267

Generovanie session ID

Pre session ID potrebujeme zvoliť trochu iný prístup. Keďže štandardná dĺžka návštevy je v GA4 30 minút, mali by sme docieliť podobnú dĺžku trvania návštevy aj pri reportovaní zo servera.

Využiť opäť môžeme akýkoľvek semi-unikátny reťazec, napríklad kombináciu anonymizovanej IP adresy a hodiny. 30 minútový blok dokážeme nasimulovať napríklad rozdelením hodiny na dve polhodiny a doplnením tohto údaju do session ID. V prípade, ak máte nastavenú inú dĺžku trvania návštevy (session) v GA4, premyslite iný spôsob.

Príklad vygenerovaného session ID: 2413212514

Použitie user ID

Ak používate namiesto client ID váš vlastný identifikátor user ID, môžete samozrejme využiť aj ten. V tomto prípade ho vaši programátori budú posielať doplnkovo k povinnému client ID.

Správna atribúcia pre server reporting

Ak by sme implementovali posielanie dát cez Measurement Protocol podľa postupu vyššie, všetky dáta o transakciách budeme správne vidieť v našom GA4. Pri väčšom množstve dát (návštevníci, ktorí neposkytli súhlas s cookies) ale uvidíme ako zdroj návštevy kanál Unassigned, prípadne Direct. Potrebujeme ešte doriešiť atribúciu pre serverové udalosti cez Measurement Protocol.

Práve na to slúži špecifická udalosť nazvaná campaign_details, ktorú je možné cez Measurement Protocol odoslať. Jej súčasťou sú parametre, ktoré môžete poznať ako UTM. Pre atribúciu podľa vašej preferencie teda využijete štandardne pomenované UTM parametre. Tu odporúčam dodržať UTM hodnoty tak, aby ste sa vyhli označeniu návštev ako Unassigned.

Konkrétne môžete cez campaign_details posielať:

• source – zdroj návštevy (utm_source)
• medium – médium návštevy (utm_medium)
• term – kľúčové slovo / fráza, cez ktorú návšteva prišla (utm_term)
• content – obsah kampane (utm_content)
• campaign – názov špecifickej kampane (utm_campaign)
• campaign_id – ID kampane (bez UTM variantu)

Kedy posielať campaign_details?

Udalosť campaign_details potrebujete poslať cez Measurement Protocol pred akoukoľvek inou udalosťou. Táto udalosť je akýmsi pomocníkom, ktorý nastaví atribúciu pre všetky ďalšie udalosti po nej. Samotné technické riešenie vo forme udalosti je pomerne zvláštne, keďže to nie je plnohodnotná udalosť a ani ju ako udalosť (event) neuvidíte nikde v reportoch.

Riešenie problémov

Measurement Protocol pri odoslaní dát zo servera nijakým spôsobom nepotvrdzuje prijatie či správnosť posielaných dát, jedinou informáciou je HTTP hlavička so stavovým kódom 204. Ako si ale dokáže overiť správne zapracovanie programátormi?

Logy

Pri tvorbe špecifikácie pre nasadenie Measurement Protocolu vyžadujeme vždy logovanie odoslaných požiadaviek (v rozsahu čas, URL, payload – telo požiadavky). Tento spôsob sa nám osvedčil, keďže implementácia je málokedy priamočiara a komplexnosť posielaných objektov v tele požiadaviek môže byť pre programátorov napriek rozsiahlej dokumentácii mätúca. Cez logy dokážeme overiť, čo a kedy bolo posielané a či takýto záznam existuje aj v GA4. Takisto tu dokážeme skontrolovať posielanie informácii o atribúcii a následne priradenie transakciám.

Overenie cez Debug endpoint

Preto je vhodné pred nasadením produkčnej verzie využiť debug endpoint, ktorý spätne vracia JSON objekt s informáciou o chybe. V prípade úspešného poslania dát bez chyby, vráti validáciu s prázdnym objektom.

Realtime report v GA4

Realtime report poskytuje okamžitý prehľad poslaných udalostí vrátane purchase. Ak váš server odosiela dáta cez Measurement Protocol, tieto udalosti by ste tu mali vidieť aj so všetkými posielanými parametrami.

Ako som uviedol vyššie, udalosť campaign_details tu ale neuvidíte. Správnu atribúciu však viete preveriť tak, že samotná návšteva a používateľ by mali mať priradený zdroj a médium podľa tejto udalosti.

DebugView v GA4

Inou možnosťou je špecifický prehľad v GA4 nazvaný DebugView. Teoreticky by ste v ňom mali vidieť všetky udalosti posielané cez Measurement Protocol, ktorým boli navyše priradené parametre:

• debug_mode – nastavený na hodnotu true alebo 1
• engagement_time_msec – nastavený na pozitívny počet milisekúnd, napríklad 1000

Ak vaši programátori splnili tieto podmienky a napriek tomu žiadne údaje v DebugView nevidíte, je to z dôvodu použitia session ID bez histórie. Aby sa vám začali udalosti v DebugView zobrazovať, odporúčam využiť existujúcu session ID, ktorú získate z minulých návštev v GA4, konkrétne extrakciou z cookie. Až následne sa vám začnú udalosti posielané s debug mode parametrom zobrazovať aj v nástroji DebugView v GA4.

Alternatíva: Server-side Google Tag Manager

Inou alternatívou pre zaznamenávanie dát na serveroch je server-side GTM kontajner. Ten preberá informácie zo skriptu v prehliadači a posiela ich bez zmeny na server. Na serveri je kontajner, v ktorom dochádza k ďalšiemu spracovaniu týchto dát. Je možné (podobne ako pri klasickom GTM kontajneri) ich poslať do Google Analytics 4, Google Ads ale aj systémov tretích strán.

Výhody

Výhodou je lepšia kontrola nad dátami, kde v kontajneri môže dôjsť k ich dodatočnej anonymizácii a niektoré údaje ako napríklad IP adresu má k dispozícii iba prevádzkovateľ webu (a teda ďalej nemusí byť zdieľaná s poskytovateľmi iných služieb). Takisto cez server-side kontajner získate o niečo viac dát, lebo dáta sú posielané zvyčajne na vašu vlastnú subdoménu (a tá nie je v zoznamoch rozšírení, ktoré blokujú analytiku). Medzi ďalšie výhody môžeme zaradiť aj zrýchlenie času nahratia stránky (tagy sú spracované na serveri) a flexibilitu pri spracovaní dát.

Aj pri server-side GTM kontajneri je možné kompletné vypnutie frontend dát a presun získavania štatistických dát priamo na server. Pri takomto nastavení je fungovanie veľmi podobné Measurement Protocolu popísanému vyššie, avšak flexibilnejšie z pohľadu dodatočných zmien. Zatiaľ čo pri Measurement Protocole je pre zapracovanie zmien nutný zásah programátora, pri server-side GTM máte stále k dispozícii možnosť dodatočne si dáta spracovať v kontajneri (a poslať ich ďalej).

Nasadenie serverového kontajnera

Služby serverových kontajnerov poskytuje priamo Google cloud alebo externí poskytovatelia ako Stape. Možnosťou je aj lokálne nasadenie na vlastných serveroch cez Docker image.

Pri behu cez Google cloud existujú dva možné spôsoby nasadenia. Prvým je využitie služby Google Cloud Run, druhou možnosťou je služba App Engine. Rozdiely medzi nimi sú skôr technického charakteru a je jedno, ktorú si zvolíte. Počítajte však s tým, že pri nesprávnej alokácii zdrojov (napríklad poddimenzovanie počtu serverov) môže dôjsť k nedostupnosti serverov a tým aj strate dát počas daného výpadku.

Nevýhodou je platba za hosting serverového GTM kontajnera. Očakávajte minimálne 20 eur mesačne pri službách ako Stape a minimálne 70 eur mesačne pri službách priamo od Google. Mesačný náklad na tieto služby vám navyše časom bude rásť, keďže Google účtuje aj poplatky za narastajúci objem dát v dátovom úložisku. Pre väčšie weby s miliónmi požiadaviek (hits) mesačne cena môže dosiahnuť aj niekoľko stoviek eur. Ak sa rozhodnete nasadiť serverový GTM kontajner vo forme Docker image sami, počítajte s nákladmi na nasadenie a bežnú údržbu servera (IT podpora / systémový administrátor).

Príklady využitia záznamu na serveri

Backend tracking je pokročilou formou nasadenia analytiky. Implementovať ho má zmysel iba vtedy, ak ním dôjde k zlepšeniu záznamu dát a aj atribúcie. Pre obohatenie analytických dát o informácie z interných systémov budete vždy potrebovať jedinečný identifikátor. Je možné ukladať si client ID alebo využívať vami používané user ID z interných systémov (ako CRM alebo e-shop).

Uvádzam niekoľko príkladov využitia záznamu na serveri. Je to len malá časť možností a ďalšie využitie závisí aj na dostupnosti dát v interných systémoch.

100 % dát a ďalšie obohatenie dát

Ak chcete mať reportované všetky údaje o transakciách a iných typoch konverzií, server tracking je vhodným spôsobom, ako to dosiahnuť. Ďalšou možnosťou je posielanie doplnkových dát, ak napríklad chcete evidovať udalosti ako odoslanie newslettera či hodnotu košíka (nedokončenej objednávky) v e-shope a podobne. Doplnkovo môžete posielať aj iné špecifické dáta o návštevníkoch, ku ktorým máte súhlas a sú anonymizované – napríklad, že návštevník komunikoval s podporou cez telefón.

Potvrdenie objednávky v offline

Ak objednávka na webe netvorí finálnu konverziu, ale je napríklad len vyjadrením záujmu, v GA4 vám budú chýbať údaje o konverziách / transakciách. Podobne tak nemusíte vedieť finálnu cenu objednávky (nákupu) až do momentu spracovania. Server tracking tvorí vhodnú formu, aby potvrdené objednávky šli automatizovane do GA4 aj s finálnymi sumami predaja.

Interakcia so zákazníkmi mimo digitálu

Ak by ste v budúcnosti chceli robiť segmentáciu na základe interakcií so zákazníkom aj mimo internetu, údaje potrebujete mať dostupné v GA4. Práve serverový záznam umožňuje evidovať udalosti ako volanie na call centrum či výmenu emailov alebo návštevu pobočky. Podobne je možné zaznamenávať stavy, ak dochádza k manuálnemu schvaľovaniu objednávok z online a podobne. Samotný záznam je obohatením dát, v prípade segmentácie pre remarketingové účely potrebujete aj súhlasy s cookies.

Kvalita dát a ďalší rozvoj

Postupný prechod k severovým riešeniam je dlhodobým trendom, keďže na dáta z prehliadačov sa už nedá spoliehať. Dôvodom chýbajúcich dát je zastaralosť niektorých systémov (využívanie third-party cookies, t.j. cookies tretích strán), používanie rozšírení na blokovanie odoslania štatistických údajov alebo nespokytnutie súhlasu na ukladanie cookies (zákon o elektronických komunikáciách).

Pri zázname cez prehliadač (frontend tracking) sa majitelia webov musia zmieriť s tým, že časť dát už nikdy nebudú mať reportovanú. Pri zázname cez server je možné dosiahnuť 100 % reportovaných údajov, avšak za cenu čiastočnej straty kontextu návštevy (a teda atribúcie – správneho určenia zdroja návštevy). Čoraz viac budeme pracovať so semi-unikátnymi identifikátormi, kde dáta nie sú viazané na konkrétneho používateľa / návštevníka.

Iste, systémy ako Bloomreach (Exponea) dokážu vytvárať veľmi detailný profil používateľa spojením údajov počas viacerých návštev aj z drobných interakcií na základe rôznych identifikátorov. Príkladom môže byť emailová adresa prvýkrát zadaná pri prihlásení do newsletteru a použitie rovnakej adresy o mesiac neskôr pri objednávke z e-shopu. Avšak tieto, ani iné podobné systémy nedokážu zjednotiť návštevnícke dáta alebo priradiť kontext pri návštevách z iných zariadení (pracovný počítač vs mobil) alebo prehliadačov (ako Chrome, Safari alebo inkognito mód), najmä ak nejde o hĺbkovú interakciu s webom.

A tak je to dobre. Doba súkromia, o ktorej už v roku 2018 písal kolega Andrej Salner, pokračuje a stále naberá na dôležitosti. Jej potvrdením je aj prelomový zákon o umelej inteligencii Artificial Intelligence Act prijatý v marci 2024 Európskym parlamentom.

Cez záznam na serveri dokážete získať 100 % dát a za ich kvalitu zodpovedajú vaše interné systémy. Ak máte k dispozícii aspoň semi-unikátny identifikátor, viete takýmto údajom navyše priradiť aspoň čiastočný kontext. Na štatistický účel vyhodnotenia sú takéto údaje dostačujúce. Vy budete mať relevantné dáta pre rozhodovanie a návštevníci webu zase chránené súkromie. A to je predsa win-win situácia.