Adaptive Mind

Tento článek je druhým ze série „Sedm smrtelných hříchů UX designéra“, která vznikla na základě mé přednášky na Barcampu ve Vsetíně. V úvodním článku najdete vysvětlení důvodů jeho vzniku. Všechny články také na konci obsahují rozcestník na další kapitoly, který budu doplňovat tak, jak budou vznikat.

Lakomství (Avaritia)

Další vývojové stádium

Jakmile jsem si uvědomil svoji pýchu, musel jsem se vrátit k dalšímu studiu oboru User Experience. Chtěl jsem se dozvědět víc a začal jsem pátrat po tom, co všechno pod tento obor spadá. Souběžně jsem se věnoval projektům pro naše klienty.

Jedním z prvních větších projektů, v rámci které jsem si vyzkoušel více různých metod budování uživatelského rozhraní, byl redesign inzertního serveru. Během analýzy tohoto obsahově velmi pestrého webu jsem kromě webové analytiky potkal také card-sorting, prototypy a výstupy z uživatelského testování (ačkoliv jsem se na realizaci přímo nepodílel). Průběžně po celou dobu projektu jsem byl v úzkém kontaktu se zástupci klienta (cca 2 měsíce analýzy a 2 měsíce vývoje, přičemž většina funkcionality zůstala zachována).

Hřešil jsem

Čím více jsem se do projektu nořil, tím více jsem se snažil nasávat informace ze všech směrů. Měl jsem pocit, že celý web je přeci o uživatelích. Proto bych měl řešit, jaký dopad na uživatelské rozhraní by měla mít korporátní identita klienta (s tak ošklivým logem přece nemůže ten web fungovat). Jak by se s novým webem měl změnit marketing, jakým způsobem by měla firma na webu komunikovat se svými klienty (copywriting, který úzce souvisí i se SEO). Chtěl jsem perfektně rozumět celému byznys modelu a za vším jsem hledal User Experience.

Následně jsem všechny přesvědčoval, abychom se plně podřídili použitelnosti a přístupnosti. Tímto postojem jsem si ale udělal řadu nepřátel – nenáviděli mě vývojáři, protože jsem jim komplikoval práci. Nerozuměli jsme si mnohdy ani s klientem, protože některé jeho požadavky byly s použitelností v přímém rozporu (např. zobrazování reklamy nebo tlak na sběr osobních údajů, které nebyly nezbytné).

Dovedu si snadno představit, že by snaha o přivlastnění všech zodpovědností došla tak daleko, že by byl vlažný výsledek (čti neúspěch) přisouzen právě vyšším nákladům a komplikacím pod souhrnnou hlavičkou User Experience.

Poučení

S odstupem to vnímám tak, že snaha ovlivnit vše vyústila v prostý fakt, že jsem se všemu věnoval pouze povrchně. Dnes už jsem smířený s faktem, že něco už je rozhodnuté a o něčem by měli rozhodovat jiní. Také s uživateli se to nesmí přehánět, protože projekty musí předně vydělávat. Omezení nejsou vždy špatná, někdy vás donutí přijít s neotřelým řešením. Když se nám podaří udržet obor User Experience menší a konzistentní, snáz v něm budeme excelovat.

Od té doby se mi na jazyku občas převaluje kacířská transformace názvu mé pozice – Client Experience Designér. Už nesmím být lakomý a musím se dělit s ostatními o zodpovědnosti, úspěchy i neúspěchy.

Rozcestník

Reklamy
Vlastnosti:

Tento článek je prvním ze série „Sedm smrtelných hříchů UX designéra“, která vznikla na základě mé přednášky na Barcampu ve Vsetíně. Vysvětlení důvodů jeho vzniku obsahuje také rozcestník na další kapitoly, který budu doplňovat tak, jak budou vznikat.

Trocha historie

Internet mě uchvátil hned od první chvíle. Dostal jsem se k němu v roce 1997, kdy mě pohltila hra Diablo, která již v této době umožňovala hru více hráčů propojených přes internetový „Battle-net“. Zároveň mě začaly zajímat webové stránky, které jsem chtěl vytvářet pro svoje „vymazlené“ postavy. Myslím, že to byl důvod, proč jsem se následně přihlásil na Fakultu aplikovaných věd Západočeské univerzity v Plzni a začal studovat softwarové inženýrství. Už během studií jsem ale tíhnul k webu. Kde to šlo, tam jsem semestrální práce posouval od hardcore programování k webovým aplikacím. I na nich jsem se ale vždy soustředil více na design a uživatelská rozhraní.

Když jsem potom (po šesti letech) školu dokončil a nastoupil do Et netery, měl jsem pocit, že o této problematice vím všechno. Přečetl jsem si bestseller od Steva Kruga, odebíral články od Jacoba Nielsena, zajímal se o Personas Alana Coppera a o úskalí webových formulářů, jak je popsal Luke Wroblewski, sledoval spousty zahraničních blogů. Když jsem se následně posunul do role „někoho, kdo vymýšlí uživatelské rozhraní“, začal jsem si říkat User Experience Designer (v roce 2007 se o tomhle pojmu zatím jenom šuškalo).

Hřešil jsem

Postupem času mi ale začalo docházet, že User Experience není pouze IT obor. S jeho dalším rozšiřováním začalo být zřejmé, že jde daleko více o (kognitivní) psychologii. Sebestředně jsem se domníval, že pokud budu sledovat všechno, co se kde šustne, přijdu na nějaké magické univerzálně použitelné řešení z oblasti IT, které jednou pro vždy vyřeší, co je vlastně „dobrá user experience“.

S každým dalším klientem bylo ale zřejmější, že nemůžu aplikovat stejné postupy na různé projekty, protože se výrazně liší v obchodních modelech a zejména cílových skupinách. Dvakrát jsem se neúspěšně pokusil použít Personas. Snažil jsem se vyrobit interní knihovnu návrhových vzorů, kterou jsem s každým projektem a novou technologií musel zahodit. Nedařilo se mi u klientů obhájit investice do uživatelského testování.

Poučení

Z tohoto období jsem si odnesl zejména pokoru. Internetové technologie se mění ze dne na den. To co fungovalo včera, nemusí fungovat dnes a zítra pro to vznikne efektivnější řešení. Klienti mají různé potřeby a je třeba jim pečlivě naslouchat, protože oni jsou ti, kteří riskují – oni investují prostředky do svých webů, aby jejich firmy fungovaly stejně dobře jako doposud nebo lépe. Pokud jsem si sám sebou jistý natolik, že poučuju klienta o tom, jak na webu bude fungovat jeho byznys, proč tedy nejdu a nestanu se jeho konkurentem?

Tempo doby prostě vyžaduje, abychom byli stále v obraze. Abychom zkoušeli nové věci a investovali spousty času do neustálého sebevzdělávání. Už neplatí, že lze na tvorbě webů snadno vydělat – vstupní bariéra konkurence je nízká a udržet krok vyžaduje spousty úsilí.

Rozcestník

Vlastnosti:

Když se objevila možnost zúčastnit se Vsetínského Barcampu, chvíli jsem váhal. Přece jenom je to z Prahy kus cesty. Pak jsem si ale vzpomněl na úžasnou atmosféru na UXCamp Europe 2010 v Berlíně a také na pozitivní ohlasy, které měla Vsetínská slezina geeků a nerdů vloni. Navíc jsem dostal chuť si něco odpřednášet.

Po výměně několika e-mailů s Michalem Bergem se zadařilo a moje přednáška si našla v programu místo v odpoledním bloku sobotního programu.

Díky drobným zmatkům kolem oběda se ale stala nepříjemná věc. Nedoneslo se ke mně, že se začátek odpoledního bloku posunul a začal jsem dříve, než dorazil někdo z organizátorů a zapnul nahrávání. Těm, které moje přednáška zajímala a mrzí je, že ji neuvidí celou ani ze záznamu, nabízím tedy alespoň sérii článků, ve kterých obsah přednášky uveřejním v utříděnější podobě.

Geneze tématu přednášky

Téma se našlo poměrně snadno. Na konferencích, kterých jsem se zúčastnil v posledních letech, jsem zaznamenal pouze dva typy přednášek:

  1. Propagujeme sami sebe:
    • Chlubíme se svými úspěchy;
    • Chlubíme se cizími úspěchy (nebo popisujeme cizí neúspěchy);
  2. Propagujeme (svůj) produkt nebo nějakou technologii.

Dostal jsem chuť poukázat na fakt, že „chybami se člověk učí“ a „chybovat je lidské“. Navíc mě inspiroval citát Dona Dodge (Developer Advocate v Googlu) z  Google Developer Day 2010: „Failure is not a word we use in the tech business, we call it experience. “

Chtěl jsem proto jít s kůží na trh a zrekapitulovat vše, co se mi během mé tříleté kariéry v pozici User Experience Designéra v Et neteře nepovedlo.

Co se vám může stát, když se pochlubíte vlastními chybami? Nemyslím si, že tím dáváte najevo pouze fakt, že jste v určitou chvíli selhali. Důležité poselství vězí v tom, že pokud jste již jednou takovou chybu udělali a uvědomujete si, že šlo o chybu, pravděpodobně ji nebudete znovu opakovat. Vysmívat se vám můžou jen experti, kteří v podobné situaci nikdy nebyli nebo jsou si naprosto jistí, že by stejnou chybu neudělali. Je fakt, že koncentrace těchto lidí je v České republice poměrně vysoká, ale nejsou jen tady (někteří jsou na dovolené v zahraničí). Tohle riziko jsem se ale rozhodl podstoupit.

Final touches

Ze soupisu zásadních problémů, které pro mě znamenaly nějaké ponaučení, jsem dal nakonec dohromady seznam sedmi bodů, které se až nápadně podobaly všeobecně známému katolickému sedmeru (smrtelných) hříchů a proto jsem si vypůjčil tuto ideu jako tematickou kulisu. Průvodním vizuálem přednášky se stalo dílo ze 16. století, jehož autorem je (pravděpodobně) Hieronymus Bosch. Tento působivý obraz navíc krásně ilustruje, že jsou jednotlivé hříchy rovnocenné a v symbolickém kolotoči se mohou neustále opakovat. Stejně tak jako opakovaně narážíme na neduhy, které v profesním životě potkaly mě.

A co vás tedy čeká?

Věřím, že nebudete vnímat moji osobní výpověď jako pokus o mentorování. V dalších dnech a týdnech (raději nic neslibuju) se pokusím vydat ke každému hříchu jeden článek, ve kterém popíšu, jak daný hřích souvisí s některým z mých nezdarů. Díky tomuto formátu si budu moci dovolit být o něco košatější a konkrétnější – do třiceti minutové přednášky se všechno vecpat nedalo.

Rozcestník

Vlastnosti: ,

Rozhodl jsem se na svém blogu postupně uveřejňovat drobné praktické tipy, jak si zpříjemnit práci s Google Analytics. Tento tip je tedy prvním z řady a doufám, že si najdu čas i na další vydání.

Problém

Chcete-li v zobrazeném reportu porovnat čtyři pokročilé segmenty, jednoduchým způsobem toho nelze docílit. Po výběru tří segmentů se vždy jako čtvrtý automaticky doplní segment „Všechny návštěvy“.

Postup řešení

  1. Zobrazte 3 ze 4 segmentů, které vás zajímají („Všechny návštěvy se jako 4. segment doplní automaticky“);
  2. přejděte na libovolný jiný report;
  3. ve zdrojovém kódu seznamu pokročilých segmentů najděte číselné ID 4. segmentu, který vás zajímá *) **);
  4. v URL najděte parametr „seg0=-1“;
  5. -1 nahraďte číselným ID čtvrtého segmentu;
  6. následně můžete prohlížet libovolné reporty, které pokročilou segmentaci umožňují.

*) jednodušší to je např. ve Firebugu

**) toto ID můžete najít také tak, že daný segment použijete samotný, pak bude v URL po překliknutí na jiný report v parametru „seg0“

Update

Na Lupě dnes (17.2.2011) vyšel obsáhlejší návod na hackování pokročilých segmentů.

