Analytics & Zkreslení dat 2 - Implementace a technické problémy

V prvním díle analytického seriálu jsme se podívali na metriky, které se ve webové analytice používají a u kterých může kvůli jejich špatnému chápání docházet ke zmatení či zkreslení pohledu na data.

Nicméně ke zkreslení získaných dat může dojít i nešikovnou implementací a některými technickými omezeními, která změnit nelze (ale je třeba je znát a zohlednit při interpretaci dat).

(Ne)přesná formulace zadání programátorovi

Typicky chcete zaznamenávat odeslání formuláře (třeba kontaktního). Informaci o odeslání vám musí předávat programátor takzvaným zavoláním kousku měřicího kódu (např. Google Analytics) či konverzního kódu (například Google AdWords či Skliku). Je však podstatný rozdíl mezi zadáním:

• „Spusťte měřicí/konverzní kód po kliknutí na tlačítko Odeslat”, nebo

• „Spusťte měřicí/konverzní kód po úspěšném odeslání formuláře”

Správná je druhá varianta. Při prvním zadání často dochází k tomu, že se měřicí kód volá opravdu při každém kliknutí na tlačítko bez ohledu na to, zda formulář obsahuje validní údaje.

Blokování měření

Měřicí kód se nespustí všem uživatelům. Většina prohlížečů má dnes v nastavení volbu „Do Not Track”, která dává měřicím systémům signál, že uživatel nechce být sledován. A podstatná část měřicích systémů tuto volbu uživatele respektuje. Krom toho mohou uživatelé používat k blokování měřicích a reklamních systémů doplňky do prohlížeče, jako je například Ghostery.

Dalším problém je s cookies samotnými. Zvláště cookies třetích stran (3rd party cookies), tzn. cookies, které mohou sbírat data o uživateli napříč více weby, jsou mnohdy blokované v prohlížeči nebo třeba přímo nastavením bezpečnostních politik firemní sítě. Cookies třetí strany se například v Google Analytics používají pro měření demografických ú­dajů.

Lidé vs. zařízení (cookies)

Většina systémů (například Google Analytics) si člověka při první návštěvě webu z určitého zařízení (například prohlížeče Chrome na mém pracovním počítači) označí vlastním vygenerovaným ID. Problém je v tom, že označení (ID) se v každém prohlížeči, který používám, vytvoří jiné. To znamená, že když používám na mobilu jeden prohlížeč, na domácím PC dva prohlížeče a v práci jeden prohlížeč a navštívím ze všech stejný web, budu v přehledech návštěvnosti figurovat jako 4 uživatelé.

A funguje to i opačně – dva lidé mohou samozřejmě používat stejný prohlížeč (ačkoliv to dnes už není příliš časté).

Zmíněné ID uživatele se ukládá do souborů cookies na počítači (mobilu atp.). Pokud jsou cookies smazány, prohlížeč reinstalován a podobně, cookie zaniká a uživatel figurující pod určitým ID tak “umírá”.

Co to může znamenat při pohledu na data? Uveďme si alespoň jeden příklad:

Jsem zákazníkem eshopu XYZ.cz a odebírám newsletter. Ráno jsem na mobilu otevřel newsletter, zaujala mě akční nabídka a prokliknul jsem se produktem ABC. Rozhodl jsem se, že si ho koupím, ale nákup udělám až večer v klidu z domova. Doma jsem šel napřímo na web XYZ.cz a koupil jsem si produkt ABC, který byl promovaný na úvodní stránce e-shopu. Protože jsem na každém zařízení pod jiným ID (jiná cookie) v Google Analytics bude moje aktivita vidět jako:

• Návštěva uživatele A, který reagoval na newsletterovou kampaň, prohlédl si produkt, ale nenakoupil.

• Návštěva uživatele B, který přišel přímo na web, zaujala ho nabídka na úvodní stránce a hned si koupil produkt ABC.

Co s tím?

Hlavní je chápat princip a myslet na něj, až budete vyhodnocovat výkonnost kampaní, které přivádějí uživatele z mobilů, ale ti následně nákup dokončují na desktopu.

V Google Analytics existuje způsob, jak spojit aktivitu jednoho reálného uživatele napříč více zařízeními. Toto řešení však vyžaduje práci programátora a je možné ho uskutečnit jen, pokud jsme schopni nějakým způsobem rozpoznat, že se na obou zařízeních jedná o stejného uživatele. Například, pokud se uživatel jednou přihlásí do e-shopu z mobilu a podruhé z desktopu, je možno tato dvě zařízení v Google Analytics “spárovat” a vnímat jako chování jediného uživatele.

