Blog

Google Analytics: Evolutia codurilor de tracking si Tooluri de debug

Povestea Google Analytics a inceput in anul 2005 cand Google a cumparat compania de web analytics Urchin. Un an mai tarziu apare Google Analytics, o solutie gratuita de tracking a vizitatorilor bazata pe Urchin. O lunga perioada de timp Google a pastrat produsul de baza Urchin pe care l-a comercializat ca solutie premium. Dar si acesta din urma a disparut, locul fiindu-i luat de Google Analytics Premium. Aceasta ar fi varianta scurta a istoriei Google Analytics, varianta lunga implica foarte multe detalii tehnice si comparatii pe cele doua produse si versiunile lor actuale.

De la lansarea din 2006 si pana in prezent, Google a oferit actualizari continuu pe Analytics, pe datele raportate, dar si pe functiile de sincronizare a datelor. Update-uri majore, in schimb, care au afectat si codurile de tracking au fost trei pana in acest moment.

Versiunea 1

Intamplator, am folosit Analytics-ul la cateva luni de la lansare. Pe finalul lui 2006 imi facusem blog si voiam sa stiu cum e cu traficul si cine ma citeste. Dupa ce mi-am pus un counter, am pus in joaca si Analytics-ul. Abia cateva luni mai tarziu am inceput sa-i inteleg utilitatea cand monitorizam traficul de pe anumite cuvinte cheie si importanta link-urilor primite. Interfata de la inceput arata ceva de genul celei de mai jos.

google-analytics-screenshot-justaddwater-2007-05-09sursa: justaddwater.dk

Prima varianta a codului de tracking si implicit prima versiune de Google Analytics avea in forma standard codul de tracking de tipul:

<script src=”http://www.google-analytics.com/urchin.js” type=”text/javascript”>
</script>
<script type=”text/javascript”>
_uacct = “UA-123123-1”;
urchinTracker();
</script>

Aceasta versiune de cod este cunoscuta si sub numele de urchin.js de la fisierul care ajuta la colectarea datelor. Toate bune cu prima versiune pana cand tehnlogia AJAX si in general JavaScript-urile au inceput sa invadeze site-urile. In acel moment, colectarea datelor a devenit partiala si Google Analytics-ul nu era capabil sa inteleaga modul in care se intampla actiunile in zone incarcate prin Ajax.

Incarcarea acestui cod era o problema si de viteza si, in unele situatii, browserul nu-l mai incarca. Din acest motiv, era recomandat ca acesta sa fie adaugat ca ultimul script din site, cat mai aproape de </body>. In felul acesta, site-ul se incarca normal indiferent daca se incarca sau nu Analytics-ul.

Versiunea 2

Pentru a rezolva partea de Ajax si viteza de incarcare a scriptului, dar nu numai astea, Google a lansat in 2007, Google Analytics V2. Acest al doilea cod avea o forma diferita fata de versiunea precedenta, dar si un nou fisier cu functii de colectare.

Daca in v1, fisierul era urchin.js, in v2, fisierul avea denumirea ga.js si un alt mod de definire a contului de Analytics si de colectare a datelor despre utilizatori si datele din cookies. Codul de trafic era de forma:

<script type=”text/javascript”>

