Jedná se o velmi užitečnou a praktickou věc pro Tag Management především rozsáhle strukturovaných či vícejazyčných webů. Ohromné výhody také přinášejí z hlediska udělování oprávnění k editace a publikaci změn v GTM.

• Váháte, zda přidělovat marketingovému oddělení a dodavatelským agenturám práva na publikaci změn, které ve vašem GTM dělají?
• Mají vaši vývojáři obavy, že „jim zas nějakej markeťák rozbije kód“?
• Řešili jste někdy dilema, zda na několik oddělených, ale obsahově podobných webů nasadit samostatné, ale konfigurací velmi podobné GTM kontejnery?
• Dostali jste se z jiného důvodu do situace, kdy jste potřebovali nakonfigurovat podobným způsobem větší množství Značek (Tags) v rámci jednoho kontejneru, a nešlo to vyřešit společným triggerem?

Zóny Google Tag Manageru vám mohou pomoci s řešením všech těchto situací.

O co jde?

Pomocí Zón lze v Google Tag Manager kontejneru používat oddělené „oblasti“, z nichž se každá chová jako samostatný celek. Vybraným uživatelům můžete udělit přístupy pouze do těch zón, ve kterých se nachází jimi spravované značky. Stejně tak lze nastavit podmínky pro spouštění jednotlivých Zón stejným způsobem, jako se nastavují u běžných Pravidel.

Zóna prakticky představuje jeden nebo více běžných GTM kontejnerů. Ty se ovšem nevkládají přímo do webu způsobem, jakým jsme zvyklí. O jejich vložení do kódu webu a vyvolání obsažených Značek se postará právě Zóna, resp. kontejner, ve kterém je nastavena. Kontejnery jsou na sobě nezávislé, disponují samostatnou sadou proměnných a mohou mít nastavena různá uživatelská oprávnění. Používají ovšem společný dataLayer.

Zónu jednoduše vytvoříte a nakonfigurujete přímo v rozhraní GTM, v poslední záložce levého menu.

Pro koho?

Zóny jsou v tuto chvíli k dispozici ve všech kontejnerech Google Tag Manager 360, který je součástí placeného balíku Google Analytics 360 Suite nebo jej lze zakoupit i samostatně. V neplacené variantě Google Tag Manageru Zóny k dispozici nejsou a zřejmě to není ani do budoucna v plánu. To ostatně odpovídá i celkovému určení této funkcionality. Ta je svým zaměřením vhodná právě zejména pro rozsáhlé weby, které využijí i další výhody 360 Suite.

K čemu to lze v GTM použít?

Pojďme se podívat na konkrétní možnosti využití. Typickým příkladem je situace, kdy určitým uživatelům chcete umožnit zásahy jen do vybrané části značek, vyvolávaných na vašem webu. Nechcete, aby agentura spravující váš Facebook měla možnost měnit nastavení měření do Google Analytics?

Vytvořte zónu, kde budou umístěny veškeré značky související s Facebookem, a agentuře udělte přístupy pouze do ní. Navíc můžete nastavit i přesná omezení, jaké typy značek, pravidel a proměnných budou v dané zóně povolené. Tím lze efektivně zabránit například konfliktům kódu samotného webu s obsahem Custom HTML značek a Custom JavaScript proměnných.

Máte několik oddělených jazykových mutací jednoho webu? Můžete centrále udělit výhradní právo na správu společných částí GTM – jediného kontejneru. Pro každý marketingový tým v daném regionu pak vytvoříte zónu, kde bude moci svá nastavovat svá specifická měření. To zároveň přinese velkou úsporu času ve chvíli, kdy potřebujete změnit nastavení některého z tagů, které jsou společné pro všechny weby.

Částečně šlo podobné situace řešit jediným společným kontejnerem a používáním pokročilých Pravidel již teď. Pokročilejší, ale méně praktickou a spolehlivou možností bylo také vkládání jednoho kontejneru do druhého skrz Custom HTML. Zóny ale přináší výrazně větší flexibilitu v nastavení, snazší ovládání pro méně zkušené uživatele (přístup pouze do konkrétní zóny) a nižší riziko chyby s fatálními následky.

Co dál?

Jsou Zóny v Google Tag Manageru funkcí, kterou musíte okamžitě začít používat a propadnout hluboké depresi, pokud ji k dispozici nemáte? Rozhodně ne. Ale v každém případě jde o užitečnou záležitost a výraznou inovaci GTM. Asi jen v málo případech bude dávat smysl nasazovat ji do konfigurace stávajících kontejnerů, ale určitě je dobré ji využít při návrhu nových implementací.

Zóny přináší zásadní výhody ve správě oprávnění u kontejnerů využívaných více stranami, zvýšení bezpečnosti skrze omezení typů entit v jednotlivých zónách a větší flexibilitu tag managementu u rozsáhlých vícedoménových webů. To vše z nich dělá bezpochyby jednu z nejužitečnějších a nejvýraznějších změn, kterými Google Tag Manager v posledních letech prošel.

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.

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

Z loňského Marketing festivalu si můžete pamatovat dva špičkové marketéry a odborníky na optimalizaci konverzního poměru. Craiga Sullivana, který vás během svého dnešního webináře zasvětí do optimalizace formulářů. A Briana Deana, který představí klíčové poznatky ze svého seznamu více než 100 CRO tipů. Společně s nimi je připravených ještě dalších 52 speakerů z celého světa, takže čtvrteční nudy se rozhodně bát nemusíte.

Všichni milovníci rostoucího konverzního poměru a piva si pak dnes večer mohou zajít „na jedno“ do restaurace Sluneční terasa T-Anker na Náměstí Republiky, kde se bude konat CRO Day Prague Meetup.

Máme pro vás dárky!

Za Medio vám přejeme nadproporciální růst konverzního poměru, vysokou míru spolehlivosti testů a samá zelená čísla. A aby to naše přání nebylo jen o slovech, máme pro vás hned několik dárků.

Všem našim stávajícím i novým klientům v oblasti CRO dáváme zdarma po dobu 3 měsíců, od května do července 2015, Business Plan pro A/B a MVT testování v rámci nástroje Visual Website Optimizer. Díky tomuto plánu můžeme spolu každý měsíc otestovat váš web až na 30.000 návštěvnících. Za program byste jinak zaplatili $465, dostáváte od nás tedy dárek v přepočtu za cca 11.500 Kč. Máte-li zájem o vstup do světa marketingu orientovaného na konverze a chcete společně s námi zlepšovat výkonnost svého webu, napište na velflova@medio.cz.

VWO na 3 měsíce zdarma? To chci!

Pouze během dneška se dále za poloviční cenu můžete přihlásit na školení optimalizace konverzního poměru s Michalem Pařízkem nebo školení Google Tag Manager s Andrém Hellerem. Sleva je navíc promítnuta i do souvisejících zvýhodněných balíčků, takže se společně s těmito kurzy můžete za lidovku přihlásit i na další naše školení nebo na analytickou konferenci DATA restart 2015.

Školení CRO za polovic? To chci!

Možností, jak oslavit CRO Day, je hodně. Jak ho oslavíte právě vy?

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ď!

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.