Ztráta informace o zdroji návštěvy

Pro vyhodnocení marketingových aktivit je klíčová informace o tom, odkud uživatel přišel. Zajímá nás, jestli přišel například z naší placené reklamní kampaně, z webu, kde o nás někdo psal, z našeho newsletteru, nebo přišel napřímo.

Běžně nastává několik situací, kdy se „pravý” zdroj návštěvnosti ztratí, nebo je přepsaný nerelevantním zdrojem, který nám neříká nic o efektivitě našich on-line marketingových aktivit.

1) Ztráta UTM parametrů při přesměrování

Takzvané UTM parametry se používají k označení zdroje (v Google Analytics) návštěvnosti zvláště u placených kampaní, newsletterů atp. Odkaz může u firmy XYZ vypadat například takto: www.xyz.cz?…. Řekněme, že jste změnili značku/název firmy z XYZ na na XYZ321 a váš web jste přestěhovali na doménu xyz321.cz. Programátor nastavil přesměrování ze starého na nový web, ale při přesměrování se ztrácejí (zahazují) všechny parametry za otazníkem. Lidé se tedy na správnou stránku dostanou, ale jejich návštěva nebude připsaná newsletteru.

Tento problém typicky nastává při redesignu webu spojeném se změnou URL webu (a nemusí jít ani o změnu domény).

Pohlídejte si, že programátor nastavil přesměrování včetně parametrů za otazníkem. Konkrétní řešení závisí na použitém serveru – pokud váš web běží na Nginx, či Apache, můžete odkázat přímo na tyto návody: Nginx wildcard 301 redirects with query strings a Apache Manipulating the Query String.

2) Ztráta informace o odkazujícím webu při prokliku z HTTPS na HTTP (direct)

V posledních letech mnoho webů přechází na zabezpečený protokol HTTPS. Pokud je váš web ještě na HTTP a někdo se na něj proklikne z webu na HTTPS, nedozvíte se, že se z takového webu prokliknul. Návštěva se bude tvářit jako přímý příchod. A nezáleží na tom, zda používáte Google Analytics či jiný systém. Při přechodu z HTTPS na HTTP nebude informace o referreru (odkazující stránce) dostupná ani v prohlížeči, a nemůže tak být poskytnuta žádnému měřícímu systému.

Můžete tak přijít například i o informace o tom, kolik lidí na váš e-shop přichází i z některých zbožových srovnávačů.

Co s tím?

Optimálně přejděte také na HTTPS (důvodů je určitě víc). Pokud nemůžete hned přejít na HTTPS, ale můžete se s odkazujícím webem dohodnout na úpravě odkazu, doplňte do vašeho odkazu UTM parametry. Tak si označíte zdroj návštěvnost sami a nemusí vás tolik trápit, že se originální informace o odkazujícím webu (referrer) nepřenáší.

3) Připsání konverze platební bráně místo původního zdroje

Měřící kód, který zaznamenává nákup (transakci) do Google Analyticcs, je volán obvykle na děkovací stránce po dokončení nákupu.

Pokud máte váš web, resp. e-shop na HTTPS a na děkovací stránku se nakupující dostává z platební brány, pak platební brána přepíše původní zdroj návštěvnosti (například PPC kampaň). Vy tak ztratíte informaci o tom, kterému reálnému zdroji vděčíte za zaplacený nákup.

V Google Analytics je řešením vyloučení odkazujících domén všech myslitelných platebních bran. Toto řešení detailněji popisuje Pavel Jašek ve svém článku. Další možností řešení je pomocí Google Tag Manageru mazat vždy na děkovací stránce referrer (odkazující stránku).

4) Používání UTM tagování v interních odkazech na webu

UTM parametry přidávané k odkazům (například ?utm_medium=e­mail&utm_source=new­sletter) slouží k označení zdroje návštěvnosti. Nikdy je nepoužívejte pro interní odkazy na webu (odkazy z interních bannerů, sliderů, promo ploch atp.). Je pro to dobrý důvod. Řekněme, že někdo přišel na váš web z PPC kampaně, ale vy máte hned na homepage banner s produkty a odkazy obsahují UTM parametry (ve stylu ?utm_medium=web&ut­m_source=banner). Když se dotyčný proklikne takovým odkazem v interním banneru a následně třeba nakoupí, vy uvidíte jako zdroj návštěvy označení dle UTM parametrů z banneru a nikoliv z PPC kampaně.

