Adaptive Mind

Posts Tagged ‘web analytics

Introduction

Why should we bother? Because it is actionable!

Internal search is the best place to gather feedback from your potential customers. They come to your website and tell you:

  • what they want to find there;
  • where did they gave up trying to navigate there and used search functionality instead.

But what do they do if they see an empty results page? Some might try to refine their search phrase, but I would say that it really doesn’t improve their overall experience.

It also might be the good signal for you to:

  • deliver content that is not currently present on your website;
  • change copywriting a bit in case you have picked a different words for the content;
  • or try to implement a manually added results for those searches.

Prerequisites

This article is meant to describe possible solutions when you are using a newer asynchronous Google Analytics tracking code placed in the head section of your website.

Google Analytics doesn’t provide this report by default. So we will have to do some extra work to achieve this. The first thing that is necessary to do is to be sure that you are able to identify a zero search results page programmatically.

Then you need to be able to manipulate the Google Analytics Tracking Script a bit or include an extra block of JavaScript into the tracked page.

Options to consider

You certainly don’t want to use an extra _trackPageview call, because this would inflate your data (especially Pages per Visit metric).

In certain cases you actually might be able to modify the tracked URL, but it can be achieved only in particular Web Content Management Systems that are able to pass in all the variables from the page into any template fragment of the generated page. With this capability, you could manipulate the tracked URL as described in this article by Justin Cutroni. The resulting code might look a bit like this:

<script type="text/javascript">
       var _gaq = _gaq || [],
             p = document.location.pathname,
             s = document.location.search;

       _gaq.push(['_setAccount', 'UA-15436952-1']);
<? if (resultsCount == 0) { ?>
       _gaq.push(['_trackPageview', p + s + '&category=no-results']);
<? } else {?>
       _gaq.push(['_trackPageview']);
<? } ?>
       (function() {
             ...you know this part...
       })();
</script>

Afterwards you can proceed with the Site Search functionality configuration by the instructions from Justin’s article.

If you don’t have such a comfortable CMS, you can still measure some extra data with the two following features of Google analytics.

Event Tracking

This method was already described in the article Using Google Analytics to Track ‘Zero Results Found’ for Site Searches by Bob Scavilla. I would just point out that it might be a lot easier if the actual search term would be generated by the CMS so you won’t have to suck it from the URL with a regular expression. The resulting code looks much simpler thought:

<? if (resultsCount == 0) { ?>
<script type="text/javascript">
       _gaq.push([
              '_trackEvent',
              'Search',
              'No-results',
              '<?=$searchTerm?>'
       ]);
</script>
<? } ?>

Custom Variables

The first thing you can do is to use a page-level custom variable. You can store the actual zero results search terms like this:

<? if (resultsCount == 0) { ?>
<script type="text/javascript">
       _gaq.push([
       		'_setCustomVar',
		1,
		'No-results',
		'<?=$searchTerm?>',
		3
	]);
</script>
<? } ?>

or you can store the particular results count:

<script type="text/javascript">
       _gaq.push([
       		'_setCustomVar',
		1,
		'Results-count',
		'<?=$resultsCount?>',
		3
	]);
</script>

Then if you are a little advanced, you can use the API to show all search terms and their count of results in one report (using ga:searchKeyword and ga:customVarValue1 dimensions and ga:pageviews metric).

Conclusion

The only downturn of some of these methods is that the Site Search Terms report still includes all the searches that ended up with no results and you cannot really distinguish them.

Advertisements

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.

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).

Většina nedávno oznámených novinek v Google Analytics nabíhá do vašich účtů postupně. Jednou z těch pomalejších jsou i reporty návštěvnosti z mobilních zařízení. V některých účtech je již mám k dispozici a začínám experimentovat i se server-side měřícími kódy.

Než vám ale mobilní trackování naběhne, rád bych se podělil o pokročilý segment, který také dokáže poměrně přesně odhalit, jaký podíl vaší návštěvnosti je právě z mobilních zařízení (aktuálně pouze z těch přístrojů, které podporují JavaScript a cookies a nechají se změřit standardním trackovacím kódem).

Pokročilý segment jsem definoval na shodu následujících dimenzí podle regulárních výrazů:

DimenzeRegulární výraz

Operating System iPhone|SymbianOS|iPod|Android|Samsung|Sony|BlackBerry|LG|Nokia|Playstation Portable
Browser HTC_|SAMSUNG|Opera Mini|Playstation Portable|Nintendo DS
Screen Resolution ^176x|^220x|^240x|^320x|^360x|^400x|^480x

Jelikož na mobilních zařízeních najdeme i operační systém Windows, ale většina návštěv s tímto systémem nespadá do mobilní kategorie, je nutné Windows do tohoto pole nezařazovat a pokusit se odchytit tyto uživatele přes mobilní prohlížeče nebo menší rozlišení.

