Server-seitiger A/B-Test: So setzen Sie ihn richtig auf!

Optimierungsprojekte von Webapplikationen sind häufig auf client-seitiges A/B-Testing ausgelegt, eine Methode, welche die meisten Tools bieten. Es gibt jedoch auch Situationen, in denen ein server-seitiger Test sinnvoll bzw. die einzige sinnvolle Lösung ist. Kameleoons Fullstack Testing Lösung ermöglicht sowohl ein client-seitiges als auch server-seitiges Testen, sowie die Kombination beider Methoden.

Server Side oder Client Side? Was sind die Unterschiede, und wie setzt man ein server-seitiges Experiment richtig auf?

1 Wann nutzt man server-seitiges,  und wann client-seitiges A/B-Testen?

Jeder gute A/B-Test fängt mit einer Hypothese an. Innerhalb einer Applikation wurde aufgrund von Datenauswertungen oder qualitativer Beobachtung ein bestimmtes Problem ausgemacht und die Lösung soll anhand des Vergleichs verschiedener Variationen gefunden werden.

Häufig handelt es sich um UX-Bereiche, angefangen bei der Farbe eines Buttons, über die Schritte in einem Checkout-Funnel bis hin zur kompletten Neugestaltung von Abwicklungswegen. Um eine Farbe oder einen Text zu ändern, benötigt man in der Regel kein server-seitiges Testen, dies kann mit wenig Aufwand über einen WYSIWYG-Editor im Frontend angepasst werden.

Wenn es jedoch beispielsweise darum geht, in einem Onlineshop zu überprüfen, ob das Entfernen der Versandkosten die Conversion Rate derart verbessert, dass die Gewinnmarge unabhängig davon steigt, so ist dies bereits schwieriger.

Ein weiteres Beispiel: Für ein Produkt muss in einem angeschlossenen Warenwirtschaftssystem eine veränderte Rechnung generiert werden bzw. die Produktkonfiguration soll geändert werden. Dies ist der ideale Fall für einen server-seitigen Test.

2 Die wichtigsten Unterschiede

Über die genannten Beispiele hinaus spielen weitere Faktoren in die Entscheidung über client- vs. server-seitiges Testen ein.

Flickering

Bei einer client-seitigen Implementierung kann es zu einem Flickern kommen, zwischen Laden des A/B-Testing Tools und Anzeige der Variation. Zwar gibt es Methoden wie bspw. die Anti-Flicker Technologie, welche dies verhindern können, der Einsatz kommt jedoch zumeist mit einer leichten Einbuße in der Website-Performance einher, da hiermit der First Contentful Paint (FCP) hinausgezögert wird. Bei einem server-seitigen Experiment wird die Veränderung bereits auf dem Server vorgerendert und ein Flickering ist somit ausgeschlossen.

Performance

Die Website-Performance und somit der Pagespeed wird maßgeblich durch das Nachladen von Assets wie CSS und Javascript beeinflusst. Technologien wie http2 und Kompressionsalgorithmen wie brotli, welche beide bei Kameleoon zum Einsatz kommen, können den Effekt reduzieren, ein weiterer Request beeinträchtigt jedoch die Performance.

Durch den Einsatz eines asynchronen Server Side SDKs wird die Performance spürbar verbessert, da hierbei lediglich einmalig die Konfiguration vom Server geladen werden muss und die Ergebnisse anschließend asynchron zurück übermittelt werden. Jegliche Veränderung wird auf dem Server vorgerendert.

Frontend oder Backend Coding

Das Umsetzen eines komplexen Tests erfordert technisches Know-How und Entwicklerressourcen. Bei einem client-seitigen Test kann dies relativ einfach outgesourced werden, da man den Test gewissermaßen über der Website bzw. Applikation programmiert. Elemente der Website oder App werden mittels Javascript verändert. Da diese Elemente bereits vorhanden sind, kann man diese Art von Projekten problemlos an einen externen Entwickler auslagern.

Bei einem server-seitigem Experiment braucht man darüber hinaus Backend-Entwicklerressourcen, und Mitarbeiter, welche sich mit der Website, bzw. den Applikationen auskennen und auch in der Lage sind, einen Test zu implementieren, welcher im Anschluss bei Bedarf für die Gewinnervariante umgebaut werden kann. Der Vorteil liegt also in der Zeitersparnis bei der anschließenden, permanenten Implementierung.

Implementierung & Deployment

Software is hard. Jede Änderung an einer komplexen Software bedeutet, dass an einer anderen Stelle – welche nicht bedacht wurde – etwas nicht mehr funktionieren könnte. Hierfür gibt es Regressionstests, Behaviour-Driven Tests und Funktionstests, welche nach der Implementierung automatisch durchlaufen.

Möchte man einen A/B-Test durchführen, so können diese Tests fehlschlagen, da die Software durch den Test mindestens zwei unterschiedliche Verhaltensweisen hat. Bei einem client-seitigen Test ist kein erneutes Deployment der Website oder Applikation notwendig. Die Software-Tests können bei Bedarf durch einen Opt-Out deaktiviert werden.

Bei einem server-seitigem Test ist das Deployment erforderlich, die Software-Tests werden entweder für den A/B-Test deaktiviert, angepasst oder schlagen fehl. Je nach Aufwand des A/B-Tests und Anpassung im Code ist es jedoch ratsam, die Software-Tests hierfür anzupassen.

Segmentierung und Nutzermerkmale

Bei einer client-seitigen Segmentierung stehen in der Regel mehr Merkmale zur Nutzeridentifikation zur Verfügung, als bei der server-seitigen Implementierung. Dies liegt schlicht daran, dass viele Parameter, welche man innerhalb des Browsers abfragen kann, zum Zeitpunkt der Anfrage beim Server noch nicht vorhanden sind.

Benötigt man bestimmte Merkmale wie bspw. Bildschirm-Auflösung, Tracking-Daten oder Daten, welche im Server noch nicht zur Verfügung stehen, so ist ein client-seitiger A/B-Test zu bevorzugen.

SEO Einfluss und Auswirkungen

Es gibt verschiedene Empfehlungen, wie man einen A/B-Test am besten einrichtet, ohne dass dieser eine negative Auswirkung auf das Ranking in Suchmaschinen ergibt. Grundsätzlich werden A/B-Tests durch Suchmaschinenbetreiber wie Bing und Google als positiv gesehen, weil sie einer verbesserten User Experience dienen.

Die Änderung im Frontend, sofern diese client-seitig gemacht wird, kann jedoch zu Veränderungen führen, welche der Suchmaschinen-Crawler als langfristige Veränderung der Seite wertet. Um dies zu vermeiden, wird mit rel=“canonical” links gearbeitet, 302 Weiterleitungen werden eingerichtet und die Tests laufen lediglich so lange, bis sie valide Ergebnisse liefern. Wie man die Testdauer berechnet und wann ein Test beendet werden kann, können Sie übrigens in weiteren Blogbeiträgen nachlesen.

Führt man einen Test server-seitig aus, so kann man gleichzeitig über x-robots Tags oder Canonical Links beeinflussen, ob die Variante für Suchmaschinen relevant sein soll, oder aber unter welcher URL die Originalvariante dargestellt wird. Die Gefahr, die Änderung als eine Art Cloaking bewertet zu bekommen, wird dadurch minimiert.

3 Anwendungsfälle für server-seitiges Testen

Ein server-seitiger Test ergibt dann Sinn, wenn Elemente geändert werden sollen, welche eine Konfiguration im Backend erforderlich machen. Dazu gehören Veränderungen im Billing-Bereich oder bzgl. der Warenwirtschaft - also Fälle, bei denen Konfigurationen von angeschlossenen Systemen beeinflusst werden.

Nehmen wir noch einmal an, in einem Onlineshop soll getestet werden, ob eine Änderung der Versandkosten eine Auswirkung auf den Umsatz hat, und wenn ja, wie groß sie ausfällt. Die Stichprobe wurde berechnet und ein Business Case kalkuliert, sodass feststeht, wie hoch der Uplift sein muss, um die Veränderung zu rechtfertigen.

Unstrittig ist, dass eine Änderung in diesem Bereich eine Auswirkung auf Rechnungserstellung und Buchhaltung haben wird. Es gibt verschiedene Möglichkeiten, einen solchen Test umzusetzen.

Nachstehend die Vor- und Nachteile der unterschiedlichen Methoden:

Client-seitiger A/B Test:

• Ein neuer Test mit einer Variante wird im A/B-Testing Tool angelegt
• Im Onlineshop werden über das Client-SDK mittels Javascript und CSS in der Variante die Versandkosten ausgeblendet oder angepasst
• Wenn ein Checkout stattfindet, wird dem Kunden automatisch ein Rabattartikel oder ein Couponcode „Versandreduktion“ in den Warenkorb gelegt, die Rechnung wird dementsprechend angepasst
• Auf der finalen Danke- Seite wird das Ziel gefeuert, welches den Warenkorbwert übermittelt
• In der Auswertung wird überprüft, ob die Variante gewinnt und der Gesamtumsatz dadurch so stark gestiegen ist, dass eine Anpassung betriebswirtschaftlich gerechtfertigt ist

Server-seitiger A/B Test:

• Ein neuer Test mit einer Variante wird im A/B Testing Tool angelegt
• Im Onlineshop werden über das Serverside-SDK die Referenz und die Variante ausgespielt - in der Referenz ohne und in der Variante mit Versandkostenanpassung
• In beiden Varianten wird im Backend Code das Ziel auf der finalen Danke-Seite mit dem Warenkorbwert gefeuert
• Die Ergebnisse werden an das A/B-Testing Tool übermittelt und dort in der Auswertung dargestellt - analog zum client-seitigen Test werden die Ergebnisse aus einer betriebswirtschaftlichen Perspektive auf Basis der Conversion-Rate miteinander verglichen

Zusammenspiel aus client- und server-seitiger Kommunikation:

• Es wird in der Variante über Javascript ein Cookie gesetzt
• Ist der Cookie vorhanden, so gibt es im Backend unterschiedliche Logiken zu den Versandkosten, welche durch die Applikation im Backend Code gesteuert und gerendert werden
• Die Rechnung wird angepasst und die angeschlossenen Systeme erhalten durch die Webapplikation korrekte Werte
• Die Ergebnisse werden client-seitig erfasst und vom A/B-Testing Tool ausgewertet

Alle 3 Varianten bieten Vor- sowie Nachteile, welche sich wie folgt darstellen:

1. Aufwand Der Aufwand einer A/B-Test Implementierung muss eingeschätzt und dem potentiellen Nutzen gegenübergestellt werden. Ein server-seitig implementierter Test bindet Backend-Entwicklerressourcen, client-seitige Tests binden Frontend-Entwicklerressourcen – hier gilt es also erstens abzuschätzen, wie man diesen Aufwand am besten abbildet, und zweitens, welche Variante am einfachsten und schnellsten umsetzbar ist.
2. „Gaming“ bzw. Ausnutzen der Variante Ein Test läuft in der Regel lediglich 2-3 Wochen, je nach Traffic und Benutzersegment. Das aktive Ausnutzen eines Tests – in diesem Fall die reduzierten Versandkosten – würde zum einen das Testergebnis verfälschen, zum anderen jedoch auch den wirtschaftlichen Effekt ggf. zunichte machen. Hier ist zu überlegen ob man bereit ist, dieses Risiko einzugehen und welche Maßnahmen je nach Methode verwendet werden können um dies zu verhindern. Ein server-seitig implementierter Test würde dies auf jeden Fall erschweren oder komplett verhindern.
3. Sicherheitseinstufung Never trust a client – ein bekanntes Prinzip aus der Softwareentwicklung, insbesondere bei Entwicklern im Backend beliebt. Die Implementierung eines server-seitigen A/B Tests bietet mehr Sicherheit während der Testdurchführung, sofern dieser korrekt implementiert wurde

Man kann diese Testideen beliebig ausweiten und eine Testreihe daraus entwickeln, bspw. ob eine Versandkostenreduktion bei unterschiedlichen Warenkorbwerten – also ab einem oder unterschiedlichen Schwellenwerten – gewinnbringend ist. Oder aber ob die Änderung in Kombination mit einer Anpassung verschiedener Zahlungsmethoden eine Veränderung erwirkt. Die Hypothesen sollten natürlich immer auf konkreten Daten basieren.

4 Deploymentzyklen beim App Testing

Bei einer App, welche im Android Play Store oder im Apple Appstore verfügbar ist, sind die Deploymentzyklen in der Regel geringer als bei einer Webapplikation. So orientieren sich reguläre Deploymentzyklen an den Sprint-Längen von Entwicklerteams oder cross-funktionalen Teams, welche in der Regel zwischen 2 und 3 Wochen liegen.

