Bereken het werkelijk bouncepercentage

Deze maand schreef ik al eerder over het bouncepercentage, en wat er eigenlijk mis mee is. Advies is om dat artikel eerst even te lezen.
In dat artikel kwamen we erachter dat het bouncepercentage, zoals nu gebruikt door Google Analytics, niet realistisch is. Of beter gezegd, het klopt gewoon niet. Hoe dat precies zit? Lees eerst even het artikel "Waarom een hoog bouncepercentage niet verkeerd hoeft te zijn".
In de tussentijd ben ik op zoek gegaan naar een oplossing, want ik ben van mening dat het ronduit slecht is dat de gegevens in Google Analytics rond het bouncepercentage niet kloppen. In dit artikel vind je "mijn" oplossing, en de eerste resultaten.

Het probleem: 1 pagina bezocht = 100% bounce

Zoals Google Analytics nu meet is elk 1-pagina-bezoek een bounce. Maar is dat wel het geval? Wat als iemand een artikel op mijn website leest, wat reacties bekijkt en daarna aan de slag gaat met de informatie uit het artikel?
Is dat een bounce? Nee. Sterker nog, dit is misschien wel een zeer tevreden bezoeker.

De oplossing: Na 20 seconden automatisch een event triggeren

Het probleem waarom Google Analytics geen tijd op pagina kan berekenen (en bij een 1-pagina-bezoek dus altijd een bounce registreert) ligt aan het feit dat ze minimaal twee pagina's nodig hebben om die tijd op pagina te bereken. Nogmaals, als je niet begrijpt wat ik bedoel, lees eerst even het artikel "Waarom een hoog bouncepercentage niet verkeerd hoeft te zijn".
Hiervoor hebben we de volgende oplossing:

Wanneer iemand op onze website komt, en de eerste pagina bekijkt, wordt er na 20 seconden automatisch een event getriggerd. Dit zorgt ervoor dat er geen bounce meer wordt geregistreerd. Wordt er maar één pagina bekeken, en duurt het bezoek korter dan 20 seconden is het een bounce, daarboven niet meer.

 

Waarom 20 seconden?

We hebben er een tijdje over gebrainstormd, en kwamen tot de conclusie dat wanneer iemand langer dan 20 seconden op onze pagina is hij ook daadwerkelijk aan het lezen is. Uiteraard is deze tijd voor discussie vatbaar.

Voorbeeldcode

Let op, voordat je deze code toevoegt aan je pagina's even een kleine waarschuwing. Het zal je statistieken overhoop gooien! Ik raad je dus aan om deze code alleen te gebruiken als je weet waar je mee bezig bent. De tijd op pagina/site zal stijgen, en het bouncepercentage waarschijnlijk sterk dalen! Het bevindt zich ook allemaal nog in een testfase, dus gebruik is op eigen risico. Verder werkt deze code alleen als je de nieuwe Google Analyticscode gebruikt.
De volgende code hebben we toegevoegd aan elke pagina op onze website, net voor de sluit-bodytag:
{code type=codetype}
<script type="text/javascript">
  if (document.referrer.indexOf(document.domain) == -1)
  {
    setTimeout("_gaq.push(['_trackEvent', 'Time', '20 seconds']);", 20000);
  }
</script>
{/code}

Met grote dank aan Andre Scholten voor het aanleveren van deze code!

 

De resultaten

Na een weekje deze code op onze website te hebben gedraaid krijgen we de volgende statistieken voor wat betreft het bouncepercentage:

Leuk, maar wat kan ik hiermee?

Zoals ik al eerder aangaf geeft dit voor ons een veel realistischer beeld. De volgende stap die we nu kunnen nemen is het inzetten van deze nieuwe statistieken om de werkelijke probleempagina's te ontdekken.
We krijgen door deze nieuwe toepassing namelijk twee soorten pagina's:

  • Pagina's met een echte bounce (korter dan 20 seconden op onze website/pagina);
  • 1-pagina-bezoeken

Beide zijn nu een stuk realistischer wat het optimaliseren een stuk eenvoudiger zal maken. Hoe we dit precies gaan aanpakken zal later deze week in een vervolgartikel verschijnen.
In de tussentijd ben ik benieuwd naar jullie mening en visie over dit onderwerp en deze oplossing!

Ook succesvol adverteren met Google AdWords?
Bekijk onze cursus Google AdWords, onze Google AdWords dienst of vul ons formulier in


