Rubrika: Digitální analytika

  • Jak počítám Opt-In rate cookies lišty

    Opt-in rate cookies lišty vyjadřuje, kolik dostanu souhlasů. Vysoká opt-in rate je fajn, znamená pro mě hodně souhlasů.

    Pokud ji chceme měřit, potřebujeme přesnější definici.

    Proč potřebujete znát opt-in rate

    Nejzásadnější důvod je, že potřebuji vědět, jak moc mohu věřit naměřeným datům. Je poměrně zásadní rozdíl, pokud mám v GA4 30 % dat nebo 70 %.

    Na souhlas udělený na cookie liště jsou navázány také marketingové kódy, které jsou klíčové pro AI algoritmy, které řídí vaše kampaně. Opt-in rate tak ovlivňuje i výkon kampaní.

    Pokud chcete pracovat s cookies lištou a optimalizovat ji, budete potřebovat opt-in rate znát.

    Ach ta definice

    Opt-in rate ale nemá jasnou standardní definici. Na internetu během chvíle najdete minimálně 3 – 4 různé.

    Vždy je to ale poměr, kde je v čitateli počet kliknutí na „souhlasím se vším“. Co je ve jmenovateli úplně není jasné. Počet návštěv? Lidí? Něco jiného?

    Pokud používáte Google Analytics, může vás napadnout počet sessions. Problém je, že pokud nedostanete souhlas na první stránce, počet sessions nemůže správně spočítat – nemáte souhlas vytvářet cookies.

    Můžete použít počet lidí, kterým se cookies lišta zobrazila. Tady ale opět narážíte na to, jak vůbec zjistit počet lidí, když nemáte souhlas.

    Můžete mrknout do reportů, které nabízí přímo nástroje pro cookie lišty. Např. v CookieHub můžete použít počet sessions. Pozor, je to úplně jiná metrika, než sessions v GA4! CookieHub (a jiné cookies lišty) považuje session za načtení skriptu, který stahuje cookies lištu. Ten je pak v prohlížeči uložen 24 hodin, pak se stáhne znova. Takže na webu můžete udělat jen jednu session denně. Navíc nerozlišuje, jestli člověk už vyjádřil souhlas nebo ne.

    Můžete použít počet zobrazení cookies lišty.

    Co si tedy vybrat?

    Co chci od opt-in rate?

    Nejdřív je třeba ujasnit, co od cookies lišty chcete. Typicky je to:

    1. Aby co nejvíce lidí kliklo na „souhlasím se vším“
    2. Aby lidé klikali na „souhlasím se vším“ co nejdříve – ideálně na první stránce. Protože pokud nedostanete souhlas na první stránce, přicházíte o klíčová data pro marketing.

    A tyto 2 požadavky musí opt-in rate popisovat.

    Jak počítám opt-in rate

    Skončil jsem s tím, že opt-in rate počítám jako

    Opt-in rate = souhlasů se všímpočet zobrazení cookie lišty

    Příklady:

    1. Člověk klikne na „souhlasím se vším“ hned na první stránce:
      Opt-in rate = 11 = 100 %
    2. Člověk na první stránce banner ignoruje, souhlas dá až na druhé stránce:
      Opt-in rate = 12 = 50 %
    3. Na webu byli 2 lidé, první banner zamítnul, druhý povolil na první stránce:
      Opt-in rate = 12 = 50 %
    4. Na webu byli 2 lidé, oba banner zamítli:
      Opt-in rate = 02 = 0 %

    Způsob výpočtu používám, protože má dvě výhody:

    1. Výsledná metrika odpovídá požadavkům – zhoršuje se, pokud lidé souhlasy nedávají. Zároveň se zhoršuje pokud lidé nedávají souhlas na první stránce.
    2. Změřit takto opt-in rate je jednoduché – stačí jen počet kliknutí a počet zobrazení. Obojí můžete získat z GA4 napojených na BigQuery, pokud posíláte anonymní pingy. Pro nastavení většinou stačí troška skriptování v GTM.

    Zároveň nepoužívám metriky, které reportuje (jinak) můj oblíbený CookieHub. Protože pokud prozkoumáte její přesnou definici, jsou výsledky zavádějící.

    Co dál

    První kroky, které udělejte

    1. Zkontrolujte si, že opt-in rate na webu měříte
    2. Zjistěte, jaká je definice opt-in rate, kterou měříte (co to vlastně měříte)

    A odteď si vždy dejte si pozor na definici metrik. Opt-in rate může být úplně jiná metrika než opt-in rate.

  • GTM v rozporu s GDPR

    Soud v Německém Hannoveru rozhodnul, že používání Google Tag Manageru (GTM) je v rozporu s GDPR. Tohle rozhodnutí mě zaujalo – protože se netýká měřicí nebo marketingové platformy, ale GTM – který by měl být „nezaujatý spouštěč“ marketingových kódů.

    O co přesně šlo? A jaký dopad to bude mít na měření?

    Celý text rozsudku je na stránkách Dolního Saska. Nejsem právník a k překladu jsem použil Google Translator (německy neumím). Tento článek neberte jako právní rady, ale jako můj pohled na situaci.

    Jak bylo měření webu postaveno

    Přesné řešení není známo, z obhajoby jde ale odvodit:

    • Na webu byl Google Tag Manager, který se načítal hned po spuštění stránky.
      GTM byl nastaven tak, aby podporoval Consent Mode 2. Výchozí nastavení u všech tagů bylo „denied“.
    • Spouštěla se funkční cookie lišta.
      Nejsem si jist, jestli splňovala vizuální požadavky GDPR na vzhled (přítomnost všech tlačítek, jejich velikosti), to ale není předmětem tohoto článku.
    • Marketingové a měřicí kódy se spouštěly vždy až po udělení souhlasu.

    To bych označil jako „běžné nastavení“ podle Consent Mode 2.0 a doporučení Google. A takto je nastavena většina běžných webů.

    Mezi řádky…

    Součástí rozsudku je poměrně rozsáhlá argumentace k tomu, proč stávající řešení nevyhovuje. Zde vybírám několik zásadních věcí (dovolil jsem si je zkrátit a pro čitelnost lehce upravit). A přidávám vlastní interpretaci.

    Rozsudek: GTM není službou výslovně požadovanou uživateli webových stránek, ani neposkytuje přidanou hodnotu ani funkci pro používání webových stránek.

    GTM tedy nelze považovat za technicky nezbytně nutný pro funkčnost webu.

    Rozsudek: …GTM je nezbytný z ekonomických důvodů…, nepřevažuje to ale nad právy uživatelů…

    GTM nejde načítat v oprávněném zájmu. Je otázka, jak by toto soud posuzoval, pokud bychom se nebavili o tag manageru od Google, ale od nějakého jiného poskytovatele.

    Rozsudek: Google Tag Manager je načítán z domény www.googletagmanager.com

    Pokud na internetu cokoliv načítáte odkudkoliv, vždycky při tom přenášíte IP adresu, cookies a informace o zařízení uživatele. To je součástí technologie, na které je internet postaven a toto nejde změnit. Tj. pokud načítáte GTM z domény www.googletagmanager.com, vždy společnosti Google poskytujete osobní údaje. Navíc tím posíláte data mimo EU. A to ještě před udělení souhlasu.

    Rozsudek: Žalobce službu k těmto účelům používá a tvrdí, že samotný Google Tag Manager nenastavuje ani nečte soubory cookie, ale pouze služby spravované tímto nástrojem.

    Podle mého může mít v principu žalobce pravdu, GTM by cookies bez souhlasu číst nemusel. Do jeho kódu ale nevidíte a nemůžete s určitostí tvrdit, jestli to opravdu dělá, nebo ne.
    Při samotném načtení GTM ale k přenosu IP adres, cookies atd. rozhodně dochází.

    Jak tedy nastavovat GTM

    Používat Server-Side GTM (SGTM) nebo Google Tag Gateway? Jiný nástroj? Jak to má být správně?

    To už se v rozsudku bohužel nepraví.

    Jednoduché vložení GTM není v souladu s GDPR. Ať máte nastaven Consent Mode 2.0 nebo ne.

    Pojďme se mrknout na jiné možnosti.

    Google Tag Manager

    Víme, že GTM není technicky nezbytně nutné. Potřebujeme technické řešení, které bude respektovat souhlas (první řešení) nebo ho obhájíme jako oprávněný zájem (ostatní).

    Máte několik možností, jak s GTM pracovat:

    1. GTM z domény www.googletagmanager.com načítat až po udělení nějakého souhlasu
      Před udělením souhlasu skript úplně blokovat. Některé cookie lišty toto umožňují samy. Nebo by vám s tím musel pomoct programátor.
      Respektujeme souhlas uživatele s měřením.
      Za mě OK.
    2. Použití Google Tag Gateway
      GTG vzniklo jako projekt Google a Cloudflare. Technicky jde request jdou z prohlížeče přes Cloudflare, kde přesměrován na endpoint Google. Nikde jsem ale nenašel, že by Cloudflare odstraňovalo původní IP adresu, cookies apod.
      V případě sporu je to podle mě spíše neobhajitelné, tj. za mě spíše NE.
    3. Použití SGTM na Google Cloud
      Pokud hostujete SGTM na Google Cloud Run, stále jdou při načtení GTM uživatelská data na servery Googlu, byť na vaši placenou službu.
      A nejsem si jist, jak by toto hodnotila legislativa, nicméně za mě spíše NE.
    4. Použití SGTM hostovaný mimo Google ekosystém
      Tady předpokládám, že jste schopni SGTM obalit firewallem a máte pod kontrolou, co přesně kam posíláte.
      Za mě spíš OK.
    5. Použít proxy pro GTM (nebo SGTM) a GTAG
      Můžete si udělat vlastní „krabičku“, přes kterou poteče request, očistíte ho o všechno a pak předáte data dál.
      Za mě OK.
    6. Použít nějakou alternativu GTM na vlastním hostingu
      Existuje několik alternativ GTM, a to european-alternatives.eu nebo na omr.com. Pokud použiji alternativní nástroj, ideálně na vlastním hostingu, věřím, že toto může být v oprávněném zájmu.
      Za mě OK.

    Google Analytics 4 a Google Ads

    Bez souhlasu posílají GA4 a GAds ve výchozím nastavení Consent Mode 2.0 na servery Google „anonymní pingy“. Při tom neumisťují cookies. Ale – jak už bylo zmíněno výše – vždy, když posíláte cokoliv na internetu, je vždy přenesena IP adresa uživatele a ostatní cookies platné pro danou doménu. Ve výsledku tedy anonymní pingy nejsou anonymní.

    Co dál

    Pokud jste webový analytik, vezte, že Consent Mode 2.0 není zárukou toho, že máte vše v pořádku. A pokud spoléháte v nastavení jen na toto, pak je možná na čase přehodnotit přístup.

    Pokud jste majitel webu, ověřte si, jak přesně máte měření nastaveno. Dokážete opravdu opravdu danou konfiguraci obhájit, pokud vám přijde z úřadu dopis?

    Potřebujete s tím pomoct?

  • Co to je Server-side měření

    Slyšeli jste už o Google Tag Manager měření (dále jen GTM), které běží na serveru? A víte, že je to ideální způsob, jak zrychlit načítání vašeho webu, zvýšit soukromí vašich uživatelů nebo zlepšit vyhodnocování atribuce u vašich marketingových kampaní? Podívejte se společně s námi, k čemu je server-side měření dobré a jak se liší od klasického měření.

    Jak funguje běžné měření

    Většina webů dnes používá ke správě měření Google Tag Manager (GTM). Kód GTM se vkládá do HTML webové stránky a pokud na web přijde uživatel, pak se stane přibližně toto:

    1. Klientský prohlížeč (tedy prohlížeč návštěvníka webu) si stáhne GTM kód.
    2. Prohlížeč kód GTM zpracuje a spustí další měřicí kódy od jednotlivých platforem (Facebook, Sklik…), do kterých chcete posílat z webu data.
    3. Většina takto spuštěných měřicích kódů jednotlivých platforem si stáhne svůj vlastní javascriptový kód, který si následně najde a zpracuje data, která potřebuje a následně je odesílá do své platformy.

    Některé měřicí kódy navíc čekají na uživatelské akce na webu (třeba stažení souboru, scrollování, odeslání formuláře) a při nich pak spouští další měření.

    Jak bylo řečeno výše, tohle všechno běží v klientském prohlížeči a znamená to pro něj poměrně velkou zátěž. Jen základní měřicí kódy na webech mají velikost minimálně 20 kB za platformu, ale třeba Facebook při načtení webu stahuje i 130 kB dat.

    Zpracování zabere nějaký čas a odeslání zvyšuje objem dat využitých stránkou. Což je problém ze spousty důvodů – zpomaluje to načtení webu (hlavně na pomalejších zařízeních nebo na mobilech může být zpomalení značné), zvětšuje objem stažených dat (uživatelé s mobily s omezeným měsíčním množstvím dat vám za toto nepoděkují), zhoršuje to pozici ve vyhledávání (pro SEO je rychlost jeden z klíčových atributů), měřicí skripty mají přístup ke všem informacím na webu a teoreticky s nimi mohou dělat cokoliv (i pokud jsou to osobní údaje).

    Co je server-side měření?

    Jak už název napovídá, server-side měření je způsob používání GTM, kdy GTM není součástí HTML stránky a neběží v prohlížeči uživatelů. Naopak je spuštěno na nějakém serveru, např. v Google Cloud. A teprve na tomto serveru jsou spouštěny jednotlivé měřicí kódy.

    V klientském prohlížeči zůstává standardní GTM, který odesílá data do serverového GTM. A to teprve řeší odesílání dat do platforem jako jsou Google Analytics, Facebook apod.

    ‍K tomu, abyste mohli spouštět server-side GTM, potřebujete vždy nějaký stroj – buď vlastní, nebo v cloudu. A potřebujete upravit nastavení svého měření.

    Kromě toho, že toto řešení nenutí uživatelův prohlížeč stahovat a odesílat spoustu dat, existuje ještě řada dalších výhod, proč by vás mohlo zajímat. Pojďme si je přiblížit.

    Jaké jsou výhody server-side GTM

    Rychlost

    Rychlost je obecně pro weby velmi důležitá. Google ji roky zmiňuje jako jeden z faktorů, které ovlivňují pozici webu ve vyhledávání. Méně měřicích kódů na stránce znamená vyšší rychlost a tím lepší pozice ve vyhledávání a více návštěvníků.Mimochodem zkuste si otestovat, kolik času zabírá zpracování měřicích skriptů na vašem webu s pomocí PageSpeed Insights – hledejte informace o kódu třetích stran:

    Příklad, kolik času zabírá spouštění načítání měřicích kódů na webu Alza.cz

    Ochrana dat

    Vypisujete-li na stránce citlivá data (např. i telefon, adresu …), skripty třetích stran (Facebook, Sklik …) vkládané do standardního GTM k nim mohou mít přístup. Naopak při měření v serverovém GTM máte jistotu, že se nedostanou k žádným jiným údajům, než které jim explicitně předáte. Jednotlivé platformy totiž komunikují jen s GTM na serveru a nedostanou se k „raw“ datům, která sbírá GTM v klientském prohlížeči.

    A mimochodem – ať chceme nebo ne, platformy vždy vidí minimálně IP adresu uživatele. Používáte-li server-side GTM, platformy se nedostanou ani k ní, pokud jim ji nepředáte.

    Rozumně nastavená Content Security Policy

    Váš web může používat bezpečnostní nastavení Content Security Policy (CSP). To se týká typicky webů, které pracují s citlivými nebo osobními údaji. Toto nastavení říká prohlížeči, z jakých domén (Facebook, Google Analytics, Sklik …) vůbec může stahovat a spouštět skripty. A musíte zde vyjmenovat všechny. Tušíte problém? Pokud používáte množství platforem, může nastavení CSP vypadat takto:

    A když náhodou něco zapomenete aktualizovat, jejda …

    V takových případech je správa všech domén složitá, často se zapomíná něco přidat nebo odebrat. Využitím GTM na serveru se seznam domén zkrátí a vám tedy odpadne část starostí.

    Bezpečnost

    Pokud nasadíte na web nějaký skript, může dělat s webem spoustu věcí. Včetně těch nepěkných jako třeba změnit obsah webu, přesměrovat ho na jiný web, odesílat citlivá data z webu do Číny. Může se to dít záměně nebo třeba nedbalostí. A věřte nám, viděli jsme podobných věcí dost. To se vám se server-side GTM stát nemůže, protože kódy jsou na serveru a k prohlížeči uživatele se vůbec nemohou dostat.

    Validace nebo obohacování dat

    Pokud chcete data nějak validovat a opravovat, máte v server-side GTM rozšířené možnost. Stejně tak je to vhodné řešení, pokud chcete data obohatit např. o marži na konkrétních produktech. Tu typicky nechcete do platforem posílat z klientského GTM, kde k takové informaci může mít přístup kdokoliv.

    Uchování dat pro vyhodnocování atribuce

    Pokud řešíte jako markeťáci atribuci za delší období, může pro vás být přechod na server side výhodou. Některé prohlížeče (Safari nebo Firefox) totiž totiž typicky agresivně mažou po 1 nebo 7 dnech cookies, které nejsou tzv. httpOnly (tedy je zjevné, že jsou určené k marketingovým účelům a né k technickému fungování webu). V rámci server side si takovou cookie uložíte sami a nemusíte se tedy obávat, že byste přišli o data od zákazníků používajících striktnější prohlížeče.

    Měření 100 % dat

    Chcete-li, můžete data do server-side GTM posílat rovnou ze serveru a ne z klientského prohlížeče (viz obrázek níže). Díky tomu můžete mít k dispozici prakticky všechna data.

    Upozorňujeme ale, že v případě zpracování osobních údajů je stále třeba respektovat GDPR a přání uživatele nebýt měřen. Tzn. není vhodné stahováním dat přímo z webového serveru obcházet souhlasy uživatelů.

    Proč ne server-side GTM?

    Využití server-side měření má samozřejmě i nevýhody.

    • Cena – jak je uvedeno výše, k tomu, abyste mohli spouštět server-side GTM, potřebujete vždy nějaký stroj – buď vlastní, nebo v cloudu. Oba přístupy ale stojí peníze.S využitím např. Google Cloud se s cenou budete pohybovat nejčastěji v rozmezí zdarma (pro malinké weby) až do 10 tisíc Kč za měsíc (weby s desítkami tisíc návštěv za den). K tomu musíte připočítat náklady na zprovoznění a složitější úpravy měření, které vyžadují programátora nebo analytika.
    • Nefunguje pro všechny platformy – ne všechny platformy aktuálně server-side měření podporují a vyžadují spuštění v prohlížeči – např. Sklik. Z často využívaných platforem server-side měření podporuje Google Analytics, Facebook, Mailchimp a několik dalších.Takže často skončíte ve stavu, kdy je v serverovém kontejneru pouze část kódů, ostatní zůstávají v klasickém GTM. Ovšem i jen část měření běžící na server side pro vás může dávat smysl – zkonzultujte se svým analytikem.

    Předpokládáme, že do budoucna bude podpora platforem přibývat a server-side bude dávat čím dál větší smysl.

    Dává to pro mě smysl?

    Nedokážete si představit, jestli je to pro vás? Myslíme si, že rozhodně ano, pokud:

    • Odesíláte data do velkého množství platforem (nejčastěji různých účtů GA), což váš web zpomaluje.
    • Potřebujete pracovat s extrémně citlivými daty (např. rodné číslo, číslo občanky …) a chcete je chránit.
    • Spousta vašich návštěvníků používá Safari nebo Firefox, což vám komplikuje dlouhodobější atribuci.
    • Potřebujete ve vyhodnocování operovat s marží produktů.
    • Potřebujete serverové měřicí kódy (typicky pro affiliate platformy), nechcete s tím ale stále otravovat programátory.

    Vidíte se v části případů, ale nejste si pořád jistí, jestli je server-side řešení pro vás?

    Dejte nám vědět! Zkonzultujeme s vámi výhody a nevýhody ve vašem případě a pokud to bude dávat smysl, rád vám s nastavením server-side měření pomůžu.

  • Cookie lišty nakonec i v ČR

    Poslaneckou sněmovnou prošla novela zákona o elektronických komunikacích. Ta přináší zásadní změny v používání cookies na webech. Zákon sice ještě čeká na podpis prezidenta, je ale pravděpodobné, že začne platit od 1. 1. 2022. Co to znamená a co je třeba do té doby udělat?

    Co se přesně mění?

    Dosud byl v Zákoně o elektronické komunikaci uplatňován princip opt-out, což znamená, že uživatele po příchodu na web upozorníte, že používáte cookies, ty ale využíváte hned po jeho příchodu na web. Typicky se jedná o lišty ve smyslu „Web používá cookies, jeho používáním s tím souhlasíte“:

    Nově bude třeba, aby uživatel dal s využitím cookies jasný souhlas –⁠ např. kliknul na tlačítko „Souhlasím“ apod. A teprve poté lze začít využívat cookies a jiné podobné technologie. Takto má souhlas zpracovaný server idnes.cz:

    Poznámky:

    • Zákon se týká i podobných technologií, např. browser storage apod. Nejde tedy pouze vyměnit cookies za jinou technologii, která ukládá nějaká data na počítač uživatele.
    • Zákon se netýká technicky nezbytných cookies –⁠ např. nutných pro přihlašování do služby nebo pro uložení košíku eshopu.

    Co to v praxi znamená?

    Cookies využívá spousta nástrojů na webu. Namátkou jsou to:

    • měřicí nástroje –⁠ Google Analytics, Hotjar, Smartlook,…,
    • remarketingové platformy –⁠ Google Ads, FB pixel, Sklik Remarketing,…,
    • konverzní kódy –⁠ Google Ads, FB pixel, Sklik Remarketing,…,
    • affiliate měřicí kódy –⁠ CJ, AffilBox,…,
    • chatovací nástroje –⁠ SmartSupp,…,
    • videa vložená do webu –⁠ YouTube, Vimeo,…,
    • tlačítka sociálních sítí pro sdílení nebo komentování –⁠ FB like box,…,
    • a další.

    Všechny tyto platformy a nástroje bude třeba upravit tak, aby nevyužívaly cookies bez souhlasu uživatelů. Pokud spravujete web nebo e-shop, téměř jistě vás čeká velké množství práce.

    Mimo samotných technických úprav bude mít ale změna další důsledky. Část uživatelů vám souhlas s používáním cookies neudělí (a můžete předpokládat, že to bude více než 50 %. Což bude mít další důsledky) a část z nich můžeme odhadnout už nyní:

    • Drastické snížení výkonu remarketignových a RTB kampaní –⁠ nebudete moci cílit remarketingové reklamy na uživatele, kteří k tomu nedali výslovný souhlas. Což v praxi může být v lepším případě polovina uživatelů. Provozovatelé se s tím snaží pracovat, např. AdFom představil koncept First-Party ID.
    • Nepřesná data v Google Analytics –⁠ i bez cookies můžete spouštět kód Google Analytics, uživatelé bez souhlasu se ale budou jevit jako jednostránkové návštěvy (bounces). Každá další stránka bude brána jako nová návštěva a nový uživatel. Bude tedy poměrně obtížné vyhodnotit měření konverzí i v rámci sessions, multifunnel bude téměř nemožný.
    • Konec vyhodnocení kampaní v rozhraní marketingových platforem –⁠ počet konverzí zaznamenaných v konverzních kódech (Google Ads, Sklik, Heureka, Zboží,…) bude výrazně zkreslen. Data pro optimalizaci kampaní budou v platformách jen obtížně použitelná.
    • Dopad na affiliate platformy a jejich partnery –⁠ ty používají cookies k připsání provize partnerovi, který konverzi přivedl. Tedy partneři by měli přijít v lepším případě o 50 % připsaných konverzí. U nich předpokládáme přechod na jiný způsob připisování konverzí, např. používání slevových kódů.

    Problém s vyhodnocením kampaní

    Problém s daty budou mít Google Analytics v tom, jak budou vyhodnocovány konverze jednotlivým zdrojům. Představme si situaci, že na web přijde uživatel z Google / CPC, projde 4 stránky, ve kterých na webu nakoupí. To může vypadat nyní nějak takto:

    Nyní (s cookies) vidíme v GA, odkud uživatel přišel i za kolik v rámci dané návštěvy nakoupil. Co se ale bude dít v době souhlasové? Vezměme 2 příklady:

    Uživatel nedá souhlas

    Pro stejný případ, ve kterém uživateli zobrazíme na úvodní stránce cookie lištu, ale uživatel klikne na „Nesouhlasím“:

    Google Analytics posílají na server pingy, které si nesou informaci, jestli jsou se souhlasem nebo bez něj. Pokud nedostanu cookies, celá session se v Google Analytics neobjeví.

    Uživatel dá souhlas až na 2. stránce

    Fajn, co se ale stane, pokud uživatel souhlasí, ale ne hned na první stránce?

    V takovém případě i tak ztrácíme informace o původním zdroji. Souhlas je tedy třeba získat co nejdřív. Pokud uživatel nedá souhlas na první stránce, bude to mít výrazný vliv na vyhodnocení kampaní.

    Google Analytics 4 dokážou částečně mezery v datech zaplnit –⁠ pro práci s konverzemi dokážou část konverzí na základě modelování konverzí odhadem přiřadit jejich zdroji. Data o chování návštěvníků (jaké stránky viděli, flow na webu atd.) budou chybět. V Universal Analytics budou chybět všechna data.

    Co je třeba udělat?

    Čeká vás určitě několik základních kroků

    1. Mapování –⁠ je třeba si sepsat, jaké vlastně používáte nástroje a jaké tyto nástroje využívají cookies. Dále je třeba sepsat si interní procesy, které využívají tyto nástroje, a popsat jak se jich úpravy dotknou.
    2. Nasazení nástroje pro sběr souhlasů –⁠ můžete vybrat nějaký z existujících (většinou placených) nástrojů, nebo vytvořit vlastní.
    3. Technická úprava měření a marketingových platforem –⁠ bude třeba upravit spouštění marketingových platforem tak, aby respektovaly souhlas uživatele. Pokud používáte Google Tag Manager, bude to pro vás jednoduší. Pokud ne, doporučujeme s tím začít.
    4. Technická úprava webu –⁠ typicky se jedná a videa vložená na vašem webu, FB a jiná sdílecí tlačítka apod., která vkládají do webu přímo vaši programátoři. Bude třeba, aby to nedělali. A např. místo videa zobrazili statický obrázek, video pak načítali teprve po kliknutí uživatele.
    5. Úprava procesů –⁠ optimalizujete kampaně? Děláte reporty z Google Analytics? Zamyslete se nad tím, jak toto budete dělat nově.
    6. Papírování –⁠ doporučujeme při této příležitosti revidovat, jestli máte uzavřené smlouvy se subjekty, které zpracovávají vaše data (nebo k nim mají přístup).

    Nečekejte!

    Nařízení platí od 1. 1. 2022 a nastavení cookie lišt není otázkou pár minut práce. Nějakou dobu vám také zabere experimentování a testování, jak budou novým způsobem sbíraná data vypadat a jaké formáty cookie lišty vám přináší největší opt-in rate. Začněte co nejdříve!