Zum Hauptinhalt springen
Kameleoon hat traditionell den Betrieb von A/B-Tests auf (mit einer JavaScript-Engine) oder auf (mit einem serverseitigen SDK) ermoeglicht. Da jedoch umfangreiche Caching-Strategien aus Performance-Gruenden ueblich sind, koennen HTTP-Anfragen die Back-End-Anwendungsserver moeglicherweise nie erreichen. Stattdessen antwortet ein vorgeschalteter Webserver direkt mit einer gecachten Version der angeforderten Seite. In diesen Konfigurationen koennen serverseitige SDKs nicht verwendet werden, da die Logik zur Zuweisung eines Besuchers zu einem Experiment im Backend-Anwendungscode geschieht, was bedeutet, dass viele Anfragen nicht verarbeitet werden koennen, weil stattdessen eine gecachte Version der Seite zurueckgegeben wird. Mit anderen Worten: Der Code, der die Verkehrsverteilung auf Variationen eines Experiments implementiert, wuerde nicht ausgefuehrt. Um diese Herausforderung zu loesen, sind Kameleoon-A/B-Testing-Module fuer die wichtigsten Webserver verfuegbar. Dadurch kann der Webserver die von jedem Besucher verwendete Variation bestimmen. Der Server kann mit einer gecachten Version der richtigen Variation antworten, sodass die Anwendung von standardmaessigen Caching-Strategien profitieren kann. Webtesting auf Webserver-Ebene ist eine Zwischenebene zwischen Front-End und Back-End.

​
Allgemeine Konzepte​

Ein Kameleoon-Webserver-Modul ist eine Low-Level-Komponente (in C fuer optimale Performance geschrieben), die die Variationszuweisung durchfuehrt, wenn eine HTTP-Anfrage ein A/B-Experiment ausloest. Anschliessend leitet es die Anfrage (intern) an eine potenziell andere URL um, die der gewaehlten Variation entspricht. Wenn beispielsweise ein Besucher die Seite https://www.shop.com/plasma-tvs.html aufruft und auf dieser Kategorieseite ein laufendes Experiment mit drei Variationen vorhanden ist, leitet der Webserver die HTTP-Anfrage intern entweder an https://www.shop.com/plasma-tvs.html (Originalversion), https://www.shop.com/plasma-tvs.html?version=B (erste Variation) oder https://www.shop.com/plasma-tvs.html?version=C (zweite Variation) weiter. Anschliessend wird eine gecachte Version dieser Seiten zurueckgegeben (oder der Aufruf an den Anwendungsserver weitergeleitet, um eine neue zu generieren, wenn der TTL-Wert abgelaufen ist). Der A/B/C-Test ist fuer Endbenutzer voellig transparent. Der Besucher sieht im Browser nur die kanonische URL https://www.shop.com/plasma-tvs.html. Einrichtung und Konfiguration des Experiments (einschliesslich der Festlegung der Ziel- und Weiterleitungs-URLs, z. B. durch Hinzufuegen des Parameters ?version=B) werden in der Kameleoon-Plattform abgeschlossen. Das Webserver-Modul aktualisiert seine Konfiguration regelmaessig von den Kameleoon-Servern und der Datenbank. Fuer eine bequeme Planung und Bereitstellung von A/B-Tests sind alle ueblichen Kameleoon-Funktionen verfuegbar, einschliesslich Starten, Pausieren und Stoppen von Tests, Aendern der Abweichung und Aendern der Konfiguration.
Aufgrund der technischen Einschraenkungen des Client-Server-Modells im Web ist die Verwendung von URL-Bedingungen die einzige Moeglichkeit, das Targeting von Experimenten auf Webserver-Ebene zu konfigurieren. Verwenden Sie ebenso in Kameleoon immer URL-Weiterleitungen, um Variationen auf Webserver-Ebene zu konfigurieren. Die negativen Auswirkungen auf Performance und SEO, die mit Front-End-(Browser-)Weiterleitungen verbunden sind, stellen bei Webserver-Weiterleitungen kein Problem dar. Stattdessen sind interne Webserver-Weiterleitungen vollkommen sicher und gelten als gute Praxis, da sie intern auf dem Webserver verarbeitet werden (sie sind schnell) und fuer Suchmaschinen-Crawler transparent sind.