Málokdo dělá A/B nebo multi-variantní testování bez souběžného měření návštěvnosti. Tímto článkem bych chtěl shrnout, jaké potíže vás mohou potkat, pokud zvolíte nejběžnější kombinaci nástrojů od Googlu (celý článek se týká pouze multi-variantních testů, protože toto nastavení doporučuji i pro testy se dvěma variantami – důvody mohu zájemcům vysvětlit v jiném článku nebo v komentářích). Mohlo by se totiž zdát, že když oba nástroje pocházejí od stejného výrobce a využívá dokonce shodnou technologii sběru dat, bude jejich integrace bezbolestná. Omyl.

Zásadním problémem je, že vývoj obou nástrojů probíhá nezávisle. Ačkoliv Google o integraci již nějakou chvíli sám hovoří a je ze stran agentur i koncových klientů bombardován žádostmi o řešení, stále se v tomto ohledu příliš nestalo. Nějaké pokusy již na webu lze nalézt (většinou v angličtině), ale žádné z nich neuvažuje všechny případy užití a navíc zatím ještě neřeší nový asynchronní sledovací kód.

Takže co všechno vás čeká, pokud se rozhodnete na svém webu využívat Google Analytics (dále GA) a Google Website Optimizer (dále GWO) současně?

Jak zajistit, aby se to nepralo?

Na testovací stránce řešíme spuštění dvou měřících skriptů (GA a GWO). Jsou-li oba skripty nakonfigurovány podobně, přepisují si cookies s údaji o návštěvníkovi a mohou tak poškodit vaše nasbíraná data.

GWO je totiž založen na starší verzi měřicího skriptu GA z dob, kdy se ještě jmenovalo toto řešení Urchin Software. Skripty tedy používají stejnou metodu sběru dat – JavaScriptem nashromážděná data v kombinaci s identifikací návštěvníků ve stejných cookies (__utma, __utmb, __utmc, __utmz a potažmo __utmv), která jsou odesílána na servery Googlu v podobě requestu na stejný jedno-pixelový obrázek s parametry.

Kontrolní skript navíc využívá své vlastní cookies (__utmx a __utmxx), kterými zajišťuje trvalost přiřazení jedné kombinace k danému návštěvníkovi.

Asynchronní kód

Kontrolní skript GWO je nutně synchronní (musíme jej spustit ještě před začátkem vykreslování vlastní stránky, aby mohl měnit její obsah podle nastavení experimentu), proto také musí vždy být přímo v hlavičce dokumentu. K plné kontrole dvou měřících skriptů na stránce ale potřebujete, aby se skripty spustily v určeném pořadí. Toho nelze dosáhnout, kombinujeme-li nový asynchronní skript GA a starý synchronní měřicí skript, který vygeneruje nastavení experimentu v GWO.

Pokud použijeme skripty vygenerované jednotlivými nástroji a umístíme je, jak nám Google doporučuje, bude navíc stránka zbytečně vyhodnocovat dvakrát hlavní měřicí skript. To si můžete prohlédnout na prvním příkladu.

Doporučuji proto využívat i pro měření GWO experimentů asynchronní syntax, který navíc umožňuje snazší inicializaci druhého trackeru.

Nastavení domén cookies

Abychom zabránili vzájemnému přepisování cookies identifikujících návštěvníka, můžeme se pokusit cookies pro oba nástroje oddělit (každý bude mít svoje) nebo si ohlídáme pořadí skriptů a druhému zakážeme přepisovat alespoň cookie s informací o zdroji návštěvnosti (__utmz). Jinak se může stát, že nám vyhledávač přidaný v nastavení GA (v dalším příkladu jde o vyhledávač „search.cataluc.cz“) nerozpozná skript GWO, který dané nastavení nemá, a zdroj přepíše (když z předchozího odkazu přejdete na testovací stránku, nastaví nejdříve skript GA správně zdroj na vyhledávač „search.mrkef.net“, ale v zápětí jej přepíše měřicí skript GWO na vyhledávač „search“).