Im Gegensatz zu Bugfixes werden mehrere Sprints genutzt, um ein neues Feature auszurollen, sodass ein Deployment auch lediglich einmal im Monat oder geringer stattfinden kann. Möchte man diese Zyklen für das A/B-Testing nutzen, so entsteht die Herausforderung des An- und Abschaltens sowie des Ein- und Ausbauen des A/B-Tests.

Client-seitige Tests können relativ einfach an- und wieder abgeschaltet werden – ohne Deployment. Bei einem server-seitigen Test ist eine Änderung lediglich durch ein Deployment der Applikation möglich.

Die Traffic Aufteilung kann über den visuellen Editor vor und während dem Test angepasst werden

Bei der Traffic-Zuweisung sieht es jedoch anders aus – hier ist irrelevant, ob ein Test client-seitig oder server-seitig implementiert wurde. Die Konfiguration kann auch während eines laufenden Tests angepasst werden und so bspw. der Gewinnervariante 100% des Traffics zugewiesen werden

5 Wie funktioniert server-seitiges Testen mit Kameleoon?

Kameleoons Gründer und CTO Jean-Noël Rivasseau hat die Architektur von Serverside-Tests in einem früheren Blogbeitrag ausführlich beschrieben. Die Entwicklerressourcen zu einer Implementierung der server-seitigen SDKs bieten Entwicklern eine gute Grundlage und zeigen, wie dies bspw. in Java, C# im .NET Umfeld, Node.js, Android oder Swift realisiert werden kann. Die Vorgehensweise ist denkbar einfach:

1. Zunächst wird ein SSX A/B Test im Back-Office von Kameleoon oder alternativ über die REST API angelegt.
2. Die Implementierung des eigentlichen Tests benötigt die Parameter, welche von Kameleoon für den Test bereitgestellt werden (Variation ID, Sitecode und Goal-IDs).
3. Der Test kann anschließend über die REST API gestartet werden, die ersten Ergebnisse werden anschließend nach ca. 30 Minuten auf der Ergebnisseite dargestellt.
4. Hat eine ausreichende Zahl von Besuchern am Test teilgenommen, kann man dies auf der Ergebnisseite auswerten. Man sieht, wann die Ergebnisse stabil genug für eine Auswertung sind.

6 Datenanreicherung und Datenauswertung eines server-seitigen A/B-Tests

Mithilfe von Custom Data Werten hat man außerdem die Möglichkeit, die Daten anzureichern, sodass im Anschluss weitere Parameter in der Auswertung zur Verfügung stehen. Hat man bspw. verschiedene Produkte, welche in einem Bestellprozess bestellt werden können, so wäre es denkbar, diese an Kameleoon zu übermitteln, um im Anschluss die Ergebnisse nach dieser Information zu filtern oder aufzuschlüsseln. 

Auswertung der Daten über die Ergebnisseite

7 Fehler und Best Practices bei server-seitigem Testen

Server-seitiges A/B-Testen bringt einige Vorteile mit sich, welche einige Kameleoon Kunden bereits nutzen. Bevor jedoch mit einem server-seitigen Testen begonnen wird, sollte sichergestellt werden, dass eine Testkultur im Unternehmen vorhanden und die nötigen Prozesse bestehen.

Tests werden dann von Backend-Programmierern erstellt, durchgeführt und wieder entfernt. Für jeden Anwendungsfall und jede Hypothese sollte vorab erneut überprüft werden, ob ein client-seitiges oder serverseitiges Testen die bessere Lösung darstellt und wieviel Aufwand der Test bedeutet. Sollen primär visuelle Bereich und UX-Themen getestet werden, oder handelt es sich um funktionale A/B-Tests, welche tief integrierte Systeme betreffen?

Anschließend können die einzelnen Tests geplant, implementiert, überprüft und durchgeführt werden, eine Test-Roadmap hilft bei der Priorisierung. Best Practice gebietet, auch für die Varianten eine Voransicht zu implementieren – entweder über einen URL-Parameter, ein Cookie oder aber einen individuellen Identifier.

Die Auswertung der Tests ist wieder einfach und klassisch über den Browser im Kameleoon-Tool möglich - hierfür sind keine Programmierkenntnisse notwendig.

Haben wir Ihre Neugierde geweckt? Wenn Sie an server-seitigem A/B-Testing interessiert sind, sprechen Sie uns an!