Cookies zná už dnes asi každý uživatel. Především díky nutnosti odsouhlasení jejich využití prakticky na každém webu. Google Analytics používají cookies pro identifikaci uživatele. Parametr cookieDomain pak určuje doménu, pod kterou se má cookie uložit.

Možnosti nastavení

V kódu Universal Analytics existují dvě možnosti, kde lze cookieDomain nastavit. Buď jako nepovinný třetí parametr v příkazu create nebo v poli, kde se dají nastavit další vlastnosti pro danou cookie, jako je například doba expirace.

ga('create', 'UA-XXXXX-Y', 'medio.cz');

ga('create', 'UA-XXXXX-Y', {
  'cookieDomain': 'medio.cz',
});

V GTM je toto nastavení podobné. Jen u tagů Analytics přidáme proměnnou do Fields to Set.

Nastavení cookieDomain v GTM

Automatizace cookieDomain

Výše uvedené příklady nastavení však nejsou úplně ideální, protože jim chybí dynamičnost. To může vést k problémům při špatném nastavení kódu, například při změně domény. Úplné opomenutí tohoto nastavení může vést k dalším problémům. Proto existuje hodnota, kterou můžete použít na každém webu a která toto nastavení automatizuje. Stačí hodnotu konkrétní domény nahradit za auto. Ve výsledku by implementovaný kód měl vypadat takto:

ga('create', 'UA-XXXXX-Y', 'auto');

Tento zápis říká Google Analytics, aby byly cookies nastaveny na nejvyšší úroveň domény. V případě webu blog.medio.cz se cookie uloží pod medio.cz. Kód ale můžu bez problému zkopírovat i na web www.datarestart.cz a cookie se úspěšně uloží pod datarestart.cz. V rámci GA je to dostupné prakticky od začátku. V GTM bylo nastavení velmi dlouho nepoužitelné a bylo přidáno až loni. Výrazně vám to zjednoduší nasazení měření a vyvarujete se následujícím chybám.

cookieDomain a chyby měření

Kam zmizeli noví návštěvníci?

Identifikace uživatele je pro spojování jeho akcí do návštěv klíčová. Žádný hit do Google Analytics neodejde bez ID uživatele. Hit může chybět například, pokud se pokusíte cookie uložit pod jinou doménu než tu, na které se uživatel nachází. Například na blog.medio.cz je možné prostřednictvím cookie uložit domény blog.medio.cz nebo medio.cz. Pokud bych ale třeba cookieDomain nastavil na google.cz, tak se žádné ID uživatele neuloží. U nového měření nebudou GA nebudou měřit vůbec žádná data. A pokud jste změnili nastavení měření, které do té doby fungovalo správně, tak se vám přestanou měřit noví návštěvníci.

Další chybou může být špatné měření mezi subdoménami. Pokud nastavení cookieDomain úplně opomenete, tak se cookies ukládají pod doménu pouze zkrácenou o www. Například tedy uživatel, který přijde na blog.medio.cz a proklikne se na www.medio.cz je pro Analytics úplně novým uživatelem. Přestože měření probíhá rámci stejného účtu. Tato chyba navíc není úplně konzistentní. Pokud by uživatel před návštěvou blogu navštívil www.medio.cz, tak bude pro Analytics tím stejným uživatelem i na subdoméně, protože tam je jeho ID dostupné. Určitá část uživatelů má tedy v rámci Analytics dvě různé a zcela oddělené identity. Hodnoty metrik jsou tak vyšší, než by měly správně být.

Závěrem

Společně s měřícím ID je cookieDomain jedním z nejdůležitějších nastavení. Všechna nová měření jsou dnes již v základu nastaveny na hodnotu auto a měřící kód funguje korektně napříč doménami a subdoménami. Přesto doporučuji nastavení cookieDomain, především u dříve nasazených měřicích kódů, zkontrolovat a případně opravit.

Pozor, pokud používáte GTM. Tam to v základu nastavené není a je nutné postupovat dle výše uvedené sekce Možnosti nastavení a proměnnou Value ve Fields to Set správně nastavit jako auto.

O jaký limit se jedná?

Jde o limit velikosti odesílaných dat, tzv. hitu. Pokud máte na stránce základní kód Google Analytics nebo Universal Analytics, tak sám od sebe na každé stránce odesílá tzv. pageview. Ta obsahuje nejrůznější informace o stránce: její doménu, cestu, název. Současně se posílá celá řada informací dalších, jako rozlišení a barvy monitoru, používaný jazyk, druh prohlížeče a mnoho dalšího.

Dosud se však jednalo o poměrně malé množství dat, které do příchodu Enhanced Ecommerce, nikoho příliš netrápilo. S nástupem Enhanced Ecommerce, v jejich plné implementaci, však přibylo do reportů elektronického obchodu mnoho nových dat, která je potřeba posbírat a odněkud poslat. A tím místem je standardně právě počítač vašeho uživatele.

Aby servery Googlu unesly velký nápor dat, přidal Google do své JavaScriptové knihovny (analytics.js) limit. Díky tomu se po překročení datové velikosti už neodešlou data žádná. Hraniční limit je 8192 bytů. Co to vlastně znamená, a jak se daná velikost dat počítá, si řekneme níže.

Jak se skládají data?

Zaběhnu teď trochu do hloubky webů. Jakmile si uživatel načte vaši stránku, tak se začnou z vašeho serveru stahovat data (HTML stránka). Prohlížeč si je přečte a zjistí, že má stáhnout nějaký JavaScriptový soubor analytics.js (hlavní řídící knihovna Universal Analytics). Stáhne ho a současně s tím, si přímo v HTML kódu té stažené stránky, přečetl, že má spustit nějaký jiný JavaScript. To je ten kus kódu, který vás vždy GA nutí vložit do hlavičky vašeho webu. Tenhle JavaScript nějakým způsobem reaguje s řídící knihovnou, co se stáhla. Ve výsledku posbírá všechna možná data a na pozadí udělá tzv. AJAXový request, kterým všechna posbíraná data odešle na server Google Analytics.

Request je ve své výsledné podobě jen obyčejná URL adresa a vypadá nějak takto:

http://www.google-analytics.com/collect?v=1&t=pageview&dl=http%3A%2F%2Fwww.medio.cz%2F&dp=%2F&ul=en-us&de=UTF-8&dt=Medio%20Interactive&sd=24-bit&sr=1920x1080&vp=1903x955&je=1&fl=19.0%20r0&_utma=162604515.73130048.1442481266.1443001465.1446205687.7&_utmz=162604515.1446205687.7.2.utmcsr%3Dfacebook.com%7Cutmccn%3D(referral)%7Cutmcmd%3Dreferral%7Cutmcct%3D%2F&_utmht=1447063452786&_u=SCCCgAAj~&jid=1801047489&cid=73130048.1442481266&tid=UA-35958405-1>m=GTM-T4DR3S&cd6=86b9b882-f8ec-b02a-7287-5079c980ab23&cd7=0&z=802881888

Trochu to rozdělím. První část je samotná adresa serveru, kam se ta data posílají:

http://www.google-analytics.com/collect

Pak následuje otazníček a za ním už jen sada parametrů a jejich hodnot:

?v=1&t=pageview&_s=1&dl=http%3A%2F%2Fwww.medio.cz%2F&dp=%2F&ul=en-us&...

URL je pořád poměrně nečitelná, zkusím to rozsekat na jednotlivé parametry:

?v=1
&t=pageview
&dl=http%3A%2F%2Fwww.medio.cz%2F
&dp=%2F
&ul=en-us
&...

Nyní je konečně trochu vidět, co se tam posílá, ale pořád to není ono. Je to tím, že URL je encodovaná. To je proces, kdy se z hezké normální URL, stanou ty divné paskvily plné procent s nesmyslnými písmeny a čísly. (%2F = /, %3A = :) Pokud URL dekóduji, vypadá nějak takto:

?v=1
&t=pageview
&dl=http://www.medio.cz/
&dp=/
&ul=en-us
&...

Teď už je URL bez problému čitelná a konečně vidíte, co se vlastně posílá. Parametr t (type) určuje, že posíláme typ hitu pageview. Parametr dl (document location) označuje celou URL stránky, parameter dp (document path) upřesuje konkrétní cestu stránky (to za lomítkem dál, ale včetně lomítka!), ul (user language) označuje nastavený jazyk mého prohlížeče atd.

Tím jsme si ukázali, kde se berou data, a jak se odesílají na server. Nezmínil jsem ale to nejdůležitější – velikost. Zpravidla platí jednoduché pravidlo – 1 znak = 1 byte. Posíláte-li si na vašem webu vlastní dimenze, imprese Enhanced Ecommerce, informace o detailu produktu, sečtěte si délku všech jejich znaků, názvů jejich parametrů a rovnítek (dl, t, dp, ul, …) a de facto to máte.

Pozor! Ten, kdo pozorně četl, si uvědomí ještě jednu věc. Takhle se to úplně počítat nedá. Vzpomeňte na enkodování URL. Co to znamená v praxi? Každý speciální znak (třeba lomítko „/“) najednou není jeden znak, ale rovnou tři znaky (%2F) a tedy i 3 byty. A to pořád není všechno. Chcete mít v GA hezká data s diakritikou? Takové „ě“ po enkodování vypadá takto: %C4%9B. Tedy dokonce 6 bytů.

Jak zjistit limit?

Cesty jsou dvě. Každá z nich má to svoje.

1. Odchytit odchozí HTTP requesty a spočítat jejich počet znaků.
2. Zastavit si GA ve chvíli odesílání a nechat si velikost vypsat.

Zjistit počet znaků

Tuto metodu osobně nedoporučuji, ale pro některé technicky méně znalé, může být jednodušší. Musíte si odchytit odchozí request a zjistit, kolik má výsledná URL znaků. Request si můžete odchytit pomocí různých pluginů nebo programů, ale také přímo v prohlížeči. Každý prohlížeč má tzv. vývojářské nástroje a má je implementované malinko jinak. V Google Chrome, IE a Edge je to klávesa F12. Firefox potřebuje zvláštní rozšíření Firebug. Pro jednoduchost použiji plugin do prohlížeče Live HTTP Headers. Ten je dostupný snad pro všechny prohlížeče a jeho ovládání je vcelku intuitivní.

Pomocí pluginu si načtete kompletní HTTP komunikaci vašeho webu a ve spleti různých URL adres najdete URL směřující na server www.google-analytics.com/collect.  Zde si zobrazíte její detail a zkopírujete její parametry. To následně vložíte do nějakého programu na počítání znaků. No a to je vše, máte velikost vašeho hitu.

Zjistit přímo bytovou velikost

Druhý způsob je metoda, která vyžaduje trochu více úsilí při prvním použití, ale ve výsledku je mnohem rychlejší. Ukážu vám, jak to dělám v prohlížeči Google Chrome, v ostatních prohlížečích, by to mělo být velmi podobné.

Začnete tím, že si otevřete vaši stránku a vývojářské nástroje, kde si překliknete na záložku sources. V mém případě otevírám www.medio.cz a vývojářské nástroje v Chromu = klávesa F12 + překlik na záložky Sources/Zdroje. Dále v levém sloupci všech scriptů otevřete adresář www.google-analytics.com a klinete na soubor analytics.js. V prostředním sloupci by se vám měl zobrazit jeho obsah. Toho se nemusíte děsit. Klikněte v levém dolním rohu prostředního sloupce na ikonku složených závorek, aby kód „zkrásněl“.

Pak klikněte kamkoliv do kódu a zmáčknete kombinaci kláves pro vyhledávání (Ctrl + F). Do vyhledávacího pole vepište 8192. Kód by vám měl přeskočit a vypadat cca takto (trochu se lišit může).

Najděte řádek, kde se porovnává číslo 8192 v nějaké podmínce (else if (8192 >= b.length)) a pak ho označte kliknutím na číslo řádku. U mě je to momentálně řádek 215. Pozor na to, že ta podmínka může mít časem trochu jiný tvar, vzhledem k tomu, že se kód Google Analytics aktualizuje. Udělejte reload stránky. Pokud se stránka načetla bez jakékoliv změny, znamená to patrně, že velikost vašich dat nedosahuje ani prvního limitu 2036 bytů, který je nastavený jen z určitých technických důvodů a nemusí vás nijak trápit. Takže můžete být úplně v klidu a nic neřešit.

Pokud se stránka zasekla a vyskočila na vás zpráva typu „Paused in debugger“, znamená to, že velikost vašich dat překročila první limit a JavaScript došel až k bodu, kdy velikost porovnává s druhým limitem. V takovém případě se právě zastavili na tzv. breakpointu, který jste před chvíli vytvořili kliknutím na číslo toho řádku. Abyste zjistili velikost dat, přepněte se do záložky console, kam napište to, s čím se porovnává hodnota 8192. V mém případě b.length a dejte enter. Ihned vám to vrátí číslo, což je skutečná datová velikost odesílaných dat.

