Dnes mě zaujal článek, který napsal můj přítel Jan Exner, Digital Marketing Consultant ve společnosti Adobe. Trefně shrnuje, jak se někdy liší očekávání od nástrojů digitální analytiky mezi konzultanty, vývojáři a marketéry. Ačkoliv Jan mluví převážně o Adobe Analytics, lze tyto myšlenky uplatnit na většinu nástrojů digitání analytiky. Požádal jsem ho tedy o to, zda mohu jeho článek přeložit do češtiny, aby se tak dostal k širšímu publiku i u nás. Odkazy na další zdroje ponechávám původní. Zde jej máte.


 

Někdy je les tak hustý, že přehlédnete stromy. Někdy je to naopak.

Nedávno jsem se bavil o Dynamic Tag Managementu a Adobe Analytics s kolegou. Kolega je vývojář, který pracuje na Adobe Experience Manageru – nástroji Adobe na správu digitálních projektů.

Během naší debaty o datech, které si přál analyzovat (a skutečně jsme se bavili o analýze, nikoliv reportingu!), jsme narazili na moment osvícení, kdy jsme oba pochopili, jak moc se náš pohled na možné výstupy Adobe Analytics liší.

On se na věc díval z pohledu vývojáře, který je zvyklý zapnout velmi detailní logování událostí – tedy poměrně ukecaný proud obrovského množství dat. V momentě výskytu nějaké nezvyklé situace se do dat ponoří a přehrabuje se v nich, dokud nenajde příčinu.

Já sám se ale na věc dívám z pohledu Adobe Analytics. Tento lze zjednodušeně popsat takto: každou zajímavou událost označíme za “Success Event”, tím se stane metrikou v reportu a pokud chceme znát nějaké detailnější charakteristiky související s danou událostí, musíme poslat další data prostřednictvím vlastních proměnných (eVary).

Tyto dva pohledu jsou zásadně nekompatibilní a měl jsem si toho všimnout již dávno. Dobré je, že jsem si díky tomu uvědomil, že jsem o tomto nesouladu ještě nenapsal, a proto to udělám nyní.

Vše začíná u prosté otázky: “Jak lze vytvořit report?”

Jak popsat stav aplikace

V aplikaci, na které můj kolega pracuje, nastávají situace, které by si přál zaznamenat. Rychle jsme se shodli, že v takových situacích by měl odesílat přislušné události (Sucecss Eventy). Jelikož jde o žádoucí situace, kvůli kterým danou aplikaci vytváří, stanou se tak jeho KPIs.

Vysvětlit, proč potřebujeme vlastní proměnné (eVary) bylo trochu složitější. Zkusil jsem uvést příklad, kdy a proč značkujeme návštěvníky dle toho, z jaké marketingové kampaně do měřené aplikace přicházejí. Pro vývojáře to ale nebylo příliš užitečné. Ten se snaží zjistit spíše něco o chování samotné aplikace.

Z jeho pohledu se uvažování ubíralo spíše směrem, že Analytics by mu měly dodat informace o průběžném stavu, v jakém se aplikace nachází v momentě, kdy nastávají situace, které měříme – tedy něco jako přefiltrovaný stack trace (tedy systémový záznam stavu všech komponent aplikace v nějakém momentě).

Pro obdobný způsob měření je lépe uzpůsoben spíš produkt Data Workbench (dříve Insight), který je součástí prémiového balíčku Adobe Analytics. Ten umožňuje i složitější cross–channel analýzy, ačkoliv i zde je potřeba hodně úprav a ladění.

Adobe Analytics (ve verzi Standard – tedy dříve SiteCatalyst) pracují trochu jinak.

A když jsme u toho, tak plně chápu, že když se zabýváte měřením aplikací, uvažujete stejně jako můj kolega. Zejména pokud jmenné konvence metod v dostupných měřicích knihovnách, obsahují pojmy jako “View” nebo “trackState”.

Hlavním bodem k zapamatování je, že při měření do Adobe Analytics musíte vždy explicitně uvést vše, co vás zajímá ohledně stavu aplikace.

“…a pak už začneme vytvářet reporty?”

Popisované rozdíly mezi vnímáním analytiky a realitou se netýkají pouze vývojářů.

Také lidé na byznys straně mají své mylné představy obvykle pramenící ze zkušeností s Business Intelligence nástroji. Přemýšlejí v pojmech kolem databází, OLAP kostek a očekávají, že reporty se budou vytvářet na obdobných principech.

Pravda je, Adobe Analytics fungují výrazně jednodušším způsobem (a v životě mě nenapadlo, že použiji slovo “jednoduchý” v tomto kontextu, ale vlastně mi to udělalo radost, asi jsem trochu geek). Adobe Analytics jsou téměř stejně jednoduché jako Google Analytics, oba tyto nástroje fungují na obdobném principu: možnost vytváření reportů je velmi striktně omezena. Posíláte data a reporty ukazují, jak tato data vypadají. Tečka.

A proč že to vlastně funguje?

Funguje to, protože v digitální analytice není mnoho různých způsobů, jak se na data dívat. Většina reportů vlastně vypadá velmi podobně: několik metrik, příslušné dimenze. Navíc máte pár specializovaných reportů – trychtýře, toky událostí, sem tam nějaké specializované vizualizace, aby byla daná souvislost v datech o něco zjevnější. Navrch pak segmentace, která vám umožňuje porovnávat podmnožiny dat s odlišnými charakteristikami.

To je v zásadě vše.

Významná rozhodnutí, která musíte učinit jsou: které metriky by nás měly zajímat a které dimenze se k nim hodí.

Reporty jsou z hlediska vývojáře jasně definovány v momentě implementace měření. O stavu aplikace se z reportů dozvíte pouze to, co z reálného stavu sami explicitně zaznamenáváte. Později s tím už moc dalších kouzel nenaděláte.

To také znamená, že s nevyšší pravděpodobností budete implementaci neustále upravovat. S každým novým poznatkem přicházejí nové otázky a potřeba měření něčeho, co se dosud neměřilo.

Pro byznys to znamená totéž: veškeré reporty, které dostanete, jsou definovány v momentě implementace. Později už žádné další informace bez další implementace nezjistíte. Ale to lze vnímat pozitivně.

Teď už snad lépe chápete, proč je Tag Management tak dobrá myšlenka.

Společně s marketérem se vývojář pohybuje na tenké lince mezi splněním všech potřeb a složitostí výstupů.

Na jedné straně chtějí všichni tolik dat, kolik je jen možné, co kdyby se někdy hodily. Je tedy tlak na to implementovat co možná nejvíce měření. Tomuto přístupu rozumím.

Na druhou stranu složitost je naším nepřítelem.

Uživatelé námi vytvořených reportů se od nich budou odvracet, pokud na ně budou chrlit příliš složitá data. Nebudou ochotní takovému systému důvěřovat. Navíc údržba složitého systému je vskutku noční můrou.

Proto existuje druhý přístup. Většina příjemců dat proto chce místo snahy změřit vše raději postupovat krůček po krůčku. Pokaždé si vše ujasnit a teprve pak pokračovat dále. Postupovat pohotově a hbitě. Implementace sice určuje, co lze následně vidět v reportech, ale fáze samotné implementace tak důležitá není. Je to něco, co je nutné absolvovat zas a znovu. Budete neustále vytvářet nové a nové a zahazovat ty staré, které přestanou být užitečné.

Doufám, že tento článek nakonec dává smysl a pomůže k osvícení také vám. Byl bych za to vděčný!

Napsat komentář

Vaše emailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *