Jako téma prvního workshopu jsme vybrali sice starší, leč zatím stále lehce tajemné téma Enhanced Ecommerce. Ve čtvrtek 15. září 2016 se na něj v konferenčním centru Green Point sešlo přes 50 účastníků od zástupců agentur až po eshopáře. Ve velkém počtu jsme dorazili i my, abychom byli k dispozici pro konzultace a řešení problémů při praktických úkolech. Úvod si vzal na starost Honza Tichý, který všem vysvětlil Enhanced Ecommerce a přemýšlení okolo něj pěkně do široka. Tomáš Kumsta si potom vzal do parády rozhraní Google Analytics a postupně všem vysvětlil report po reportu. Samozřejmě nechyběla řada praktických úkolů, na kterých si účastníci procvičili i své vyhodnocovací dovednosti. Po posilňujícím občerstvení na slunečné terase přišla segmentace v podání Marka Aldorfa, u jehož úkolů se zapotil snad každý. Pomyslnou třešničku nabídla Romana Velflová, která ukázala, jak snadno a efektivně vytáhnout ecommerce data z Google Analytics ven a dál s nimi mimo GA pracovat. A protože jsme měli my i Google náladu na rozdávání, nabídli jsme všem účastníkům hodinovou konzultaci v oblasti webové analytiky od nás zdarma. Jedinou podmínkou bylo složení individuální certifikační zkoušky Google Analytics do předem daného termínu.

Vybrané Enhanced Ecommerce tipy

• Implementaci je vhodné si rozfázovat. Nikdy se nesnažte to zvládnout všechno najednou. Zvládnete tak jedině získat rozbitá data.
• Pokud uživatel vstoupí přes stránku s detailem produktu, tak Google Analytics tuto aktivitu vnímá jako dva po sobě jdoucí hity: 1. zobrazení stránky (Pageview), 2. zobrazení podrobnosti o produktu (Product Detail Views).
• Podmínky vs. Sekvence ve vlastních segmentech jsou „pěknej humus“. Jedině přes sekvence si dokážete nastimulovat více podmínek pro jeden hit.
• Pokud porovnáváte nějaké metriky, dejte pozor, aby měly stejný rozsah (scope). Když např. srovnáváte zobrazení podrobnosti o produktu (Product Detail Views) a unikátní nákupy (Unique Purchases), mícháte jablka s hruškami, resp. hity s návštěvami.
• Přes API Google Analytics máte přístup k 65 dimenzím a metrikám elektronického obchodu, ale 2/3 se týkají pouze Enhanced Ecommerce.

Výběr fotek

Více fotek si můžete prohlédnout v galerii.

Zaujal vás DATA workshop a chcete se o dalším termínu dovědět mezi prvními? Zapište se do našeho seznamu, dáme vám včas vědět!

Jedním z řešení je odchytávání HTTP komunikace, což se hodí zejména u kontroly nativních aplikací. Každopádně tohle řešení je poměrně pracné a vzhledem k podstatě webu i dost zbytečné. Google Chrome má totiž zabudovanou podporu na vzdálené ladění (debugging). Potřebujete v zásadě jen tři kroky:

1. Nastavit telefon
2. Připojit k počítači a Chromu
3. Ladit!

Nastavení telefonu

V nastavení Androidu potřebujete udělat jedinou věc. Tou je zapnutí funkce Ladění USB (USB debugging). Tuhle položku najdete Nastavení v sekci Pro vývojáře (Developer options).

Pokud tuto položku vůbec nevidíte, máte ji pravděpodobně skrytou. U novějších androidů to tak často bývá. Musíte v nastavení najít něco jako O telefonu/O programu a tam najít číslo buildu, na které musíte 7x poklepat. V každém telefonu a verzi Androidu je to vždy trochu jinak schované, takže případně googlete.

Jakmile se konečně dostanete do nastavení Pro vývojáře, tak jen zaškrtněte checkbox USB debugging a potvrďte vyskakovací okno. Pokud nevíte, co děláte, tak si s ostatním nastavením raději nehrajte.

Připojení k PC a Chromu

Připojte telefon k počítači klasickým nabíjecím kabelem jako obvykle. Otevřete Google Chrome a do adresního řádku napište chrome://inspect. Pokud ještě nemáte, tak zaškrtněte Discover USB devices. Následně by vám na telefonu měl vyskočit alert, který potvrďte. Kdyby náhodou alert nevyskočil, zkuste telefon odpojit a připojit znovu. Případně opětovně vypnout a zapnout ladění. Občas se proces chytí ve špatném pořadí a není to poznat. Maximálně na podruhé se mi to ale povedlo vždy.