Pokud chcete sledovat v Google Analytics prokliky interními plochami a odkazy na webu, použijte události nebo Enhanced E-commerce Promotions.

Falešné konverze

Konverzí nyní myslím dokončení nějaké objednávky na webu.
Tyto konverze jsou obvykle v Google Analytics měřeny jako:

• Transakce (e-shop), nebo

• cíle (všechny typy webů).

Konverze se započítá na poslední stránce objednávkového procesu. Ale co když přijdu na web zítra a v prohlížeči se mi znovu načte poslední stránka objednávkového procesu? Započítá se konverze? To, zda bude druhý den poslední stránka dostupná (zobrazí se), nebo zda se zavolá konverzní kód, záleží na tom, jak je web/e-shop naprogramovaný. Správně by stránka již neměla být dostupná, nebo by neměla při opakovaném zobrazení volat konverzní kódy. Velmi často takto šikovně ale weby naprogramováné nejsou.

Co s tím? Jak zjistím, zda mám falešné konverze? Mohu jim zamezit bez nutnosti úpravy webu programátorem?

Rozdělme to na několik situacíj:

1. Google Analytics – Transakce
   Každá transakce má své jednoznačné ID. Pokud v Google Analytics uvidím v přehledu Výkon prodeje u některých transakcí dva záznamy se shodným ID (a cenou), jde pravděpodobně o tuto situaci. Pokud se problém vyskytujte často, udělejte si testovací nákup a/nebo tento problém proberte s programátorem e-shopu.

2. Google Analytics – Splnění cíle
   Pokud víte, že ke konverzní stránce vede například tříkrokový (třístránkový) formulář, můžete se v přehledu Konverze > Cíle > Obrácená cesta k cíli podívat, zda konverzi (splnění cíle) předcházelo zobrazení konkrétních stránek. Pokud místo předchozích stránek uvidíte jen položku “(entrance)”, jde typicky o situaci, kdy se konverzní stránka zobrazila znovu (třeba po otevření prohlížeče se zapamatovanou stránkou druhý den). Řešení bude obvykle na straně programátora. Je třeba, aby cílová URL (na níž je navázaný cíl) byla dostupná jen uživatelům, kteří bezprostředně před tím prošli všemi kroky formuláře.

3. Google AdWords – Transakce
   Pokud v konverzním kódu zadáte Order ID (typicky stejné číslo jako posíláte do Google Analytics jako číslo transakce) minimalizujete riziko vícenásobného počítání jedné konverze.

Nezapočítání dynamických stránek

Zobrazení stránky se do Google Analytics započte standardně jen při načtení celé stránky. Dnes mnoho webů k zobrazování stránky používá JavaScript, tudíž k načtení celé stránky nedojde a zobrazení se nezměří (a to i pokud se změní viditelná adresa URL stránky).

Další problém nastává s jednostránkovými weby, nebo stránkami, kde je obsah schovaný v záložkách. Tyto problémy a postup řešení detailněji popisuji v článku Dynamické weby a zkreslení návštěvnosti webu.

Podezřele nízká míra okamžitého opuštění

Míra okamžitého opuštění webu (bounce rate) se v Google Analytics spočítá jako podíl: návštěvy se zobrazením jediné stránky*) / všechny návštěvy
(*)přesněji: návštěvy s jedinou interakcí; interakcí je kromě zobrazení stránky například událost).

Pokud je míra okamžitého opuštění menší než 10 %, je to podezřele nízké číslo a měli byste zkontrolovat implementaci měření. A to i v případě, že je pod deseti procenty míra okamžitého opuštění jen u některé z nejčastějších vstupních stránek.

Typickými problémy, které způsobují zkreslení míry okamžitého opuštění jsou:

• Duplicitní měřicí kód na stránce – tzn. při jednom zobrazení stránky se změří 2×.

• Na stránce se bez nutnosti interakce uživatele volá kód pro měření události (který nemá nastaven “non-interaction” příznak – více v nápovědě Google Anaylytics).

Technických záludností bylo pro dnešek dost. V třetím díle miniseriálu se podíváme na atribuci (přisuzování) konverzí různým zdrojů návštěvnosti v kontextu různých reportovacích systémů.

Všechny díly seriálu Analytics & Zkreslení dat:

1. Zmatení pojmů 
2. Implementace a technické problémy
   
3. Atribuce konverzí a rozdíly mezi systémy 

Uložit

Uložit

Uložit