Op het SEOmoz blog stond afgelopen week een interessant artikel over hoe je met Google Analytics de prestaties van bepaalde site-secties beter kunt monitoren. Het stelt je in staat om rapportages zoals de volgende te maken, waarmee je de verschillende onderdelen van een site beter kunt monitoren:

seomoz stacked site sections

Dit is inderdaad een supertip, maar de methode om de data te vergaren is nogal... omslachtig en … inflexibel en … onnodig arbeidsintensief en .... je raadt het al, dat kan beter ;)

Ik ga ervan uit dat je het SEOmoz artikel gelezen en begrepen hebt. Als dat niet zo is, moet je eerst nog ff wat huiswerk doen. Hoe dan ook, ik noem die methode de 'profile & URL based filter' methode.

Laat ik eens beginnen met vertellen wat er volgens mij allemaal mis mee is.

Nadelen profielen-/filtermethode

#1 Fragmentarische rapportages

Bij SEOmoz (en niet alleen daar, kan ik je vertellen) maken ze gebruik van profielen en daarbinnen wordt alleen de data verzameld die aan een bepaald filter voldoet. Nadeel hiervan is dat je per profiel apart moet kijken wat de data is, dat exporteren naar een spreadsheet, dat herhalen voor de andere profielen, etc. Hun analytics guru, Joanna Lord, is hier elke week zeker een uur mee bezig (maar inmiddels is ze al naar de customvars aan het kijken ;))

Als je dit automatiseert met de API, dan kun je delen van dat werk al opvangen, maar dan moet je wel de technische know-how hebben om dit aan te pakken (je kunt eventueel dit script gebruiken). Maar dat is veel moeite, voor veel mensen te technisch, en eigenlijk ook onnodig.

#2 URL based filtering

Tweede nadeel van deze methode (en van geavanceerde segmenten, die je ook hiervoor kunt gebruiken), is dat de filtering plaatsvindt op basis van URL-patronen. Als je bijvoorbeeld een bepaalde sectie of categorie van je site wil uitlichten, dan kun je die 'vangen' door te filteren op basis van een URL-patroon. Als ik bijvoorbeeld alle blogartikelen wil filteren op monlog.nl, dan filter ik op alles wat '/logs/' in de URL heeft.

Meerdere categorieën

Op zich werkt dat wel, maar wat doe je als je je artikelen hebt ingedeeld in categorieën, en je hebt artikelen die in meerdere categorieën zijn geplaatst? Niet zelden past een artikel in zowel categorie A als B. Bij een standaard Wordpress systeem kun je artikelen al in meerdere categorieën plaatsen.

Verwerk je al die categorienamen in de URL? Dat zou al snel hele lelijke URLs opleveren. Toch wordt dit gedaan, helaas.

Categorienaam staat niet in URL

En wat doe je als een URL bij een bepaalde sectie hoort, maar de naam van die sectie (bijvoorbeeld een categorie) is niet verwerkt in de URL?

Categorienaam staat per ongeluk in de URL

Of als je filtert op een bepaald woord in de URL, en dat woord wordt toevallig ook genoemd in een ander gedeelte van de URL (als bijvoorbeeld de URL gegenereerd wordt naar voorbeeld van de titel van het artikel), terwijl het niet tot die categorie behoort? Dan wordt het wel meegenomen in de telling van je filter.

Hoe dan wel

Waar het op neerkomt is dat URL based filtering wel redelijk goed kan werken voor kleine sites met een goed uitgedachte informatie-achitectuur en URL-hierarchie, maar dat het voor grotere sites niet flexibel genoeg is. Dat geldt bijvoorbeeld zeker voor grotere blogs/magazines/kranten... Het soort sites waar ik dagelijks mee werk zeg maar ;)

#3 Statische profielen

Een ander nadeel, wat ik vooral als programmeur vervelend vind, is dat het definiëren van zo'n profiel met een filter statisch is. Als een categorienaam gewijzigd wordt (en vaak daarmee ook de URL), dan werkt het filter niet meer.

