Het eerste deel van dit artikel heeft hopelijk duidelijkheid geschept over hoe event tracking werkt en hoe deze gebruikt kan worden. Als dit niet het geval is dan beantwoord ik eventuele vragen graag via de comments.

Bijwerkingen van Google Analytics event tracking

Wanneer event tracking geïmplementeerd is kunnen globale metrics een andere trend aannemen dan voorheen. Dit komt omdat een event door Google gezien wordt als een gebruikersactie, er gebeurt iets dus dit heeft effect op een aantal zaken zoals time on site, time on page en bounce rate.

Als event tracking zo geïmplementeerd wordt dat elke pagina request automatisch een event laat uitsturen om een bepaalde system event te tracken (bijvoorbeeld een flash applicatie die zijn status als event stuurt, ook bij eerste binnenkomst) dan ziet Google dit dus als een gebruikersactie. Omdat deze actie altijd plaatsvindt, en Google Analytics ervan uitgaat dat een gebruiker iets deed dat deze event veroorzaakte, kan deze pagina request dus per definitie geen bounce meer zijn.

Met andere woorden: Event staat gelijk aan geen bounce. Als de actie altijd gebeurt dan is je bounce rate 0.0% voor elke request.

Verklaarbaar

In principe is deze redenering van Google heel goed te begrijpen, als een gebruiker iets doet op je site dan bouncet deze niet. Een beetje tegenstrijdig van ze is dat ze dan wel een plugin aanbieden die de laadtijd van elke pagina meet en per event naar Google Analytics stuurt. Kijk maar naar de TimeTracker plugin.

Pas op

Als event tracking geïmplementeerd wordt dan is de kans dat de globale waarden voor bounce rate, time on site en time on page veranderen. Dit kan weer impact hebben op andere cijfers die wellicht gebruik maken van deze metrics om uiteindelijk tot een KPI te komen. Dus als event tracking geïmplementeerd wordt dan is het mogelijk dat bepaalde KPIs opeens hele andere waarden laten zien dan voorheen.

Anders is niet altijd verkeerd

Zoals ik al eerder aangaf is het best te verklaren waarom event tracking een impact heeft op interactie gerelateerde metrics zoals bounce rate. Het hoeft dan ook niet te betekenen dat verschil in cijfers slecht is, het kan zelfs beter zijn dan voordat event tracking mogelijk was.

Vele websites hebben tegenwoordig de mogelijkheid om met componenten te interacteren en voor deze acties is geen nieuwe page-load nodig. Als een bezoeker op een webpagina komt daar met enkele Flash/Ajax componenten speelt en daarna weg gaat dan wordt dit zonder event tracking als een bounce geregistreerd. Hetzelfde is het geval als een gebruiker op een content pagina komt, daar een minuut de content leest en dan weg gaat.

Beide voorbeelden hierboven zullen dus een bounce registreren, maar dat zijn ze in feite niet.

Event tracking helps 😉

Hier kunnen we dus events gebruiken om een beter beeld te schetsen. In het geval van interacties met een Flash/Ajax of ander element waarvoor geen pagina (re)-load nodig is, kan worden volstaan met event tracking voor deze applicatie. Dat kom mooi uit, want als dit soort applicaties aangeboden worden op een website dan is het toch goed om het gebruik hiervan te meten om te zien of deze hun doel bereiken.

In het geval van pagina´s met daarop interessante content komt er iets meer bij kijken om van de verkeerde bounces af te komen..

Meten van interesse op een enkele (landings)pagina

Als je een content heavy site hebt waar veel mensen binnenkomen via zoekmachines zal je vaak een hoger dan gemiddelde bounce rate zien omdat zoekende mensen vaak maar in een ding geïnteresseerd zijn, namelijk de content waar ze naar zoeken. Als het doel van de site is het informeren van bezoekers dan is het dus belangrijk om deze bezoekers te identificeren en ervoor te zorgen dat deze niet als bounce gemeten worden. Dit is mogelijk door een enkele regel Javascript te gebruiken die een Google Analytics event aanroept.

setTimeout(pageTracker._trackEvent,30000,"interest", "view", ´content naam´);

Kijk hier voor meer uitleg over de Javascript functie.

Let op dat het gebruik van de Javascript setTimeout functie niet zonder risico´s is, als je geen ervaring hebt met Javascript schakel dan een expert in om het voor je te doen.

Deze regel zet een timer die over 30 seconden een event naar Google Analytics stuurt. Deze event zorgt voor 2 dingen:

1. Een event is gestuurd, dus deze bezoeker wordt niet geregistreerd als een bounce.
2. De content naam wordt meegestuurd, zodat je in Google Analytics kunt zien welke content veel gelezen wordt.

Omdat het bezoek nu niet als een bounce gemeten wordt is zijn ´tijd op site´ en ´tijd op pagina´ gemeten niet 00:00:00 zoals dit normaal gesproken het geval zou zijn, zelfs als een bezoeker 3 minuten naar één pagina kijkt voordat deze de site verlaat. De reden hiervoor is dat Google Analytics gewoon geen manier heeft om te meten wanneer een bezoeker de site verlaat. Door een event te sturen meet u dus in ieder geval de gebruikers die langer dan de gespecificeerde tijd naar een pagina kijken waardoor je feitelijk interesse kunt meten.

Omdat er een ´content naam´ moet worden meegestuurd voor het meten van interesse is het tevens mogelijk de content wat flexibeler te meten zonder dat de paginanamen daarvoor moeten worden aangepast. Stel de site laat informatie zien over koffie en er zijn per soort koffie 3 pagina´s. U kunt dan de naam van de koffiesoort en de pagina insturen, maar u kunt dan ook beslissen om enkel de koffiesoort in te sturen en zo de interesse voor de koffiesoort in zijn geheel meten.

Hoe lang de definitie van interesse is zal per site verschillen, maar zet dit niet te kort; de eerste 7 seconden bijvoorbeeld zullen bezoekers nog overwegen of een pagina interessant is of niet en kunnen ze alsnog weggaan voordat ze de content goed gelezen hebben.

De kanttekening die ik bij deze methode wil plaatsen is dat je natuurlijk ook mensen meet die een pagina openen, een kopje koffie gaan halen en als ze terug zijn, naar een andere site navigeren. Het is een afweging die gemaakt moet worden om te beslissen welke methode realistischere cijfers zal laten zien, want als je niks doet dan meet je de mensen die wel geïnteresseerd de pagina lezen en daarna weggaan als bounces.

Andere belangrijke details voor gebruik van event tracking

Request limiet

Let op dat er een limiet zit aan requests die per sessie gedaan kunnen worden aan Google Analytics. Per gebruikersbezoek pikt Google ongeveer 500 requests op. Als er meer verstuurd worden dan zal Google sommige requests niet registreren. In 99 % van de gevallen zal die limiet niet overschreden worden. Als dit wel het geval is dan adviseer ik zeer kritisch te kijken of alle events die gebruikt worden echt nodig zijn om te meten.

Geen conversies

Op het moment dat ik deze blog post is het nog niet mogelijk om conversies te zien die door events zijn getriggered, dit is een groot gemis voor deze feature en ik hoop dat Google dit in de toekomst alsnog mogelijk maakt.

Dit is het einde van deel twee van dit artikel over event tracking met Google Analytics. Als er vragen en/of opmerkingen zijn dan zie ik deze graag terug in de comments van deze blog.