Segment samozřejmě není absolutně přesný – bylo by vhodné lépe prozkoumat možná rozlišení a navíc je nutné sledovat i aktuálně používané operační systémy a prohlížeče a segment průběžně upravovat. Na základní rychloanalýzku podílu mobilní návštěvnosti a jeho pomalého ale jistého nárůstu mi ale dostačuje.

Před Summitem jsem si položil několik otázek a nyní bych rád shrnul, zda jsem na ně nalezl odpovědi.

Atribuční model

Jednoznačnou odpověď ohledně dalšího vývoje atribučního modelu v Google Analytics jsem nedostal. Rozhodně jsem ale nebyl jediný, který se o tuto problematiku zajímal a podobnými dotazy mě podpořilo hned několik dalších konzultantů.

Prozatím se musíme smířit se současným pojetím Googlu, ale díky novým Multiple Custom Variables se možnosti vlastní implementace atribučního modelu rozšiřují.

Případové studie, tipy, triky, komunikace

Kvalita prezentací se různila. Od strohých popisů průběhu projektů s důrazem na komplikace během prosazování použití analytických nástrojů, přes prodejní nebo přehledové prezentace vlastních nebo cizích produktů konzultantských firem až po inspirativní přednášky o nových způsobech nahlížení na data s praktickými ukázkami.

Osobně mě nejvíce zaujaly možnosti měření aktivit v sociálních sítích a integrace s marketingovými nástroji nebo analytickými nástroji z kategorie business intelligence.

Novinky v Google Analytics

Nejpříjemnějším překvapením byly ale nakonec prezentace novinek v Google Analytics (anglicky Google Analytics Now More Powerful, Flexible And Intelligent), ale také pečlivě připravený postup jejich zveřejnění. Vybral jsem několik z nich a nyní se pokusím naznačit možnosti jejich praktického využití.

Analytics Intelligence

Ukázka Analytics Intelligence

Tato skvělá nová funcionalita vám ušetří mnoho práce s analýzou trendů a umožní vám včasné zaznamenání neobvyklých změn a to zejména:

  • jste-li konzultanty, kteří chtějí své klienty odstínit od množství nesrozumitelných dat a informovat je pouze o podstatných změnách na jejich webu
  • nemáte-li čas na hloubkovou analýzu všech segmentů – např. podle zdrojů návštěvnosti, vstupních stránek, geografických regionů nebo různých prohlížečů (např. nárůst návštěvnosti po billboardové kampani na severní Moravě)
  • chcete-li si ověřit, že změny, které jste na webu provedli se odrazily očekávaným způsobem na klíčových veličinách (např. snížení Bounce Rate po optimalizaci Landing Page)

Statistický aparát za touto funkcionalitou navíc umožňuje zobrazit pouze ty nejvýraznější změny a srovnávání trendů mezi dny, týdny až měsíci. Další výhodou je, že Google přepočítal tato data i zpětně.

Manuálním nastavením varování navíc můžete být informování o konkrétních změnách e-mailem (kterak používat Custom Alerts – anglicky od Avinashe Kaushika).

Multiple Custom Variables

Jak jsem již zmínil v poznámce o Atribučním modelu, byla konečne vyslyšena prosba o rozšíření počtu uživatelských proměnných. Prozatím byla k dispozici pouze jedna vázala se na uživatele (prohlížeč) v podobě cookie s 2-letou trvanlivostí.

Nové nastavení umožňuje využití až 5-ti uživatelských proměnných, které lze navíc podle trvanlivosti rozdělit do tří kategorií:

  • Visitor – stejná jako u současné _utmv cookie – zůstává tedy platná i po vypnutí prohlížeče a návratu uživatele na web (př. uživatel, který alespoň jednou příšel z kampaně v AdWords)
  • Session – její platnost končí s odchodem uživatele z webu (př. odlišení přihlášeného/nepřihlášeného uživatele)
  • Page – je vázána pouze na jedno konkrétní zobrazení stránky (př. segmentace typu „Uživatel, který navštívil stránku s kontaktním formulářem“)

Další tipy můžete nalézt také v anglickém článku Justina Cutroniho Google Analytics Custom Variables Overview.

Rozšíření správy Cílů (Goals)

Vytváření duplicitních profilů jen kvůli omezení 4 cílů na profil je konec – nyní bude k dispozici cílů 20 a navíc bude možné sledovat i cíle v podobě měkkých metrik – dosažení určitého počtu zobrazení stránek nebo času stráveného na vašem webu (videoukázka na Youtube, anglický článek New Google Analytics Goals).

Další užitečná vylepšení

Mezi další dlouho očekávané změny bych zařadil také vylepšení filtrování tabulek a možnost zobrazení více dimenzí v jedné tabulce (videonávod na Youtube), zpoužitelnění metriky unikátních návštěvníků v Custom Reports (anglicky Segmenting Unique Visitors in Google Analytics), možnost sdílení Custom Reports a Advanced Segments a trackování mobilních zařízení.

Závěrečné shrnutí

Summit mě opravdu nadchl. Pracovní prostředí v Googleplexu je báječné a setkání s podobně uvažujícími lidmi je vždy inspirativní. Vývojářské týmy analytických produktů Google to opravdu myslí vážně a pečlivě naslouchají všem podnětům z řad webových analytiků. Budoucnost těchto produktů je díky silné základně konzultantských firem, které je podporují, zcela jistě světlá.

Vlastnosti:

Poslední den Summitu autorizovaných konzultantů v Mountain View v Kalifornii byl věnován serverové variantě Google Analytics, kterou akvíroval Google v roce 2005 a na jejím základě postavil jeho mladšího hostovaného bratříčka. Dopředu varuji, že míra techničnosti následujícího je již mírně za hranicí stravitelnosti, takže jeho další čtení podstupujete na vlastní nebezpečí.

Developers overview

Vývojářský tým se nejprve pochlubil, že dbá na zpětné krmení (feedback) svých uživatelů a za poslední rok vydal 5 updatů Urchinu verze 6, vyřešil 3 000 supportních ticketů, zpracoval 1 500 postů na diskusním fóru (z toho 246 od Mikea Chipmana) a vypil 475 galónů kafe. Smutnou tečkou za úvodem byl ale fakt, že jsou pro Urchin dedikovány nižší zdroje než pro Google Analytics, jejichž rapidní tempo vývoje v posledních měsících nemají šanci napodobit.

Nicméně byly představeny některé nové funkcionality, které určitě stojí za zmínku. Do prvního balíčku novinek patřila užší integrace se SEM produkty jako Google AdWords, Yahoo! Advertising nebo Google Keyword Suggestion Tool. Integrace s AdWords umožňuje automatizovanou správu rozsáhlejších kampaní včetně bid managementu s doporučenými hodnotami investic k dosažení optimálních výsledků a automatických alertů v případě, že jsou tyto hodnoty nastaveny příliž nízko. Dalším pozitivem této integrace je také to, že toto využití AdWords API je bezplatné.

Dále byly představeny některé nové reporty (srovnání výkonu zdrojů a médií návštěvnosti a Time on Site) a Data Export API podporující jak SOAP tak REST rozhraní. Dalším splněným snem administrátorů Urchinu by měla být také redukovaná varianta GeoDB s granularitou do úrovně zemí, která si namísto celé 600 megové databáze do úrovně měst, sítí a společností vystačí se 156-ti megabajty.

Na závěr bylo také oznámeno, že bude Urchin k dispozici až v 10-ti jazykových mutacích, mezi kterými čeština bohužel prozatím není.

Nové možnosti hostování Urchinu

V březnu letošního roku byla Calebem Whitmorem založena společnost Analytics Pros, která oznámila, že plánuje poskytování cloudovaných hostingových služeb šitých na míru Urchinu. Pro společnosti, které si nemohou dovolit náročnou instalaci a konfiguraci tohoto nástroje to tak může být zajímavá alternativa a to i vzhledem k tomu, že s touto společností lze uzavírat dvoustranné smlouvy o úrovni poskytovaných služeb včetně záruk o bezpečnosti dat a smluvních pokut v případě chyb na straně dodavatele (SLA).

Integrace

Rod Jacks z australské společnosti Panalytics představil betaverzi produktu, který umožní nahradit uživatelské rozhraní Analytics a integrovat různou úroveň dat z různých API (Google Analytics, Urchin nebo také Omniture). Formou specializovaných dotazovacích jazyků v několika různých šablonách (MS Excell, HTML a řada dalších) bude možné data díky jejich produktu transformovat do podoby, se kterou bude možné dále pracovat. Mike Chipman ze společnosti Actual Metrics dále představil nadstavbu administrátorského rozhraní Urchinu, která umožňuje hromadnou správu profilů, filtrů a uživatelů a vylepšuje možnosti časování některých automatických úkolů.

Slovo závěrem

Poslední akcí Summitu byla společná návštěva Tied House restaurace a baru v Mountain View. Překvapilo mě zejména zaujetí většiny zúčastněných, kteří i po 4-denním Summitu byli schopní několik dalších hodin debatovat na téma webové analytiky. Nám ostatním už nezbylo než zamáčknout slzu a těšit se na příští rok.

Vlastnosti:

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.