Já doporučuji druhou cestu. U ní je třeba zajistit zejména shodné nastavení domény a jejího hashování v hodnotách cookies. To je nutné učinit nejen pro oba měřicí skripty, ale také pro kontrolní skript GWO. Nejlépe se mi k tomu osvědčila definice globálních proměnných, které zná kontrolní skript GWO (_udn a _uhash) a jejich využití při nastavení obou trackerů – jenom pozor na to, že nastavení těchto proměnných budete muset udělat na každé stránce, nikoliv pouze na testovací.

Data o testu v Analytics

Co umí Website Optimizer?

Chcete-li vyhodnocovat experimenty pouze v GWO, jste značně omezení – měří totiž pouze konverzní poměr k jednomu definovanému cíli (Jaký podíl návštěv, který obsahoval testovanou stránku, obsahoval zároveň cílovou stránku?).

Co nás dále může zajímat?

Často ale potřebujeme data bohatší. Zajímá nás další chování návštěvníků po zhlédnutí testované stránky, vyhodnocování testu i podle dalších parametrů (Jaký je Bounce Rate testovaných variant? Má na test vliv i prohlížeč a jeho verze nebo rozlišení obrazovky?). Statisticky zdatnější experimentátoři mohou pak tato data využít také k ověření, že vyhodnocovaný konverzní poměr je statisticky nezávislý na způsobu volby skupin, kterým se obě varianty zobrazují.

Varianty integrace dat

Naším cílem je tedy dostat do GA informaci o tom, která z variant se danému návštěvníkovi zobrazila (pokud navštívil testovací stránku).

Tuto informaci můžeme zaznamenat buď do tzv. „User-defined Variable“ nebo do nových „Custom Variables“, které mají časem tuto jedinou proměnnou plně nahradit. Aktuálně má stále „User-defined Variable“ jednu podstatnou výhodu – lze podle ní filtrovat návštěvnost. Díky tomu můžete u vybraných testů vyrobit profily, které budou obsahovat pouze data o chování návštěvníků, kteří viděli některou konkrétní variantu. U „Custom Variables“ si budete muset vystačit s vyhodnocováním pomocí pokročilých segmentů, které mohou za určitých okolností zobrazovat zkreslená data (díky tzv. vzorkování).

Další nepříliš známou variantou může být ještě sledování testů prostřednictvím „Site Search“, kdy do GA místo URL adresy testované stránky zaznamenáte URL prodlouženou o dva parametry (např. test=IDTESTU a varianta=IDVARIANTY). Ale o tomto nastavení zase někdy jindy.

Shrnutí

Během psaní tohoto článku jsem narazil na spousty dalších možností a souvislostí, které se mi do jednoho postu jednoduše nevejdou. Je proto možné, že se tomuto tématu budu věnovat i nadále. Očekávám ale v budoucnosti razantnější změny ze strany Googlu a těším se, že se bez takovýchto složitostí nakonec obejdeme.

Všechny příklady, včetně finálního řešení najdete na rozcestníku, který jste již možná v rámci jednotlivých příkladů objevili.

As promised I am going to accomplish my UXCampEurope Berlin 2010 participation. For those who missed the whole thing, I prepared an online survey to analyze which tools and methods that are used in UX industry do the real practitioners use and consider useful.

I tried to attract the participants by sharing the URL of the survey by giving the event attendees a physical notice (and I would like to thank Sigy for the „offline tweet idea“).

Photo by @mahemoff

The survey

The survey listed 19 user experience tools/methods in 5 categories:

  • Qualitative user research
    • Offline surveys/questionnaires
    • Online surveys
    • Remote user testing
    • Full-scale user testing
  • Quantitative user research
    • Eye tracking
    • Mouse tracking/screen recording
    • Web analytics
    • A-B/Multivariate testing
  • Information Architecture/Labeling
    • Card sorting/tree testing
    • Search keywords research/Text-ads testing
    • Mind maps
  • Wireframing and Prototyping
    • LoFi wireframes/mockups
    • HiFi wireframes
    • Non-functional prototypes
    • Full-functional prototypes
  • Interaction Design/Scenarios
    • Component/Widget libraries
    • Storyboards
    • Personas
    • Pageflows/Activity diagrams

