In een van de voorgaande artikelen over deze optimalisatiecase hebben we een experimentopzet beschreven waarin we besloten te kijken naar de invloed die de indeling van de pagina heeft op de bounce-rate van de website. Dit experiment loopt inmiddels en er zijn een aantal ontwikkelingen die ik met jullie wil delen.
Een betere kijk op de bounce-rate
Het overgrote deel (94%) van de site-bezoekers op gratisadviseurs.nl komt binnen via een zoekmachine en landt direct op een vraag/antwoord pagina. Indien een bezoeker vervolgens langer dan 30 seconden naar deze pagina kijkt dan kunnen we wellicht spreken van een geïnteresseerde bezoeker die misschien zijn/haar vraag ook wel beantwoord ziet en daarmee succesvol is. Door het toevoegen van een script aan de pagina worden deze 1 paginabezoeken van 30 seconden of meer niet meer als een bounce gezien op gratisadviseurs.nl. Dit script ziet er als volgt uit (met dank aan Joost de Valk):
onload=”setTimeout(‘pageTracker._trackEvent(\’Still Viewing:\’, window.location)’,30000)
Na implementatie van het script daalde de bounce-rate van 68% naar 38%. Deze 38% zijn dan dus bezoekers die slechts 1 pagina hebben bekeken en binnen 30 seconden weer zijn vetrokken.

We blijven er naar streven om deze bounce-rate verder te verlagen omdat een bezoeker idealiter niet mag ´bouncen´ op deze site. Wordt er een antwoord op de vraag gevonden dan zou de bezoeker moeten stemmen op de kwaliteit van het antwoord. En wordt er geen antwoord gevonden dan zou de bezoeker moeten converteren in een vraagsteller, gerelateerde vragen moeten aanklikken of bijvoorbeeld naar een categorie kunnen klikken.
Het bounce-rate experiment
Hypothese
Door de indeling van de vraag/antwoord pagina om te draaien waardoor de vraag, het antwoord en de gerelateerde vragen bovenaan komen te staan wordt de zichtbaarheid van de belangrijkste informatie vergroot (vraag & antwoord, gerelateerde vragen en waardering antwoord) waardoor de bezoeker beter getriggerd wordt om door te klikken. De informatie over de beheerder, e-mail, rss-feeds etc. zal hierdoor naar beneden verhuizen. Dit alles moet een daling van de bounce-rate tot gevolg hebben.
Lees hier over de achtergrond rondom dit eerste experiment en bekijk de schermvoorbeelden.
Het experiment wordt uitgevoerd met de Google Website Optimizer. Omdat je hiermee een experiment niet kan beoordelen op een eventuele wijziging in de bounce-rate hebben we Google Website Optimizer alleen gebruikt om de 2 paginavarianten willekeurig aan de bezoeker te presenteren. Hiertoe hebben we een A/B test aangemaakt met:
Variant A (controle variant): http://www.gratisadviseurs.nl/question.php?id=44208 (en alle andere id´s)
Variant B (nieuwe variant): http://www.gratisadviseurs.nl/questionnew.php?id=44208 (en alle andere id´s)
De bounce-rate van de 2 varianten hebben we vervolgens vergeleken in Google Analytics.Â
Het resultaat
Om de uitkomsten in Google Analytics goed te kunnen vergelijken zijn er 2 segmenten aangemaakt.
Segment 1 (Control) = Pagina bevat ´question.php?id=´
Segment 2 (Variant B) = Pagina bevat ´questionnew.php´
Als we dan beide segmenten over de Google Analytics data leggen dan zien we het volgende resultaat:

We zien een enorme daling in bounce-rate naar 0,74%!! Geweldig!! Of toch niet? Beetje ongeloofwaardig is het wel zo´n lage bounce-rate. De verklaring hiervoor ligt in het feit dat de Google Website Optimizer een bezoeker van de controlepagina redirect naar de nieuwe variant. Hier wordt dan vervolgens nooit een bounce geregistreerd, er zit immers een pagina voor. Google Analytics registreert dus altijd 2 paginaweergaves indien een bezoeker een variantpagina ziet.
Om een zuiverder beeld te krijgen van de data is tevens gekeken naar de 2 variantpagina’s als bestemmingspagina en dus zijn er 2 nieuwe segmenten in Google Analytics aangemaakt:
Segment 1 (Control bestemming) = Bestemmingspagina bevat ´question.php?id=´
Segment 2 (Variant B bestemming) = Bestemmingspagina bevat ´questionnew.php´
De uitkomst van deze segmentatie:

Door te kijken naar bestemmingspagina´s sluiten we de voorgaande redirect uit en kijken we alleen naar de bezoekers die als 1e pagina in hun sessie de controle- of variantpagina zien. We zien hier heel andere resultaten en een enorme verslechtering in de bounce-rate van de nieuwe variant (56% t.o.v. 38% op de controlepagina´s). Dit kan uiteraard voorkomen en een slechter resultaat is ook een belangrijke learning. Toch kunnen we op basis van deze data ook geen betrouwbare uitspraken doen. De nieuwe variant is in dit segment ´slechts´ door 1700 bezoekers gezien. En de vraag is hoe deze bezoekers eigenlijk rechtstreeks op deze pagina terecht zijn gekomen? Is deze groep representatief voor de gehele bezoekpopulatie van gratisadviseurs.nl?
De grenzen van de Website Optimizer A/B test?
Lopen we met dit experiment tegen de grenzen aan van de Website Optimzer in combinatie met Google Analytics of zijn er andere mogelijkheden om dit experiment met voldoende betrouwbaarheid uit te voeren?
Ideeën, tips, suggesties en opmerkingen zijn welkom!
- Conversie optimalisatie in de praktijk (4): gratisadviseurs.nl
- Conversie optimalisatie in de praktijk (5): gratisadviseurs.nl
- Conversie optimalisatie in de praktijk (3): gratisadviseurs.nl
- Conversie optimalisatie in de praktijk (2): gratisadviseurs.nl
- Conversie optimalisatie in de praktijk (1): gratisadviseurs.nl
Senior Webanalytics Consultant
OrangeValley
Senior Consultant Webanalytics & Conversieoptimalisatie bij OrangeValley
Lees verder »Nieuwsbrief
Voortdurend op de hoogte van het laatste analytics en optimalisaties nieuws met onze nieuwsbrief!
Gebruik je al Unbounce?
Deze Testing software wordt in Nederland onder andere gebruikt door
Lees meer over UnbounceAangeboden door AboutAnalyticsNieuwste reacties
- Leendert: Als ik het nu zo kijk heeft independer dit met de lening site wel aangepast. Ik vind dit een interessante materie. Al...
- Jan de Vries: Dank Michel voor je tip!
- Michel Kompanje: Leuke site om in de gaten te houden is http://visual.ly/. Binnenkort kun je hier op een gemakkelijker manier je eigen...
- Ton Wesseling: @egan dank voor het delen van je gedachten. Die ‘light’ decision-making engine zie ik wel ontstaan bij...
20 reacties
Je kan de representativiteit van dit soort tests verbeteren door in Google Analytics sommige groepen bezoekers uit te sluiten (uiteraard binnen een eigen profiel).
Want je wil eigenlijk inzicht krijgen in wanneer een zoeker met een gerichte vraag direct antwoord vindt op zijn vraag.
Door bepaalde bezoeker uit te sluiten (bijvoorbeeld direct bezoek, referrals van freepublicity e.d.) en niet op te nemen in de test kom je al in de buurt van de het segment bezoekers die een vraag hebben en hier gericht antwoord op zoeken.
Het zou zelfs te overwegen zijn enkel bezoekers die binnenkomen op een bepaald soort trefwoord op te nemen.
Uiteraard zitten hier behoorlijk wat aannames in en ik ken de case niet goed genoeg om te beoordelen of het een representatief resultaat kan opleveren.
Maar door verschillende testen te draaien (bijvoorbeeld met verschillende specifieke groepen trefwoorden, wat uiteraard tegelijkertijd kan in verschillende profielen) kan je wellicht toch tot aanvullende inzichten komen.
Grootste probleem zit in het feit dat de nieuwe variant niet goed wordt geteld. De GA code zit in de header van de pagina, deze moet naar onder in de body. De kans dat de bezoeker dan is getelt voordat WO de redirect naar de nieuwe variant doorvoert is minimaal. Andere optie is om de tellercode van GA me tee nemen binnen de variatie, waardoor de code pas wordt uitgeserveerd wanneer de variant wordt getoond. Andersom zou eigenlijk de layout moeten blijven staan en middels javascript het contentgedeelte moeten worden getoond. Of dit nu versie A of versie B is, dan is er geen redirect. Dit is m.i. de ideale situatie.
Ander probleem is de 30 seconden limiet. Stel nou dat in de nieuwe versie de bezoeker helemaal tevreden is over het antwoordt en daardoor de pagina verlaat, maar later terugkomt omdat hij tevreden is over de kwaliteit van de website? Dit langere termijn effect kan wel worden gemeten, maar is nooit helemaal terug te herleiden naar de test.
Punt van Roel over segmenteren is een goed. Alleen zou ik niet zozeer kiezen voor een bepaald type bezoeker, maar voor uniformiteit in de kwaliteit van de antwoorden. Laten we eerst eens testen op vragen waarvan het antwoordt van goede kwaliteit is (de gewenste situatie). Zou jammer zijn als de B variant net alle slechte antwoorden heeft gezien…
Erg goed punt Ton, ik was in mijn veronderstelling er vanuit gegaan dat de kwaliteit van de antwoorden op een regelijk uniform niveau ligt. Maar bij nader inzien kan ik me zeker goed indenken dat dit niet het geval is. Segementeren op kwalitatieve antwoorden is dan ook in dit geval een goede keuze.
@Egan: Ik ken GA en WO niet goed genoeg om te zeggen of hier echt de grenzen liggen. Dit lijkt me een niet al te ingewikkelde test en zou dus, zeker met de oplossing van Ton, makkelijk uit te voeren moeten zijn.
Er is wel iets wat me opviel: aan het begin zeg je dat de bounce rate terug gebracht wordt van 68% naar 38% door een bezoeker die langer dan 30 seconden blijft niet als bounce te tellen. Iets verderop wordt duidelijk waar het eigenlijk om gaat: ratings en/of conversie naar vragenstellers. Je KPI’s zijn dus rating en “stel vraag”. Daarmee is visit>30sec ‘slechts’ een PI. Leuk dat iemand langer blijft, maar echt euforisch word je er niet van.. Volgens mij zou je de bounce rate dus niet kunstmatig moeten verlagen door alle >30sec visits er uit te halen. Het zou hier op zich goed zijn om visitduur mee te nemen in rapportages/dashboard, voor het volledige inzicht.
@Ton, Google Analytics tag naar onderen plaatsen kan het inderdaad verhelpen. De andere oplossing die je geeft zou misschien ook wel werken. We kunnen in Optimizer een multivariate test aanmaken die het gehele contentgedeelte varieert (we kunnen dan ook meerdere indelingen testen). Als we dan in een setvar of een track_pageview de getoonde variant meegeven kunnen dan kunnen we vervolgens in Google Analytics het effect op de bounce-rate beoordelen.
@Roel, selecteren op de kwaliteit van het antwoord en ook of er wel een antwoord gegeven is een mooie vervolgstap.
Knap!
Zowel het scriptje van Joost De Valk als de segmentering om een zicht op het werkelijke gedrag te krijgen.
Er loopt een hoop Web Analytics talent rond in Nederland.
Kan je op basis van de entrance sources voor de laatste segmenten al niet wat wijzer worden over vergelijkbaarheid?
Tip voor verdere test: haal er dat geel en het overaanbod van lettertypes uit. Vervang ook het woord “toelichting”door vraag.
Ik kijk uit naar de volgende stappen.
Als je de Google Website Optimizer gaat gebruiken voor een A/B test moet je met een aantal zaken rekening houden:
1. Het Google Analytics meetscript mag niet voor het Google Website Optimizer controle script staan. Anders krijg je inderdaad een verschrikkelijk vertekende meting qua tijd en bounce rate. Wanneer je dus gaat testen, plaats de GATC dan onder het GWO script zodat de redirect plaatsvindt voor de meting.
2. Na een test kunnen mensen de oude URL nog in hun bookmarks hebben, ook zou er naar toe gelinked kunnen worden. Het kan daarom handiger zijn om de multivariate optie in te zetten voor de A/B test.
Verder is het wel degelijk mogelijk om met de GWO een test op te zetten waarbij je de invloed op de bouncerate meet. Door de vrij nieuwe functie utmx te gebruiken kun je eenvoudig een aantal zaken doorgeven aan GA:
utmx(“combination”) kun je gebruiken om het nummer van de getoonde combinatie naar GA te gooien.
utmx(“combination_string”) kun je gebruiken om de getoonde variaties van de secties naar GA te gooien.
Zo kun je in GA precies zien wat de tijd/bouncerate/enz is van de diverse varianten. Het op deze manier koppelen aan GA biedt veel meer mogelijkheden, dus je loopt nog zeker niet tegen de grenzen aan.
Misschien een stomme vraag, maar is dit javascript, of een andere code?
@Jeroen: De GA code is inderdaad Javascript.
Merci, eens proberen of ik dit in mijn Joomla site kan implanteren.
Jammer, niet integreerbaar binnen de normale joomla-module-structuur
Heb ik het goed begrepen? U spreekt over de bounce rate zoals die wordt weergegeven via Google Analytics? En dat scriptje van JdValk kan het resultaat beïnvloeden? Dan lijkt dit script me wel handig om in je template te plaatsen, want geldt besproken 30 seconden [url=http://www.wasseo.nl/SEO-Diensten.php]bounce rate[/url] concept niet voor alle pagina’s? Ik zal eens kijken of het voor mijn sites ook werkt.
@Bounce Rate, het script van Joost de Valk beïnvloed inderdaad de meting van bounce rate binnen Google Analytics.
Eigenlijk geeft het script aan dat als iemand 30 seconden op de landingspagina blijft dit niet als bounce geteld moet worden maar gewoon als een regulier bezoek aan die pagina.
Het is uiteraard wel belangrijk om per pagina goed na te gaan of 30 seconden wel correct is om het bezoek niet als bounce te laten tellen (zo kan bijvoorbeeld voor een hoofdpagina met als doel om bezoekers een keuze te laten maken tussen verschillende informatiepagina’s juist helemaal niet wenselijk zijn om na 30 seconden de ‘bounce’-meting te stoppen).
@Roel, helemaal mee eens die tijd verschilt per pagina. Kijk naar het doel van de pagina en baseer daarop een acceptabele tijd. Op een homepage bijvoorbeeld wil je dat bezoekers snel hun weg vinden en doorklikken naar een van de onderwerpen. Langer dan 30 seconden zou hier dan betekenen dat de pagina niet overzichtelijk is en men niet snel genoeg kan vinden wat men zoekt (negatieve gebruikservaring).
Ik dacht dat doorklikken naar een andere pagina op dezelfde site nooit als een bounce werd geregistreerd. Lijkt me ook niet logisch. De bezoeker blijft toch? Is misschien wel wat gaan bestellen.
Ik ben het met beide reacties eens. Echter, ik was ervan overtuigd dat doorklikken naar een andere pagina op de dezelfde site niet als bounce werd gerekend. Lijkt me ook niet logisch. Misschien is de bezoeker wel iets gaan bestellen. (Ik herinner me dat ik iets dergelijks al heb geschreven, maar zag mijn reactie niet staan. Dus heb ik deze pagina opnieuw vanuit mijn e-mail geopend en het stond er echt niet. Mocht ik toch dubbel hebben gepost, bied ik mijn excuses daarvoor aan.)
@ Egan, helemaal mee eens, deze aanpassingen dien je erg weloverwogen te maken.
@Bounce rate, je hebt volkomen gelijk dat doorklikken op de zelfde website (mits daar ook de scripts van het zelfde tracking systeem op geplaatst is) niet als bounce telt. Wat je in dit geval met het script doet is zo’n klik simuleren na 30 sec. sommige pagina’s kunnen hun doel (bijvoorbeeld enkel informeren) binnen 30 sec. na een bezoek makkelijk behalen (als bezoekers na de 30 sec. de pagina verlaten mag je verwachten dat de informatie gelezen is). Andere pagina is het doel niet de bezoeker minimaal 30 sec. met de informatie te boeien maar over te halen tot een actie (bijvoorbeeld klik naar een andere pagina). Het gebruik van scripts wat na een bepaalde tijd de bounce niet meer telt kan in dit geval de bounce rate van de pagina sterk vertekenen.
Overigens zou ik zelf als aanvulling op het timer script ook de bezoekers die de 30 sec. op de pagina hebben vol gemaakt voorzien van een User Defined tracking variabele. Zodat je de werking van het script en gedragingen van deze bezoekers kan nagaan.
Dit is allemaal erg theoretisch… Als ik zoek met bv Google dan klik ik vaak de meest interessante links open in nieuwe tabbladen. Vervolgens ga ik kijken naar de inhoud van de tabbladen. Dat een pagina 10 minuten open staat wil dan niet zeggen dat het geen bounce is.
Hmm, heeft hij wel een punt mee….
ik heb het script in mijn footer gemikt, maar heb tot nu toe nog geen resultaat gezien in mijn bouncerate, hetgeen me sterk verbaasd.
Met een bouncerate van 80% en een gemiddelde tijd op de site van 1:30 minuten ZOU je verwachten dat een groot deel van de bounces komen van mensen die via google op een recensie komen en daarna vertrekken (google: 90% van verkeer ofzo).
Conclusie zou dan zijn dat OF ik heb het script niet werkend gekregen, OF de 20% die niet bouncet is gemiddeld een erg langzame lezer…
Waarschijnlijk de eerste optie.
Ik denk dat het voor mij een gewoonte is die ik heb overgehouden aan het begintijdperk van het internet. Hacktic/XS4ALL met een 28k8 modem. Het duurde vaak lang voordat een pagina binnen was dus een paar vensters openklikken en dan rustig de eerste pagina lezen terwijl de andere pagina’s langzaam binnenkwamen. Ik zie het andere mensen ook regelmatig doen…