A/B Tests auf Single Page Applications – so geht‘s

A/B Tests auf Single Page Applications (SPA) können eine echte Herausforderung sein. Mit den richtigen Tools, ein paar Kniffen und etwas technischem Background sind sie jedoch fast so schnell gebaut wie auf einer klassischen Website. Hier erfährst du, was du als CRO beim A/B Testen auf einer Single Page Application beachten solltest und wie du häufige Fehler vermeidest.

Single Page Applications und der Unterschied zu herkömmlichen Websites

Eine Single Page Application ist eine Webanwendung, bei der alle notwendigen Ressourcen (z.B. HTML, CSS, JavaScript Code) beim ersten Laden der Seite heruntergeladen werden. Danach interagiert der Benutzer mit der Anwendung, ohne dass die Seite komplett neu geladen wird. Inhalte werden dynamisch nachgeladen und aktualisiert, wodurch ein nahtloses und reaktionsschnelles Benutzererlebnis entsteht. 

Deshalb fühlen sich SPAs bei der Benutzung im Browser eher wie native Apps auf dem Smartphone oder Tablet an. Sie können theoretisch mit einer einzigen URL (z.B. nur der Domain) auskommen. Somit ist ein klassischer A/B Test schwer zu adressieren, wenn er nicht unbedingt direkt auf der Startseite sondern z.B. auf einer Produktdetailseite stattfinden soll. 

Oft verwenden Entwickler von SPAs jedoch trotzdem separate URLs, um das Tracking in Analyse-Tools zu vereinfachen und die Suchmaschinenoptimierung (SEO) zu begünstigen. Diese Tatsache können sich Conversion Rate Optimierer zu Nutze machen, um ihre Experimente dennoch an verschiedenen Stellen der User Journey zu triggern. 

Im Unterschied zur SPA besteht eine klassische Website aus mehreren HTML-Seiten, die jeweils eine eigene URL haben und bei der Navigation zwischen den Seiten neu geladen werden. Der Hauptunterschied liegt also darin, wie Inhalte geladen und präsentiert werden:

Single Page Application

• Inhalte werden dynamisch nachgeladen.
• Der Benutzer bleibt auf derselben Seite, während Inhalte aktualisiert werden.
• Das Benutzererlebnis ist flüssiger und schneller, da keine Seitenwechsel stattfinden.
• A/B Tests sind schwieriger umzusetzen, jedoch genauso möglich.

Klassische Website

• Jeder Seitenwechsel erfordert das vollständige Laden einer neuen Seite.
• Das Benutzererlebnis kann langsamer und weniger flüssig sein, insbesondere bei häufigen Seitenwechseln.
• A/B Tests lassen sich einfach einbauen, weil das Laden der jeweiligen Seite den Trigger für den Start des Tests auslöst.

Es gibt nur eine oder wenige URLs – wo platziere ich meinen Test?

Für gewöhnlich starten A/B Tests, wenn eine vorher definierte Seite vollständig in den Browser geladen wurde. Da eine Single Page Application nur aus einer einzigen Seite besteht, können die A/B Testing Tools einen klassischen Test außer in der Startansicht nur dann starten, wenn die URL im Browser wechselt.

Dies geschieht jedoch nur, wenn es die Entwickler der Applikation vorgesehen haben – eigentlich nötig ist es für die Funktion der SPA nicht. Im Zweifel fehlt also eine geeignete URL, um den Test auszulösen.

Das sollte dich jedoch nicht davon abhalten, A/B Tests auf einer Single Page Application durchzuführen. Und zwar aus diesen drei Gründen:

Nur wenige Page URLs – diese Optionen bieten sich an

1. Du kannst mit den wenigen vorhandenen URLs schon sehr viele Ideen vertesten (selbst wenn es nur eine einzige URL gibt).
2. Es ist für Entwickler recht einfach, weitere URLs wie z.B. ‚/detail‘, ‚/selection‘ oder ‚/check-out‘ hinzuzufügen und damit einen Seitenwechsel vorzutäuschen. Das wird ohnehin für ein korrektes Funnel-Tracking in den Analytics-Tools benötigt, was als gutes Argument dafür gelten dürfte.
3. Einige A/B Testing Tools bieten neben der Page-URL auch andere Trigger an. So kann z.B. das Erreichen einer bestimmten Scrolltiefe oder der Klick auf ein per CSS-Selektor definiertes Element (auf Eindeutigkeit achten!) als Auslöser für einen A/B Test verwendet werden. Diese Option ist eventuell erst in einem höheren Plan deines Tools verfügbar. Prüfe also, ob in deinem aktuellen Plan Custom Triggers möglich sind. Falls nicht, könntest du ein Upgrade erwägen.

Tipp: Vergewissere dich zuerst, ob und – wenn ja – wann sich im Laufe der typischen Customer Journey die Seiten-URL im Browser ändert. Am besten notierst du dir die Schritte und die jeweils angezeigten URLs. Dann sprichst du mit deinen Frontend-Devs, ob die URL-Struktur der Single Page Application an das tatsächliche Funnel-Schema angepasst werden könnte.

Inhalte werden erst später geladen – wie kann ich sie dennoch verändern?

Single Page Applications sind hochgradig dynamisch. Nahezu jede Nutzerinteraktion löst einen Request aus und lädt den angefragten Content im Hintergrund vom Server oder aus einer bereits vorhandenen Datenquelle (z.B. JSON im HTML-Code). Oft werden Inhalte, die gerade nicht im sichtbaren Bereich des Browsers (Viewport) liegen erst dann gerendert, wenn der User an die entsprechende Stelle scrollt. Das nennt man Lazy Loading.

Das bedeutet, dass der Inhalt, den du mit deinem A/B-Test verändern willst, möglicherweise noch gar nicht im sichtbaren Bereich der HTML-Seite präsent ist, wenn sie dir dein A/B Testing Tool zeigt. 

Ein Beispiel hierfür sind Tooltips, die erst dann erscheinen, wenn der Nutzer das „Info-I“ anklickt. Auf einer klassischen Website wird das komplette Tooltip-Element mit seinem Content beim Erstaufruf der Seite geladen und per CSS einfach ausgeblendet. Im A/B Testing Tool kannst du es sichtbar machen und zum Beispiel den Info-Text des Tooltips verändern.

Dagegen ist der gesamte Text des Tooltips auf einer Single Page Application im Originalzustand noch nicht vorhanden. Hier wird nur das „Info-I“ geladen. Beim Klick darauf lädt die App den Tooltip-Content nach und zeigt ihn dem Nutzer. Dein A/B Testing Tool findet also keinen Text, den es dir zum Editieren anbieten könnte. In den Dev-Tools deines Browsers siehst du in diesem Fall möglicherweise nur ein leeres <span></span>.

Tools überwachen die Seite mit einem Mutation Observer

A/B Testing Tools wie VWO oder Kameleoon bringen einen sogenannten Mutation Observer mit. Dieser beobachtet alle Veränderungen der Seite solange, bis ein bestimmtes Element, das über einen CSS-Selektor definiert wurde, sichtbar wird. Dann erst wendet das Tool die gewünschte Änderung an.

Ein praktisches Beispiel für den Mutation Observer

Nehmen wir einmal an, du möchtest den Text eines Popups ändern, welches erst nach Klick auf einen Button erscheint. Dafür bieten die Editoren zwei Modi an: Den Navigate– und den Design-Modus.

Im Navigate-Modus kannst du dich wie ein User über die Seite bewegen, alle Links und Buttons funktionieren wie erwartet. Hierin klickst du auf den Button, der das Popup öffnet. Dann wechselst du in den Design-Modus, editierst den Text des Popups und speicherst den A/B Test.

Das A/B Testing Tool weist deiner Modifikation einen CSS-Selektor zu, der eindeutig zu dem Inhalt des geöffneten Popups passt. Der Mutation Observer beobachtet die Seite nun solange bis das im CSS-Selektor adressierte Element im DOM-Baum sichtbar wird. Dann führt er deine Modifikation durch und beendet die Beobachtung.

Derartige Tests solltest du in der QA besonders intensiv überprüfen. Auch wenn das Tool sich alle Mühe gibt, einen eindeutigen Selektor für dein Element zu finden, kann es dies nicht in jedem Fall. Denn es weiß nicht, welche Elemente durch Nutzeraktionen später noch eingeblendet werden.

Tipp: Wenn du vor der Entscheidung stehst, welches A/B Testing Tool das richtige für dein Projekt ist, dann frage beim Anbieter nach, ob der Editor einen Mutation Observer enthält. Auch wenn noch nicht ganz perfekt, ist dies der einfachste Weg, einen A/B Test auf einer Single Page Application durchzuführen.

Mit Javascript einen eigenen Mutation Observer bauen

Der Mutation Observer funktioniert jedoch nur bei A/B Tests, die im Editor eines A/B Testing Tools gebaut wurden. Wenn du einen Javascript basierten Test zu einem späteren Zeitpunkt starten möchtest, kannst du zum Beispiel die setInterval()-Methode nutzen und damit das auslösende Event (z.B. Klick auf einen Button oder Erreichen einer bestimmten Scrolltiefe) überwachen.

// Beispiel für eine Interval-Funktion
if (window.myInterval) {
clearInterval(window.myInterval);
}
window.myInterval = setInterval(function() {
if (document.querySelector('CSS-Selektor')) { // hier den CSS-Selektor eintragen
// hier die Modifikation ausführen
clearInterval(window.myInterval);
}
}, 1000);

