Vlastní dimenze a vlastní metriky se podobají výchozím dimenzím a metrikám v účtu Analytics, jen si je vytváříte sami. Můžete je využít ke shromažďování a analýze údajů, které služba Analytics automaticky neměří.
Obsah tohoto článku:- Úvod
- Požadavky
- Omezení a varování
- Životní cyklus vlastních dimenzí a metrik
- Konfigurace
- Shromažďování údajů
- Zpracování údajů
- Přehledy
- Příklady
- Rozsah na úrovni požadavku na server
- Rozsah na úrovni relace
- Rozsah na úrovni uživatele
- Rozsah na úrovni produktu
- Vlastní metriky
- Doporučení ohledně implementace
Úvod
Vlastní dimenze a metriky umožňují propojit data ze služby Analytics s daty jiného druhu, např. s údaji o řízení vztahů se zákazníky. Příklad:
- Pokud v systému řízení vztahů se zákazníky shromažďujete údaje o pohlaví přihlášených uživatelů, můžete je propojit s daty ze služby Analytics a získat tak metriku Zobrazení stránek podle pohlaví.
- Jste-li vývojář her, možná místo předdefinovaných metrik, jako je Zobrazení stránek, raději využijete metriky jiné, např. „dokončení úrovně‟ nebo „nejvyšší skóre‟. Jestli data zaznamenáváte pomocí vlastních metrik, můžete vývoj u těch nejdůležitějších sledovat ve vlastních přehledech. Jsou srozumitelné a zároveň flexibilní.
Vlastní dimenze můžete ve vlastních přehledech použít jako primární. Kromě toho je lze využít jako segmenty a jako sekundární dimenze ve standardních přehledech.
Požadavky
Vlastní dimenze a metriky jsou dostupné pouze ve službách, u nichž byla povolena platforma Universal Analytics, nebo obsahují alespoň jeden výběr dat pro přehledy aplikace. Vlastní dimenze a metriky jsou podporovány sadami SDK pro Google Analytics v systémech Android a iOS v2.x nebo novější, kódem analytics.js i Protokolem měření.
Vlastní dimenze a metriky vyžadují dodatečná nastavení v účtu Analytics a v měřicím kódu. Až oba kroky nastavení dokončíte, můžete začít vlastní dimenze a metriky používat v přehledech.
Omezení a varování
V každé službě je k dispozici 20 indexů pro různé vlastní dimenze a 20 indexů pro vlastní metriky. V účtech typu 360 je k dispozici 200 indexů pro vlastní dimenze a 200 pro vlastní metriky.
Vlastní dimenze nelze odstranit, ale můžete je deaktivovat. Nedoporučujeme, abyste vlastní dimenze „recyklovali“. Pokud název, rozsah či hodnotu vlastní dimenze upravíte, může dojít k tomu, že se s novým či starým názvem dimenze spárují jak nové, tak i staré hodnoty. V přehledech se tak data zkombinují, čemuž není možné efektivně zabránit filtrováním.
Při použití s demografickými údaji nejsou některé vlastní dimenze v přehledech k dispozici. Pokud budete chtít s touto kombinací pracovat, můžete v přehledech nebo rozhraní API narazit na omezení, případně nekompatibilitu.
Životní cyklus vlastních dimenzí a metrik
Životní cyklus vlastní dimenze nebo metriky má čtyři fáze:
- Konfigurace – definujete vlastní dimenze a metriky pomocí indexu, názvu a dalších vlastností (například rozsahu).
- Shromažďování údajů – odešlete hodnoty vlastních dimenzí a metrik ze své implementace do Google Analytics.
- Zpracování údajů – vaše data jsou zpracována s využitím vlastních dimenzí a metrik a příslušných filtrů výběru dat pro přehledy.
- Přehledy – v uživatelském rozhraní Google Analytics vytvoříte nové přehledy s vlastními dimenzemi a metrikami.
Konfigurace
Abyste mohli hodnoty vlastních dimenzí a metrik odesílat do Google Analytics, musíte je nejprve definovat v příslušné službě, která Analytics využívá. Každá služba využívající Analytics má k dispozici 20 indexů pro vlastní dimenze a dalších 20 indexů pro vlastní metriky.
Při definování své vlastní dimenze nebo metriky zadáte její název a další konfigurační hodnoty. Analytics jí přiřadí číslo indexu, pomocí něhož ji pak budete označovat. Pro vlastní dimenze se používají tyto konfigurační hodnoty:
- Název – název vlastní dimenze, který se zobrazí v přehledech.
- Rozsah – udává, na které údaje se vlastní dimenze nebo metrika použije. Další informace o rozsahu
- Aktivní – určuje, zda bude hodnota vlastní dimenze nebo metriky zpracována. Neaktivní vlastní dimenze se sice mohou v přehledech zobrazit, ale hodnoty se nezpracují.
Pro vlastní metriky jsou určeny tyto konfigurační hodnoty:
- Název – název vlastní metriky, který se zobrazí v přehledech.
- Typ – určuje, jak bude hodnota vlastní metriky v přehledech zobrazena.
- Minimální/maximální hodnota – udává minimální a maximální hodnoty, které budou v přehledech zpracovány a zobrazeny.
- Aktivní – určuje, zda bude hodnota vlastní metriky zpracována. Neaktivní vlastní metriky se sice mohou v přehledech zobrazit, ale hodnoty se nezpracují.
Vlastní dimenze a metriky lze definovat v uživatelském rozhraní Google Analytics.
Jakmile máte vlastní dimenzi nebo metriku definovanou, snažte se pokud možno neměnit její název a rozsah. Další informace o tom, jak mohou tyto změny ovlivnit tvorbu vašich přehledů, najdete v Doporučeních ohledně implementace.
Shromažďování údajů
Hodnoty vlastních dimenzí a metrik jsou do Analytics odesílány v čase určeném pro sběr dat, a to jako pár parametrů zahrnující index a samotnou hodnotu. Parametr indexu odpovídá číslu indexu, které je vlastní dimenzi či metrice přiřazeno ve fázi konfigurace.
Na rozdíl od jiných typů údajů jsou vlastní dimenze a metriky do Analytics odesílány ve formě parametrů připojených k jiným požadavkům na server (např. k zobrazení stránky, k události nebo k transakci elektronického obchodu). K odeslání hodnoty vlastní dimenze či metriky do Analytics je nutné, aby byla nastavena ještě předtím, než dojde k vyvolání měření.
Pokud nastavujete hodnotu vlastní dimenze, můžete použitý kód vypadat například takto:
ga('create', 'UA-XXXX-Y', 'auto');
// Nastavení hodnoty vlastní dimenze s indexem 1.
ga('set', 'cd1', 'Level 1');
// Odeslání hodnoty vlastní dimenze spolu s požadavkem na server typu zobrazení stránky.
ga('send', 'pageview');
Typy vlastních metrik
Vlastní metriky typu Celé číslo nebo Čas by měly být odesílány jako celá čísla. Vlastní metriky typu Měna je možné odesílat jako hodnoty s pevně stanoveným počtem desetinných míst, který odpovídá místní měně.
Zpracování údajů
Při zpracování vlastních dimenzí se pomocí rozsahu určí, pro které požadavky na server se konkrétní hodnoty použijí. Filtry výběru dat naproti tomu určují, které požadavky na server a jejich přidružené hodnoty budou nakonec zahrnuty do přehledů.
Rozsah a priorita
Rozsah určuje, které požadavky na server budou přidruženy ke konkrétní hodnotě vlastní dimenze. Existují čtyři úrovně rozsahu – produkt, požadavek na server, relace a uživatel:
- Produkt – hodnota se vztahuje na produkt, pro který byla nastavena (platí pouze pro rozšířený elektronický obchod).
- Požadavek na server – hodnota se vztahuje na konkrétní požadavek na server, pro který byla nastavena.
- Relace – hodnota se vztahuje na všechny požadavky na server v rámci jedné relace.
- Uživatel – hodnota se vztahuje na všechny požadavky na server v rámci aktuální relace i v rámci budoucích relací, dokud se hodnota nezmění nebo nedojde k deaktivaci vlastní dimenze.
Pokud má vlastní dimenze rozsah na úrovni produktu, vztahuje se hodnota pouze na produkt, pro který byla nastavena. V rámci jednoho požadavku na server je možné odeslat více produktů, a stejně tak i více vlastních dimenzí s rozsahem na úrovni produktu.
Rozsah na úrovni požadavku na serverPokud má vlastní dimenze rozsah na úrovni požadavku na server, vztahuje se hodnota pouze na požadavek na server, pro který byla nastavena. Tento princip znázorňují obrázky A, B a C:
Rozsah na úrovni relace
Pokud se v určité relaci vyskytnou dvě různé hodnoty s rozsahem na úrovni relace, které mají nastaven stejný index, bude upřednostněna ta hodnota, která byla nastavena později. Tato hodnota se použije pro všechny požadavky na server v rámci dané relace. Situaci znázorňuje obrázek D níže: hodnota, která byla nastavena jako poslední, přepíše všechny předchozí hodnoty daného indexu:
Rozsah na úrovni uživatele
A konečně, pokud jsou v rámci určité relace nastaveny dvě vlastní dimenze s rozsahem na úrovni uživatele, bude v dané relaci upřednostněna hodnota, která byla nastavena jako poslední. Tato hodnota se použije pro všechny budoucí relace daného uživatele.
Jak ukazuje obrázek B níže, pro všechny požadavky na server v rámci druhé relace se použije hodnota A vlastní dimenze, tak jako v případě vlastní dimenze s rozsahem na úrovni relace. Situace na obrázku C se však od rozsahu na úrovni relace liší. Protože má vlastní dimenze 1 rozsah na úrovni uživatele, použije se hodnota A vlastní dimenze i pro požadavky na server ve třetí relaci:
Filtry
Filtry výběru dat mohou s vlastními dimenzemi a metrikami pracovat několika způsoby.
Jednotlivé hodnoty vlastních dimenzí a metrik jsou připojeny k požadavku na server, s nímž byly přijaty, a to bez ohledu na svůj rozsah. Pokud na daný požadavek na server použijete filtr výběru dat, můžete filtrovat i vlastní dimenzi či metriku, a to v závislosti na jejím rozsahu:
- Rozsah na úrovni požadavku na server: Vlastní dimenze a všechny vlastní metriky s rozsahem na úrovni požadavku na server se budou filtrovat, pokud je filtrován i požadavek na server, se kterým souvisí.
- Rozsah na úrovni relace nebo uživatele: Vlastní dimenze s rozsahem na úrovni uživatele nebo relace nebudou filtrovány, a to ani v případě, že je filtrován požadavek na server, k němuž jsou připojeny. Jejich hodnoty se přesto použijí pro všechny požadavky na server v rámci aktuální relace, a pokud má dimenze rozsah na úrovni uživatele, tak i v budoucích relacích.
Podle vlastních dimenzí lze také sestavit filtry výběru dat. Pokud k tomuto kroku přistoupíte, budou požadavky na server filtrovány podle rozsahu vlastní dimenze. Pokud byste například filtrovali podle hodnoty vlastní dimenze s rozsahem na úrovni uživatele, získali byste aktuální a budoucí relace množiny uživatelů, kteří jsou s touto hodnotou spojeni.
Přehledy
Po dokončení konfigurace, shromažďování údajů a dalších fází zpracování jsou vlastní dimenze a metriky zpřístupněny přes uživatelské rozhraní přehledů.
Vlastní dimenze a metriky jsou k dispozici ve vlastních přehledech a můžete je použít spolu s rozšířenými segmenty. Vlastní dimenze lze také použít ve standardních přehledech jako sekundární dimenze.
Příklady
Níže uvedené příklady ukazují, jak mohou vlastní dimenze a metriky využít například vývojáři her ke zjišťování chování hráčů.
Dejme tomu, že vývojář her právě vydal novou hru.
V současné implementace služby Analytics je sledováno zobrazení obrazovky hráčem v jednotlivých úrovních hry. Vývojář má informaci o tom, kolikrát byly jednotlivé úrovně odehrány. Nyní hledá odpověď na složitější otázky:
- Kolikrát byly odehrány jednoduché úrovně v porovnání se středně těžkými nebo těžkými ?
- Kolik úrovní bylo odehráno v každém dni v průběhu bezplatného třídenního zkušebního období?
- Kolik úrovní odehráli uživatelé ve zkušebním období v porovnání s těmi, kteří si hru koupili?
K tomu je třeba vytvořit vlastní dimenze, přes které vývojář seskupí požadavky na server, relace a uživatele.
Vývojář dále prodává některé doplňující funkce, které prohloubí zážitek ze hry, například tzv. „power-upy‟. Vývojář již používá pole Kategorie a Varianta, ale chce použít ještě dodatečné pole k měření síly zakoupených „power-upů‟. To by mu pomohlo určit, zda jsou power-upy o určité síle populárnější než jiné.
Rozsah na úrovni požadavku na server
Ukažme si příklad, kdy vývojář her použije vlastní dimenze na úrovni požadavku na server, aby zjistil, kolikrát byly různé úrovně hry odehrány na jednotlivé úrovně obtížnosti (jednoduchou, středně těžkou a těžkou).
Vývojář již sleduje počet odehrání jednotlivých úrovní pomocí počtu zobrazení obrazovky. A teď chce ještě zjistit, na kterou obtížnost hrají uživatelé nejčastěji.
Přehled bude vypadat takto:
| Obtížnost | Počet zobrazení obrazovek |
|---|---|
| jednoduchá | |
| středně těžká | |
| těžká |
Před použitím vlastních dimenzí mohl vývojář zjistit celkový počet zobrazení obrazovky v jednotlivých úrovních, ale nemohl zobrazení podle obtížnosti filtrovat.
Použije-li vlastní dimenze na úrovni požadavku na server, může jednotlivá zobrazení obrazovky spojit s úrovní obtížnosti. Díky tomu mohou přehledy zahrnovat také nejčastěji hranou obtížnost.
Proč použít rozsah na úrovni požadavku na server?
Uživatel může v průběhu jedné relace odehrát i několik úrovní hry. Použitím rozsahu na úrovni požadavku na server zajistíte, že hodnota obtížnosti bude přiřazena pouze k zobrazení obrazovky, s nímž byla odeslána. Díky tomu lze spojit jednotlivá zobrazení obrazovky v každé úrovni hry s jedinečnou úrovní obtížnosti.
Konfigurace
Chcete-li implementovat vlastní dimenzi, musíte ji nejprve definovat v nastaveních své služby, která najdete v části Správce v Analytics. V tomto příkladu bude definice vlastní dimenze vypadat takto:
| Číslo | 1 |
| Název | Obtížnost |
| Rozsah | Požadavek na server |
| Aktivní | pravda |
Shromažďování údajů
Ve hře již vývojář sleduje jednotlivé úrovně pomocí zobrazení obrazovky. Aby bylo možné přidružit obtížnost k jednotlivým úrovním, je třeba nastavit hodnotu vlastní dimenze ještě předtím, než je vyvoláno sledování počtu zobrazení obrazovky.
Implementace může vypadat nějak takto:
ga('create', 'UA-XXXX-Y', 'auto');
// Nastavení hodnoty vlastní dimenze s indexem 1.
ga('set', 'cd1', 'easy');
// Odeslání hodnoty vlastní dimenze spolu s požadavkem na server typu zobrazení stránky.
ga('send', 'pageview', '/level_1/');
V tomto příkladu je vlastní dimenze nastavena ještě před tím, než je zahájeno sledování počtu zobrazení obrazovky v dané úrovni hry. Tím se úroveň obtížnosti spojí s příslušným zobrazením obrazovky a v přehledech je pak možné seskupit požadavky na server typu zobrazení obrazovky podle úrovně obtížnosti.
Zpracování údajů
Po shromáždění požadavků na server a jejich odeslání do Analytics jsou údaje zpracovány a hodnoty vlastní dimenze se použijí pro požadavky v závislosti na svém rozsahu.
Například shromážděné údaje pro jednoho hráče, který zahájil jednu relaci a odehrál šest úrovní, budou vypadat takto:
userId = 5555 Session 1: H1: screen_name=/level_1/ cd1_value=easy H2: screen_name=/level_2/ cd1_value=medium H3: screen_name=/level_3/ cd1_value=hard H4: screen_name=/level_4/ cd1_value=easy H5: screen_name=/level_5/ cd1_value=medium H6: screen_name=/level_6/ cd1_value=medium
Použití rozsahu na úrovni požadavku na server zajistí, že bude každá hodnota obtížnosti přidružená pouze k zobrazení obrazovky, se kterým byla odeslána.
Přehledy
Protože je každé zobrazení obrazovky přiřazeno k příslušné hodnotě obtížnosti, může vývojář po zpracování dat vytvořit přehled, v němž jsou jako dimenze použity název obrazovky a obtížnost a jako metrika počet zobrazení obrazovky.
| Název obrazovky | Obtížnost | Počet zobrazení obrazovky |
|---|---|---|
| úroveň 1 | jednoduchá | 1 |
| úroveň 2 | středně těžká | 1 |
| úroveň 3 | těžká | 1 |
| úroveň 4 | jednoduchá | 1 |
| úroveň 5 | středně těžká | 1 |
| úroveň 6 | středně těžká | 1 |
Můžete vytvořit vlastní přehled, ve kterém je obtížnost primární dimenzí pro seskupení zobrazení obrazovky. Zjistíte tak, kolikrát uživatelé jednotlivé úrovně obtížnosti odehráli:
| Obtížnost | Počet zobrazení obrazovky |
|---|---|
| jednoduchá | 2 |
| středně těžká | 3 |
| těžká | 1 |
V tomto přehledu jsou nejčastějšími úrovněmi ty se střední obtížností. Statistiky lze získat právě díky seskupení zobrazení obrazovky pomocí vlastních dimenzí na úrovni požadavku na server.
Rozsah na úrovni relace
Nyní se podívejme na příklad, kdy chce vývojář her pomocí vlastních dimenzí na úrovni relace zjistit, kolik úrovní bylo odehráno v jednotlivé dny bezplatného třídenního zkušebního období.
Díky sledování zobrazení obrazovky u jednotlivých úrovní již vývojář ví, kolikrát byly jednotlivé úrovně odehrány. Nyní chce zjistit, kolik úrovní bylo odehráno v jednotlivé dny.
Požadovaný přehled bude vypadat takto:
| Zkušební den | Počet zobrazení obrazovky |
|---|---|
| 1. den | |
| 2. den | |
| 3. den |
Díky vlastním dimenzím na úrovni relace může vývojář seskupit zobrazení obrazovky podle dnů zkušebního období a zjistit, jak se počet zobrazení změní, pokud uživatel stráví v bezplatném zkušebním období delší dobu.
Proč použít rozsah na úrovni relace?
Pomocí rozsahu na úrovni relace můžete celé návštěvy a všechny jejich dílčí požadavky na server efektivně seskupit do jediné hodnoty Zkušební den.
Stejného výsledku dosáhnete i pomocí rozsahu na úrovni požadavku na server. Rozsah na úrovni relace ale umožňuje pohodlné nastavení hodnoty Zkušební den a vyžaduje pouze drobné doplnění kódu.
Konfigurace
Vlastní dimenzi Zkušební den lze definovat v části nastavení služby uživatelského rozhraní Analytics pomocí těchto hodnot:
| Číslo | 2 |
| Název | Zkušební den |
| Rozsah | Návštěva |
| Aktivní | pravda |
Shromažďování údajů
Ve hře již vývojář sleduje jednotlivé úrovně pomocí zobrazení obrazovky. Aby byl určitý den přiřazen ke všem zobrazením obrazovky v relaci, je třeba pro danou relaci nastavit hodnotu vlastní dimenze pouze jednou.
Vývojář vlastní dimenzi nastaví, jakmile uživatel poprvé spustí hru:
ga('create', 'UA-XXXX-Y', 'auto');
// Nastavení hodnoty vlastní dimenze s indexem 2.
var day = getDayOfTrial();
ga('set', 'dimension2', day );
// Odeslání hodnoty vlastní dimenze spolu s požadavkem na server typu zobrazení stránky.
ga('send', 'pageview', '/level_1/');
Vlastní dimenzi na úrovni relace je možné nastavit kdykoli během relace. V tomto příkladu však bylo pro vývojáře pohodlnější stanovit zkušební den a nastavit příslušnou hodnotu na začátku relace.
Zpracování údajů
Po shromáždění požadavků na server a jejich odeslání do Analytics jsou údaje zpracovány a hodnoty vlastní dimenze se použijí pro požadavky v závislosti na svém rozsahu.
Například údaje shromážděné od jednoho hráče, který hrál první den dvakrát, druhý den jedenkrát a třetí den rovněž jedenkrát, vypadají takto:
userId = 5555 Session 1: H1: screen_name=/level_1/ cd2_value=1 H2: screen_name=/level_2/ H3: screen_name=/level_2/ Session 2: H4: screen_name=/level_3/ cd2_value=1 H5: screen_name=/level_4/ H6: screen_name=/level_4/ Session 3: H1: screen_name=/level_1/ cd2_value=2 H2: screen_name=/level_2/ H3: screen_name=/level_3/ Session 4: H1: screen_name=/level_3/ cd2_value=3
Hodnoty vlastní dimenze byly odeslány pouze s jedním zobrazením obrazovky v rámci dané relace.
Rozsah na úrovni relace zajišťuje, že hodnota Zkušební den bude přiřazena ke všem požadavkům na server v rámci dané relace, tedy nikoli jen k požadavku, s nímž byla odeslána.
Přehledy
Po zpracování budou hodnoty vlastní dimenze na úrovni relace přiřazeny ke všem zobrazením obrazovky, které byly v rámci dané relace přijaty. Vývojář může nyní vytvořit přehled s dimenzemi Zkušební den a Název obrazovky a s metrikou Počet zobrazení obrazovky:
| Zkušební den | Název obrazovky | Počet zobrazení obrazovky |
|---|---|---|
| 1 | úroveň 1 | 1 |
| 1 | úroveň 2 | 2 |
| 1 | úroveň 3 | 1 |
| 1 | úroveň 4 | 2 |
| 2 | úroveň 1 | 1 |
| 2 | úroveň 2 | 1 |
| 2 | úroveň 3 | 1 |
| 3 | úroveň 3 | 1 |
A pokud chce vývojář seskupit zobrazení podle dnů a zjistit, kolik úrovní bylo odehráno každý den zkušebního období, může vytvořit vlastní přehled s primární dimenzí Zkušební den:
| Zkušební den | Počet zobrazení obrazovky |
|---|---|
| 1 | 6 |
| 2 | 3 |
| 3 | 1 |
Z údajů vidíme, že většina úrovní byla odehrána hned první den, zatímco druhý a třetí den to bylo výrazně méně. Tyto statistiky je možno získat díky vlastním dimenzím na úrovni relace, pomocí nichž lze seskupit více relací a příslušné dílčí požadavky na server podle jedné jediné hodnoty.
Rozsah na úrovni uživatele
Nakonec si ukažme příklad, jak může vývojář her pomocí vlastních dimenzí na úrovni uživatele zjistit, kolik úrovní odehráli platící uživatelé a kolik uživatelé bezplatného zkušebního období.
Podobně jako v předchozím příkladu je celkový počet odehrání jednotlivých úrovní sledován pomocí zobrazení obrazovky. Nyní chce vývojář seskupit jednotlivá zobrazení obrazovky podle platících a neplatících uživatelů.
Požadovaný přehled bude vypadat takto:
| Typ hráče | Počet zobrazení obrazovky |
|---|---|
| Bezplatný | |
| Platící |
Tato data vývojář získá díky vlastní dimenzi na úrovni uživatele, když přiřadí všechna zobrazení obrazovky konkrétního uživatele ze všech aktuálních i budoucích relací k hodnotě Typ hráče.
Proč použít rozsah na úrovni uživatele?
Rozsah na úrovni uživatele umožňuje pohodlně seskupit všechny dílčí relace a požadavky na server daného uživatele podle jedné jediné hodnoty. Toto je vhodné zejména pro hodnoty, které se u daného uživatele příliš často nemění, jako je třeba Typ hráče v tomto příkladu.
Stejného výsledku dosáhnete i pomocí rozsahu na úrovni požadavku na server nebo rozsahu na úrovni relace. Rozsah na úrovni uživatele je ale nejpohodlnějším řešením a vyžaduje pouze malé množství kódu navíc.
Konfigurace
Vlastní dimenzi Typ ráče můžete definovat v části Správce pomocí těchto hodno
| Index | 3 |
| Název | Typ hráče |
| Rozsah | Uživatel |
| Aktivní | pravda |
Shromažďování údajů
Podobně jako v předchozích příkladech již vývojář sleduje jednotlivé úrovně pomocí zobrazení obrazovky. Aby seskupil zobrazení obrazovky podle typu hráče, stačí, když nastaví dimenzi Typ hráče, jakmile uživatel spustí hru. Tento krok pak případně zopakuje, pokud uživatel zaplatí za přístup k plné verzi hry.
Vývojář vlastní dimenzi nastaví, jakmile uživatel poprvé spustí hru:
ga('create', 'UA-XXXX-Y', 'auto');
// Nastavení hodnoty vlastní dimenze s indexem 3.
ga('set', 'dimension3', 'Free' );
// Odeslání hodnoty vlastní dimenze spolu s požadavkem na server typu zobrazení stránky.
ga('send', 'pageview', '/level_1/');
Vývojář pak nastaví vlastní dimenzi také v případě, že uživatel zaplatí za přístup k plné verzi hry:
ga('create', 'UA-XXXX-Y', 'auto');
// Nastavení hodnoty vlastní dimenze s indexem 3.
ga('set', 'dimension3', 'Paid' );
// Odeslání hodnoty vlastní dimenze spolu s požadavkem na server typu zobrazení stránky.
ga('send', 'pageview', '/level_1/');
Zpracování údajů
Tak jako v předchozích příkladech jsou údaje po shromáždění zpracovány a hodnoty vlastní dimenze se použijí pro požadavky na server v závislosti na svém rozsahu.
Například údaje shromážděné od hráče, který hrál dvakrát jako neplatící uživatel a jedenkrát jako uživatel platící, by vypadaly takto:
userId = 5555 Session 1: H2: screen_name=/level_1/ cd3_value=free H3: screen_name=/level_2/ Session 2: H1: screen_name=/level_2/ H2: screen_name=/level_3/ H3: screen_name=/level_3/ Session 3: H1: screen_name=/level_3/ cd3_value=paid H2: screen_name=/level_4/
Hodnota free (neplatící) nastavená v 1. relaci se použije pro všechny požadavky na server v rámci dané relace a stejně tak i pro 2. relaci, dokud nebude ve 3. relaci nastavena nová hodnota paid (platící).
Přehledy
Po zpracování budou hodnoty vlastní dimenze Typ hráče přiřazeny k relacím, v nichž byly nastaveny, a také ke všem budoucím relacím a požadavkům na server.
Vývojář tak může vytvořit přehled s dimenzemi Typ hráče a Název obrazovky a metrikou Počet zobrazení obrazovky:
| Typ hráče | Název obrazovky | Počet zobrazení obrazovky |
|---|---|---|
| Neplatící | úroveň 1 | 1 |
| Neplatící | úroveň 2 | 2 |
| Neplatící | úroveň 3 | 2 |
| Platící | úroveň 3 | 1 |
| Platící | úroveň 4 | 1 |
A pokud chce vývojář seskupit zobrazení obrazovky podle typu hráče a zjistit, kolik úrovní odehráli platící a neplatící uživatelé, může vytvořit vlastní přehled s typem hráče jako primární dimenzí:
| Typ hráče | Počet zobrazení obrazovky |
|---|---|
| Neplatící | 5 |
| Platící | 2 |
Z údajů vidíme, že více úrovní odehráli neplatící hráči. Tyto statistiky lze získat pomocí vlastních dimenzí na úrovni uživatele, které seskupí uživatele, jejich dílčí relace a požadavky na server podle jedné jediné hodnoty.
Rozsah na úrovni produktu
Podívejme se na příklad, kdy chce vývojář her pomocí vlastních dimenzí na úrovni produktu zjistit, jak silný „power-up‟ (slabý, středně silný nebo silný) byl zakoupen.
Vývojář již sleduje, kolik power-upů bylo zakoupeno pomocí Rozšířeného elektronického obchodu. Nyní chce zjistit, jak silný power-up si uživatelé kupují nejčastěji.
Přehled bude vypadat takto:
| Síla power-upu | Tržby za produkt |
|---|---|
| slabá | |
| středně silná | |
| silná |
Před použitím vlastních dimenzí mohl vývojář zobrazit celkové tržby za produkt power-up, ale nemohl je seskupit podle síly.
Pomocí vlastní dimenze na úrovni produktu lze přiřadit sílu k jednotlivým produktům. Přehledy tak mohou zahrnovat nejčastěji kupovanou sílu (a také sílu, která je nejčastěji zobrazována, na níž se nejčastěji kliká, nebo která je spojena s dalšími akcemi Rozšířeného elektronického obchodu).
Proč použít rozsah na úrovni produktu?
Uživatel může během jediného nákupu pořídit hned několik power-upů. Použití rozsahu na úrovni produktu způsobí, že bude hodnota síly přiřazena pouze k produktu, s nímž byla odeslána. Díky tomu lze k jednotlivým zakoupeným power-upům přiřadit jedinečnou sílu.
Konfigurace
Vlastní dimenzi Síla power-upu lze definovat v části Správce nastavení v uživatelském rozhraní Analytics pomocí těchto hodnot:
| Číslo | 4 |
| Název | Síla power-upu |
| Rozsah | Produkt |
| Aktivní | pravda |
Shromažďování údajů
Ve hře již vývojář sleduje jednotlivé nákupy power-upů. Aby bylo možné přiřadit sílu k jednotlivým power-upům, je třeba nastavit hodnotu vlastní dimenze s využitím produktových dat.
Přidání této dimenze k produktu může vypadat nějak takto:
ga('ec:addProduct', { // Zadání údajů o produktu v proměnné productFieldObject.
'id': 'P12345', // ID produktu (textový řetězec)
'name': 'Powerup', // Název produktu (textový řetězec)
'category': 'Extras', // Kategorie produktu (textový řetězec)
'variant': 'red', // Varianta produktu (textový řetězec)
'price': '10.00', // Cena produktu (měna)
'quantity': 2, // Množství produktu (číslo)
'dimension4': 'strong' // Vlastní dimenze na úrovni produktu (textový řetězec)
});
ga('ec:setAction', 'purchase', {
'id': 'T12345',
'revenue': '20.00'
});
ga('send', 'pageview'); // Odeslání údajů o transakci spolu s počátečním zobrazením stránky.
V tomto příkladu je vlastní dimenze nastavena spolu s informacemi o produktu. Tím se přidruží síla k danému power-upu.
Zpracování údajů
Stejně jako v předchozích příkladech jsou po shromáždění požadavků na server a jejich odeslání do Analytics údaje zpracovány a hodnoty vlastní dimenze se použijí pro produkty, s nimiž byly nastaveny.
Například údaje shromážděné od hráče, který zahájil jednu relaci a zakoupil tři power-upy, budou vypadat takto:
userId = 5555
Session 1:
H1: product_name=powerup cd4_value=weak
product_name=powerup cd4_value=strong
H2: product_name=powerup cd4_value=weak
Použití rozsahu na úrovni produktu zajistí, že bude každá hodnota power-upu přidružená pouze k produktu, se kterým byla odeslána.
Přehledy
Protože je každý produkt přiřazen k příslušné síle, může vývojář po zpracování dat vytvořit vlastní přehled, v němž jsou podle síly seřazeny tržby.
| Síla power-upu | Tržby za produkt |
|---|---|
| slabá | 20,00 |
| silná | 10,00 |
V tomto přehledu tvoří největší část tržeb slabé power-upy.
Vlastní metriky
Rozsah
Stejně jako vlastní dimenze mohou mít i vlastní metriky různý rozsah. Vlastní metriky na úrovni požadavku na server se přiřazují ke všem dimenzím stejné úrovně, s nimiž byly odeslány. Obdobně jsou pouze se „svými“ produkty spojeny vlastní metriky na úrovni produktu. Níže uvedený příklad ilustruje právě tyto dva typy vlastních metrik.
Příklad vlastní metriky na úrovni požadavku na server
Ve výše uvedených příkladech sledoval vývojář her jednotlivá odehrání úrovně pomocí zobrazení obrazovky. Metrika počet zobrazení obrazovky v jednotlivých přehledech představuje pokusy hráče o dokončení dané úrovně.
Ale vývojář chce zjistit také míru dokončení jednotlivých úrovní.
Ke zjištění míry dokončení použije novou vlastní metriku nazvanou Dokončení úrovně a porovná ji s počtem zobrazení obrazovky u jednotlivých úrovní.
Požadovaný přehled bude vypadat takto:
| Název obrazovky | Počet zobrazení obrazovky | Dokončení úrovně |
|---|---|---|
| úroveň 1 | ||
| úroveň 2 | ||
| úroveň 3 |
Proč použít vlastní metriku?
V mnoha případech budete mít při sledování svých nejdůležitějších metrik možnost využít událostí, zobrazení obrazovky a/nebo vlastní metriky. Použijete-li vlastní metriku, můžete získat flexibilnější a přehlednější vlastní přehledy. Proto jde o vhodnou metodou pro sledování nejdůležitějších metrik.
V tomto příkladu nemohla být dokončení úrovně sledována pomocí zobrazení obrazovky, aniž by byl počet zobrazení obrazovky u každé úrovně započítán dvakrát. Bude tedy nutné zvolit jiný způsob.
Teoreticky by bylo možné použít i samotnou událost. Vzhledem k její hierarchické povaze by však bylo obtížné vytvořit výše uvedený přehled sloučením počtu zobrazení obrazovky a dokončení úrovně v rámci jedné jediné dimenze.
Kvůli výše uvedeným omezením a protože dokončení úrovně je pro tohoto vývojáře velmi důležitou metrikou, bude nejvhodnější použít ke sledování dokončení úrovně vlastní metriku.
Konfigurace
Vlastní metriku Dokončení úrovně lze definovat v části správy uživatelského rozhraní pomocí těchto hodnot:
| Číslo | 1 |
| Název | Dokončení úrovně |
| Rozsah | Požadavek na server |
| Typ formátování | Celé číslo |
| Aktivní | pravda |
Shromažďování údajů
Vývojář již sleduje zahájení jednotlivých úrovní pomocí zobrazení obrazovky. Nyní chce sledovat i dokončení úrovně pomocí nové vlastní metriky.
Stejně jako v případě vlastních dimenzí jsou i vlastní metriky do Analytics odesílány jako parametry připojené k jiným požadavkům na server. Pokud chce vývojář odeslat hodnotu vlastní metriky a zaznamenat tak uživatele, který dokončil danou úroveň, bude muset odeslat ještě jeden další požadavek na server. V tomto příkladu bude při dokončení úrovně spuštěna událost a k této události bude přidružena vlastní metrika.
Implementace může vypadat nějak takto:
ga('create', 'UA-XXXX-Y', 'auto');
// Zvýšení metriky dokončení úrovně o 1.
ga('set', 'metric1', 1 );
// Odeslání hodnoty vlastní metriky spolu s požadavkem na událost.
ga('send', 'event', 'Level', 'completion');
Zpracování údajů
Před zpracováním budou údaje pro hráče, který během jedné relace odehraje tři úrovně, vypadat takto:
userId = 5555 Session 1 H1: type=screen_view screen_name=/level_1/ H2: type=event screen_name=/level_1/ cm1_value=1 H3: type=screen_view screen_name=/level_2/ H4: type=screen_view screen_name=/level_2/ H5: type=screen_view screen_name=/level_2/ H6: type=event screen_name=/level_2/ cm1_value=1 H7: type=screen_view screen_name=/level_3/ H8: type=event screen_name=/level_3/ cm1_value=1
Přehledy
Po zpracování může vývojář vytvořit přehled pomocí dimenze Název obrazovky a metrik Počet zobrazení obrazovky, Celkový počet událostí a Dokončení úrovně.
| Název obrazovky | Počet zobrazení obrazovky | Celkový počet událostí | Dokončení úrovně |
|---|---|---|---|
| úroveň 1 | 1 | 1 | 1 |
| úroveň 2 | 3 | 1 | 1 |
| úroveň 3 | 1 | 1 | 1 |
Protože vývojář sleduje dokončení úrovně pomocí vlastní metriky, nemusí filtrovat události dokončení z celkového počtu událostí.
Místo toho jednoduše vytvoří tento vlastní přehled s vlastní metrikou Dokončení úrovně:
| Název obrazovky | Počet zobrazení obrazovky | Dokončení úrovně |
|---|---|---|
| úroveň 1 | 1 | 1 |
| úroveň 2 | 3 | 1 |
| úroveň 3 | 1 | 1 |
Z údajů vidíme, že 2. úroveň je ve srovnání s 1. a 3. úrovní obtížnější. Z počtu zobrazení obrazovky lze totiž vyčíst, že má jen 33% míru dokončení. Sledováním počtu dokončení úrovně pomocí vlastní metriky může vývojář snadno najít odpovědi na otázky týkající se nejdůležitějších metrik a vytvořit zjednodušené přehledy, které pak může sdílet s ostatními.
Příklad vlastní metriky na úrovni produktu
Ve výše uvedených příkladech sleduje vývojář her jednotlivé nákupy power-upů. Ke každému nákupu je možné přiřadit řadu metrik, například množství nebo tržby za produkt.
Vývojář však v nedávné době spustil propagaci s nabídkou kreditu pro všechny uživatele ve výši 2 000 Kč. Chce změřit, které power-upy si lidé za tento kredit koupí.
Aby rozpoznal kredity použité na nákup produktů, použije novou vlastní metriku nazvanou Použité kredity.
Požadovaný přehled bude vypadat takto:
| Síla power-upu | Tržby za produkt | Použité kredity |
|---|---|---|
| silná | ||
| středně těžká | ||
| slabá |
Konfigurace
Vlastní metriku Použité kredity můžete definovat v části Správce pomocí následujících hodnot:
| Index | 2 |
| Název | Použité kredity |
| Rozsah | Produkt |
| Typ formátování | Celé číslo |
| Aktivní | pravda |
Shromažďování údajů
Tak jako v případě vlastních dimenzí na úrovni produktu jsou i vlastní metriky na úrovni produktu odesílány do Analytics jako parametry připojené k produktovým datům.
Implementace může vypadat nějak takto:
ga('ec:addProduct', { // Zadání údajů o produktu v proměnné productFieldObject.
'id': 'P12345', // ID produktu (textový řetězec)
'name': 'Powerup', // Název produktu (textový řetězec)
'category': 'Extras', // Kategorie produktu (textový řetězec)
'variant': 'red', // Varianta produktu (textový řetězec)
'price': '10.00', // Cena produktu (měna)
'quantity': 2, // Množství produktu (číslo)
'dimension4': 'strong', // Vlastní dimenze s rozsahem na úrovni produktu (textový řetězec)
'metric2': 5 // Vlastní metrika s rozsahem na úrovni produktu (celé číslo)
});
ga('ec:setAction', 'purchase', {
'id': 'T12345',
'revenue': '20.00'
});
ga('send', 'pageview'); // Odeslání údajů o transakci spolu s počátečním zobrazením stránky.
Zpracování údajů
Před zpracováním mohou údaje od hráče, který si koupil nějaké power-upy, vypadat asi takto:
userId = 5555
Session 1
H1: type=screen_view screen_name=/level_1/
H2: type=screen_view screen_name=/level_2/
product_name=powerup cd4_value=weak cm2_value=5
product_name=powerup cd4_value=strong cm2_value=5
H4: type=screen_view screen_name=/level_2/
product_name=powerup cd4_value=medium cm2_value=1
product_name=powerup cd4_value=weak cm2_value=10
Přehledy
Po zpracování dat může vývojář vytvořit přehled s dimenzí Síla power-upu a metrikami Tržby za produkt a Použité kredity:
| Síla power-upu | Tržby za produkt | Použité kredity |
|---|---|---|
| slabá | 20 | 15 |
| silná | 10 | 5 |
| středně těžká | 10 | 1 |
Údaje naznačují, že hráči využívají své kredity na slabé power-upy. Největší zisk získal vývojář na středně silných power-upech.
Doporučení ohledně implementace
Při implementaci vlastních dimenzí a metrik nezapomeňte na tyto skutečnosti:
Úprava stávající dimenze nebo metriky
Pokud upravíte název či rozsah stávající vlastní dimenze nebo metriky, může to ovlivnit vaše data:
- Úprava názvu: ovlivní již zpracované údaje. Staré údaje budou přístupné pouze pomocí nového názvu.
- Úprava rozsahu: údaje, které již byly zpracovány, ovlivněny nebudou. Nový rozsah se použije pouze při zpracování nových údajů.
- Změna aktivního stavu: pole Aktivní určuje, zda se hodnoty vlastní dimenze nebo metriky skutečně zpracují. Vlastní dimenze či metrika se ve vašich přehledech objeví, i když má pole Aktivní hodnotu
false. Hodnoty se však nezpracují, proto k ní nebudou žádná data přidružena.
Při nastavování rozsahu myslete dopředu
Při rozhodování o rozsahu pro určitou vlastní dimenzi zvažte, jak často se daná hodnota bude měnit. Pokud jde o hodnotu, která se může v průběhu jedné relace mnohokrát změnit (například název úrovně ve hře), použijte rozsah na úrovni požadavku na server a hodnotu nastavte před každým požadavkem. Naproti tomu vlastní dimenzi, jako je například pohlaví, obvykle stačí na úrovni uživatele nastavit jednorázově. Odesílání hodnoty pohlaví s každým požadavkem na server by vyžadovalo zbytečně mnoho práce, zatímco použití rozsahu na úrovni uživatele pro vlastní dimenzi, která se často mění, by k dané hodnotě nesprávně přiřadilo mnoho požadavků na server.