Ervan uitgaande dat je dit op voorhand al wist, kon je dat tegelijkertijd aanpassen, maar de helft van de tijd weet je niet eens dat een categorienaam/url gewijzigd is. Daar kom je pas achter als de redacteuren je in paniek bellen omdat de traffic van een bepaalde sectie is ingestort ;)

Hoe het dan wel moet

Wat je dan eigenlijk nodig hebt, is dat jouw CMS-systeem Google Analytics simpelweg laat weten dat de URL gewijzigd is van die sectie, en dat de datavergaring van GA zich daaraan aanpast. De naam van een categorie moet dus A: variabel zijn, en B: gegenereerd worden door je eigen CMS systeem, zodat het altijd up to date is.

#4 handwerk

En wat ik als efficiency-maniak ook vervelend vind, is dat dit allemaal onnodig handwerk is. Iedere repetitieve handeling moet je automatiseren! Dat scheelt tijd en dus geld: in het geval van SEOmoz bijvoorbeeld 1 uur per week = 52 uur per jaar.

Hoe dan wel? Customvars

Je begrijpt dus wel dat ik op zoek ging naar iets beters. Mag ik u voorstellen: Custom variables.

Ik hou niet zo van overbodige herhaling, dus verwijs je eerst naar de helpsectie van Google Analytics over hun Customvars: lezen.

Maar heel in het kort voor de luie mensen onder ons: je kunt zelf bepaalde data Google Analytics inschieten door de standaard trackingcode aan te passen.

Een heel concreet – en voor (grote) blogs zeer bruikbaar – voorbeeld is dat je bepaalde secties van je site wil analyseren, dat ze niet (goed) te groeperen zijn op hun URLs en dat je ze snel bij elkaar in 1 overzicht wilt kunnen bekijken en exporteren voor verdere analyse. Daarnaast maak je gebruik van een hiërarchie in je categoriestructuur: je wil hoofd- en subonderwerpen apart en in relatie tot elkaar kunnen analyseren en bekijken.

Hiervoor heb je de zogenaamde 'Page Level' custom variables nodig. Een korte uitleg vind je hier: lezen.

Zorg dat je snapt wat met 'slots' en 'scope' bedoeld wordt.

Plaatsing van de customvars

Er zijn verschillende zaken die je moet onthouden. Allereerst is de rapportage van deze data nogal traag. Je moet bijvoorbeeld al zeker 2 dagen wachten na installatie om te zien of het überhaupt werkt.

Daarnaast maakt het uit welke versie van de Google Analytics tracking code je gebruikt. Als je besluit om dit te gaan toepassen en online gaat zoeken naar voorbeelden, dan zul je voornamelijk voorbeelden tegenkomen die uitgaan van de ouderwetse trackingcodes van Google Analytics. Maar inmiddels is de asynchrone trackingcode standaard. Wat je dan kunt doen is _setCustomVar in _gaq.push duwen voordat je _trackPageview aanroept:

<script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(

['_setAccount', 'UA-XXXXX-X'],
['_setCustomVar', 1, 'Sectie', 'Sectienaam', 3],
['_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>

Hoe ik dat weet? Nou ik heb dit gelezen.

Praktijkvoorbeelden

Ik vond dat deze twee artikelen een duidelijke en goed begrijpbare uitleg geven, inclusief plaatjes voor degenen die willen zien hoe het resultaat zal zijn:

ga custom variables example report

Conclusie

Zoals je ziet kun je met die Custom Vars heel veel bereiken, dus ik raad je aan om ze eens goed te bestuderen! p.s.: ik ben geen analytics guru, dus als iemand een betere methode weet die ik nog niet ken (en dat is dus zeker mogelijk), dan hoor ik dat graag! Happy analizing!


Monlog

Deel dit SEO artikel met: