Bijwerkingen van Event Tracking met Google Analytics

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.

Reacties (8)

  1. Op zich lijkt het een handige functionaliteit die javascript setTimeout. Maar ik vraag me af in hoeverre dit een goed beeld geeft van de daadwerkelijke interesse. Er zit volgens mij namelijk een veel te groot gedeelte met ruis tussen. Wanneer ik uit eigen ervaring spreek heb ik gemiddeld denk ik zo’n acht pagina’s tegelijk open staan in verschillende tabbladen en browsers, terwijl ik er maar één tegelijk kan bekijken. Dit betekent dat er maximaal maar 12,5% van mijn mogelijke javascript timeout’s daadwerkelijk correct meten. Ik denk dat de meeste mensen die websites bezoeken gemiddeld toch wel meer dan twee pagina’s open hebben staan. Dit betekent als dat er dus meer ongeldige metingen zijn dan geldige metingen. Of zie ik hier iets vekeerd?

    Ik zit me ook af te vragen of een statistieken pakket niet op één of andere manier kan meten wanneer ik een pagina verlaat. Om een voorbeeld te noemen: Google Docs kan ook meten wanneer ik een pagina verlaat of een ander URL intyp. Ik krijg dan een melding of ik het bestand wil opslaan. Is het niet mogelijk om in plaats van die meldingen een script te activeren die aangeeft aan Analytics dat de pagina verlaten wordt? Graag je reactie!

  2. Ik heb nog niet kunnen ontdekken dat event tracking van invloed is op de time-on-site en time-on-page. Voor zover ik weet wordt alleen je bouncerate er door beinvloed, en dat heeft Google bewust ‘by-design’ gedaan.

    De manier waarop jij de setTimeout gebruikt werkt niet in Internet Explorer, die accepteert geen extra argumenten in de setTimeout aanroep. Maar het is goed dat je de waarschuwing eronder hebt geplaatst 😉

  3. @Jeroen: Klopt, het zal zeker een bepaalde mate van ruis genereren. Per site is het een afweging die je kan maken. Als je bijvoorbeeld een e-hop hebt dan is deze implementatie een stuk minder interessant dan op een tekst gerelateerde site zoals een blog.

    Ik snap dat sommige mensen veel met tabs werken (ik ben er zelf een van), maar ik denk dat je dit meer zult zien bij internet professionals dan bij de gemiddelde gebruiker. Als ik dan moet kiezen tussen enige ruis of geen enkele data dan kies ik toch voor de ruis.

    De techniek die gebruikt wordt voor de melding van Google Docs die je krijgt voordat je een pagina verlaat kan helaas niet betrouwbaar ingezet worden voor dit doeleinde. De reden hiervoor is dat als je een request afschiet naar Google terwijl de gebruiker naar een andere pagina gaat of deze juist afsluit, dan abort de request en wordt er niks verstuurd. Ik ben bang dat dit in 99% van de keren zo zal zijn.

    @Andre:
    Bedankt voor je tip. ik heb dit script kennelijk uitvoeriger getest in Google Analytics dan op browsers, dit deel van het script is dan ook nog steeds in een uitprobeerfase, mede omdat ik graag wilde zien wat de andere experts hier op webanaliste.nl van het idee vinden. Ik zal binnenkort een beter compatible script plaatsen die in alle browsers werkt.

    Overigens heb ik in mijn tests wel kunnen zien dat de time-on-site en time-on-page worden beïnvloed. Ik kan dit vrij gemakkelijk zien, want als dit script uitgevoerd wordt en het is de laatste actie van de bezoeker dan is time-on-site en time-on-page exact 00:00:30.

  4. Het zou mooi zijn als je met behulp van filters in Google Analytics de events in sommige profielen buiten beschouwing kon laten. Dan behoud je tenminste altijd je oorspronkelijke data.

  5. Beste,

    Ik heb een vraag waar ik niet snel een antwoord op vind.
    Stel: Ik heb een profiel met even tracking. Load en play van een movie.
    Op dit profiel zet ik een ander profiel met een filter op bepaalde foldernamen.
    In het gefilterde profiel wordt de event tracking niet doorgegeven.
    Waarom niet en hoe kan ik dit bekomen?

    Dank voor de hulp.

  6. Hallo Frederic,

    Ik ben bang dat ik iets meer informatie nodig heb om je te helpen met dit probleem. Ik gebruik zelf ook gefilterde profiles en daar heb ik verder geen problemen mee m.b.t. event tracking.

    Je kan mij eventueel emailen met meer specifiekere details (die ik natuurlijk voor mij zal houden), dan kan ik je misschien wat beter helpen.

Reacties zijn gesloten.