Po úspěšném připojení se vám v počítači zobrazí seznam otevřených záložek z prohlížeče na telefonu. Mimo cool tlačítek typu focus, close a reload, je tam hlavně to, co nás zajímá nejvíc -> inspect. Klikněte na to a otevřou se vám standardní vývojářské nástroje Chromu napojené na váš mobilní prohlížeč.

Závěrem

Jistě se najdou tací, které napadne otázka: „A k čemu to vlastně je? Proč prostě neemulovat zařízení v dektopovém Chromu?“ nebo „Proč to vůbec řešit, když mám responzivní web?“ Odpověď je prostá: „Protože můžete.“ To, že máte responzivní web, neznamená, že se na mobilu třeba nemůžou špatně ukládat cookies. Což je něco, co ani emulací nelze úplně zjistit. Je to prostě další možnost jak být zase o něco přesnější.

Související články a odkazy:

• Google Developers: Remote debugging
• MDN: Remote debugging Firefox
• Modus Create: Remote debugging iOS a Safari

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!

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!

Je to bezpečné?

Viděl jsem, že lidé kontejnery přemigrovali bez většího přemýšlení sami hned, jak to bylo možné. Naštestí je odpovědí ano. Bezpečné to je. Nemělo by se vám nic rozbít ani přestat měřit.  V čem tedy tkví ten problém? GTM 2.0 se liší způsobem klikání a zvláště některá pokročilá nastavení se klikají poměrně hodně odlišně. Hlavně všechny kódy, kde se používaly automatické listenery, ale třeba i DOM a LOAD eventy.

V čem je tedy problém?

Obě rozhraní fungují jinak, tedy ani google sám nebyl schopný tu migraci udělat dokonalou. Pokud se smíříte s pouhou funkčností, asi nic řešit nemusíte, ale jak vždy říkám na školení Google Tag Manager: „GTM je poměrně nepřehledný nástroj, takže udržet ho co nejjednoduší, je dost zásadní premisa.“ V tomhle ta migrace jde ovšem na druhou stranu a ruku vám opravdu nepodá.

Pár těch nedokonalostí:

Trigger All pages

Všechny stránky je v GTM velmi časté pravidlo, v novém názvosloví trigger. Jenže ten trigger se také někdy jmenuje All pages, případně je uvozený typem URL – All Pages, apod. Zároveň je to jediný trigger, který je v novém i starém rozhraní již předefinovaný. Každopádně migrace si s tím neporadí a místo toho předdefinovaného vám vytvoří nový samostatný. Hurá! Duplicita. Proč ho tam nemít hned dvakrát.

Built-In proměnné

Pokud jste si zakládali GTM v posledním roce, budete v makrech (nově proměnných) mít poměrně hodně věcí, kterým asi často ani nerozumíte (history old state, element target, …). V novém rozhraní, pokud je potřebujete, se dají zapnout zaškrtnutím checkboxu, tzv. Built-in proměnné. Proč je tedy mít ještě někde mimo, když je navíc asi nechci mít vůbec? Migrace ty Built-in použít neumí, takže vám je duplikuje do těch vlastních proměnných.

Listenery

Posledním problémem jsou již zmíněné listenery. Ty v novém rozhraní vlastně vůbec neexistují, nahradily je speciální triggery. Protože je ale způsob překlikání poměrně náročný a velmi težko automatizovatelný, Google ustoupil a při migraci se přenáší listenery i do nového rozhraní. Je jasné, že dají přednost spíše funčknosti, než estetice a metodice nástroje. Jak jsem již napsal, fungovat to bude. Pokud chcete GTM využívat dále v budoucnosti a nechcete za rok trpět totální nepřehledností a dostat se do fáze, kdy to bude tak komplikované, že to raději založíte nově a čistě, nebylo by špatné si tyhle listenery a následná pravidla jako Event – gtm.linkClick převést na triggery. Zkusím tu nastínit jeden ukázkový příklad jak to provést. Mějte však na paměti, že se to nedá automatizovat a každý případ je dost unikátní.

Ukázka přenastavení Link Click Listeneru

Aby vše fungovalo, určitě jste měli naklikaný tag typu Link Click Listener (Posluchač kliknutí na odkaz), ten měl většinou nastavené spouštěcí trigger na Všechny stránky(All pages), pokud ne, nevadí. Důležité je, abyste si zapamatovali všechna nastavení tagu, zdali máte zapnuté či vypnuté nastavení Wait for tags nebo Check Validation.

Potom jste měli různé další tagy, které jste chtěli spouštět právě při kliknutí na odkaz. Trigger by mohl vypadat nějak takto:

Co teď s tím? Přenastavení proveďte v několika krocích.

