Google Optimizer en Dynamische Websites
Als je een website wil gaan optimaliseren, zul je bepaalde tests moeten gaan uitvoeren. Je zou bijvoorbeeld willen weten welke pagina-indeling de beste conversie oplevert. Ook zou je je af kunnen vragen of bepaalde headgroottes, afbeeldingen of teksten kunnen leiden tot meer conversies (een conversie kan een registratie, aankoop of aanvraag zijn bijvoorbeeld). Bij de ene test zal een simpele A/B test volstaan, maar bij andere gevallen zul je gebruik moeten maken van multivariate testing. Er zijn diverse tools te huur of te koop, maar dan ben je vele duizenden euro’s (vaak per maand ook nog) kwijt. Gelukkig is er Google Site Optimizer: een gratis A/B en Multivariate testing tool (voorheen al beschikbaar via AdWords). Nu is dit niks nieuws, maar hierbij mijn bevindingen over de (on)mogelijkheden van deze tool.
Probleem
Tegenwoordig volstaat een statische site niet meer als regelmatig nieuwe content plaatst op je website. Het probleem met dynamische sites en tools als Google Site Optimizer is dat je geen PHP, ASP(X) of JSP code in je tests kan plakken. 
Als je bijvoorbeeld een site hebt draaien op PHP en MySQL, wordt er data opgehaald uit de database, geparsed en uiteindelijk weergegeven in HTML. Nou is het op zich niet zo’n ramp als je simpele dingen zou willen gaan testen, maar het wordt wel problematisch als je bijvoorbeeld een lijst met zoekresultaten middels een multivariate test wil gaan testen.
Als je een statische webpagina zou hebben, dan zou je de Optimizer tags om de oude content heen zetten en blijft deze gewoon zichtbaar voor de zoekmachines. De test-content wordt direct bij het laden van de testpagina ingeladen door Site Optimizer.
Het is zeker niet onmogelijk om verschillende delen van je resultatenlijst te laten rouleren middels Optimizer, maar wel ingewikkeld. Moeilijker wordt het als je website ondersteuning biedt voor meerdere talen en het wordt helemaal een crime als je ook nog eens een caching-systeem op de achtergrond hebt draaien om overhead op je database(server) te voorkomen.
Oplossing met losse elementen voor dynamische content
Middels een Javascript oplossing kun je met een xmlHTTPrequest individuele (multivariate) delen van je webpagina laten inladen/testen door Google Site Optimizer. Dit zou je bijvoorbeeld willen indien je ondersteuning voor meerdere talen hebt via PHP. Je moet eerst dus de testpagina delen uit elkaar slopen en als varianten opslaan in individuele files. Stel je hebt bijvoorbeeld een zoekformulier, plus een box met wat aanbiedingen, dan zul je dus zowel de aanbiedingen als het zoekformulier los moeten knippen (je kan alle <html>, <head> en <body> delen weglaten want deze worden al in de testpagina geladen) en op moeten slaan als zoekbox1.php en aanbiedingen1.php (cijfers aanvullen met variantnummers en in die file dan de wijzigingen maken).
Het gaat dus puur om de elementen zelf. Vervolgens zet je in de (parent)testpagina het Javascript welke zorgt dat de elementen op de juiste plaats komen te staan en maak je in Google Site Optimizer de nodige varianten aan. In iedere variant plak je dus niet de elementen (deze staan immers al in losse files klaar) maar roep je de Javascript functie aan die de juiste variant aanroept. Dit zou een voorbeeld code zie je invoert in Google Optimizer van Zoekbox Variant 1 kunnen zijn:
<script>loadVariant(”targetDiv”, “zoekbox1.php”);</script>
Het probleem bij deze oplossing (lekker tegenstrijdig he?) is wel dat er een vertraging oploopt indien er in zoekbox1.php ingewikkelde PHP codes geparsed moeten worden. Het element wordt ingeladen zodra deze klaar is met parsen (dit komt door de xmlHTTP call die gemaakt wordt door de Javascript functie).
Mijn ervaring is dat dit als vertraagd wordt ervaren door bezoekers waardoor je je bezoekers verliest. Dit is helemaal het geval als SEO belangrijk is voor je website en je bijvoorbeeld wilt gaan testen op een pagina die goed in de rankings staat. Het is namelijk dan van belang dat de originele content ten alle tijden blijft staan waar deze staat. Nu kun je wel de content overschrijven via deze Javascript functie maar dan ziet de bezoeker een “flicker” moment zodra de Site Optimizer content wordt ingeladen (en de oude content overschrijft). Dit is helaas ook geen nette oplossing dus.
De enige manier waarop je een nette test uit kunt voeren is door een A/B (split) test uit te voeren zodat je verschillende “versies” van je complete pagina laat wisselen. Op deze manier kun je dus gewoon duplicaten maken van een ASP, PHP of JSP pagina en deze instellen in Google Site Optimizer. Natuurlijk kun je meer dan twee versies maken zodat je een A/B/C/D/E/F test krijgt bijvoorbeeld. Probleem is dat je dan 5 variaties hebt in plaats van dat je combinaties van alle gewijzigde elementen krijgt. Bij multivariate tests kun je bijvoorbeeld al snel 30+ combinaties hebben en kan er sneller een conclusie getrokken worden door Optimizer. Het mooie hiervan is dat je dus alle mogelijke varianten test in plaats van de bepaalde variaties die je in de A/B test hebt klaargezet. Helaas moet je soms concessies maken, het belangrijkste is dat je naar de context kijkt en de juiste test voor jouw situatie kiest.
Op Usarchy.com staan nog een aantal opvallende A/B test resultaten. Later deze week zal ik voor de liefhebbers de Javascripts plaatsen zodat (indien je lichtgewicht PHP elementen gebruikt) op eenvoudige wijze toch gebruik kunt maken van Multivariate Tests via Google Site Optimizer.
Tags: A/B Testing, Google, Google Site Optimizer, Multivariate Testing, Site Optimizer, Usability
September 7th, 2008 at 7:19 pm
Kom maar door met de js’jes… Snap geloof ik bijna 14,3% van wat je hier zegt maar we hebben het voor Eduhub ook nodig.
September 8th, 2008 at 10:31 am
Ruben, het is een inderdaad nogal omslachtige oplossing (helemaal voor niet-techies) maar wel eentje die werkt. De voorbeelden zullen het en en ander verduidelijken