Co a jak udělat, aby byl Váš web pěkně měřitelný

10. Říjen 2011
  •  
  •  

V současné době používám na všech menších projektech Google Analytics (GA). Občas narazím na novou část webu, jejíž konfigurace je obtížná. Tak to totiž končí, když analytik nemluví s vývojáři. Hodně z věcí je sice možno nějak upravit pomocí JS, někdy je to dokonce nutné (např. Drupal a trackování interního vyhledávání). Často je ale nutné takto zavést vazbu na nějaký HTML element či na nějaký text (např. H1 nebo div.ok). Sepsal jsem tedy "Listy pro vývojáře", tedy několik věcí, jak upravit aplikaci tak, aby se analytikovi líbila.

Moje požadavky obsahují toto:

Tagy

Javascript pro měření pomocí GA je třeba umístit na všechny stránky. Pozor hlavně pokud web používá více šablon a když vytváříte další šablonu pro existující web.

Development

Pokud je to možné, je neodesílat requesty na GA z development prostředí.

  • U velkých projektů určitě.
  • U malých projektů je třeba zvážit poměr čas / výkon. V takovém případě je vhodné GA nasazovat až v při spuštění projektu.

Jednostránkové formuláře

Cílové URL jednostránkových formulářů jsou jiné. Příklad:

Form: domena.cz/kontaktni-formular
Po odeslani: domena.cz/kontaktni-formular/odeslano

Pro odlišení stačí přidat i parametr domena.cz/kontaktni-formular?odeslano=1, je pak ale třeba zajistit, aby se v URL neobjevil jiný parametr, resp. neobjevil před parametrem odesláno - nelze reagovat na URL domena.cz/kontaktni-formular?sid=123456&odeslano=1. Pokud budete mít někdy takový případ (odlišení URL pomocí parametru a ukládáte do URL query nějaké další věci), potřeba to konzultovat.

Pokud je opravdu problém nastavit URL po odeslání jinou (např. na magických webech postavených na Drupalu, WP etc.), lze zpráva o odeslání zjistit z toho, že na dané URL je přítomen nějaký HTML elemnet (např. div s class="ok"). Zavádíme tak ale odpudivou vazbu na nějaký HMTL element, kterému když jendou kodér změní class, tak přestane fungovat měření GA. Odpudivé!

Z hlediska GA není problém používat jednu stránku s potvrzením odeslání pro více stejných formů.

Vícestránkové formuláře

každý krok vícestránkového formuláře by měl mít jinou URL. Zde už ale pokud možno NEpoužívat odlišení pomocí query parametrů - zde nesprávné parametry v query stringu mohou rozbít vizualizaci trychtýře a skládat poté celou cestu konverzním trychtýřem je velmi pracné. Tj. NEpoužívat domena.cz/kontaktni-formular?odeslano=1.

Příklad pěkného formu:

  • www.foo.com/shop/prehled
  • www.foo.com/shop/zakaznik
  • www.foo.com/shop/platba
  • www.foo.com/shop/rekapitulace
  • www.foo.com/shop/dekujeme-za-vas-nakup

YouTube

Umíme měřit starý formát videa (embed) a video vytvořené pomocí JS API. Neumíme trackovat iFrame video. Pokud je to možné, preferujte formáty, které umíme měřit.

iFrame má sice také JS API, podle dokumentace je to ale pouze development verze a může se často měnit. GA skript tento formát tedy zatím nepodporuje.

Více subdomén

pokud projekt jede na více doménách / subdoménách, je třeba to dát vědět a zohlednit při nastavení GA. Pokud to nastaveno nebude, jeden člověk při přechodu z www.foo.com na blog.foo.com a zpět na www.foo.com se zobrazí jako 2 návštětvy na www.foo.com a jedna na blog.foo.com. Což není správně...

Přesměrování z domén třetího řádu

Každý trošku slušný developer zajišťuje přesměrování z URL bez www na URL - např. při zadání foo.com dojde k automatickému přesměrování na www.foo.com. Málo který vývojář ale řeší přesměrování na doménách třetího řádu - např. z www.blog.foo.com na správnou URL blog.foo.com. Pokud není toto přesměrování ošetřeno a nevhodně nastavíte platnost cookies, dojde k neustálému přepisování cookies a všechny pageviews přicházející na www.blog.foo.com se budou jevit jako přímé návštěvy. Dle mých zkušeností (s nevhodným nastavením) je jich asi 3 až 5 %.

Závěrem

Těchto několik bodů mi velmi usnadnilo práci. Máte nějaké další poznámky k tomu, co by měli dělat vývojáři pro to, abyste byli spokojení? Dejte vědět!

Přidat komentář