V proměnných si zaškrtněte Click URL a Page Path, abyste je pak mohli v ostatních částech GTM používat.

Vytvořte nový trigger. Bude typu Click. V kroku 2 nastavte trigger type na Link Click. Přeneste na něj stejné nastavení jako měl listener.

V kroku 3 se nastavuje spouštění jakoby toho listeneru. Pokud jste původní listener měli nastavený na všechny stránky, vůbec nad tím nepřemýšlejte a nastavte tuto položku jako na obrázku a berte to jako „blackbox“. Při budoucích nastaveních si pak pamatujte, že nastavení podmínky s tímhle žlutým rámečkem má vypadat pokaždé takhle. Použijte vytvořenou proměnnou Page Path. Pokud jste původní listener měli nastavený nějak specificky, toto je to místo, kde byste to měli promítnout.

Ve čtvrtém kroku definujete, kdy se má spouštět samotný trigger. V podstatě to, co definuje trigger na druhém obrázku. Takže přesně totéž přeneste i sem za použití vytvořené proměnné Click URL

Nově vytvořený trigger připojte k tagu místo toho, kde máte nastavený původní přemigrovaný trigger. Na závěr už jenom smažte jak ten původní trigger, tak i tag listeneru a vše by mělo v pořádku fungovat.

Ve výsledku tedy není rozhodně špatné tu migraci na svém účtu povolit už dnes. Každopádně zvažte, zda tomu GTM nepřizpůsobit a v rámci migrace ho i manuálně nepročistit. Přeci jenom v tom budete za půl roku pracovat zase vy sami. Zkoušeli jste už migraci? Napiště na jaké další problémy jste přitom narazili? Pomůžeme vám.

Související články a odkazy:

• André Heller: Google Tag manager 2.0
• Simo Ahava: Migration to V2 using the migration assistant

Export a import kontejnerů

Začnu tím nejmenším a nejrychlejším. Zároveň je to jediná věc, která přibyla i v aktuální verzi a narazíte na ni i bez beta účtu. Ode dneška můžete kopírovat a vkládat kompletní nastavení kontejnerů. GTM umožňuje import i export s výjimkou některých starších kontejnerů GTM,  kde není povolen import.

Při exportu jednoduše vyberete číslo verze nebo draft. Dostanete celkem jasný a předhledný JSON. Můžete si ho rovnou zkopírovat přes schránku, ale pro import do dalšího kontejneru je vyžadovaný vyexportovaný soubor, který stáhnete stiskem tlačítka Export.

Samotný import oproti tomu nabízí hned několik způsobů vkládání. Prvním z nich je Overwrite (přepsání), vytvoří verzi vašeho aktuálního draftu, všechno smaže a následně na základě vložené souboru vytvoří všechna nová makra, pravidla a tagy. Druhým způsobem je Merge (sloučení). Ten také nejprve z draftu udělá verzi a následně naimportuje všechna nová data a nastavení, aniž by cokoliv mazal. V případě konfliktů (stejné názvy a rozdílné nastavení) si sami vyberete, zda konfliktní položky přepíše podobně jako celá varianta jedna, nebo duplikuje a přejmenuje.

Celý proces je zabezpečený. Nejprve musíte jít na tzv. Preview, to vám ukáže počty nových, změněných či smazaných položek. Případně si k tomu můžete zobrazit bohužel nepřiliš přehledné detailní info. Teprve po kontrole vše potvrdíte.

Import konjterneru do GTM. Tzv. Preview mód pro kontrolu změn.

Nové uživatelské rozhraní

Velmi podstatnou změnou je nové uživatelské rozhraní. Oproti posledním změnám prošlo totálním redesignem. Zatím ho nedoporučuji používat na ostrá data, jelikož bude chvilku trvat, než se ustálí a odstraní všechny chyby. Nové rozhraní najdete na adrese tagmanager.google.com, zatímco staré zůstává na www.google.com/tagmanager.

Momentálně nemůžete využít nové rozhraní ve starých účtech a kontejnerech, pouze s ním založit nové účty. Volitelná migrace by měla být možná v nebližší době, v lednu 2015 pak Google nuceně zmigruje úplně všechny účty. Samozřejmě už i dnes je možné přesunout svá nastavení pomocí exportu a importu, pouze tím přijdete o verze a jejich historii. A samozřejmě musíte obměnit ID ve svém zdrojovém kódu.

Došlo k některým důležitým přejmenováním. Dosavadní rules (pravidla) se přejmenovala na triggers a dosavadní macros (makra) na variables. České ani jiné překlady zatím nejsou k dispozici.

Celkově je rozhraní posunuté směrem k nedávným redesignům Adwords a Analytics. Většina problémových věcí (konfliktní správa od více uživatelů naráz, nepřehlednost rozsáhlejšího kontejneru…) ale bohužel zůstala.

Nové UI v GTM. Hlavní stránka se shrnutím informací.

Na značky a proměnné jinak

Pokud už jste v GTM zběhlí, bude vám chvilku trvat, než si zvyknete na nové rozložení a způsob vytváření tagů. Každý tag nyní musí být bezpodmínečně svázaný s nějakým GTM eventem, který můžete chápat jako typ pravidla. Z technického hlediska funkčnosti GTM to takto bylo navržené vždycky, ale přímo v rozhraní to člověk moc nevnímal.

Příklad: Pokud jste měli tag, který se vám spouštěl na nějaké url, jednoduše jste vytvořili nové pravidlo, kdy se makro {{url}} rovnalo té dané URL. GTM tam pak sám doplnil {{event}} equals gtm.js (event značící načtení GTM knihovny a spuštění všech skriptů). Teď vytvoříte tag, jako trigger zvolíte typ Some Pages případně More a teprve tam můžete vytvářet podmínky, téměř stejně jak jste byli zvyklí. Podle úhlu pohledu je výhodou či nevýhodou, že můžete vytvořit několik triggerů naráz. Celkově je to ale zpočátku dost matoucí.

Dosavadní makra, nově variables (proměnné) prošla také drobnou změnou. Při vytváření kontejneru jste měli přegenerovanou hromadu maker, které jste ve většině případu nevyužili. Teď si o tom, které proměnné budete mít k dispozici, rozhodujete klikáním na příslušné checkboxy. Alternativně vytvořením Custom Variables. Každopádně na toto pozor při importech, nastavení starých kontejnerů se tomu neumí přizpůsobit a místo zakliknutí v předefinovaných proměnných přidá identické proměnné v podobě právě Custom Variables.

Dále nesmím opomenout, že se zvětšil počet předdefinovaných tagů, nicméně pro český trh to neznamená skoro nic, jelikož většinu nástrojů třetí strany zde moc webů nepoužívá.

GTM API

Poslední novinkou od Google je zpřístupnění veřejného API, na které se dá programátorsky napojit. Díky němu můžete spravovat a zautomatizovat:

• účty,
• kontejnery,
• tagy,
• pravidla – staré rozhraní,
• triggery,
• makra – staré rozhraní,
• proměnné,
• verze kontejnerů,
• uživatelská práva.

Více o API napíšu v nějakém dalším článku, zatím si můžete projít dokumentaci na Google Developers.

Závěrem jedno školení právě pro vás

GTM udělalo poměrně velký krok. Doufejme, že není poslední. Jaký dojem na vás udělala změna? Myslíte, že je to krok správným směrem?

Mimochodem máme jednu horkou novinku. Tímto představujeme nové velké celodenní školení zaměřené na Google Tag Manager pěkně zostra a do hloubky. Několik kratších a spíše začátečnických kurzů a workshopů GTM už se v Česku objevilo, naše velké školení ale půjde zgruntu a zaměří se na pokročilejší tipy a postupy, znalosti implementací a návrhů apod. Více informací najdete na našem školicím webu, nejbližší termín vypisujeme na 27. listopadu 2014.

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.

V Google Analytics je přitom možné je rozumně sloučit dohromady a nepřijít přitom o žádná data. Pokud ještě nemáte, odlište si ještě předtím všechny zbožáky od ostatních zdrojů návštěvnosti, jak jsme popsali v našem předchozím článku.

Slučujeme Heuréky dohromady

Nastavení se provádí formou filtrů. V tomto případě hned tří a navíc závislých na pořadí!

V prvním filtru uchovejte subdoménu bokem pro budoucí potřeby. U přístupů z Heuréky je dimenze Název kampaně vždy prázdná, takže si subdoménu uložte do ní:

Zbožáky se subdoménami – subdoména do kampaně

Totéž udělejte s cestou za lomítkem, kterou si uložte do taktéž prázdné dimenze Obsah kampaně:

Zbožáky se subdoménami – cesta do obsahu

A na závěr už jenom sjednoťte zdroj kampaně, tedy odstraňte z něj subdoménu:

Zbožáky se subdoménami – sjednocení zdroje

To je všechno. Výsledkem bude učesaný přehledný report zdrojů návštěvnosti. Původní subdomény si můžete zobrazit v rámci sekundární dimenze Název kampaně:

A dokonce jste navíc získali ještě odkazující cestu, která v reportech obvykle není, viz dimenze Obsah kampaně:

 Související články

• Romana Velflová: Chytře na mobilní návštěvnost z Heuréky
• André Heller: Odlišení zbožových srovnávačů v Google Analytics
• 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č?

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