Adverteer jij al via Google AdWords? Vraag dan onze gratis Google AdWords Quickscan aan!

  1. Very good job Karel en Andre!
    Ik heb nog een vraagje: Meet deze code wel de time on page? Zet die deze standaard dan op 20 sec? Kortom hoe zit dat?
    Het aanmaken van een extra websiteprofiel (dus geen account) is een oplossing zodat je je cijfers niet allemaal overhoop gooit.

    1. Wanneer een bezoeker verder niets op de pagina doet (geen andere events triggered) zal de tijd op site/pagina inderdaad 20 seconden zijn.
      Het aanmaken van een extra profiel zou een mogelijkheid zijn maar weet dat niet zeker. Die code voor dat event staat los van de Analyticscode. Misschien als dat event gefilterd wordt.

  2. Wat mij betreft is het geen kwestie van goed en fout, maar een definitieverschil. Net als metrics zoals time on site en site-speed, waar je goed moet weten wat de definities zijn, om geen verkeerde conclusies te trekken.
    Mijn voorkeur gaat ook uit naar tijd op de pagina. In speed-trap wordt de bouncerate al automatisch berekend o.b.v. tijd op de pagina. Deze staat op 15 seconden, geloof ik. Het is wel interessant als je beide statistieken naast elkaar hebt, dat is nog waardevoller denk ik.

  3. Wat een interessant artikel. Het blijkt maar weer dat sommige verbeterpunten zich in de kleine details vinden. Brainstormen is heel effectief. Toch wordt dat vaak onderschat.

  4. Je hebt gelijk dat de definitie van GA's bounce-rate voor discussie vatbaar is. Ook heb je gelijk als je stelt dat een bezoeker die maar 1 pagina bezoekt niets aan het bezoek heeft gehad.
    Onderstaande reactie is uitsluitend van toepassing als je de GA rapportages die zijn gebaseerd op jouw 'oplossing' deelt met derden. Voor eigen gebruik moet je zelf weten wat je doet, maar naar derden toe moet je hiermee ontzettend oppassen:
    Ik vind de 'oplossing' die je beschrijft gewoonweg helemaal fout: je probeert een 'correctie' in te bouwen die voor de volle 100% is gebaseerd op een aanname.
    De 'kritiek' die je hebt op de definitie die Google hanteert geldt ook voor wat jij hiermee doet, maar dan net andersom: hoe wil jij verifiëren dat de bezoekers in de 20 seconden threshold die je inbouwt daadwerkelijk jouw site leest? Voor hetzelfde geld krijgt de bezoeker een telefoontje die hij/zij moet afhandelen.
    Nog veel erger is dit: jouw 'oplossing' heeft duidelijke consequenties voor, en beïnvloed andere meetwaarden (zoals iemand anders al noemde). Het middel is hiermee erger geworden is dan de kwaal.
    Google maar eens op Level-of-Granularity (in de context van datawarehousing), of lees eens een boek van Ralph Kimball, en koppel deze kennis aan de meetwaarden die betrekking hebben op aantal opgevraagde pagina's en tijden per pagina (plus mogelijk andere meetwaarden) van GA.
    Je zult dan hopelijk snel begrijpen dat het zowel onwenselijk als onmogelijk is om betrouwbare rapportages te krijgen die onder het laagste level of granularity liggen...
    Als je rapportages gebaseerd op jouw 'oplossing' deelt met derden is de situatie nog veel ernstiger: je ondermijnt dan de 'autoriteit' van GA in zijn totaliteit doordat er oneigenlijke definities aan ten grondslag liggen.
    Nogmaals, dit soort trucs werken prima voor jouw eigen site, maar doe dit niet voor sites en Adwords-campagnes die je mogelijk voor klanten beheert! Als je dit soort trucs uithaalt voor beheerde sites/campagnes, dan kan ik maar één reden bedenken waarom je dit zou doen: cijfers mooier laten lijken dan ze zijn om daarmee eigen falen te maskeren.

    1. Beste Marcel,
      Ontzettend bedankt voor je uitgebreide reactie! In heel veel punten geef ik je ook 100% gelijk. Ik geef ook duidelijk aan in het artikel dat het op eigen risico is, en dat we hier zelf gewoon mee aan het testen zijn.
      Ik blijf er wel bij dat in onze situatie er nu betere rapporten ontstaan, die ik kan inzetten voor verdere optimalisatie van deze blog. Het mag ook voor zich spreken dat ik dit nooit zou toepassen op andere websites / websites van klanten. Want dat het de data door elkaar gooit, dat mag duidelijk zijn.
      Brengt me eigenlijk ook op een ander punt. Ik zet GA in voor optimalisatie van onze blog. En ik pas het zo aan dat ik er, naar mijn mening, ook echt iets aan heb. Het gaat me dus niet om "een zo laag mogelijk bouncepercentage". Maar ik wil wel weten welke pagina's een bounce geven volgens GA, terwijl de inhoud wel gelezen wordt. Op die manier kan ik meer leren over de verschillende bezoekers/artikelen en daar verder op inspelen.
      Nog iets anders. Heb je geen interesse om eens een artikel te schrijven over dit onderwerp, zodat we er allemaal wat meer van kunnen leren? Lijkt me erg leuk!

  5. Hoi Karel,
    Ik heb hier vaker mee gespeeld (http://padicode.com/blog/analytics/the-real-bounce-rate/), maar het geeft nog niet de informatie die je echt wilt hebben. Je wilt weten of er wel of geen interactie is geweest met de webpagina (van klikken tot scrollen tot typen). Totaal geen interactie kan dan alsnog een non-bounce betekenen omdat men wel gedurende bepaalde tijd een interactie met het merk heeft gehad. Om dit goed te bepalen wil je dan elke halve minuut of minuut een event via Google Analytics meten (zodat je een AB test vanwege de bouncerate nog beter kunt beoordelen). Wat ik echter altijd in het laatste geval doe (je wilt immers meten om te verbeteren) is een clickmap, mousemove en screenrecording tool meelaten lopen, zodat je nog beter (geaggregeerd en gevisualeerd) weet wat het bezoekersgedrag is.
    Voor het beoordelen van je contentkwaliteit (op bijvoorbeeld een weblog) is de verbeterde non-bounce wel een prima aanvullende metric.

  6. Duidelijk artikel er blijft voor mij alleen 1 vraag over.
    Heeft een hoge bounce rate effect op je Google indexering / ranking / authority.
    In dit geval zou deze code die een terechte verlaging van de bounce rate geeft nog meer voordelen kunnen bieden.

    1. Als dat zo was zou ik er voor zorgen dat mijn bouncerate op 0 zou komen te staan 😉 Je kunt er 100% van uit gaan dat Google daar niets mee doet. Het is zelfs zo dat Analytics data niet door de andere Google teams (kwaliteit, spam, etc) te benaderen/gebruiken is.

    1. Wanneer het een "offline conversie" betreft (telefoon, adresgegevens) heb je gelijk. Zie ook het eerdere artikel wat ik aanhaal in dit artikel. Bij een online conversie niet, want dan vind er een te meten actie (nieuwe pagina, event) plaats, en is er dus geen sprake meer van een bounce.

  7. Ga volledig akkoord Karel. Bovendien kan het zijn dat de landingspagina volstaat met video's waarvan een bezoeker er een 10-tal bekijkt en dan je website verlaat. Dit zal een bounce geven, terwijl je content echt wel relevant bleek voor de bezoeker. Daarom is het belangrijk events op pagina's bij te houden en deze in rekening te nemen als je het bounce percentage bekijkt.

  8. Ik ben het niet eens met dat nu de bouncerate aangepast wordt. Hij blijft immers een bounce, alleen wil je weten of het een nuttig bezoek is geweest. Naar mijn mening moet je hier met custom variabelen werken die getriggerd worden of events die de bouncerate niet beïnvloeden. Wanneer je daarna een pagina gaat analyseren dan moet je met geavanceerde segmenten werken om tot conclusies te komen.
    Maar het blijven bounces, want ze hebben maar één pagina bekeken en zijn weer weg. Nu ga je de betekenis van bounce rate ombuigen naar mooie statistieken.
    Uiteraard sta ik open voor commentaar.

  9. interessante gegevens!
    Ik ben het eens met Karel Geenen: het is niet erg dat men "slechts" 1 pagina bezoekt, omdat het blijkbaar voldoende is voor de bezoeker, om daarna contact om te nemen met de aanbieder.
    Die ervaring heb ik al vele jaren. Dank iedereen voor de nuttige info. Ron

Reageren

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Terug naar top