and the participants were asked to answer how often they use such a tool and how useful do they think it is:

Usage frequency:
1-Never, 2-Rarely, 3-Regularly, 4-Often, 5-Every time
Usefulness:
1-Worthless, 2-Informative, 3-Helpful, 4-Insightful, 5-Priceless

Participants

I hoped for more participants to be able to share significant results. After one week there are only 20 people who completed the form and I feel that I owe them at least some results so I will try to formulate a few hypotheses based merely on qualitative data.

There were 7 participants from Germany, 6 from Czech Republic, 3 from UK, 2 from Denmark, 1 from France and 1 from Spain.

Most of them stated their job title to be User Experience Designer, others are UX consultant, Analyst, Concept Developer, Information Architect and student. One participant was concerned that people in marketing industry might use these tools less often, but i don’t have enough data to support or confute this idea.

Results

So lets start with the numbers. I normalized the data, so it can be read easier.

Survey results

These numbers show how the participants perceive the listed tools/methods in relation to each other on the scale from 0 (the least used and useful tool) to 100 (the most frequent and appreciated one).

Qualitative user research

I have to admit that these results don’t surprise me a lot. Almost everyone has read Steve Krug’s „Don’t Make Me Think!“ and we all agree that usability is the core attribute of every software product. I think the optimism around remote user testing is interesting although the participants haven’t used it a lot. It may be caused by the fact that these tools had a pretty extensive representation during this year’s UXCampEurope.

Participants also mentioned etnography research, (non)directed interviews, focus groups and other sorts of sessions with the target audience.

Quantitative user research

On the other hand web analytics are widely adopted. The pessimism about its usefulness may be caused by the information overload that hasn’t been successfully tackled yet by any software vendor providing on the market. There is also a positive anticipation around a-b/multivariate testing. The small penetration of mouse tracking and screen recording tools is something that surprised me, because fancy heat-maps produced by these tools are demanded and well received by clients.

Information Architecture/Labeling

I admit that this category was the most vaguely defined. But it seems that card sorting and mind maps are also pretty widespread and seen as satisfactory in general.

The participants also used task analysis and affinity diagrams. We can also argue wether mental models or cognitive walk-troughs belong into this category or should rather live within qualitative user research.

Wireframing and Prototyping

These few questions are in fact only another dimension in the area. I was interested if perfection is widely required in all stages of concept development. We can argue that it depends highly on the size of the projects, but I can see no trend in relying on perfect wireframes or prototypes so the concept phase overlaps with the product development.

Interaction Design/Scenarios

In the last category I was pretty surprised by the wide adoption of personas and storyboards, which might be caused by the grouping of the tools. Participants also mentioned swimlanes and object modeling in this category.

Conclusion

These results are not intended to be a full-scale statistically significant research as I didn’t pay much attention to recruiting participants or data cleanup. I just wanted to share an idea and provoke a discussion about the industry and the UX practitioners feelings about its overall maturity.

I am not saying that I managed the whole thing well, but I would really like to hear what you think about the topic rather than the survey itself.

Předem upozorňuji, že následující článek bude obsahovat pokročilejší návod. Pokud nejste webovým analytikem, raději se mu vyhněte obloukem, protože jinak skončíte s papírem, tužkou a nechápavým pohledem na tváři.

Proč tento článek píšu

Kdo zná specifika nastavení cílů a trychtýřů v Google Analytics, určitě mi dá za pravdu.

Trychtýře v Google Analytics nejsou příliš flexibilní nástroj.

Proč tomu tak je? Zejména díky nemožnosti nastavit trychtýře zpětně. Pokaždé jste odkázáni pouze na nová data počínaje dnem nastavení trychtýře. Nejednomu z nás pak také způsobil vrásky nějaký překlep nebo chybka v porovnání s regulárním výrazem, o které se díky zpoždění vyhodnocování trychtýřů až 24 hodin dozvíte příliš pozdě.

Naštěstí existuje lék v podobě analýzy dat přes Google Analytics Data Export API.

Co potřebujete k dosažení výsledku