​
Betrieb von A/B-Experimenten auf Webserver-Ebene​

  1. Erstellen Sie in der Kameleoon-App ein neues A/B-Experiment mit dem Code-Editor.
  2. Erstellen Sie in Kameleoon die Variationen, die Sie fuer das Experiment implementieren moechten. Waehlen Sie fuer jede Variation die Option URL-Weiterleitung und geben Sie die gewuenschte neue URL ein.
  3. Waehlen Sie das Targeting des Experiments aus, indem Sie eine oder mehrere URL-Targeting-Bedingungen hinzufuegen. Jede uebereinstimmende URL auf dem Webserver loest das Webserver-Modul fuer die Anfrage aus und aktiviert eine interne Weiterleitung. Das Modul speichert ein (First-Party-)Cookie mit dem Namen kameleoonVisitorCode fuer uebereinstimmende Anfragen.
Bei Webserver-Experimenten werden nur URL-Weiterleitungsoptionen beruecksichtigt. Alle anderen Modifikationen an den Variationen, wie JavaScript- oder CSS-Codeaenderungen ueber den grafischen Editor, werden ignoriert.
Sie koennen dann die Abweichung waehlen und das Experiment wie gewohnt starten. Das Pausieren oder Stoppen des Experiments funktioniert ebenfalls wie erwartet.
Traffic-Ausschluss funktioniert nicht mit A/B-Experimenten auf Webserver-Ebene. Die Analytik fuer die Originalversion des Experiments enthaelt Daten von Besuchern aus dem ausgeschlossenen Bucket, anstatt diese Besucher vollstaendig vom Experiment auszuschliessen.
Um potenzielle Behandlungen auf der Serverseite zu unterstuetzen (Tracking, Implementierung von Variationen), fuegt der Webserver jeder Anfrage, die einem Kameleoon-Experiment entspricht, einen HTTP-Header hinzu, wenn die Option in der Nginx-Konfigurationsdatei aktiviert ist (kameleoon_headers on;). Der erste Header heisst kameleoon-experiment und sein Inhalt hat das Format experimentID=variationID, wobei experimentID die ID des ausgeloesten Experiments und variationID die ID der zugewiesenen Variation darstellt. Der zweite Header heisst kameleoon-redirection und sein Inhalt hat das Format variationID=redirectionURL, wobei variationID die ID der zugewiesenen Variation und redirectionURL den fuer die Weiterleitung verwendeten Parameter darstellt.

​
Unterstuetzte Plattformen​

​
Nginx-Server-Modul​

Das Modul unterstuetzt die Nginx-Versionen 1.18.0, 1.20.2 und 1.21.4; das Docker-Paket ist hier verfuegbar. Die neueste Version des Moduls unterstuetzt die Nginx-Version 1.27.1; das Docker-Paket ist hier verfuegbar.
Das Modul wird auf einer x86_64-Architektur getestet.
Ein Python-Skript muss ebenfalls parallel installiert werden (und periodisch ueber einen CRON-Job ausgefuehrt werden; Intervalle von 30 oder 60 Minuten werden empfohlen). Automation-API-Anmeldedaten (fuer die OAuth 2.0-Authentifizierung) sind erforderlich, um das Skript zu verwenden. Details finden Sie im Artikel API-Anmeldedaten.

​
Apache HTTPd-Server-Modul (veraltet)​

Das Apache-httpd-Modul unterstuetzt die Version 2.4 und wurde auf einer CentOS-Distribution mit x86_64-CPU-Architektur getestet.
Ein Python-Skript muss ebenfalls parallel installiert werden (und periodisch ueber einen CRON-Job ausgefuehrt werden; Intervalle von 30 oder 60 Minuten werden empfohlen). Dieses Skript aktualisiert die vom Kameleoon-Modul benoetigte generierte Nginx-Konfigurationsdatei. Das Skript laedt auch die Konfigurationsdatei neu.