Praxisguide
Die Durchführung von A/B- und multivariaten Tests auf Websites und Onlineshops ist in den letzten Jahren zunehmend einfacher geworden. Obwohl einfachere Test ohne technisches Wissen umsetzbar sind, ist dieses Wissen für die Umsetzung fortgeschrittener Testvarianten unverzichtbar.
Autor
Julian Kleinknecht
Die Durchführung von A/B- und multivariaten Tests auf Websites und Onlineshops ist in den letzten Jahren zunehmend einfacher geworden. Am Markt sind hierzu vielfältige Tools verfügbar, die mit ähnlichen technischen Ansätzen die unterschiedlichen Testvarianten konsistent ausliefern und Testergebnisse zuverlässig sammeln.
Obwohl einfachere Test ohne technisches Wissen umsetzbar sind, ist dieses Wissen für die Umsetzung fortgeschrittener Testvarianten unverzichtbar. Im Rahmen sich immer weiter entwickelnder Webtechnologien kommt es außerdem häufig zu Konflikten und Inkompatibilitäten. Insbesondere können verschiedene Tracking-Tools und andere JavaScripts Einfluss auf die Auslieferung der Testvarianten nehmen. Vor diesem Hintergrund ist ein tiefergehendes Verständnis der technischen Funktionsweise der Testingtools sinnvoll und notwendig, um erfolgreiche Tests sicherzustellen.
Vor allem bei der Zusammenarbeit mit technischen Teammitgliedern wie Webentwicklern zahlt sich dieses Wissen aus, weil der Arbeitsaufwand besser eingeschätzt werden kann.
Im Folgenden wird beleuchtet, was passiert, wenn ein A/B- oder multivariater Test auf einer Website aktiv ist und welche Technologien dies ermöglichen. Zu diesem Zweck wird ein Website-Test vom ersten Besuch bis zur Conversion verfolgt und beschrieben, was dabei „unter der Oberfläche“ passiert.
Der grundsätzliche Ablauf eines Website-Tests lässt sich wie folgt zusammenfassen. Nachdem einem Besucher zufällig eine Testvariante zugewiesen wurde, wird der Inhalt der originalen HTML-Seite mit Hilfe von JavaScript entsprechend verändert. Falls der Besucher die gewünschte Aktion (Conversion) durchführt, wird die Nummer der zugewiesenen Testvariante ausgelesen und gespeichert.
Diese Schritte werden durchlaufen:
Jeder dieser Schritte wird im Folgenden beschrieben und erläutert. Dies geschieht sowohl abstrahiert von einem bestimmten Testingtool, als auch im Detail für das populäre Testingtool Optimizely.[1] Alle Schritte können im eigenen Browser nachvollzogen werden.
Die technischen Einzelheiten werden mit Hilfe der „Entwicklertools“ in Chrome veranschaulicht. Alle anderen bedeutenden Browser besitzen ähnliche Entwicklertools: „F12 developer tools“ (Internet Explorer), „Developer Toolbar“ (Firefox), „Dragonfly“ (Opera) sowie „Safari Web Inspector“ (Safari).
Im Folgenden wird die Demo-Website unter „conversionboosting.com/beispiel-tech-grundlagen“ als Beispielseite verwendet. Es wird angenommen, dass auf dieser Seite ist ein A/B-Test aktiv ist.
Sobald ein Besucher diese URL aufruft, wird die HMTL-Datei index.php vom conversionboosting.com-Server geladen. Neben Inhalten der Seite wie Bildern und Text enthält der Quelltext auch verschiedene Tags. Diese haben meistens die Form von mehreren Zeilen JavaScript-Code, die in den <head>-Bereich einer Website integriert werden.
Der Optimizely-Tag auf conversionboosting.com/beispiel-tech-grundlagen sieht wie folgt aus:
<script src="//cdn.optimizely.com/js/526890376.js"></script>
Wegen der Vielzahl an Tags sind Tag-Management-Systeme mittlerweile sehr beliebt. Wenn Tags von Testingtools mit Hilfe eines Tag-Management-Systems ausgeliefert werden, achten Sie unbedingt darauf, dass dieses die synchrone Auslieferung von Tags unterstützt.
Manche Tag-Management-System liefern Tags standardmäßig asynchron aus, das heißt Tags werden erst geladen, wenn der Inhalt der Seite schon geladen wurde. Dies ist sinnvoll, um die Ladezeit von Websites nicht unnötig zu verlangsamen. Bei Tests führt dies jedoch dazu, dass das Austauschen der Inhalte (Schritt 3b) sehr spät geschieht und der Besucher zuerst die Originalseite sieht („flackern“).
Der Optimizely-Tag lädt nun die Datei 526890376.js von cdn.optimizely.com/js. Tags anderer Testing-Tools laden die entsprechenden JavaScript-Dateien beispielsweise von diesen Servern:
Im Gegensatz zu den anderen Tools lädt Adobe Target die JavaScript-Datei (mbox.js) nicht von Adobes Server, sondern vom Server des Kunden. Auf den ersten Blick scheint dies sinnvoller zu sein, als die Datei von einem Server in den USA zu laden. Viele Testingtools speichern die JavaScript-Dateien jedoch in sogenannten Content Delivery Networks, welche Server an vielen europäischen Standorten besitzen und Inhalte schneller zu Verfügung stellen als „normale“ Server.
Die Funktionsweise der verschiedenen JavaScript-Dateien ist sehr unterschiedlich. Generell kann in drei Ansätze unterschieden werden:
Erste Generation: Die Datei ist eine für alle Websites konstante Bibliothek. Dies ist der „klassische Ansatz“ von Website-Testing-Tools, wie der beispielsweise von Offermatica (heute: Adobe:Test) erfunden wurde. In diesem Fall übernimmt ein Server die gesamte Logik. Die JavaScript-Bibliothek schickt dem Server nur standardisiert verschiedene Meta-Informationen über den Besucher (URL, Cookies). Die Datenhaltung, das Session-Management und jegliche andere Logik finden auf dem Server statt. Auch Basis all dieser Daten sendet der Server dann die auszuliefernden Inhalte an den Browser, der diese nur darstellt.
Der Vorteil dieser Lösung ist, dass die Funktionalität primär auf dem Server abläuft. Dies ist ausfallsicherer und erlaubt deutlich komplexere Möglichkeiten, beispielsweise hinsichtlich Targeting. Der Server kann die vom Browser empfangenen Daten anreichern (beispielsweise mir umfangreichen Profildaten oder einer Geolokalisierung) und so deutlich umfangreichere Auslieferungsregeln umsetzen.
Ein weiterer Vorteil ist, dass für einen Außenstehenden die Testinglösung eine „Blackbox“ ist. Er kann nicht erkennen, weshalb das Testing-Tool die ausgelieferte Testvariante ausgewählt hat. Auch sind die weiteren Testvarianten nicht ohne weiteres einsehbar.
Der primäre Nachteil dieses Ansatzes ist die zusätzliche Ladezeit aufgrund der zusätzlichen Kommunikation mit dem Server. Diese kann bis zu 500ms betragen und so für den Besucher deutlich spür- (verlangsamter Seitenaufbau) oder sogar sichtbar (Flackern) sein.
Zweite Generation: Die Datei ist eine generierte Bibliothek, die alle Informationen zu dem laufenden Test enthält.
Um den Geschwindigkeitsnachteil abzuschaffen, benutzt die zweite Generation von Testing-Tools (prominentester Vertreter dieser Gattung ist Optimizely) vorgenerierte Dateien auf einem Content Delivery Network (CDN). Dadurch wird die Gesamtladezeit auf deutlich unter 100ms verkürzt und die Testvarianten werden sofort ausgeliefert.
Die vorgenerierte Datei enthält dabei sämtliche Logik und sämtliche Varianten der Tests. Der Browser führt diese Logik aus, zeigt die passende Variante an und sendet Trackingdaten an einen Server. Der Server ist hier nur an der Datensammlung beteiligt, nicht an der Auslieferung des Tests.
Neben dem Vorteil der gesteigerten Geschwindigkeit gibt es auch Nachteile. Der größte Nachteil ist, dass in der JavaScript-Datei öffentlich alle Tests und Testvarianten verfügbar sind. Es ist also für einen Außenstehenden recht einfach, die Tests und ggf. die damit verbundene Teststrategie nachzuvollziehen. Dies kann ein deutlicher Wettbewerbsnachteil sein. Ein weiterer Nachteil ist die (im Vergleich mit der serverseitigen Auslieferung) geringere Komplexität der Testkonfiguration, die durch den Browser abgebildet werden kann.
Dritte Generation: Die Datei wird vollständig dynamisch erzeugt und enthält nur die Testelemente, die jetzt genau für diesen Benutzer benötigt werden.
Um nun auch noch den Nachteil der Ausspähbarkeit von Testinhalten zu lösen, setzen Lösungen der dritten Generation (beispielsweise Visual Website Optimizer) auf eine Mischung aus CDN und serverseitiger Auslieferung, sogenannten „Dynamischen Content Delivery Networks“ (Dynamic CDN). Hier wird in hoher Geschwindigkeit für jeden User eine eigene Datei generiert, die nur genau die anzuzeigenden Inhalte enthält. Diese Variante braucht auch nur einen Serveraufruf und ist deshalb maximal leicht langsamer als eine Lösung der zweiten Generation. Die Daten sind jedoch geschützt und durch die serverseitige Generierung bieten sich größere Möglichkeiten für Targeting und Auslieferungslogik.
Manche Tools wie Optimizely oder Visual Website Optimizer bieten die Möglichkeit, die JavaScript-Bibliothek jQuery in der gerade besprochenen JavaScript-Datei auszuliefern. Falls jQuery noch nicht auf der Website integriert ist,
muss dieses also nicht zusätzlich eingebunden werden.
Sollten Sie jQuery bereits verwenden und die aktuelle Version nutzen, sollten Sie diese Funktion auf jeden Fall deaktiviert. Ansonsten kann es dazu kommt, dass zwei verschiedene jQuery-Versionen eingebunden werden. Dies kann zu Inkompatibilitäten führen und Auswirkungen auf den Test und den Rest Darstellung und Funktionalität der Seite haben.
Falls in der Website jedoch bereits eine ältere Version von jQuery eingebunden wird, kann es sein, dass einige Funktionen des Testingtools nicht mehr funktionieren, da diese eine aktuelle jQuery-Version voraussetzen.
Bei der Implementierung des Testingtools sollten Sie diesen Punkt auf jeden Fall mit der IT-Abteilung besprechen. Es ist möglich, zwei verschiedene jQuery-Versionen gleichzeitig zu verwenden. Dies ist jedoch mit zusätzlichem Aufwand verbunden und bedarf besonderer Sorgfalt bei der Programmierung.
Sobald das Testingtool (unabhängig davon, ob in Form einer JavaScript-Datei oder auf einem Server) tätig wird, überprüft dieses, ob die Targeting-Bedingungen des aktuell laufenden Tests erfüllt sind. „Soll der Besucher also am aktuellen Test auf dieser URL teilnehmen?“
Die Targeting-Bedingungen bestehen also aus diesen zwei Komponenten:
Verschiedene Testingtools setzen diese beiden Bedingungen unterschiedlich um. Einige Testingtools wie Optimizely und Visual Website Optimizer speichern diese Bedingungen direkt in der im zweiten Abschnitt beschriebenen JavaScript-Datei. In anderen Tools wie Maxymiser sind diese Bedingungen auf dem Server des Tools hinterlegt. Das JavaScript des Tools ruft diese Information in einer weiteren HTTP-Anfrage vom Server des Tools.
Die erste Methode hat den großen Vorteil der Geschwindigkeit, da keine weitere HTTP-Anfrage notwendig ist. Die zweite Methode erlaubt dagegen deutlich komplexere Bedingungen im Targeting, die in der ersten Methode technisch nicht umgesetzt werden können. Beispielsweise können detaillierte Profile von Besuchern auf dem Server des Testingtools gespeichert werden und Besucher nur zu einem Test zugelassen werden, wenn diese bestimmten komplexere Eigenschaften besitzen.
In Optimizely sieht dies wie folgt aus (die Umsetzung der zweiten Bedingung ist in zwei Teile aufgeteilt):
Im Folgenden wird beschrieben, wie die Einstellungen in dieser Dialogbox technisch umgesetzt werden.
Nicht alle Tests sollen auf jeder einzelnen Seite einer Website laufen. Deshalb gilt es zu spezifizieren, auf welchen Seiten ein Test laufen soll.
Im Folgenden werden zwei Szenarien beschrieben und wie diese technisch umgesetzt werden können:
1. Es soll nur einer bestimmten Seite getestet werden, zum Beispiel eine Landingpage.
2. Es soll seitenübergreifend getestet werden, zum Beispiel alle Produktdetailseiten, Kategorieseiten oder alle Schritte des Checkout-Prozesses.
(1) Test einer bestimmten Landingpage
Wenn nur eine einzige Seite getestet werden soll, bietet sich die einfachste und häufigste Möglichkeit an: Das Angeben der URL, auf welcher der Test laufen soll.
Laut Spezifikation des World Wide Web Consortiums (W3C) besteht eine URL aus folgendem Bestandteilen (wobei einige optional sind):
| http:// | www. | test | .de | /vz/ | abc.htm | ?q=query | #anker |
| Protokoll | Subdomain | Domain-name | Top-Level-Domain | Verzeichnis | Dateiname | Query-Parameter | Anker |
Angenommen die Landingpage ist unter „https://conversionboosting.com/beispiel-tech-grundlagen“ gespeichert. Ausschließlich auf dieser Seite soll der Test ausgeführt werden.
Per JavaScript gibt es verschiedene Möglichkeiten die URL der aufgerufenen Seite zu identifizieren. In der Variable [2] „document.URL“ ist die komplette URL inkl. aller obigen genannten Bestandteile gespeichert.
Chrome Entwicklertools
Es gibt jedoch Fälle, in denen eine Website sowohl unter https:// als auch http:// erreichbar ist. Das Protokoll ist also verschieden. Die Variable „document.location.pathname“ liefert in einem solchen Fall nur den Namen des Verzeichnisses und ggf. den Dateinamen.
Weitere Szenarien in denen dies hilfreich ist sind unter anderem:
Alle weiteren oben beschriebenen Bestandteile einer URL können mit Hilfe folgender Befehle erkannt werden:
| http:// | www. | test | .de | /vz/ | abc.htm | ?q=query | #anker |
| Protokoll | Subdomain | Domain-name | Top-Level-Domain | Verzeichnis | Dateiname | Query-Parameter | Anker |
| document.location.protocol |
document.location. hostname |
document.location. pathname |
document.location.search | document.location.hash |
Es ist auch möglich zu spezifizieren, dass Tests nur dort ausgeführt werden sollen, wo beispielsweise der Ausdruck „grundlagen“ in der URL enthalten ist. Dazu kann die JavaScript-Funktion indexOf() verwendet werden. document.URL.indexOf("grundlagen") gibt die Position des Ausdrucks „grundlagen“ in der aktuellen URL wieder. Wenn diese Zahl größer als 0 ist, ist der Ausdruck in der URL enthalten
(2) Seitenübergreifende Tests
Bei einem Test beispielsweise aller Kategorieseiten wird ein Kriterium benötigt, dass alle diese Kategorieseiten eindeutig identifiziert. Dieses Kriterium muss auf alle Kategorieseiten – und nur auf diese – zutreffen. In anderen Worten muss das Kriterium eine notwendige und hinreichende Bedingung dafür sein, dass die Seite eine Kategorieseite ist.
Kategorieseiten können oft anhand der URL identifizieren. Beispielsweise ist eine Seite dann eine Kategorieseite, wenn deren URL entweder „/herren/“, „/damen/“ oder „/kinder/“ enthält.
Bei vielen Websites und Shops enthalten die URLs der Produktdetailseiten jedoch keinen automatisch erkennbaren Hinweis darauf, welche Art von Seite es ist. Zalandos URLs der Produktdetailseiten haben beispielsweise folgendes Format: zalando.de/converse-all-star-hi-sneaker-high-navy-co412a04j-502.html. Die URLs mancher Onlineshops sind noch kryptischer, da die Shop-Software nicht richtig konfiguriert wurde. In diesem Fall lassen sich anhand der URL gar keine Rückschlüsse auf den Inhalt der Seite ziehen.
Dieses Problem lässt sich durch JavaScript-Variablen im Quelltext lösen, die als eindeutig identifizierendes Kriterium für eine Produktdetailseite dienen können. Beispielsweise könnte in der Variable „productID“ die interne ID des Produkts gespeichert sein. Nur wenn diese Variable gesetzt ist, handelt es sich um eine Produktdetailseite.
Falls eine solche Information noch nicht im Quelltext vorhanden ist, sollten Sie so früh wie möglich mit Ihrer IT-Abteilung sprechen und dafür sorgen, dass eine solche Variable eingebaut wird. Bei vielen Kundenprojekten hat sich herausgestellt, dass diese – auf den ersten Blick schnell zu erledigende Aufgabe – den Beginn eines Tests unnötig verzögern kann. Wenn Sie einen seitenübergreifenden Test planen, sollte deshalb einer der ersten Gedanken sein, wie die relevanten Seiten eindeutig identifizieren werden können.
Es ist wichtig, dass diese Variable im Quelltext vor dem Code des Testingtools eingebaut wird. Nur dann kann diese Information für das Targeting eines Tests verwendet werden:
<script> var productID = 421; </script>
<script src="//cdn.optimizely.com/js/526890376.js"></script>
Es ist nicht immer der Fall, dass jeder Besucher an einem bestimmten Test teilnehmen soll. Folgenden Szenarien sind denkbar.
Es sollten nur Besucher am Test teilnehmen, die
Wie funktioniert das Targeting bestimmter Besucher technisch?
Bedingung: Vorgängerseite
Die Vorgängerseite wird im HTTP-Protokoll „referrer“ genannt und beim Aufrufen eines Dokuments übermittelt. Diese Information kann per JavaScript mit dem Befehl „document.referrer“ ausgelesen werden.
Bedingung: verwendeter Browser
Browsername sowie Browserversion sind im JavaScript-Object „navigator“ vorhanden.
Wahrscheinlich werden nur selten Tests spezifisch für bestimmte Browser konzipiert. In der Mehrzahl der Fälle werden bestimmte, vor allem ältere Browser, von Tests ausgeschlossen, da es zu teuer wäre alle Testvarianten auch in diesen Browsern korrekt darzustellen. Bevor Sie jedoch einen Browser von einem Test ausschließen, sollten Sie im Webanalysetool überprüfen, dass nur ein geringer Teil der Besucher diesen Browser verwendet und somit nicht zu viele Besucher vom Test ausgeschlossen werden.
In Google Analytics können die verwendeten Browser beispielsweise unter Besucher > Technologie > Browser und Betriebssystem eingesehen werden. Ein Klick auf den Namen eines bestimmten Browser verrät die verwendeten Browserversionen.
Bedingung: Geo-Targeting
Manche Produkte oder Angebot sind nur in bestimmten Ländern oder Regionen verfügbar. Deshalb sollten Test nur dort durchgeführt werden.
Das Auslesen des Standorts eines Besuchers ist komplexer, als die beiden vorigen Bedingungen. Zwar gibt es im HTML5-Standard die geolocation API mit deren Hilfe man den Standort relativ genau auslesen kann. Dafür muss jedoch die explizite Erlaubnis des Besuchers eingeholt werden. Stattdessen wird der Standort eines Besuchers in den meisten Fällen anhand der IP-Adresse bestimmt. (Siehe auch „5 Tipps für erfolgreiches Geo-Targeting“ im ConversionBoosting-Blog.)
Bedingung: verwendete Sprache
Neben Browsername und -version sind im navigator-Objekt auch die Informationen zur Sprache des Browsers gespeichert. Der entsprechende Befehl lautet: navigator.language. Dieser Ansatz ist jedoch nicht ohne Probleme. [3]
Fortgeschrittene Bedingungen
Alle oben angesprochenen Bedingungen verwenden Informationen über das Verhalten des Besuchers auf einer vorigen Seite. Diese Informationen werden in den meisten Fällen in Cookies gespeichert und später ausgelesen, sobald die Targeting-Bedingungen überprüft werden. Mehr dazu im nächsten Abschnitt.
Nachdem feststeht, dass unser beispielhafter Besucher an einem Test teilnimmt, muss nun bestimmt werden, welche Variante ihm angezeigt wird. Falls der Besucher an einem früheren Zeitpunkt schon am aktuellen Test teilgenommen hat, wird die ihm zugewiesene Testvariante jetzt aus dem Cookie des Testingtools ausgelesen.
Optimizely speichert die zugewiesene Testvariante in dem Cookie „optimizelyBuckets“. Dieser kann in den Entwicklertools mit document.cookie angezeigt werden./p>
Falls der Besucher noch nicht am aktuellen Test teilgenommen hat, wird ihm nun zufällig eine der Testvarianten zugewiesen. Das Ergebnis der Auslosung wird in obigen Cookie geschrieben. Informationen werden in Cookies mit folgendem Befehl gespeichert:
document.cookie = "optimizelyBuckets=variante1";
Die von Optimizely gesetzten Cookies sind First-Party-Cookies. Das heißt sie sind in unserem Beispiel mit der URL „conversionboosting.com“ assoziiert und können nur von Dateien auf diesem Server ausgelesen werden. Optimizely-Cookies sind also nicht davon betroffen, dass Safari Third-Party-Cookies standardmäßig nicht akzeptiert und Firefox diesem Beispiel ab der Version 26 folgenden wird.
In manchen Fällen findet die Conversion auf einer anderen Domain statt als das Ausspielen der Testvarianten. Manche Onlineshops greifen beispielsweise auf externe Warenkorb-Software zurück, die auf einer anderen Domain gehostet wird.
In diesem Fall gibt es oft keine Alternative zur Verwendung von Third-Party-Cookies. Bei der Interpretation der Testergebnisse muss man sich jedoch bewusst sein, dass nicht alle Conversions gemessen werden können. Besucher, deren Browser keine Third-Party-Cookies akzeptieren, werden nicht gezählt.
Ein weiterer Fall verdient außerdem Aufmerksamkeit. Angenommen ein Test läuft auf www.beispiel-website.de und der zugehörige Shop befindet sich unter shop.beispielwebsite.de. In diesem Fall müssen Cookies von zwei unterschiedlichen Subdomains geschrieben und gelesen werden. Es muss deshalb auf jeden Fall sichergestellt werden, dass Cookies des Testingtools mit „.beispiel-website“ (mit einem Punkt am Anfang) – und nicht mit www.beispiel-website.de“ – assoziiert werden.
Exkurs: Risiken der Verwendung von Cookies
Das Erkennen von Besuchern und Ausspielen der richtigen Testvarianten basiert auf der Verwendung von Cookies. An dieser Stelle soll deshalb kurz auf deren Risiken eingegangen werden. Mit der zunehmenden Verbreitung von Smartphones und Tablets ist das größte Risiko wohl, dass Cookies nicht Device-übergreifend funktionieren. Wenn einem Besucher auf seinem Computer Variante 1 zugewiesen wurde, kann er auf seinem Smartphone Variante 2 und auf seinem Tablet Variante 3 sehen. Gleiches gilt natürlich auch für verschiedene Computer, zum Beispiel den privaten Computer und den Firmencomputer im Büro
Für Websites mit kurzen Kaufentscheidungen ist dieses Problem nicht schwerwiegend, da Besucher die Website oftmals nur einmal aufrufen. Bei „High-Involvement“-Produkten und einer längeren Recherche-Phase erhöht sich jedoch das Risiko, dass Besucher auf unterschiedlichen Geräten unterschiedliche Testvarianten zu Gesicht bekommen. Wie lange eine durchschnittliche Kaufentscheidung dauert, kann im Webanalyse-Tool nachgesehen werden. In Google Analytics findet man diese Information beispielsweise unter Conversions > E-Commerce > Zeit bis zum Kauf (E-Commerce-Tracking muss implementiert sein).
Neben dem fehlenden Device-übergreifenden Tracking stellt das Löschen von Cookies durch Besucher ein weiteres Problem dar. Wie viele Besucher tatsächlich regelmäßig ihre Cookies löschen ist eine schwierig zu beantwortende Frage und hängt wahrscheinlich stark von der jeweiligen Branche der Websites ab. Laut einer comScore-Untersuchung aus dem Jahr 2012 werden jedoch in ca. 30% aller Browser mehr als viermal pro Monat die Cookies gelöscht[iv].
Eine Alternative zur Verwendung von Cookies bietet das so genannte „Device Fingerprinting“ wie er schon von manchen Webanalyse-Tools eingesetzt wird. Zum aktuellen Zeitpunkt (Januar 2014) verwendet jedoch keines der populären Testingtools diesen Ansatz.
Das größte Problem beider Phänomene (nicht Device-übergreifend, Cookies werden gelöscht) ist, dass Besucher mehrere Varianten sehen und deshalb eine Conversion nicht einer Variante zugesprochen werden kann. Dies verfälscht natürlich die Ergebnisse eines Tests.
Wenn auf verschiedenen Varianten verschiedene Versprechen gegeben werden, kann dies außerdem zu noch größeren Problemen führen. Angenommen eine Testvariante verspricht einen Rabatt von 5 EUR, eine andere jedoch 10 EUR. Falls ein Besucher beide Varianten sieht, kann dies zu einem Vertrauensverlust in die Website führen.
Nachdem feststeht, welche Variante dem Besucher angezeigt wird, erhöht das Testingtool nun die Besucheranzahl der jeweiligen Testvariante in der Datenbank. Zu diesem Zweck wird eine HTTP-Anfrage an den Server des Testingtools (bei Optimizely ist dies http://log.optimizely.com) gesendet.
Diese Anfrage enthält verschiedene Informationen, unter anderem
Wie detailliert diese Informationen über den Besucher aufgezeichnet werden, ist für jedes Testingtool verschieden.
Wenn dem Besucher nicht die Kontrollvariante zugewiesen wurde, wird nun der Inhalt der Website ausgetauscht. Es gibt drei verschiedene Wege, wie dies umgesetzt werden kann:
Dieser Ansatz ist mit Abstand der am häufigsten eingesetzte. Der Quelltext der Seite wird – noch bevor der Besucher die Seite sieht – modifiziert, so dass die Testvariante dargestellt wird.
Hier kommt das JavaScript-Ereignis document.ready zum Einsatz. Dieses Ereignis wird gesetzt, sobald der Quelltext der Seite geladen, aber noch nicht angezeigt wurde. Denn nur wenn der Quelltext vollständig geladen wurde, kann dieser verändert werden.
Das namensgebende Document Object Model (DOM) bezeichnet vereinfacht ausgedrückt eine Schnittstelle, um auf Teile des Quelltexts der Webseite Bezug zu nehmen und diese zu verändern [5]. Diese Schnittstelle ermöglicht es JavaScript alle Elemente einer Website zu verändern. Im Folgenden wird beschrieben, wie dies mit Hilfe der weitverbreiteten JavaScript-Bibliothek jQuery funktioniert, die auch von Optimizely eingesetzt wird.
Exkurs: wie jQuery das einfache Austauschen von Inhalten ermöglicht
Folgende drei Bestandteile von jQuery ermöglichen das einfache Austauschen beliebige Elemente:
Um mit CSS HTML-Elemente im Quelltext zu formatieren, müssen diese entweder Standard-Elemente wie Überschriften sein oder mit einer Klasse oder ID gekennzeichnet werden. Die große Neuerung von Sizzle ist, dass dies nicht mehr notwendig ist. Es können alle Elemente im Quelltext – seien dies auch noch so verschachtelt – herausgegriffen werden. Da die Syntax auf der von CSS basiert, ist es für Webentwickler einfach zu erlernen.
<div id="content">
<ul>
<li>erstes Listenelement</li>
<li>zweites <a href="#">Listenelement</a></li>
<li>drittes <a href="#">Listen</a>element</li>
</ul>
</div>
In obigem Beispiel kann das zweite Listenelement beispielsweise mit dem Befehl div#content > ul > li:lt(2) herausgegriffen werden. Der Link innerhalb des Listenelements kann mit div#content > ul > li:lt(2) > a referenziert werden. Diese Befehle funktionieren auch dann, wenn auf der gleichen Seite noch weitere Listenelemente und Links vorhanden sind.
Die Manipulations-Funktionen [6] erlauben es, das soeben ausgewählte HTML-Element entweder an eine andere Stelle zu platzieren (detach() sowie prepend()), zu entfernen (remove()) oder sogar zu verdoppeln (clone()). Neue Elemente können auch sehr einfach generiert und an einer beliebigen Stelle eingefügt werden. Auf diese Weise kann eine komplette Seite verändert werden.
Die css()-Funktion erlaubt es schließlich jede CSS-Eigenschaft eines HTML-Elements mit den üblichen CSS-Befehlen zu verändern. Zum Beispiel kann die Farbe des obigen zweiten Listenelements so verändert werden:/p>
$("div#content >ul > li:lt(2)").css({"color":"red"}).
Die Abstände eines <div>s können mit dieser Zeile modifiziert werden:
$("div#box").css({"margin":"2px"}).
Trotz der weiteren Verbreitung der Methode der DOM-Manipulation ist diese nicht ohne Probleme. In manchen Situationen sehen Besucher die ursprüngliche Seite für den Bruchteil einer Sekunde bevor der Inhalt ausgetauscht wird. Dieses „Flackern“ tritt auf jeder Seite mit einem aktiven Test auf und kann zu Irritationen bei den Besuchern führen.
Ein weiteres Problem der DOM-Manipulation stellt dar, dass die Kontrollvariante einen ungerechten Vorteil erhält, da es einige Millisekunden länger dauert bis die Testvarianten aus der Kontrollvariante „generiert“ und angezeigt werden. Dies kann das Testergebnis verfälschen, da langsamere Seiten zu mehr Abbrüchen der Besucher führen können.
Um sich darüber bewusst zu werden, wie stark das Problem ist, sollten die Testvarianten in verschiedenen Browsern und auf verschiedenen Computern angesehen werden und die Ladezeiten verglichen werden. Außerdem lohnt es sich die zusätzliche Zeit zu messen, die der Browser für das Rendern der Testvariante benötigt. [7] Er sollten mehrere Messungen durchgeführt werden, um Ausreißer herauszufiltern.
Um unverfälschte Testergebnisse zu erzielen, kann die Kontrollvarianten künstlich um die zuvor gemessene Zeitspanne verlangsamt werden.
CSS-Formatierungen mit !important
Statt jQuery’s verschiedene Methoden der Manipulation des Quelltextes kann für manche Aufgaben auch ein einfacherer Ansatz gewählt werden. Hierzu wird eine zusätzliche CSS-Datei geladen, welche Formatierungen der ursprünglichen Seite überschreibt.
Auf der Beispielseite ist die Überschrift in Arial gesetzt, da die Überschrift im übergreifenden <div> mit der Klasse container liegt – die Schriftart wurde von dieser Klasse geerbt. [8] Mit folgendem CSS-Befehl in einer externen CSS-Datei kann die Überschrift jedoch sehr einfach geändert werden.
h1 { font-family: "Times New Roman" !important;}
Der Hinweis „!important“ signalisiert dem Browser, dass dieser Befehl alle anderen sonst vorrangingen Befehle überschreiben soll.
Natürlich können nicht nur Schriftarten geändert werden, sondern alle verfügbaren CSS-Befehle angewendet werden. Beispielsweise kann ein Element mit Hilfe von „display: none;“ ausgeblendet werden.
Die eigentliche Stärke dieses Ansatzes liegt bei der Entwicklung von Testvarianten komplexerer Websites und Onlineshops. Bei solchen werden Eigenschaften von HTML-Elementen noch während des Ladens der Seite verändert. Es kann deshalb sein, dass Änderungen durch das Testingtool durch die Website wieder überschrieben werden.
Beim Einsatz von !important, werden diese „Überschreibungen“ jedoch ignoriert.
Beim zweiten möglichen Ansatz werden Besucher auf eine andere URL weitergeleitet nachdem ihnen eine Testvariante zugewiesen wurde. Von conversionboosting.com/beispiel-tech-grundlagen würden Besucher zum Beispiel auf conversionboosting.com/beispiel-tech-grundlagen/v1 weitergeleitet werden. Falls ihnen die Kontrollvariante zugewiesen wird, passiert nichts.
Diese Weiterleitung kann mit folgendem einem JavaScript-Befehl umgesetzt werden:
window.location = "https://conversionboosting.com/beispiel-tech-grundlagen/v1";
Ein häufig geäußertes Bedenken bezüglich der URL-Weiterleitung ist, dass Google diese Methode als Cloaking einstuft. Beim Cloaking versteckt man einen Website-Inhalt vor Google. Man zeigt also zwei Internetseiten mit derselben URL: eine perfekt suchmaschinenoptimierte Variante speziell für den Google-Bot und eine für menschliche Besucher. Die menschlichen Besucher bekommen die perfekte SEO-Variante gar nicht zu Gesicht, während die Seite für Menschen vor Google versteckt werden soll, weil sie weniger suchmaschinenoptimiert ist.
Auch beim Testing präsentiert man bisweilen zwei Versionen einer Website unter einer Internetadresse. Das hat Testing mit Cloaking gemeinsam. Google hat jedoch im Webmaster Central Blog klar Stellung bezogen und erklärt, dass Website-Testing keinen Einfluss auf das Ranking einer Website hat [9]. Mit den Content Experiments in Google Analytics bietet Google auch selbst ein Testingtool an, unterstützt so also auch das Website-Testing.
Da bei der Weiterleitungsmethode verschiedene URLs angelegt werden, ist es sehr wahrscheinlich, dass unter diesen URLs zumindest teilweise der gleiche Inhalt verfügbar ist. Um Abstrafungen durch Suchmaschinen zu vermeiden, sollte sichergestellt werden, dass die Testvarianten nicht in den Index aufgenommen werden.
Hierzu empfehlen wir zwei Maßnahmen.
1.) Weisen Sie mit Hilfe der noindex-Attributs die Crawler der Suchmaschinen an, die jeweilige Seite nicht zu indizieren: <meta name="robots" content="noindex">
2.)Setzen Sie ein canonical-Tag mit der URL der Kontrollvariante:
<link rel="canonical" href="https://conversionboosting.com/beispiel-tech-grundlagen">. Auf diese Weise teilen Sie Suchmaschinen mit, welche Seite in den Index aufgenommen werden soll
Damit das implementierte Webanalyse-Tool weiterhin sinnvolle Zahlen liefert, muss dieses auf allen Testvarianten eines URL-Splittests eingebaut werden. Dabei ist zu beachten, dass bei Testvarianten die URL der Originalvariante als Seitennamen verwendet wird. Wenn dies nicht geschieht erscheint jede Testvariante als separater Eintrag im Webanalyse-Tool und viele Auswertungen sind nur noch sehr umständlich möglich.
Beide vorgestellten Methoden haben Vor- sowie Nachteile, die hier kurz beschrieben werden sollen.
Gegenüber der DOM-Manipulation hat die Methode der URL-Weiterleitung den großen Vorteil, dass kein JavaScript programmiert werden muss, um Testvarianten zu erstellen. Es kann einfach die Originalseite per HTML bearbeitet werden und unter einer neuen URL (hier „/v1/“) gespeichert werden. Der Arbeitsaufwand ist wesentlich geringer. Auf diese Weise können beispielsweise auch bestehende Varianten von Landingpages gegeneinander getestet werden.
Des Weiteren tritt das oben beschriebene „Flackern“ nicht auf. Stattdessen ist es jedoch wahrscheinlich, dass einige Besucher bemerken, dass sie an einem Test teilnehmen, vor allem, wenn die URLs einen Hinweis auf einen Test enthalten wie in „/test2/v1“ oder „/ab/1“.
Der größte Nachteil von URL-Splittest sind jedoch die beschränkten Einsatzmöglichkeiten: diese sind auf Landingpage-Tests beschränkt. Sobald in einem Onlineshop seitenübergreifend oder anderer dynamischer Inhalt getestet werden soll, muss auf die DOM-Manipulation zurückgegriffen werden.
Des Weiteren speichern Benutzer Lesezeichen von interessanten Seiten. Leider zeigt das Bookmark dann auf die direkte URL einer Testvariante. Was ist aber, wenn der Test beendet ist? Selbst wenn sie die Testvariante nach Testende noch online belassen, muss diese auch weiterhin aktualisiert werden. Wenn Sie die Testvarianten nicht online belassen, erhalten die Besucher im schlimmsten Fall eine Meldung „404 – Seite nicht gefunden“, im besten Fall leiten Sie diese (serverseitig) auf die Kontrollvariante um.
Google AdWords verfolgt Weiterleitungen bei der Feststellung der eigentlichen Zielseite einer Anzeige und zur Berechnung des Quality-Scores von dieser. Durch einen URL-Splittest kann es so zu einem (negativen wie positiven) Einfluss auf den Quality-Score kommen.
Wenn ein Besucher nun ein zuvor definiertes Conversion-Ziel erreicht, wird diese Conversion vom Testingtool aufgezeichnet. Dies stellt den letzten Schritt in der Beschreibung des Ablaufs dar.
Mögliche Ziele sind unter anderem:
Einige dieser Ziele stellen wahrscheinlich nur Mikro-Conversions dar, das heißt sie sind nicht das eigentliche Ziele einer Website. In allen populären Testingtools lassen sich jedoch eine Vielzahl an Conversion-Zielen festlegen.
Das Conversion-Tracking läuft nun in diesen Schritten ab:
Es gibt zwei Wege, wie das Tracking der gerade beschriebenen Ziele technisch umgesetzt werden kann. Ein Ziel wird erreicht, wenn
Der Aufruf einer bestimmten URL wird analog zum oben beschriebenen Targeting (3.1.1) aufgezeichnet. Sobald also die URL der Vielen-Dank-Seite oder der Bestellbestätigungsseite aufgerufen wird, wird eine Conversion gezählt.
Bei anderen Conversion-Zielen ändert sich die URL der Seite nicht, weshalb die Zielerreichung auf eine andere Weise registriert werden muss. Ein Klick auf ein Element mit der ID „button“ kann beispielsweise mit Hilfe von jQuery auf folgende Weise erkannt und dann an Optimizely gesendet werden:
$("div#id").on("click", function() {
window[‚optimizely‘].push(["trackEvent", "eventName"]);
});
Sobald ein Ziel als erreicht gilt, wird der im Schritt 3.2 gesetzte Cookie ausgelesen, um zu speichern, welche Testvariante der „konvertierte“ Besucher gesehen hat.
Erstaunlicherweise gibt es in JavaScript keine Funktion, um nur den Wert eines bestimmten Cookies auszulesen. Stattdessen sind Informationen zu allen auf der Domain gespeicherten Cookies in der Variable document.cookie enthalten.
Neben der gesehenen Testvariante werden weitere für die Segmentierung wichtige Informationen aus Cookies ausgelesene. Beispiele dafür sind:
Wie auch schon beim Tracking eines Besuchs (siehe 3.3) wird wieder eine HTTP-Anfrage an den Server des Testingtools gesendet, um Conversions aufzuzeichnen.
Neben den im Schritt 4.2 ausgelesenen Informationen sollte bei E-Commerce-Seiten auch der Warenkorbwert sowie häufig die Anzahl der gekauften Produkte übertragen werden. Diese Informationen müssen natürlich vom Shopsystem an das Testingtool übergeben werden. Um die Testergebnisse noch detaillierter auswerten zu können, werden in manchen Testingtools auch die Kategorien der gekauften Produkte gespeichert.
Wie detailliert die zu speichernden Informationen sind hängt auch mit den Kosten für das Testingtool zusammen. So sind beispielsweise in (teureren) Testingtools für Enterprise-Kunden wie Maxymiser oder Adobe Target mehr Arten der Segmentierung möglich, als in günstigeren Tools wie Optimizely oder Visual Website Optimizer.
In Unternehmen mit besonders hohen Sicherheitsanforderungen wie Banken besteht häufig die Furcht, dass durch Testingtools schädlicher Code per JavaScript in eine Seite eingefügt werden könnte. Deshalb lehnt es die IT-Abteilung
dort manchmal ab, JavaScript in sensible Bereiche einer Website wie dem Antragsprozess für einen Kredit einzufügen. Manche Testingtool ermöglichen deshalb Conversion-Tracking mit Hilfe von .gif-Pixeln anstelle von JavaScript.
Auf der Vielen-Dank-Seite wird dann beispielsweise folgendes Bild mit den Maßen 1×1 eingebunden:
<img src=http://log.testingtool.com/pixel?id=123&type=conv&rev=20120″ height=“1″ width=“1″ />
Der große Nachteil dieses Ansatzes besteht darin, dass keine Informationen aus Cookies an das Testingtool übergeben werden können. Die Möglichkeiten zur Segmentierung der Testergebnisse sinken dramatisch. Es empfiehlt sich
deshalb, diesen Nachteil gegenüber den Sicherheitsbedenken abzuwägen.
Im letzten Schritt werden die HTTP-Anfragen vom Server des Testingtools registriert und in eine Datenbank geschrieben. Aufbauend auf diesen gespeicherten Informationen werden diejenigen Reports generiert, welche im Interface des Testingtool abgerufen werden können.
Nachdem ein Besucher konvertiert gibt es drei Möglichkeiten, welche Inhalte das Testingtool diesem Besucher anzeigt:
Wenn Besucher nicht von den aktuellen bzw. weiteren Tests ausgeschlossen werden (1. und 2. Möglichkeit), stellt die außerdem die Frage, ob wiederholte Conversion nochmals gezählt werden sollen.
Verschiedene Testingtools haben unterschiedliche Standardeinstellungen, welche Varianten „konvertierte“ Besucher sehen und ob Conversions nochmals gezählt werden. Informieren Sie sich also darüber, wie Ihr Testingtool damit verfährt und entscheiden, Sie ob diese Wahl sinnvoll ist.
Beim bis jetzt beschriebenen Ansatz werden die Änderungen der Seite client-seitig, das heißt im Browser des Besuchers, vollzogen. Dies geschieht mit JavaScript.
Bei der Server-seitigen Auslieferung werden analog zur Client-seitigen Auslieferung alle zu modifizierenden Elemente einer Website herausgegriffen. Die Inhalte werden jedoch nicht auf dem Computer des Besuchers verändert, sondern noch bevor die Website den Computer des Besuchers erreicht.
Dazu wird ein so genannter Proxy-Server zwischen den Server und den Computer des Besuchers geschaltet. Wenn einem Besucher eine Testvariante zugewiesen wurde, ersetzt der Proxy-Server die zuvor markierten Elemente durch die jeweiligen Elemente der Testvarianten und sendet die modifizierte Datei an den Browser des Besuchers. Beide Arten der Auslieferung haben verschieden Vor- und Nachteile, die jeweils den Einsatz für bestimmte Szenarien sinnvoll machen. Es ist generell nicht zu sagen, welcher Ansatz der bessere ist.
[1] Dieser Report wurde ohne die Mithilfe oder Unterstützung von Optimizely erstellt. Da Optimizely jedoch eine recht große Verbreitung hat, haben wir es als Beispiel gewählt.
[2] Eigentlich ist „URL“ eine Eigenschaft des document-Objekts.
[3] Für eine Diskussion dieses Themas siehe http://stackoverflow.com/questions/1043339/javascript-for-detecting-browser-language-preference
[5] Für eine ausführliche Definition siehe http://www.w3.org/TR/DOM-Level-2-Core/introduction.html
[6] Eine komplette Übersicht findet man unter http://api.jquery.com/category/manipulation/
[7] Ein Ansatz dazu wird hier beschrieben: http://stackoverflow.com/questions/17080716/confuse-about-dom-manipulation-in-javascript
[8] Für mehr Informationen zum Thema Vererbung von Eigenschaften in CSS siehe http://www.css4you.de/wscss/css08.html