Pokud se nad tím zamyslíte a trochu více si v tom pohrajete, tak zjistíte, že tento postup opět nedělá nic jiného, než že počítá znaky ve výsledné URL. Pro mě osobně je ale pohodlnější hlavně z toho důvodu, že pokud se chci podívat na další stránku, tak ji prostě otevřu a breakpoint stále funguje, takže nemusím znovu odchytávat requesty, hledat, kopírovat, atd. Navíc obvykle funguje i napříč weby, takže pokud nechcete sledovat limity GA i u konkurence, nezapomeňte na konci ten breakpoint zase vypnout – opět kliknutím na číslo řádku.

Znáte ještě nějaký další způsob? Podělte se s námi!

Dosud jste byli v Google analytics omezeni jen na ty metriky, které standardně sledoval a nabízel systém sám za sebe, případně na vaše vlastní metriky, do kterých jste si ale museli sami natvrdo nahrát jejich hodnoty.

Teď přibývá třetí typ: počítané metriky (v angličtině Calculated Metrics). Jak už název napovídá, můžete si definovat svou vlastní novou metriku tak, že definujete nějaký vzoreček, kterým spočítáte její hodnotu z ostatních již existujících metrik. A tu pak přímo použít ve svých reportech.

K čemu se počítané metriky hodí?

Díky počítaným metrikám si najednou umíte přímo v reportech zobrazit spoustu čísel, které tam dosud chyběly. A když jste s nimi i přesto chtěli pracovat, tak jste si je museli spočítat v hlavě nebo nějakém nástoji mimo Google Analytics.

Když jste třeba potřebovali dostat ukazatel ARPU (Average Revenue Per User), tedy průměrné tržby na jednoho uživatele, museli jste si do jednoho sloupce zobrazit počet uživatelů, do druhého tržby. A pak si je mezi sebou někde v hlavě vydělit. Anebo si ty dva sloupce vyexportovat někam ven z Google Analytics a vydělit si je mezi sebou třeba nějakým vzorečkem v Excelu.

Teď si prostě založíte počítanou metriku, tedy další „sloupeček“ v tabulce, v jejíž definici jenom zadáte, že se má spočítat jako tržby děleno počet uživatelů, a je to:

Obdobně velkým problémem dosud bylo, že jste si sice mohli do Google Analytics posílat refundace, tedy storna a vratky jednotlivých transakcí. Ale ty se evidovaly zvlášť, zcela odděleně od původních tržeb, takže jste pak bez složité segmentace nikde neviděli v jednom sloupci výsledné tržby očištěné právě o storna či vratky. Dnes si stačí založit počítanou metriku „Čisté tržby“, kterou spočítáte jako „Tržby – Refundace“.

Pokud znáte svoji průměrnou maržovost a máte takový sortiment, kde je maržovost napříč objednávkami podobná, například 15 %, tak si můžete založit metriku „Marže„, kterou necháte spočítat jako „Tržby * 0.15“.

A když už budete mít v Google Analytics hrubou marži (ať už zmíněným vynásobením průměrnou maržovostí, nebo prostě díky tomu, že si posíláte svou skutečnou marži společně s každou uskutečněnou objednávkou přes Measurement Protocol), tak si hned můžete přes Data import posílat do Google Analytics i nákladová data. A nakonec si definovat vlastní metriku „Zisk“ jednoduchým vzorečkem „Marže – Náklady“.

A od zisku je už jen krůček třeba k návratnosti jednotlivých reklamních kanálů, tedy k počítané metrice „ROI„, definované vzorečkem „(Zisk – Náklady) / Náklady“. Vítejte do světa skutečné analytiky.

Tohle bylo jen několik málo příkladů, možností je neomezeně a snad už chápete mé nadšení, protože počítané metriky opravdu posouvají Google Analytics zase do další ligy.

Jak počítané metriky založit?

Celý postup je popsaný v dokumentaci Google Analytics, takže jenom stručně bodově:

• Počítané metriky se nastavují pro každý výběr dat zvlášť. Takže nejprve v administraci svého Google Analytics účtu vyberete napravo požadovaný výběr dat.
• Pod ním otevřete sekci „Počítané metriky“ a kliknete na tlačítko „Přidat počítanou metriku“.
• Ve formuláři pak už zadáváte definici metriky jako takovou:
  • Běžné jméno, pod kterým bude viditelná v reportech
  • Externí jméno, pod kterým bude dostupná zejména v různých API
  • Datový typ – celé číslo, desetinné číslo, čas, procenta…
  • Samotný vzoreček, ve kterém kromě ostatních existujících metrik můžete používat základní aritmetické operátory + – * /, dále pak závorky pro vyznačení priorit a konstantní čísla, včetně desetinných.

To je celé. Metrika se vám okamžitě objeví v nabídce mezi ostatními metrikami. Primárně se očekává, že ji budete používat při sestavování vlastních dashboardů a zejména vlastních reportů.

Další poznámky k počítaným metrikám

Otázka, která vás asi hned napadne, proč nevidíte počítané metriky ve svých Google Analytics. Dá se očekávat, že novou funkci bude Google zapínat jednotlivým účtům postupně v následujících týdnech až měsících. Takže trpělivost, i na vás určitě brzy dojde.

Nepříjemné jsou limity, které Google na počítané metriky uvalil. Aktuálně je počet omezen na nejvýše 5 v jednom výběru dat, pokud používáte standardní Google Analytics zdarma, takže bohužel je nutné hodně šetřit a rozmýšlet, co vlastně opravdu nutně potřebuji vidět. V placených GA Premium je pak počet navýšen na 50 metrik na jeden výběr dat.

Google bude brzy rozšiřovat možnosti vzorců počítaných metrik o další operátory respektive funkce. Z tohoto pohledu to asi ještě dlouho bude slabota, odhadoval bych možná tak nějaká sčítací, průměrovací, min a max funkce a šmytec. Navíc mi přijde, že Google k syntaxi vzorců nepřistupuje nijak systematicky a promyšleně, spíš dost nahodile, když někoho napadne, co by to taky ještě mohlo nabízet a počítat. Zkuste si to porovnat s propracovanými a promyšlenými jazyky pro definici metrik, jak je známe z jiných analytických nástrojů, jako je třeba MAQL.