Mit der Javascript-Methode setInterval() sucht dieses Script im Abstand von einer Sekunde nach einem Element auf der Seite, dass per eindeutigem CSS-Selektor definiert wurde. In dem obigen Beispiel könnte dieser Selektor so aussehen: div.popup-inner > span. Sobald dieses Element im DOM-Baum erscheint, startet die eigentliche Modifikation und die ganze Suchaktion wird mit clearInterval() beendet.

Drei Dinge sind beim Verwenden von setInterval() zu beachten

1. setInterval() läuft bei einer Single Page Application im Hintergrund immer weiter – solange bis es mit clearInterval() beendet wurde. Sollte der Nutzer also nicht die beabsichtigte Interaktion durchführen, dann können auf den Folgeseiten Fehler in der Konsole auflaufen. Am besten, du überprüfst die Konsole nach dem Einbau der Methode nicht nur im aktuellen, sondern auch auf den darauf folgenden Schritten.
2. Solltest du mehrere Intervalle in deinem Script verwenden, dann müssen alle einen eigenen Namen haben. myInterval muss also beim Kopieren z.B. in myInterval1 umbenannt werden (an allen vier Stellen).
3. Ein Intervall von 1000 Millisekunden ist ein Kompromiss zwischen Speed und Browserlast. Es wird zu einem kleinen Flicker-Effekt führen. Das bedeutet, der Nutzer sieht erst den originalen Content und dann nach maximal einer Sekunde den modifizierten. Du kannst das Intervall heruntersetzen. Bedenke aber, dass der Browser des Users damit recht viel Arbeit bekommt und es im Falle eines Fehlers zu massenhaft Errors in der Konsole kommen kann.

Was tun, wenn der A/B Test nach kurzer Zeit wieder verschwindet?

Single Page Applications werden mit modernen Frameworks gebaut. Zu den bekanntesten zählen React, Gatsby und NextJS. Diese Frameworks sind darauf ausgelegt, dem User eine extrem hohe Response zu liefern, den Seitenaufbau so schnell wie möglich durchzuführen.

Dafür speichern sie sogenannte Snapshots der Applikation zwischen. Kehrt der Nutzer zum Beispiel an einen früher bereits besuchten Ort zurück, dann wird einfach der Snapshot wiederhergestellt, anstatt einzelne Komponenten neu zu laden.

Leider führt dieses Verhalten auch dazu, dass die A/B Tests, die ja den ursprünglichen DOM-Baum verändert haben, wieder überschrieben werden und somit nicht mehr sichtbar sind.

Für den statistischen Wert des Testergebnisses und selbstredend auch für die User Experience ist es nachteilig, wenn der User zunächst Inhalte eines Tests sieht, dann beim Zurückkehren jedoch den originalen Content gezeigt bekommt.

Re-Apply-Funktion im Editor aktivieren

Die A/B Testing Tools (VWO und Kameleoon kenne ich aus eigener Erfahrung, bei den anderen bitte einmal nachfragen) bieten dafür eine Re-Apply oder ähnlich genannte Funktion.

Diese startet die Modifikation einfach neu, nachdem sie erkannt hat, dass der Browser-Content aus einem Snapshot neu gerendert wurde. Eventuell muss diese Funktion – genau wie der Mutation Observer – erst aktiviert werden. Das geschieht in den Settings des jeweiligen A/B Tests. Du findest sie, indem du den Editor in der Variante öffnest.

Mit Javascript weiter führende Links einfangen

Für Script basierte A/B Tests bietet es sich an, alle von der Testansicht weiter oder zurück führenden Buttons und Links mit einem EventListener zu belegen, der die eigentlichen Änderungen neu startet.

Führt zum Beispiel ein Button zum Warenkorb, und der modifizierte Content soll auf der Warenkorb-Seite ebenfalls sichtbar sein, dann sorgt ein EventListener auf dem Button dafür, dass die Änderungen dort erneut ausgeführt werden.

Eventuell ist zusätzlich ein setTimeout von etwa 1000 Millisekunden sinnvoll, um die erneute Ausführung etwas zu verzögern. Ansonsten besteht die Gefahr, dass die Modifikation schneller fertig ist als das Rendering der Warenkorb-Seite.

Fazit

Ein einfacher A/B Test auf einer Single Page Application ist mit den heutigen Tools kein Problem mehr. Dennoch sollte man sich als CRO mit den technischen Eigenarten seiner SPA auseinander setzen und den Kontakt zu den Frontend-Entwicklern suchen, die die App gebaut haben.

Bist du bisher davor zurück geschreckt, auf der Website deines Unternehmens A/B Tests durchzuführen, weil diese ganz oder in Teilen eine Single Page Application ist? Dann möchte ich dir gern raten, es einmal zu probieren.