Jelikož nechci do tohoto článku zatahovat programování, použiji k získávání dat volně dostupný Data Feed Query Explorer. Má dvě zásadní nevýhody oproti vlastní implementaci stahovače dat v některém z podporovaných jazyků.

  1. Nelze pokládat dotazy na API v cyklech.
  2. Je nutné data ručně kopírovat z vygenerované HTML tabulky.

Výhodou zase může být, že nemusíte dohledávat identifikátory profilů, ze kterých chcete data stahovat, ani názvy dimenzí a metrik, kterými definujete své dotazy.

K další vizualizaci dat pak můžete využít libovolný tabulkový procesor.

Formální definice trychtýře

V oficiální dokumentaci v uživatelském rozhraní se dočteme, že z reportu se dozvíme:

V kterém okamžiku návštěvníci, kteří určenou cestu započali, tento proces opouštějí?

Poznámky k tomuto shrnutí:

  • Záleží na přepínači povinnosti prvního kroku, zda mohou návštěvníci danou cestu započít někdy dále v trychtýři (klidně na cílové stránce).
  • Stejně jako u cílů jsou v trychtýři zahrnuti návštěvníci vždy pouze jednou (ve smyslu „kam se dostali v cestě nejdále“).

Nadále budu uvažovat pouze trychtýř bez povinnosti prvního kroku, ale na konci článku si jistě sami dokážete odvodit, jak by se dal získat trychtýř včetně tohoto přepínače.

Vstup do trychtýře

Vstupem do trychtýře tedy chápeme unikátní zobrazení stránky, které předcházelo danému kroku a nebyla to stránka kroku předchozího (zde je drobná odchylka od chápání trychtýřů v Google Analytics, jelikož moje implementace nezahrnuje do cesty návštěvníky, kteří některý z kroků „přeskočí“ – u mě se pak objeví zase ve vstupech kroku následujícího). V případě, že návštěvník započal svoji návštěvu rovnou v některé ze stránek cesty, označíme vstup jako „(entrance)“.

Výstup z trychtýře

Výstupem z trychtýře je pak unikátní zobrazení stránky, která následovala po daném kroku trychtýře u uživatelů, kteří nenavštívili další krok trychtýře.

Sekvence dotazů na API

Vlastní trychtýř tedy sestavíme vždy ze dvou dotazů pro každý definovaný krok s následujícími parametry:

Typ dotazu parametr hodnota
Vstup filters ga:nextPagePath==/aktualni-krok.html
Vstup segment dynamic::ga:pagePath!=/predchozi-krok.html
Výstup filters ga:previousPagePath==/aktualni-krok.html
Výstup segment dynamic::ga:pagePath!=/nasledujici-krok.html

Přičemž segment můžeme vynechat u vstupů do prvního kroku a výstupů z kroku posledního.

Pro všechny dotazy se pak nemění nastavení parametrů dimensions, metrics, sort, start-date, end-date, max-results (nejvíce 10 000) a ids.

parametr hodnota
dimensions ga:previousPagePath,ga:nextPagePath
metrics ga:uniquePageviews
sort -ga:uniquePageviews
start-date 2010-04-01*
end-date 2010-04-01*
max-results 10 000*
ids ID vašeho profilu*

* toto není apríl – data označená hvězdičkou si samozřejmě zvolte dle svých potřeb

Nakonec potřebujete ještě poslední dotaz, kterým získáte počty unikátních shlédnutí jednotlivých kroků trychtýře.

Následně lze také dopočítat, jaké procento návštěvníků se dostalo k následujícímu kroku (počet zobrazení následujícího kroku bez zobrazení jiných vstupních stránek dělený počtem zobrazení aktuálního kroku) a kolik lidí z trychtýře opustilo celý web (počet zobrazení daného kroku minus počet přenosů do kroku dalšího minus počet zobrazení jiných výstupních stránek).

Sleduj mě na Twitteru

Moje twíty

RSS Google Reader

  • Objevila se chyba, RSS zdroj je pravděpodobně mimo provoz. Zkuste to později.

RSS 417.cz

  • Objevila se chyba, RSS zdroj je pravděpodobně mimo provoz. Zkuste to později.