Počítané metriky se počítají on-the-fly v reálném čase, tedy v okamžiku, kdy si necháte vypsat každý jeden report. Což je na jednu stranu hodně užitečné, protože jsou k dispozici hned po jejich vytvoření a fungují i zpětně na jakákoliv historická data. Na druhou stranu budou zejména v standardních gratis Google Analytics ještě víc zpomalovat počítání a vykreslování reportů, nemluvě o riziku dřívějšího vzorkování.

Související články

• Google support: Calculated metrics
• 25 Calculated Metrics for Google Analytics

Jak to chodí na MeasureCampu

MeasureCamp je velká událost pro všechny nadšence do digitální analytiky. Slouží především k networkingu, výměně zkušeností a znalostí, poznávání lidí nebo nových cest ke zkušenostem.

Jde o (ne)konferenci či chcete-li barcamp. Není předem daný žádný pevný program, řečníkem může být kdokoli z účastníků, kdo má k webové analytice co říci. Harmogram se sestavuje přímo na místě společně na začátku dne z témat, která jednotliví návštěvníci nabídnou.

MeasureCamp se koná o víkendu. Každý z účastníků je tak na konferenci dobrovolně ve volném čase. Všechni, s kým se na MeasureCampu potkáte, jsou tak lidé, kteří webovou analytiku nebo online marketing berou vážně a je jim víc, než jen pouhou prací.

Žádná teorie. Většina účastníků není profesionálnimi speakery, ale jsou prefesionály ve webové analytice se spoustou praktických zkušeností, o které se chtějí podělit.

MeasureCamp je zdarma. Organizování celé (ne)konference je hrazené ze sponzorských darů partnerů, kteří věří v dlouhodobé vzdělávání a rozvíjení komunity okolo webové analytiky. Nebojte se, nečekají vás žádné prvoplánovitě prodejní prezentace.

Chcete-li navnadit ještě více, přečtěte si zápisky Adama Šilhana ze čtvrtého, pátého a šestého londýnského MeasureCampu.

Přijďte na pražský MeasureCamp

První český MeasureCamp se uskuteční v sobotu 12. září 2015 v krásných prostorách společnosti Etnetera.

Přihlásit se můžete na webu konference a vstup je zcela zdarma. První série lístků bude uvolněna již dnes a kapacita je omezena, takže s registrací určitě neváhejte!

Úroveň celé akce předznamenávají i jména organizátorů, kteří za pražským MeasureCampem stojí: Petr Havlík z Optimicsu, Honza Tichý a André Heller z Media, Lukáš Čech z Etnetery, Michal Pařízek a Jarda Vojna z Avastu, Pavel Jašek z Tipsportu, Adam Šilhan z Igloonetu nebo Roman Appeltauer z Digmato.com.

Aby vám neunikla žádná důležitá informace, navštivte oficiální web, sledujte twitter @MeasurecampCZ a přihlaste se k MeasureCamp newsletteru.

Staňte se partnerem

MeasureCamp je nevýdělečná akce, všechny náklady spojené s jeho organizací jsou pokryté příspěvky dobrovolných partnerů. Staňte se jedním z nich a pomozte nám český MeasureCamp uskutečnit. Ozvěte se nám!

Těšíme se na setkání na MeasureCampu!

Kdy a kde:

Pondělí 27. dubna
Konferenční centrum City
sál Empiria
Na Strži 65/1702
Praha 4

Každoročně začátkem léta pořádáme konferenci SEO restart. Ta si už ve světě českého digitálního marketingu svou pozici a jméno vydobyla. SEO a internetový marketing je ovšem jen jednou tváří Media. Naše druhá tvář se nese ve znamení webové a datové analytiky. A protože nás data baví a chtěli jsme se pustit do něčeho nového, rozhodli jsme se připravit i druhou konferenci zaměřenou právě na analytiku: DATA restart.

Čeká vás nabitý celodenní program. Se svou přednáškou vystoupí například Tomáš Čupr, Petr Havlík, Jan Tichý a dalších pět potvrzených řečníků. O posledním, devátém, speakerovi právě probíhá veřejné hlasování. Kompletní seznam přednášejích a témat naleznete na webu datarestart.cz.

Kromě klasických přednášek jsme se rozhodli konferenci obohatit o blok šesti ignite přednášek. Pokud byste náhodou nevěděli, co to ignite je, jedná se pětiminutovou přednášku s dvaceti slidy nekompromisně se přepínajícími přesně po patnácti sekundách. Rozhodně se tedy nemusíte bát, že byste u nich usínali. Program ignite bloku brzy zveřejníme, zatím, alespoň na ochutnávku, se můžete těšit na Roberta Němce s tématem Efektivní marketing bez výzkumu je jako orgasmus bez sexu.

Celou konferenci večer uzavře společná afterparty v blízké restauraci Coolna.

Vše podstatné se dozvíte na oficiálním webu datarestart.cz. Aktuální průběžné informace pak můžete sledovat na facebookové události konference.

Těšíme se na vás!

Registrujte se právě teď!

Obecně na úvod

U nás používáme primárně angličtinu. Velká většina názvů má více slov, a protože GTM neumožnuje v názvech prakticky žádné speciální znaky, jako oddělovač používáme spojovník s mezerami “ – „. V některý případech využíváme ještě standardní javascriptovou tečku „.“. Všechny ty to případy vám dále na příkladech vysvětlím, ale ještě než se do toho pustím, je důležité, abyste si uvědomili, že každá pravidla mají své hranice. Existují případy, kdyby byl název dle pravidel tak šílené dlouhý a nepřehledný, že je lepší pojmenovat ho trochu více lidsky. Efektivita stojí vždy nad přesností.

Tagy

Obecně se ve všech tazích na začátku píše jejich typ. Následuje pomlčkový oddělovač a případný podtyp. Jako poslední přidáváme nějaké upřesnění, abychom věděli, k čemu daný tag patří, resp. stručný zápis, kde se spouští. Tagů existuje velká spousta druhů, tak jsme si je rozdělili do několika skupin:

• Analytics Tagy
• Ostatní předdefinované tagy
• Custom HTML tagy

Analytics tagy

Tyto tagy mají trochu odlišnou konvenci od ostatních tagů. Po zkušenostech u nich upřednostňujeme upřesnění před podtypem. Je to proto, že Analytics tagů se obvykle nasazuje řádově nejvíc a nejčastěji se s nimi nějak manipuluje. Pro jeden měřený účet máme někdy tři, jindy třeba devět tagů. Narozdíl od Adwords, kde máme obvykle třeba dva. Na začátek tedy napište jejich typ (GA/UA). Pokud máte v kontejneru více než jeden analytics účet nebo property, využijte jejich názvy jako další součást názvu tagu (právě to upřesnění):

• UA – Hlavní weby – Blog (Účet Hlavní weby a property Blog)
• UA – Global (Účet Global  s jedním property, proto ho neuvádím vůbec.)

Následně napište podtyp (Pageview, Ecommerce/Transaction, Event, Social, …) a další upřesňující hodnoty, jsou-li třeba:

• UA – Hlavní weby – Blog – Pageview (Obecná pageview pro měřící kód blogu.)
• UA – Global – Event – header.logo (Konkrétní označení události pro Global účet.)
• UA – Pageview (Základní tag pro universaly, pokud v kontejneru nemám jiné měřící UA kódy.)

Každé slovo začíná velkým písmenem. Neplatí to pouze tehdy, objeví-li se v názvu skutečná hodnota. Typicky výše zmíněný header.logo (Jeho význam není v tomto článku důležitý.)

Ostatní předdefinované tagy

Tyto tagy rovněž uvozujte typem (Adwords, Listener, …). Pak konečně následuje to upřesnění. Obvykle to znamená umístění kódu z hlediska hostname nebo URL – Místo, kde se kód má spustit. Umístění nerozepisujte do detailu (To se dělá v definici pravidla. Zde jde pouze o základní rozlišení, co nejobecnější možnost.) Pokud spouštíte tag úplně všude (All pages), nebude mít žádné upřesnění.

• Listener – Link Click (Posluchač pro kliky na odkazy, All pages)
• Listener – Form Submit (Posluchač pro odeslané formuláře, All Pages)
• Adwords – Remarketing – Blog (Adwords Remarketing kód pro sekci Blog. Alternativní zápis je Adwords – Remarketing – blog.medio.cz. Záleží na složitosti účtů a webu. Většinou stačí první varianta.)
• Adwords – Conversion – Akademie (Adwords konverzní kód pro objednávku školení.)

Custom HTML tagy

Pro tyto tagy platí vesměs stejná pravidla jako pro ty předdefinované. Uvozujte typem, pokračujte podtypy a nějakým upřesněním pozice.

• Adform – Global tracking Point – news.medio.cz
• Etarget – Remarketing
• FB – Remarketing
• Gemius
• Gemius – Heatmaps

Jednoduše řečeno jde o přehlednost a pochopitelnost. Pokud to název splňuje, je to v pořádku.

Pravidla

Event – ga.event (Spouštění obecných eventů s předurčenými hodnotami v dataLayeru. Toto pravidlo se spustí jakmile se v dataLayeru objeví ‚event‘: ‚ga.event‘). Názvy pravidel jsou velmi jednoduché a striktní. Obsahují naprosto přesně svůj obsah. (Jaké makro nabývá jaké hodnoty.)