var gaJsHost = ((“https:” == document.location.protocol) ? “https://ssl.”:“http://www.”);

document.write(unescape(“%3Cscript src=’” + gaJsHost + “google-analytics.com/ga.js’ type=’text/javascript’%3E%3C/script%3E”));

</script>

<script type=”text/javascript”>

try {

var pageTracker = _gat._getTracker(“UA-12345-1”);

pageTracker._trackPageview();

} catch(err) {}

</script>

Desi se incarca mult mai repede ca primul, inca mai erau probleme cu incarcarea lui si in continuare a ramas recomandarea de a fi plasat in footer inainte de </body>. O data cu acest cod, au venit si mai multe date in rapoartele Analytics-ului.

Versiunea 2b

In mai 2010, Google ofera un update pe codul de tracking, fara insa a schimba protocolul de colectare, ga.js. Unii considera acest update ca fiind versiunea 3 de Analytics, numarand efectiv codurile, in realitate estte doar o schimbare la nivel de colectare.

Acest nou cod este cunoscut si ca versiunea asincrona a codului de Analytics sau simplu “async”. Acest mod de colectare a adus cu adevarat plusul in viteza de incarcare si practic nu mai ingreuneaza incarcarea site-ului. Totodata, este prima versiune de cod de tracking a Analytics-ului care se recomanda sa fie plasata in partea de sus a paginii, cat mai aproape de </head>. Doar asa datele colectate au cea mai buna acuratete. Codul de tracking arata de forma:

<script type=”text/javascript”>
var _gaq = _gaq || [];

_gaq.push([‘_setAccount’, ‘UA-XXXXXX-YY’]);
_gaq.push([‘_trackPageview’]);
(function() {
var ga = document.createElement(‘script’); ga.type = ‘text/javascript’; ga.async = true; ga.src = (‘https:’ == document.location.protocol?
‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;
var s = document.getElementsByTagName(‘script’)[0];s.parentNode.insertBefore(ga, s);})();

</script>

Este usor de recunoscut prin variabila de colectare _gaq.

Aceasta versiune este in acest moment si versiunea curenta a codului de tracking pentru varianta “clasica” de Google Analytics.

Versiunea 2c

Chiar daca nu este un update si este optional, in mai 2012 Google a anuntat versiunea beta a remarketingului bazat pe audienta creata cu Analytcs-ul.  Pentru a putea face asta, este necesara o schimbare la nivel de cod de tracking. Mai exact,

bucata de cod:

ga.src = (‘https:’ == document.location.protocol ? ‘https://ssl’ : ‘http://www’) + ‘.google-analytics.com/ga.js’;

se inlocuieste cu:

ga.src = (‘https:’ == document.location.protocol ? ‘https://’ : ‘http://’) + ‘stats.g.doubleclick.net/dc.js’;

Tot aceasta schimbare in cod este necesara si pentru a putea vedea datele demografice despre utilizatori in noul raport din Google Analytics. Ca si celelalte doua versiuni, este tot asincron, deci se recomanda adaugarea lui inainte de </head>

Versiunea 3

Update-ul major in Google Analytics vine o data cu al treilea protocol de comunicare, denumit Universal Analytics (UA). Acesta a fost anuntat oficial in octombrie 2012, dar versiunea beta publica a fost oferita spre testare in martie 2013. De atunci si pana in acest moment, Analytics-ul s-a imbunatatit continuu, iar pe moment, imbunatatirile sunt aduse in ambele versiuni.

Daca de la 1 la 2 totul se facea printr-o schimbare de cod si un update la nivel de extra-tracking, trecerea de la 2 la 3 in mod automat se face printr-un sistem de migrare lansat in urma cu cateva luni. Datele se colecteaza diferit si implicit migrarea nu este una doar la nivel de cod, ci si la nivel de server.

Codul de UA arata de forma:

<script>
(function(i,s,o,g,r,a,m){i[‘GoogleAnalyticsObject’]=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,’script’,’//www.google-analytics.com/analytics.js’,’ga’);

ga(‘create’, ‘UA-XXXX-Y’, ‘auto’);
ga(‘send’, ‘pageview’);

</script>

Schimbarile sunt majore fata de V2, iar din punct de vedere tehnic, este un mod de colectare reproiectat integral. Din punctul meu de vedere, cele mai importante imbunatatiri din UA sunt cele care tin de inserarea datelor proprii si legarea Analytics-ului la sistemele proprii de CRM sau sisteme de business intelligence. Tot importanta este si promisiunea de a oferi date in mod unic despre utilizatorii care folosesc mai multe device-uri pentru a accesa acelasi site.

Ca si versiunea asincrona, codul de UA se adauga inainte de </head>.

De mentionat…

Desi surprinzator, inca mai exista site-uri care utilizeaza prima versiune de V2. Trecerea la Universal Analytics inca nu este recomandata deoarece nu exista suport pentru toate functiile (remarketingul spre exemplu nu este disponibil), insa o trecere la codul asincron era important sa se faca cel tarziu la finalului anului 2011.

O alta problema majora este pozitionarea codului de tracking. Multe site-uri il adauga inainte de </body>, in loc de </head>. Acest lucru nu face decat sa dilueze acuratetea datelor.

Debug-ul codurilor de tracking

Cele mai multe probleme cu instalarea corecta a codului de Analytics o au platformele care ofera plugin-uri in care doar treci ID-ul contului si asat-i tot. Din diverse erori, codul de tracking ajunge sa nu mai functioneze sau sa nu colecteze date din diverse functii.

Debug-ul in sine este o activitate simplu daca se rezuma doar la verificarea existentei sau lipsei de cod de tracking, insa daca site-ul utilizeaza event-uri sau alte functii, atunci este cazul de analiza avansata si doar un web analyst cu experienta o poate face. Unele lucruri solicita cunostinte avansate de programare pentru a putea intelege erorile.

In momentul de fata utilizez urmatoarele pluginuri cu care verific rapid “starea de sanatate” a codului si extra tracking-ului de Google Analytics.

Tag Assistant

O extensie de Chrome care verifica tag-urile care sunt instalate pe un cont. Este foarte utila in situatia in care utilizati un tag manager pentru instalarea codurilor de Analytics. Recunoaste toate versiunile de Google Analytics, Tag Manager-ul, dar si codurile de AdWords.

Simplu de utilizat, informatie minimala, dar utila. Se descarca gratuit de aici.

Google Analytics Debugger

unnamed

Tot un produs Google ca extensie de Chrome este si Google Analytics Debuger. Datele nu sunt afisate pur si simplu ca in cazul extensiei anterioare, ci sunt afisate in consola de JavaScript. Detalii despre cum se ajunge sunt in pagina plugin-ului. Recunoaste atat versiunea asincrona, cat si versiunea Universal Analytics.

Este foarte util pentru a vedea rapid daca se trimit corect datele spre Analytics, recunoaste si event-urile si variabilele custom, iar cine are ceva mai multe cunostinte de programare (web analytics) poate vedea mult mai multe analizand tot ce afiseaza extensia. O parte din date se pot vedea si in sectiunea Real Time, dar aici situatia este ceva mai avansata si se pot vedea mai multe informatii decat cele din rapoartele Real Time.

Ghostery

A fost prima extensie de browser folosita pentru a vedea ce coduri de tracking sunt instalate, nu stie doar de Google Analytics, recunoaste peste 1800 de scripturi. Cand l-am instalat eu prima data acum multa vreme era doar plugin de Firefox, acum este disponibil si in alte browsere.

Nu stie decat sa spuna ce este instalat, nimic mai mult. Este mai mult util de vazut ce se mai foloseste in piata ca tooluri.

WASP – Web Analytics Solution Profiler

unnamed
WASP-ul cred ca a fost primul tool de debug care oferea suport si pe Analytics. A luat nastere in 2006, iar o lunga perioada de timp a fost o extensie platita.  A fost vandut, rascumparat si intr-un final a ajuns din 2013 la Cardinal Path, un jucator important din lumea furnizorilor de servicii de web analytics. Acestea au lansat versiunea free pentru Chrome.  La cum se prezinta acum, este un instrument foarte complex si util pentru cine doreste sa faca un debug avansat.

Fiddler

Insa, de departe cea mai complexa aplicatie de debug este una care analizeaza comunicarea dintre browser si scripturile care se incarca. Iar Fiddler  asta face, o analiza in profunzime a comunicarii la nivelul de jos. Tot un instument gratuit, insa unul care este util doar celor care au experienta de intelegere a comunicarii browser->server.

***

De preferabil este sa nu ajungeti la debug complex, dar din pacate se intampla ca scripturile de tracking sa fie alterate de diverse actiuni in programare. Constant realizez verificari pe “starea de sanatate” a scripturilor si analize care sa confirme ca datele se colecteaza in parametri normali.

The following two tabs change content below.

Bogdan Pantoc

Web Analytics & Web Performance at Funnel
Autor al cartii Analiză Web – Descoperă tot ce trebuie să știi despre vizitatorii siteului tău. Specializat in web analytics, conversion rate optimization, usability si user experience, PPC.

  Autor:

Copyright 2017- Funnel Web Performance