Adaptive Mind

Posts Tagged ‘javascript

Warning: this is pretty heavy JavaScript stuff.

If you’d ask what the most used web analytics solution is, you would probably get pretty obvious answer. But what is not so obvious to the most people who use Google Analytics is the fact that it is a piece of JavaScript and it can be customized a lot. Especially these days when we measure dynamic websites full of JavaScript features that stay hidden to the basic generated tracking script.

Frontend developers got used to benefit from JavaScript libraries like jQuery that help them not to write repetitive code, resolve a lot of cross-browsers issues and achieve a better maintainability of their code. And as I said before, Google Analytics Tracking Code (GATC) is just another piece of JavaScript that you include into your website, so why wouldn’t you give it the same treatment as to the rest of the scripts.

A little optimized basic asynchronous tracking script (Google recommends to put it into your document’s <head> section as an inline script):

var _gaq = [];

_gaq.push(

       ['_setAccount', 'UA-XXXXXX-X'],   // doplnit vlastní ID účtu

       ['_trackPageview']

);

 

(function (d, t) {

       var g = d.createElement(t),

             s = d.getElementsByTagName(t)[0];

       g.async = 1;

       g.src = ("https:" === d.location.protocol ? "https://ssl" : "http://www");

       g.src += ".google-analytics.com/ga.js";

       s.parentNode.insertBefore(g, s);

}(document, "script"));

With this article I would like to start a series of implementation tips that should help you to make the most of Google Analytics implementation using the features of the most popular JavaScript library jQuery.

Prerequisites

And when I say that the tracking script is just another piece of JavaScript, I would give it a proper treatment also in terms of your website’s performance. Because the most of the setting script doesn’t change, you can remove it from the inline script block and include it (minimized) into a JavaScript bundle to:

  1. allow the browsers to cache some extra bytes of code;
  2. decrease the needed number of HTTP requests to your server.

Because we are going to use jQuery library, the only thing that you have to do is to make sure, that the library will be initialized, when we will need to use it. So I would recommend that jQuery is the first and our setting script the second script in the bundle. It might look like in this file.

First tip: Custom Events

With this functionality which is built-in the jQuery library you can easily measure activity of your website’s visitors that is purely controller by another JavaScript within a single page. You can use it for interactions with tabbed content, carousels, pagination or whatever you decided to implement in JavaScript or AJAX to enrich your visitor’s experience.

Somewhere within your JavaScript code:

// Fire Event

$(document).trigger("custom", [{

       param: "value"

}]);

The corresponding part handling the event:

// EVENT HANDLER

$(document).bind("custom", function (e, extraParameters) {

       alert(extraParameters.param);

});

The main advantage of this approach is that you can set some basic conventions for your frontend developers so they would fire a Custom Event on every measurable interaction. Then it is up to you whether you will implement the event’s handler to do the actual measurement.

Example 1: Measuring AJAX calls

You should probably measure only the successful requests, so the code might look like this:

// in the AJAX call definition

$.ajax({

       url: "myurl.html",

       success: function(){

             // ...

             $(document).trigger("ajax:call", [{

                    trackURL: $(this).url

             }]);

       }

});

And when you decide to measure this event, you can simply extend your GATC

// EVENT HANDLER

$(document).bind("ajax:call", function (e, extraParameters) {

       _gaq.push(["_trackPageview", extraParameters.trackURL]);

});

Conclusion

I hope this was somehow useful to you. I would like to continue with similar tips, so stay tuned.

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.

…aneb pozor na innerHTML v Exploreru

Vzhledem k tomu, že mi tahle peripetie ukradla dnes půl hodiny života, rozhodl jsem se, že ji zveřejním, třeba existuje někdo, kdo o ní neví a pomůžu mu.

Kapitola první – Microsoft je zase chytřejší než konkurence…

…a přesně ví, kam který element patří.

Proto vás nenechá poměrně oblíbenou JavaScriptovou funkcí innerHTML vložit některé věci, které nevyhovují standardům (nebo Exploreru?).

Příklad

Nelze vložit <form> do jiného <form>u. Obdobně to funguje například při vkládání blokových objektů do paragraphu atd.

Kapitola druhá – chybové hlášky, jak jsme na ně zvyklí

Kámen úrazu je ovšem to, jak se tato nevole prohlížečů z dílny výše zmíněného výrobce „vkládat něco někam“ projeví. Exception, která je v tuto chvíli vyhozena zní „Neznámá chyba při běhu programu“ („Unknown runtime error“) a pakliže neošetřujete většinu svého kódu konstrukcí try {} catch (error) {}, nedozvíte se ani to. Pak si zkuste něco ladit.

Vlastnosti: ,