• Event – header.logo (Spouštění konkrétnějších eventů pevně danými hodnotami v GTM. Rozdíl mezi tímto a předchozím pravidlem spočívá pouze ve využitelnosti, o které povím něco v jiném článku. Jmenné konvence jsou identické.)
• URL – All pages (Předdefinované pravidlo. Musíte se s ním smířit, protože dokud GTM nezačne podporovat speciální znaky v názvech, tak lepší alternativu pojmenování asi nenajdeme. Jinak bych ho přejmenoval na URL – .*)
• Hostname – akademie.medio.cz (Zde asi není, co vysvětlovat)
• Event – gtm.formSubmit (Obecné pravidlo formulářového posluchače, v reálu prakticky nevyužitelné, protože vždycky chceme specifikovat konkrétní formulář nebo odkaz apod. -> viz Submit – id.objednat)
• Submit – id.objednat (Pravidlo pro odeslání formuláře s objednávkou. Navěšené na posluchače. Nemusíte specifikovat složité pravidlo typu Event – gtmFormSubmit, Element id – objednat. Místo toho vytvoříme typ Submit, který sám o sobě je jasný, a doplníme upřesněním, kterou část elementu připojujeme. Stále doufám, že budou jednou ty speciální znaky povolené a fungovat. V tomhle případě by to velmi radikálně usnadnili. Podobu s nimy (alternativy) uvádím v závorkách na konci.):
  • id. – Element ID (Submit – #objednat)
  • class. – Element Classes (Click – .box – tahle alternativa funguje i dnes)
  • url. – Element URL (Link Click – ?.*\.pdf)
  • target. – Element Target (Link Click – _blank)

Výše uvedená pravidla jsou jednoduchá. U složitějších pravidel to nazvat takhle jednoduše nelze. To je přesně ten případ, který jsem zmiňoval na začátku. Místo nějakých dlouhých názvů typu:

• Event – gtm.linkClick, ElementClasses – button, Element URL – medio.cz-verejnaskoleni-individualni-skoleni-zdarma, URL – medio.cz-verejna-skoleni

by se to dle výše uvedených pravidel dalo zkrátit jako:

• Link Click – class.button url.medio.cz-verejna-skoleni-individualni-skoleni-zdarma, URL – medio.cz-verejna-skoleni

To je však stále dost nepřehledné a v seznamu pravidel je to pro vás prakticky nepoužitelné. Proto je asi lepší využít nějakého stručného jasně popisného slovního popisu. Bohužel vám nikdy nedá úplnou přesnost, ale stejně budete muset takto napsané pravidlo pravděpodobně otevřít, abyste se podívali, co představuje. I tak je dobré alespoň zachovat spouštěcí typ. Ve výsledku by to mohlo vypadat tedy takto:

• Link Click – Button Individuální Zdarma

Někdy je těžké tuto pomyslnou hranici mezi efektivitou a přesností najít, ale vždy tam ta hranice být musí.

Makra

1st Party Cookie – cookie.název („datový typ“ cookies označuje v makrech, že se jedná o cookies, aby se nám nepletla s datalayerem a JS proměnnýma. Po tečce následuje její název). Google Tag Manager některá makra předvytváří. Jejich názvosloví je lehce odlišné od toho, které používáme u nových maker proto si je buďto přejmenujte nebo se s nimi smiřte a zvykněte si na ně, není jich tolik. Základním pravidlem názvů je camelCase, tedy velbloudí notace. To samozřejmě vychází z javascriptu, ve kterém rovněž vytváříme dataLayer a většinu tagů. První písmeno prvního slova je malé, první písmena ostatních slov jsou velká. Toto pravidlo se různě doupravuje podle typů maker:

• Auto-Event Variable – tato makra už jsou většinou předdefinovaná pomocí nešikovného oddělovače „mezery“. Můžeme je také přejmenovat na tečkovou notaci (element.url, element.id, atd..) nebo se s tím prostě smířit. element je opět „datový typ“.
  • element
  • element url
  • element classes
  • element id
  • element target
• Constant String – konstanty pojmenováváme velkými písmeny s oddělovačem mezerou (UA ID, GA ID, MEDIO.CZ)
• Container Version Number – version.77
• Custom Javascript – Vždy vrací nějakou hodnotu, takže se jedná vlastně o standardní getter. (getRMKPageType, getUAID, …). V případě, kdy vrací boolean využijte klasicky „is“ (isCrossDomain, …)
• Data Layer Variable – Nejpoužívanější typ maker. Uvádíme datový typ dl. (dl.pageType, dl.visitorId, …)
• Debug mode – isDebugMode – vrací hodnotu stejně jako Custom javascript.
• DOM Element – id.identifikator (rozlišujeme pomocí ID, takže datový typ id.)
• HTTP Referrer – hodnoty referreru
  • referrer
  • referrer.protocol
  • referrer.hostname
  • referrer.port
  • referrer.path
  • referrer.query
  • referrer.fragment
• JavaScript Variable – js.název (datový typ js označuje v makrech, že se jedná o javascriptové proměnné, aby se nám nepletla s datalayerem a cookies. Po tečce následuje její název)
• Lookup Table –vrací hodnoty, platí pro ní totéž co pro Custom Javascript.
• Random Number – randomNumber
• URL – jednotlivé hodnoty
  • url
  • url.protocol
  • url.hostname
  • url.port
  • url.path
  • url.query
  • url.fragment

A to je vše. Samozřejmě najdete mnoho případů, kdy konvence nebudou úplně ideální a budete si je muset přiohnout. Například pokud máte analytics s jedním účtem a mnoha properties nebo využíváte stejně pojmenované cookies s jiným významem přes několik různých webů. Nebo jednoduše nepotřebujete názvy dělit na tolik skupin, datových typů, apod. V podobných scénářích je nutné si doupřesnit nebo naopak zrušit nějaká pravidla a tyto konvence brát pouze jako základ. Mějte na paměti, že to nejdůležitější je, aby se váš tým neztrácel, věděl a mohl efektivně pracovat.

Vzorkování znehodnocuje data

Před nějakou dobou psal Honza Tichý o tom, jak si je vysegmentovat přímo v reportech Google Analytics. To je snadná a rychlá cesta, kterou můžete použít kdykoliv bez nutnosti předchozího nastavování. Daleko lepší ale je odlišit si cenové srovnávače už v okamžiku změření návštěvy pomocí pokročilých filtrů. Zejména kvůli vzorkování neboli samplingu. Porovnejte sami, se kterými daty byste pracovali raději:

SEGMENTACE: Pokud na svém webu máte vyšší návštěvnost, využívají Google Analytics sampling – pro rychlejší výstup počítají reporty jen z části návštěvnosti. Tento přehled byl vytvořen na základě 1,92 % dat. Prezentovaná čísla jsou tak zatížena obrovskou statistickou chybou a jejich výpočet je zdlouhavý.

FILTRY: Data, která mají najednou kontext a lepší zpracování. 8 % návštěv ze srovnávačů cen generuje 19 % objednávek. Na pár kliknutí se hned dostanete k přehledným reportům tak, jak je potřebujete vidět. Nedochází k žádné statistické chybě ani čekání na výpočet.

Všechny zbožáky pod stejné médium

Dimenze Médium kampaně slouží v Google Analytics k označení základních typů návštěvnosti. Lze tak od sebe navzájem odlišit návštěvníky z fulltextů, placených kampaní, přirozených odkazů nebo přímou návštěvnost. Obdobně je dobré oddělit i všechny návštěvy ze zbožáků pod nějakou souhrnnou hodnotu, například medium=product.

V sekci Správce si u svého konkrétního view otevřete volbu Filtry. Vyberte nový filtr a pojmenujte ho.

TIP: My ho označujeme jako Medium pro zbožové srovnávače.

Pak zvolte Vlastní filtr > Pokročilé. V poli A označte volbu Zdroj kampaně a do příslušného pole zkopírujte následující regulární výraz:

((^|\.)(artikul|b2bc|elektrus|eshop-katalog|foxter|heureka|koupis|mojse|monitor|shoops|taxa|vybereme|zaza|shop\-mania|pricemania|cochces)\.cz)|cen[ayou]|koupe|koupis|levn|naa?kup|obchodu|porovn|setri|shop(y|alike)|slevu|srovn|zbozi|shopalike

Nevadí, pokud zápisu nerozumíte. Stačí prosté copy-paste. Z lišty v konstruktoru následně vyberte Médium kampaně. Do textového políčka napište vámi zvolený název pro zbožové médium. My využíváme jednoduše anglické product.

A už jen sbíráme data

A to je celé. Poté už pouze necháte Google Analytics sbírat data. Změna se promítne až do reportů odteď dál, zpětně se bohužel nic nepřepočítává.

Všechna čísla za všechny zbožové srovnávače pak velice snadno najdete sdružené pod společné médium product v reportu Akvizice > Veškerá návštěvnost.

Přečtěte si také navazující návod, jak s pomocí filtrů elegantně sjednotit desítky řádek Heuréky do souhrnného reportu, aniž bychom přišli o jakákoliv podstatná data.

 Související články

• Romana Velflová: Chytře na mobilní návštěvnost z Heuréky
• André Heller: Elegantní sledování návštěvnosti z Heuréky
• Jan Tichý: Snadná segmentace návštěv ze zbožových srovnávačů
• OXy Online: Nový ceník prokliků na Heuréce – sáhneme si hlouběji do kapsy?
• Mergado: Co čekat od nového ceníku Heureky
• Heuréka: Ceník prokliků
• Adam Jurák: Jak nám nesou zbožáky a proč?

Aktualizováno ke dni 21. 7. 2015

Google Analytics ve svých výkazech zdrojů návštěvnosti nepracují úplně správně s českými vyhledávači. Do reportu neplaceného vyhledávání padá vlastně jen Seznam a Google, případně shodou náhod ještě pár dalších, které se ale schovají pod nic neřikající „search“.

Zbylé vyhledávače či zbožáky pak Google Analytics vůbec nepoznají. Řadí je chybně mezi běžné odkazující stránky do reportu „Odkazy“. A hlavně z nich nijak nereportují dotazy uživatelů.

Upravené skripty v klasických Google Analytics

Ve starých Google Analytics bylo pro přidání dalších vyhledávačů nutné upravit měřicí kód ve vašem webu. Konkrétně pro to sloužil příkaz _addOrganic.

Protože to byl poměrně častý případ a bylo zbytečné, aby si to psal každý zas a znovu sám, existovala řada hotových předpřipravených skriptů. Asi nejvíc se z nich v Česku rozšířil můj upravený asynchronní kód.

Jak na české vyhledávače v Universal Analytics

Dnes ale už dost pravděpodobně používáte Universal Analytics, tedy novou generaci Google Analytics. Tady je postup zcela jiný. Většina nastavení se tu přesunula z měřicího kódu přímo do grafického rozhraní. Takže místo „programování“ si všechny potřebné změny prostě „naklikáte“.

Vše najdete v sekci Správce > Služba > Údaje o měření > Zdroje z neplaceného vyhledávání:

Přidání fulltextových vyhledávačů do Google Analytics

 
Protože se vše musí pokaždé klikat pracně ručně, je účelné vkládat jen ty nejdůležitější vyhledávače a zbožáky, kde to má význam. Není přitom nutné zadávat vyhledávače, které už Google zná sám. Co tedy při revizi nastavení Universal Analytics přidáváme my?

Existuje samozřejmě celá řada dalších vyhledávačů a zbožáků, které je určitě možné také přidat. Návštěvnost z nich přicházejících je ale zpravidla tak mizivá, že to nemá valný smysl.

Pomůžeme vám!

Bojíte se, že nastavení vašich Google Analytics je tristní a nástroj vám kvůli podobným nedostatkům zobrazuje zcela špatná čísla? Tušíte, že máte v měření velké rezervy, ale nevíte, kudy začít? Ozvěte se nám, uděláme kompletní revizi vašeho účtu Google Analytics a společně s vámi nalajnujeme celou vaši webovou analytiku.

Chcete se dozvědět víc tipů, jak lépe pracovat s vyhodnocováním návštěvnosti? Přijďte na naše školení Google Analytics.

„Na svých školeních Google Analytics jsem dosud ukazoval, že řada omezení v reportech je za stávající situace z principu neřešitelná, protože by Google musel celý systém od základu přepsat. No, a teď ho právě přepsal.“

Ohlášené změny bych bez zdráhání označil za revoluční. Nejedná se totiž jen o přidávání více či méně užitečných funkcí do stávajícího systému, jak tomu bylo doposud. Google to teď vzal pěkně z gruntu a překopal celé Google Analytics od základu. Technologicky i filozoficky. S nadsázkou řečeno nezůstane na pozadí měření kámen na kameni a během příštího roku budeme mít úplně nový a úplně jiný analytický systém. Lepší.

Webinář o Universal Analytics

V návaznosti na tento článek jsme připravili speciální webinář o Universal Analytics. Podívejte se na něj také:

Co je dnes na Google Analytics špatně?

Stávající Google Analytics jsou ve srovnání s konkurencí nejlepší web analytický nástroj zdarma. Trpí ale řadou omezení:

• Měření je dnes orientované na zařízení, na prohlížeč, na cookies. Dnes ale běžně jeden člověk používá více různých zařízení – počítač v práci, notebook doma, tablet, smartphone… Google Analytics je měří jako více naprosto nesouvisejících uživatelů.
• S tím souvisí i velmi problematické a složité měření napříč více doménami, které zatím nelze nijak rozumně vyřešit.
• Data se agregují. Detailní záznamy o konkrétních uživatelích, jejich jednotlivých návštěvách, hitech a vztazích mezi nimi se dlouhou dobu neukládaly vůbec nebo velice omezeně.
• Google Analytics tak neumí celou řadu důležitých analýz, například vyhodnocování typických cest uživatelů webem, smysluplnou práci s vracejícími se uživateli, nedejbože s vracejícími se zákazníky, sledování opakovaných objednávek (Customer Lifetime Value), pohodlné vyhodnocování akvizičních kampaní apod.
• Obecně pak v důsledku toho mají Google Analytics velice mizernou práci s uživateli (návštěvníky). Všimněte si, že také skoro všechny nabízené reporty se váží na návštěvy, nikoliv na návštěvníky.
• Zabudovaná atribuce konverzí na poslední započitatelný zdroj je jednak v řadě případů pro vyhodnocování kampaní nedostatečná, jednak pak způsobuje zásadní zkreslení celého reportu zdrojů návštěvnosti a jeho chybnou interpretaci běžnými uživateli.
• Nezdravě velkou část měřicí logiky řeší a rozhoduje kód na straně konkrétního prohlížeče, místo co by to měly pod kontrolou přímo servery Google Analytics. Ať už se jedná o počítání návštěv daného návštěvníka, expirace započaté návštěvy, vyhodnocování aktuálního zdroje návštěvnosti, evidence předchozího zdroje, rozlišování fulltextových vyhledávačů apod. Samotné Google Analytics slouží převážně jen jako hloupý mechanický sběrač a zobrazovač dat poslaných z měřicího kódu.
• Vlastní data přitékají jen z měřicího kódu a jen v reálném čase. Nejde jakkoliv kamkoliv přihrát nějaká vlastní smysluplná data, natož pak asynchronně. Nejde nic zpětně změnit nebo přepočítat, co do Google Analytics jednou spadne, to už tam je navždy.

Nicméně v posledním roce už bylo jasné, že se na pozadí systému začalo něco měnit. Google totiž začal zlehounka a nenápadně představovat některé funkce, které by s výše popsaným přístupem neměl teoreticky vůbec umět, například Multichannel Funnels.

Revoluci v celé šířce představuje ale právě nyní. Co bude tedy konkrétně jinak?

Uživatel, uživatel, uživatel!

Hlavní pozornost při měření se přesouvá z prohlížeče na uživatele. Uživatel reprezentovaný přiděleným jedinečným identifikátorem teď bude středobodem vesmíru a celého jsoucna. Pro změření jakékoliv akce uživatele kdekoliv stačí poslat do Google Analytics jeho unikátní ID a systém si k němu vše spáruje. Google o tom hovoří jako o Universal Analytics.

Je jedno, na jakém bude uživatel zařízení nebo na jaké bude doméně. Pokud máte způsob, jak si mezi nimi předat jeho ID, máte vyhráno. A nebudete dokonce ani odkázáni na ID, které vám vygeneroval nějaký měřicí kód. Můžete libovolně používat třeba svá vlastní uživatelská ID.

Na rozdíl od dosavadních složitých a komplikovaných cookies bude ID uživatele jediná věc, kterou si musíte pamatovat. Párování pageviews, rozlišování a expirování jednotlivých návštěv, počítání zdrojů, rozpoznávání vyhledávačů, tedy věci, o které se dosud staraly cookies a měřicí kód, se teď budou všechny řešit až přímo na serverech Google Analytics.

K čemu to bude dobré?

To má zásadní dopad na celé měření, reporty, vyhodnocování a nastavování:

• Budete umět snáze sledovat jednoho uživatele napříč různými zařízeními i různými doménami.
• Bude možné sledovat silnější kontext mezi jednotlivými návštěvami a pageviews stejného uživatele.
• Pro měření už v principu oficiálně vůbec nepotřebujete měřicí kód ani cookies a vlastně ani prohlížeč, pokud nechcete. Můžete snadno měřit cokoliv a odkudkoliv.
• Otevře se tím prostor pro řadu nových reportů pracujících s uživatelem. Sledování kohort, návratnosti uživatelů a frekvence jeho příchodů (RFM – Recency, Frequency, and Monetary Value), lepší evidence více různých zdrojů jednoho uživatele, počítání celkových vynosů z jednoho uživatele u opakovaných objednávek (CLV – Customer Lifetime Value), jejich celkové přiřazení k zapojeným kampaním apod.
• Google už také nyní dává do veřejného testování svůj Attribution Modelling Tool, umožňující přepínat různé atribuční modely a přiřazovat tak konverze příchozím zdrojům podle různých pravidel a kritérií tak, jak je to právě u vašeho projektu nejvhodnější a nejsmysluplnější. Ten byl zatím k dispozici jen v placené Premium verzi.
• Většina nastavování se přesune z měřicího kódu do grafického rozhraní Google Analytics. Dobu trvání kampaně, expirace návštěvy, přidání vyhledávače nebo vlastních souvisejících webů si bude moci naklikat markeťák sám bez nutnosti programátorských zásahů.
• To na druhou stranu umožní i naprosto legální a snadný vznik různých alternativních měřicích kódů s dosud netušenými rozšiřujícími funkcemi a vlastnostmi.

Nahrajte si vlastní data

Orientace na uživatele a jeho přiřazené ID otevírá prostor pro kombinování změřených přístupů s dalšími daty, která o uživateli máte. A Google v tomhle směru slibuje hodně.

Dosud Google pojímal Analytics jako sběrač dat z vašeho webu. A když jste chtěli něco víc, museli jste si reporty vyexportovat a následně je sami propojovat s dalšími daty někde stranou, třeba v Excelu. Situace se teď otáčí a právě Google Analytics by se časem mohly stát tím centrálním bodem, kam si třeba přes CSV nahrajete vše, co o uživateli víte, kde se všechna data potkají a zkombinují.

• Vlastní dimenze. Dosud jsme v Google Analytics omezeni jen předpřipravenými dimenzemi (zdroj, prohlížeč, název stránky…). Nově bude možné definovat vlastní dimenze a plnit je vlastními daty. Například demografickými údaji u všech svých uživatelů vytaženými ze svého CRM.
• Offline konverze. Obdobně budete moci k uživatelům, u kterých umíte nějak evidovat jejich uživatelské ID, přiřadit třeba i jejich offline objednávky uskutečněné nakonec po telefonu, e-mailem nebo osobně na prodejně.
• Náklady na kampaně. Do Google Analytics bude možné nahrávat i data o nákladech ze svých reklamních kampaní. To bylo dosud možné jen u reklamy z Google Adwords, pokud jste si propojili oba účty. Nově budete moci do Analytics dostat náklady za jakoukoliv libovolnou reklamní kampaň, ať už to bude Sklik nebo placené články z Placly. V reportech tak vznikne nová sekce Acquisitions.
• Související novinkou je pak výrazně lepší kategorizace a správa kampaní v administračním rozhraní a přes nově zavedený trackovací parametr utm_id.

Narušená kontinuita

Mějte ale na paměti, že základní metriky, jako je návštěva nebo uživatel, se sice budou jmenovat stejně, ale budou znamenat něco jiného. Mění se zásadně třeba i způsob, jak se od sebe navzájem rozlišují jednotlivé návštěvy.

Podobné reporty tedy budou nově dávat úplně jiná absolutní čísla a bude je potřeba jinak chápat a interpretovat. Totéž pak platí i pro všechny další od nich odvozené statistiky.

Přechod na nové měření tedy bude znamenat velkou změnu metodiky, a tedy i narušení kontinuity sledovaných dat. Po nutnou dobu ale bude možné používat staré i nové měření paralelně vedle sebe, aniž by se jakkoliv vzájemně ovlivňovala.

Co není úplně jasné

Osobně mi ještě není jasných pár věcí, kde se ale obávám, že je Google spíš řešit nebude, což by mohlo přínos ohlášených novinek trochu omezit. Možná mě v komentářích pod článkem doplní někdo informovanější?

• Google Analytics budou umět měřit jednoho uživatele pod jedním ID z více zařízení. Pravděpodobně ale neřeší nejdůležitější a nejsložitější část celého problému – tedy jak tohle jedno společné ID na těch víc zařízení dostat, jak na úplném začátku poznat, která všechna zařízení patří jednomu uživateli. Zatím to vypadá tak, že tohle si bude muset každý řešit sám po svém. Otázka je, zda lze vůbec nějaké univerzální řešení vymyslet.
• S tím souvisí i možnost zpětného párování uživatelů. Často až po nějakém čase zjistím, že dva návštěvníci, jeden na iPadu a druhý na notebooku, kterým jsem přiřadil dvě různá ID, jsou ve skutečnosti jeden a tentýž uživatel. Budu mít možnost je zpětně kanonizovat do jednoho uživatele?
• Základní měření bude nejspíš stále synchronní a jednou změřená data nebude nejspíš i nadále možné až na výjimky zpětně měnit, přepočítávat, upravovat, doplňovat.