A/B-Testing

Für die Durchführung eines Experiments muss es zunächst erstellt werden. Dies ist im SiteArchitect und ContentCreator auf unterschiedliche Weise möglich.

Abbildung 2. Button zur Experimenterstellung im SiteArchitect

In beiden Clients wird mit der Erstellung des Experiments die A/B-Testing-Leiste eingeblendet. In dieser werden die Originalseite und eine automatisch erzeugte Variante in Form von Tabs dargestellt. Die Variante ist für die sofortige Bearbeitung selektiert (vgl. Abbildung A/B-Testing-Leiste im ContentCreator und in der Vorschau des SiteArchitects).

Abbildung 3. A/B-Testing-Leiste im ContentCreator und in der Vorschau des SiteArchitects

Für ein bestehendes Experiment können beliebig viele weitere Varianten hinzugefügt bzw. existierende Varianten gelöscht werden. Des Weiteren kann für jede Variante eine Verteilung sowie für das gesamte Experiment eine Teilnahmerate definiert werden.

Abbildung 4. Einstellungen bearbeiten

Nach der Erstellung und Bearbeitung des Experiments kann es über den Button Starten begonnen werden. Ist der Start erfolgreich, wird der Button grün und sein Label wechselt zu Läuft.

Ein bestehendes Experiment kann über den Button Experiment beenden in Form des Fähnchens gestoppt werden. Die selektierte Variante wird als neue Originalseite übernommen und die A/B-Testing-Leiste ausgeblendet.

Das Modul muss mithilfe der mitgelieferten abtesting-<Versionsnummer>.fsm-Datei auf dem FirstSpirit-Server hinzugefügt werden. Öffnen Sie für die Installation des Moduls den ServerManager und wählen Sie den Bereich Server-Eigenschaften → Module.

Abbildung 5. Modulverwaltung in den Server-Eigenschaften

Im Hauptpanel ist eine Liste der auf dem FirstSpirit-Server installierten Module zu sehen. Wählen Sie nach dem Klicken auf Installieren die mitgelieferte abtesting-<Versionsnummer>.fsm aus und bestätigen Sie die Auswahl mit Öffnen. Nach der erfolgreichen Installation wurde der Liste ein Ordner A/B-Testing Module hinzugefügt, der Alle Rechte erhalten muss (vgl. Abbildung Modulverwaltung in den Server-Eigenschaften).

Für den Einsatz des A/B-Testing-Moduls werden einige Vorlagen sowie projektspezifische Angaben benötigt. Sowohl der Import der Vorlagen als auch die weitere Konfiguration kann über die Projekt-Komponente vorgenommen werden, die dem verwendeten Projekt hinzuzufügen ist. Öffnen Sie dafür den ServerManager und wählen sie den Bereich Projekt-Eigenschaften → Projekt-Komponenten.

Abbildung 6. Projekt-Komponenten in den Projekt-Eigenschaften

Im Hauptpanel ist eine Liste aller bereits vorhandenen Projekt-Komponenten zu sehen. Wählen Sie nach dem Klicken auf Hinzufügen die A/B-Testing Project Configuration und bestätigen Sie die Auswahl durch OK. Die Projekt-Komponente wird anschließend der Liste im Hauptpanel hinzugefügt und muss noch konfiguriert werden (vgl. Abbildung Projekt-Komponenten in den Projekt-Eigenschaften). Selektieren Sie dafür den Eintrag in der Liste und öffnen Sie den zugehörigen Konfigurationsdialog über Konfigurieren (vgl. Abbildung Konfigurationsdialog der Projekt-Komponente).

Abbildung 7. Konfigurationsdialog der Projekt-Komponente

Arbeitsablauf zum Starten des Experiments

In dem Konfigurationsdialog wird über eine Combobox zunächst ein Arbeitsablauf zum Starten eines Experiments ausgewählt. Es muss sich dabei um einen Freigabe-Arbeitsablauf handeln, der alle einem Experiment zugehörigen Seiten und Seitenreferenzen freigibt. Mit dem Modul wird ein Beispiel-Arbeitsablauf ausgeliefert, der diese Anforderung bereits erfüllt. Wahlweise kann jedoch auch ein bestehender projektspezifischer Arbeitsablauf verwendet werden.

Name der priorisierten Transition

Oft enthält ein Arbeitsablauf mehrere von einem Status ausgehende Transitionen. In diesen Fällen wird eine Entscheidung benötigt, welche dieser Transitionen zu wählen ist. Der Arbeitsablauf verharrt dabei bis zu seiner Fortsetzung im aktuellen Status. Für den in der Projekt-Komponente ausgewählten Arbeitsablauf kann daher der Referenzname einer zu priorisierenden Transition angegeben werden. Sie wird vom Arbeitsablauf ausgeführt, während die anderen Transitionen unbeachtet bleiben.

Zulässige Seitenvorlagen selektieren

Der Konfigurationsdialog zeigt des Weiteren eine Liste aller für die Redakteure verfügbaren Seitenvorlagen. Dies bedeutet, dass technische oder ähnliche Vorlagen, die in den Auswahllisten der beiden Clients versteckt sind, an dieser Stelle nicht dargestellt werden. In der Liste des Konfigurationsdialogs müssen die für die Durchführung eines Experiments zulässigen Vorlagen selektiert werden. Für Seitenreferenzen, deren zugrunde liegende Seite auf einer nicht selektierten Vorlage basiert, wird der Button bzw. Menüeintrag zur Erstellung eines Experiments in beiden Clients ausgeblendet. Über die Tastenkombination STRG + A können alle Vorlagen innerhalb der Liste ausgewählt werden. In diesem Fall besteht keinerlei Einschränkung und es kann auf jeder Seitenreferenz ein Experiment erstellt werden.

Seiten löschen

Im nächsten Schritt ist zu entscheiden, wie beim Löschen von Varianten aus einem bestehenden Experiment bzw. beim Beenden eines Experiments mit den Seiten der einzelnen Varianten verfahren werden soll. Standardmäßig ist die dafür zur Verfügung gestellte Checkbox Seiten löschen deaktiviert. In diesem Fall bleiben die Seiten aller Varianten nach ihrer Entfernung aus einem bestehenden Experiment bzw. nach dem Beenden eines Experiments erhalten. Ist die Checkbox aktiviert, werden die Seiten der nicht übernommenen Varianten gelöscht.

Vorlagen importieren

Zuletzt können über den Button Vorlagen importieren diverse Templates in das Projekt übertragen werden. Sie stellen die Funktionalitäten des A/B-Testing-Moduls für den Redakteur bereit.

Dem Projekt muss eine Web-Komponente hinzugefügt werden. Öffnen Sie hierfür den ServerManager und wählen Sie den Bereich Projekt-Eigenschaften → Web-Komponenten.

Abbildung 8. Web-Komponenten in den Projekt-Eigenschaften

Innerhalb des Hauptpanels sind verschiedene Registerkarten zu sehen, die eine Liste der bereits vorhandenen Web-Komponenten enthalten. Wählen Sie nacheinander alle Registerkarten aus und selektieren Sie jeweils nach dem Klicken auf Hinzufügen die A/B-Testing WebApp, um diese über OK hinzuzufügen. Die Liste im Hauptpanel wird dann um die Web-Komponente ergänzt (vgl. Abbildung Web-Komponenten in den Projekt-Eigenschaften).

Die Web-Komponente muss auf einem aktiven Webserver installiert und anschließend aktiviert werden. Dieser kann über die Auswahlbox gewählt werden.

Detaillierte Informationen zum Hinzufügen von Web-Komponenten finden Sie in der FirstSpirit Dokumentation für Administratoren.

Bei der Erstellung verschiedener Varianten für ein Experiment wird die zugehörige Dispatcher-Seitenreferenz an den Variaten gespeichert. Diese Zuordnung erfolgt mithilfe der Metadaten.

Die Vorlage ist in den Projekt-Eigenschaften anzugeben und muss dafür im Projekt existieren. Legen Sie sie zunächst an, wenn dies nicht zutreffen sollte. Andernfalls öffnen Sie den ServerManager und wählen Sie den Bereich Projekt-Eigenschaften → Optionen. Selektieren Sie anschließend die Metadaten-Vorlage über den entsprechenden Auswahlbutton (vgl. Abbildung Optionen in den Projekt-Eigenschaften). Die Speicherung der vorgenommenen Änderungen erfolgt über den Button OK.

Abbildung 9. Optionen in den Projekt-Eigenschaften

Für die Auswertung des Erfolgs der einzelnen Varianten müssen diese während der Laufzeit des Experiments verfolgt werden. Das Tracking ist nicht Teil des A/B-Testing-Moduls, sondern muss projektspezifisch erfolgen. Es wird daher ein Analytics-Tool benötigt, welches grundsätzlich beliebig wählbar ist. Das A/B-Testing-Modul besitzt an dieser Stelle eine komplett offene Architektur und ist nicht auf spezielle Dienste beschränkt.

Mit dem während der Konfiguration der Projekt-Komponente durchgeführten Imports wurde dem Projekt das Google Analytics Plugin hinzugefügt. Dieses Tracking Plugin ist entsprechend seines Namens auf Google Analytics ausgelegt und benötigt daher ein entsprechendes Konto.

Entnehmen Sie die Konfiguration des von Ihnen gewählten Analytics-Tools bitte der Dokumentation des jeweiligen Anbieters.

Ein Experiment besteht aus einem automatisch erstellten Dispatcher und beliebig vielen Varianten. Jede Variante muss eine Zuordnung zur Dispatcher-Seite des entsprechenden Experiments besitzen. Diese Zuordnung erfolgt über die folgende Eingabekomponente:

Metadaten-Eingabekomponente. 

<CMS_INPUT_TEXT name="md_experiment_uid" hFill="yes" singleLine="no" useLanguages="yes" hidden="yes">
	<LANGINFOS>
		<LANGINFO lang="*" label="Dispatcher" description="Dispatcher"/>
	</LANGINFOS>
</CMS_INPUT_TEXT>

Die Eingabekomponente ist versteckt und muss der Metadaten-Vorlage des verwendeten Projekts hinzugefügt werden. Sie wird bei der Erstellung einer neuen Variante automatisch mit der UID der Dispatcher-Seitenreferenz des Experiments gefüllt.

Existiert innerhalb des Projekts noch keine Metadaten-Vorlage, so ist diese anzulegen.

Die Metadaten-Vorlage muss in den Projekt-Eigenschaften ausgewählt werden.

Weitere Informationen zu Metadaten finden Sie in der FirstSpirit Dokumentation für Administratoren.

Die Bereitstellung der Funktionalitäten des A/B-Testing-Moduls erfolgt über vier Formatvorlagen, die im HTML-Code aller zulässigen Seitenvorlagen zu referenzieren sind. Die Vorlagen A/B-Testing Head, A/B-Testing Body und Traffic Allocation Plugin wurden dem FirstSpirit-Projekt bereits während des bei der Konfiguration der Projekt-Komponente durchgeführten Imports hinzugefügt. Die vierte Vorlage entspricht dem einzubindenden Tracking Plugin.

Alle vier Formatvorlagen sind für die Verwendung der A/B-Testing-Funktionalitäten zwingend erforderlich und müssen über CMS_RENDER-Aufrufe in der verwendeten Seitenvorlage referenziert werden:

Referenzierung der Formatvorlagen in der Seitenvorlage. 

<head>
   [...]
   $CMS_RENDER(script:"has_experiment", pageref: #global.node)$
   $CMS_IF(hasExperiment)$
      $CMS_RENDER(template:"abtesting_head")$
      $CMS_RENDER(template:"traffic_allocation_plugin")$
      $CMS_RENDER(template:"TRACKING PLUGIN REFERENCENAME")$ ❶
   $CMS_END_IF$
</head>
<body>
   $CMS_RENDER(template:"abtesting_body")$
   [...]
</body>

Zusätzlich zu den Formatvorlagen muss die folgende JSTL-Taglib sowie die JSP-Page-Direktive eingebunden werden. Im Gegensatz zu ihnen sind die beiden Aufrufe jedoch am Anfang des HTML-Codes zu platzieren.

Handelt es sich bereits um ein JSP-Projekt, sind die Zeilen gegebenenfalls schon vorhanden.

JSTL-Taglib und JSP-Page-Direktive. 

<%@ page language="java" contentType="text/html; charset=$CMS_VALUE(#global.encoding)$" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core" prefix="c" %>

Des Weiteren muss gewährleistet werden, dass es sich bei allen an einem Experiment beteiligten Varianten um JSP-Seiten handelt. Dafür muss in den Eigenschaften der jeweiligen Seitenvorlage die Dateiendung jsp definiert werden (vgl. Abbildung Dateiendung definieren).

Abbildung 10. Dateiendung definieren

Für die Ausführung der verschiedenen Funktionalitäten des A/B-Testing-Moduls ist die Verfügbarkeit der Redaktionsrechte unentbehrlich. Die nachfolgende Tabelle erläutert, welche Rechte während der Laufzeit eines Experiments benötigt werden und welche Funktionalität ihnen jeweils zugehörig ist.

Selektieren Sie für die Verteilung der Redaktionsrechte jeweils den Root-Knoten der Inhalte- bzw. Strukturverwaltung. Wählen Sie anschließend im sich per Rechtsklick öffnenden Kontextmenü den Punkt Extras → Rechte ändern und öffnen Sie darüber die Rechtevergabe. Teilen Sie im darauf sichtbaren Dialog den Redakteuren Ihres Projekts die entsprechenden Rechte zu.

Der in der Projekt-Komponente ausgewählte Arbeitsablauf wird bei der Durchführung eines Experiments über die A/B-Testing-Leiste auf dem Dispatcher ausgeführt. Er lässt sich jedoch auch manuell über die allgemeinen FirstSpirit-Funktionalitäten auf den einzelnen Varianten durchführen. In beiden Fällen ist die Freigabe aller am Experiment beteiligten Seiten und Seitenreferenzen zwingend erforderlich, um Fehler während der Generierung und im Live-Stand zu vermeiden.

Mit dem Modul wird ein Beispiel-Arbeitsablauf ausgeliefert, der diese Anforderung bereits erfüllt. Wahlweise kann jedoch auch ein bestehender projektspezifischer Arbeitsablauf angepasst werden. Beide Möglichkeiten stellen zwei vollwertige Alternativen dar und werden in den nachfolgenden Unterkapiteln erläutert.

5.4.2. mitgelieferter Arbeitsablauf

In der Auslieferung des A/B-Testing-Moduls ist ein Arbeitsablauf enthalten, der die beschriebenen Anforderungen bereits erfüllt. Für seine Verwendung muss er im Konfigurationsdialog der Projekt-Komponente ausgewählt werden. Da er auf den BasicWorkflows basiert, werden diese im Projekt vorausgesetzt.

Installation des BasicWorkflows-Moduls

Sind die BasicWorkflows noch nicht im Projekt vorhanden, muss vor der Verwendung des mitgelieferten Arbeitsablaufs zunächst das BasicWorkflows-Modul auf dem FirstSpirit-Server installiert und die Web-Komponente aktiviert sein. Die dafür notwendigen Schritte verhalten sich analog zur Installation des A/B-Testing-Moduls und der Aktivierung der zugehörigen Web-Komponente. Die Web-Komponente der BasicWorkflows wird allerdings nur in der Registerkarte ContentCreator benötigt.

Zusätzlich muss der Arbeitsablauf durch die Auswahl des bereitgestellten Element Status Providers für den ContentCreator aktiviert werden. Öffnen sie dafür den ServerManager und wählen Sie den Bereich Projekt-Eigenschaften → ContentCreator. Ändern Sie anschließend den Eintrag des Element Status Providers auf den Eintrag BasicWorkflows Status Provider und speichern Sie die Änderung mit OK.

Abbildung 11. Auswahl des Element Status Providers

Import der Skripte und des Arbeitsablaufs

Anschließend müssen die für den Freigabe-Arbeitsablauf verwendeten Skripte der BasicWorkflows dem Projekt hinzugefügt werden. Wechseln Sie hierfür in die Vorlagen-Verwaltung im SiteArchitect und klicken Sie auf den Kontextmenüeintrag Importieren. Dieser öffnet einen Importdialog, in dem aus den Verzeichnissen des Arbeitsplatzrechners die Importdatei export_basic_release auszuwählen ist. Nach der Bestätigung über Öffnen erscheint ein weiterer Dialog, der alle in der Datei enthaltenen Elemente anzeigt. Da nur die Skipte benötigt werden, kann der Import des Arbeitsablaufs release deaktiviert werden (vgl. Abbildung Import der Skripte). Importieren Sie anschließend über dasselbe Vorgehen den Arbeitsablauf, der mit dem A/B-Testing-Modul mitgeliefert wurde.

Abbildung 12. Import der Skripte

Der importierte Arbeitsablauf muss abschließend in den einzelnen Verwaltungen erlaubt werden, um auf FirstSpirit-Elementen ausgeführt werden zu können. Öffnen Sie hierfür auf den Root-Knoten der Verwaltungen über den Kontextmenüeintrag Rechte ändern die Rechtevergabe. Im Reiter Arbeitsablauf Rechte sind anschließend die Checkboxen Erlaubt und Freigabe-Rechte nutzen für den importierten Arbeitsablauf zu aktivieren. Schließen Sie den Dialog zuletzt über den Button OK.

Funktionalität

Nach der Durchführung der Installation und des Imports kann der Arbeitsablauf innerhalb des Projekts verwendet werden. Dabei lässt er sich grundsätzlich auf unterschiedlichen Elementen ausführen:

Dispatcher

Beim Starten, Aktualisieren und Fortführen eines Experiments über die A/B-Testing-Leiste wird der Arbeitsablauf auf dem zugehörigen Dispatcher ausgeführt. Neben dem Dispatcher werden in diesem Fall automatisch auch alle dem Element zugehörigen Varianten freigegeben.

Variante

Über die allgemeine FirstSpirit-Funktionalität lässt sich der Arbeitsablauf auch auf einer Variante ausführen. In diesem Fall erhält der Redakteur eine Sicherheitsabfrage, ob das zugehörige Experiment freigegeben werden soll. Bestätigt der Redakteur diese Frage, werden alle Varianten und der Dispatcher freigegeben. Andernfalls wird der Arbeitsablauf abgebrochen und die Variante verbleibt in ihrem vorherigen Zustand.

Pro Experiment kann immer nur ein Arbeitsablauf ausgeführt werden. Dies bedeutet: Die Ausführung des in Projekt-Komponente ausgewählten Arbeitsablaufs über die A/B-Testing-Leiste ist nicht möglich, wenn eine der Varianten gesperrt ist oder sich bereits in einem Arbeitsablauf befindet. Die manuelle Ausführung eines Arbeitsablaufs auf einer Variante ist nicht möglich, wenn sich die Seite oder die Seitenreferenz des zugehörigen Dispatchers bereits in einem Arbeitsablauf befindet. In beiden Fällen erhält der Redakteur einen Hinweis und der Start des jeweiligen Arbeitsablaufs wird unterbunden.

Wird der Arbeitsablauf manuell über die allgemeine FirstSpirit-Funktionalität aufgerufen, so ist anschließend ebenfalls ein manueller Reload der Vorschau notwendig, um etwaige Änderungen am Status der A/B-Testing-Leiste sichtbar zu machen.

Element ohne Bezug zu einem Experiment

Wird der Arbeitsablauf auf einem FirstSpirit-Element ausgeführt, das nicht Teil eines Experiments ist, so verhält er sich gemäß seiner Standardfunktionalität.

Nähere Informationen zu den BasicWorkflows finden Sie in der zugehörigen Dokumentation.

Zusammen mit dem Modul wird das Google Analytics Plugin bereitgestellt. Es ist entsprechend seines Namens auf Google Analytics ausgelegt und wird dem Projekt bereits mit dem während der Konfiguration der Projekt-Komponente durchgeführten Import hinzugefügt.

Neben der Notwendigkeit eines Google Analytics-Kontos muss lediglich die Projekteinstellungen-Vorlage erweitert und in den Projekt-Eigenschaften selektiert werden. Außerdem ist das Plugin in der Seitenvorlage zu referenzieren.

Des Weiteren benötigt das Plugin eine Google Analytics Id sowie eine Dimension Id:

Alle erforderlichen Schritte werden nachfolgend erläutert.

6.1.1. Registrierung und Konfiguration eines Google Analytics-Kontos

Für die Verwendung des mitgelieferten Google Analytics Plugins wird ein Google Analytics-Account benötigt. Sollten Sie noch keinen Account besitzen, können Sie sich auf dieser Seite registrieren: http://www.google.com/analytics/

Bei der Registrierung leitet ein Assistent Sie durch die erforderlichen Schritte zur Erstellung eines Accounts.

Abbildung 13. Registrierung eines Google Analytics-Kontos

Nach der Bestätigung der Google Analytics-Nutzungsbedingungen ist die Registrierung abgeschlossen.

Weitere Informationen zur Konfiguration entnehmen Sie bitte der Google Analytics-Hilfe.

<head>
   [...]
   $CMS_RENDER(script:"has_experiment", pageref: #global.node)$
   $CMS_IF(hasExperiment)$
      $CMS_RENDER(template:"abtesting_head")$
      $CMS_RENDER(template:"traffic_allocation_plugin")$
      $CMS_RENDER(template:"google_analytics_plugin")$
   $CMS_END_IF$
</head>
<body>
   $CMS_RENDER(template:"abtesting_body")$
   [...]
</body>

6.1.3. Erweiterung der Projekteinstellungen-Vorlage

Das mit dem Modul bereitgestellte Google Analytics Plugin greift auf die folgende Eingabekomponente zu, die der Projekteinstellungen-Vorlage hinzugefügt werden muss. Existiert innerhalb des Projekts noch keine solche Vorlage, so ist diese anzulegen. Die Vorlage muss außerdem in den Projekt-Eigenschaften ausgewählt sein.

Projekteinstellungen-Eingabekomponente. 

<CMS_GROUP>
   <LANGINFOS>
      <LANGINFO lang="*" label="A/B-Testing"/>
   </LANGINFOS>

   <CMS_INPUT_TEXT name="ab_googleid" hFill="yes" singleLine="no" useLanguages="no">
      <LANGINFOS>
         <LANGINFO lang="*" label="Google Analytics Id"/>
      </LANGINFOS>
   </CMS_INPUT_TEXT>
</CMS_GROUP>

Innerhalb des Projekts ist über dieses Feld in den Projekteinstellungen die Google Analytics Id anzugeben. Sie wird vom Plugin verwendet und ermöglicht das Tracking der Varianten eines Experiments durch Google Analytics.

Sie finden die Google Analytics Id innerhalb Ihres Google Analytics-Accounts unter dem Pfad Admin → Account → Property → Tracking Info → Tracking Code. Abbildung 14. Pfad zur Ermittlung der Google Analytics Id

6.1.4. Angabe der Projekteinstellungen-Vorlage

Wird das Google Analytics Plugin verwendet ist neben der Metadaten-Vorlage auch die Projekteinstellungen-Vorlage in den Projekt-Eigenschaften anzugeben. Die Vorlage dient der Bereitstellung der Google Analytics Id und muss dafür im Projekt existieren und, wie im vorausgehenden Kapitel beschrieben, erweitert werden. Führen Sie diese Schritte zunächst durch, wenn dies nicht zutreffen sollte.

Andernfalls öffnen Sie den ServerManager und wählen Sie den Bereich Projekt-Eigenschaften → Optionen. Selektieren Sie anschließend die Einstellungs-Seite über den entsprechenden Auswahlbutton (vgl. Abbildung Optionen in den Projekt-Eigenschaften). Die Speicherung der vorgenommenen Änderungen erfolgt über den Button OK.

Abbildung 15. Optionen in den Projekt-Eigenschaften

6.1.5. Angabe der Dimension Id

Das Google Analytics Plugin fügt dem Einstellungsdialog eines Experiments ein Textfeld hinzu. In diesem ist die Id der in Google Analytics erstellten Custom Dimension anzugeben.

Öffnen Sie dafür über den Button Einstellungen bearbeiten den zugehörigen Dialog eines bestehenden Experiments (vgl. Abbildung Einstellungen bearbeiten). Erfassen Sie die Dimension Id anschließend in dem vorgesehenen Textfeld und speichern Sie Ihre Angabe durch das Schließen des Dialogs über den Button OK.

Nähere Informationen zur Custom Dimension finden Sie in der Google Analytics-Hilfe unter dem Punkt Dimensionen und Messwerte.

Abbildung 16. Einstellungen bearbeiten

Soll für das Tracking ein anderes Analytics-Tool verwendet werden, kann dieses jederzeit in Form eines Tracking Plugins projektspezifisch hinzugefügt werden. Das A/B-Testing-Modul besitzt an dieser Stelle eine komplett offene Architektur und ist nicht auf spezielle Dienste beschränkt.

Der folgende Code entspricht der Basisimplementierung eines solchen Tracking Plugins und zeigt den allgemeinen Aufbau:

Basis-Code. 

<script>
   var myPlugin=( function(){
      $-- init variables --$
      var myVar; ❶
      return {
         $-- add gui --$
         addGui: function (container) { ❷
            myVar=('myPlugin' in config && 'myVar' in config['myPlugin']) ? config['myPlugin'].myVar : "";
         },

         $-- store additional params --$
         storeParams: function () { ❸
            var addParams={
               $-- new parameter: store --$
               "myVar":myVar
            }
            return addParams;
         },

         $-- add analytics code --$
         addTrackingCode: function (variant) { ❹
            var trackingId='$CMS_RENDER(script:"getconfiguration", param:"myPlugin:myVar",
            srcUid:#global.node.uid)$';
         }
      };
   })();
   pluginRegistry.register('myPlugin', myPlugin); ❺
</script>

variable = ('pluginname' in config) ? config['pluginname'].variable : "";

var pluginname=( function(){
   $-- init variables --$
   var variable;

   return {
      $-- add gui --$
      addGui: function (container) {
         [...]
      },
      [...]
   };
})();

"<NAME>":<VALUE>

$CMS_RENDER(script:"getconfiguration", param:"pluginname:variable", srcUid:#global.node.uid)$';

pluginRegistry.register('pluginname', pluginname);

Zur Überprüfung der einleitend formulierten Annahme wird über den Menüpunkt Aktionen → Experiment erstellen eine Variante der Originalseite erzeugt. Diese Variante und die Originalseite werden in Form von Tabs in der daraufhin eingeblendeten A/B-Testing-Leiste dargestellt, wobei die Variante für die sofortige Bearbeitung selektiert ist (vgl. Abbildung A/B-Testing-Leiste im ContentCreator).

Abbildung 19. A/B-Testing-Leiste im ContentCreator

Gleichzeitig wird im SiteArchitect neben der Variante automatisch jeweils eine Dispatcher-Seite in der Inhalte- und in der Struktur-Verwaltung angelegt. Sie enthält eine Liste aller Varianten des Experiments und wird ihrerseits in den Metadaten der Varianten referenziert. Auf diese Weise wird eine bidirektionale Zuordnung erzeugt.

Die Erstellung eines Experiments ist nur dann möglich, wenn die Durchführung von Experimenten für die ausgewählte Seite erlaubt und sie nicht bereits Teil eines Experiments ist. In beiden Fällen ist der Menüpunkt ansonsten nicht sichtbar. Des Weiteren wird eine fehlerfreie Konfiguration und eine ausreichende Rechtedefinition vorausgesetzt. Andernfalls ist der entsprechende Menüpunkt im ContentCreator zwar sichtbar, aber deaktiviert. Diese Regeln gelten auch für den SiteArchitect, in dem die Erzeugung eines Experiments über den Button Experiment erstellen erfolgt. Abbildung 20. Experiment erstellen im SiteArchitect Er kann nur in der Struktur-Verwaltung auf Seitenreferenzen verwendet werden. Andernfalls ist er ebenfalls ausgeblendet. Die A/B-Testing-Leiste wird anschließend in der Vorschau eingeblendet. Abbildung 21. A/B-Testing-Leiste im SiteArchitect

Über den Button Variante hinzufügen in Form des Plus-Zeichens oder per Duplizierung über das Dropdown-Menü jedes Tabs können beliebig viele Varianten angelegt werden. Sie erscheinen als weitere Tabs. Für die Story wird nur eine Variante benötigt, die bereits bei der Erstellung des Experiments automatisch angelegt wurde.

Entsprechend der zuvor formulierten Annahme werden in der Variante die gewünschten Änderungen vorgenommen: Sie erhält eine Bühne mit einem Bild und einer Überschrift. Außerdem rückt der Teaser Wir besuchen Sie! in den Fokus, indem er neu positioniert und mit einem anderen Bild versehen wird (vgl. Abbildung Variante).

Abbildung 22. Variante

Über den Punkt Variante löschen im Dropdown-Menü jedes Tabs in der A/B-Testing-Leiste lassen sich Varianten aus dem Experiment entfernen. Der entsprechende Tab wird anschließend nicht mehr in der Leiste angezeigt und die Seitenreferenz im SiteArchitect gelöscht.

Die Originalseite stellt in diesem Zusammenhang eine Besonderheit dar. Bei ihr handelt es sich um die initiale Referenz, auf der das Experiment basiert. In der Regel sollte sie daher nicht aus dem Experiment entfernt werden. Besteht dennoch der Wunsch, die Originalseite zu löschen, muss zunächst eine Sicherheitsabfrage bestätigt werden (vgl. Abbildung Löschen der Original-Seite im ContentCreator).

Abbildung 23. Löschen der Original-Seite im ContentCreator

Über den Button Einstellungen bearbeiten in Form dreier ineinandergreifender Zahnräder und den Schieberegler im sich darauf öffnenden Dialog kann nach dem Hinzufügen der Varianten prozentual festgelegt werden, wie viele Webseiten-Besucher an dem Experiment teilnehmen sollen (vgl. Abbildung Einstellungen bearbeiten). Ohne anderslautende Angabe nehmen immer alle Besucher an einem Experiment teil.

Abbildung 24. Einstellungen bearbeiten

Des Weiteren lässt sich an dieser Stelle definieren, mit welcher Verteilung die einzelnen Varianten angezeigt werden. Standardmäßig werden sie alle mit derselben Verteilung (100/n %) dargestellt. Sie lässt sich jedoch nach Belieben ändern. Der Dialog kann somit sowohl berechnete als auch manuell eingetragene Daten enthalten. Um eine Unterscheidung zwischen ihnen zu ermöglichen, werden die berechneten Werte grau hinterlegt visualiert.

Existiert nur für einige Varianten eine manuelle Definition, wird die Differenz über die verbliebenen Varianten gleichverteilt. Ist für alle Varianten eine Verteilung festgelegt, wird diese jeweils verwendet. Die Summe aller Angaben muss 100 % ergeben.

Die folgenden Beispiele sollen dies veranschaulichen.

Beispiel 1. keine Benutzereingabe

In dem auf der nachfolgenden Abbildung dargestellten Fall besitzen alle Varianten eine Verteilung von jeweils 25%. Da diese für alle Varianten berechnet wurde, sind die Eingabefelder grau hinterlegt.

Abbildung 25. standardmäßige Gleichverteilung

Beispiel 2. Benutzereingabe für genau eine Variante

In dem auf der nachfolgenden Abbildung dargestellten Fall besitzt die Variante_1 eine duch den Benutzer festgelegte Verteilung von 40% und die anderen Varianten eine berechnete Verteilung von jeweils 20%.

Abbildung 26. Verteilung bei einer Benutzereingabe

Beispiel 3. Benutzereingabe für mehrere Varianten

In dem auf der nachfolgenden Abbildung dargestellten Fall besitzen die Originalseite und die Variante_1 eine durch den Benutzer festgelegte Verteilung von 20% bzw. 30% und die Varianten 2 und 3 eine berechnete Verteilung von jeweils 25%.

Abbildung 27. Verteilung bei mehreren Benutzereingaben

Für die Abfrage weiterer Informationen kann der Dialog mit der Tracking Plugin-Methode addGui um zusätzliche Elemente erweitert werden. Die Anzahl dieser Elemente ist von der Implementierung des Tracking Plugins abhängig. Auf der Abbildung Einstellungen bearbeiten wurde beispielsweise das Google Analytics Plugin verwendet, das eine Dimension abfragt.

Wurden alle benötigten Varianten erstellt und die Teilnahmeraten sowie alle weiteren Angaben für das Experiment konfiguriert, kann es über den Button Starten begonnen werden. Der Button stößt den Arbeitsablauf an, der während der Konfiguration der Projekt-Komponente ausgewählt wurde. Er muss alle dem Experiment zugehörigen Seiten und Seitenreferenzen freigeben, damit diese mit dem nächsten Deployment in den Live-Stand übertragen werden.

Nach dem erfolgreichen Durchlauf des Arbeitsablaufs wechselt der Button seine Beschriftung zu Läuft und die Freigabe wird anhand des bekannten Farbschemas durch die Statusanzeigen des ContentCreators und der A/B-Testing-Leiste visualisiert (vgl. Abbildung laufendes Experiment).

Abbildung 28. laufendes Experiment

In vielen Fällen besitzen Arbeitsabläufe auch manuelle Schritte. Ein Beispiel hierfür ist das sogenannte Vier-Augen-Prinzip für die Freigabe. Bei diesem wird die Freigabe zunächst nur angefordert und nicht direkt durchgeführt. Das Experiment befindet sich während solcher manueller Schritte im Arbeitsablauf, bis dessen Weiterschaltung erfolgt. Der Button in der A/B-Testing-Leiste besitzt solange die Beschriftung Fortsetzen (vgl. Abbildung Experiment im Arbeitsablauf). Da das Experiment in diesem Zustand als bearbeitet und nicht freigegeben gilt, wird der Status außerdem entsprechend visualisiert.

Abbildung 29. Experiment im Arbeitsablauf

Es besteht die Möglichkeit, das Experiment während seiner Laufzeit zu verändern. Dies kann sich beispielsweise durch die Bearbeitung oder die Löschung einer bestehenden bzw. durch das Hinzufügen einer weiteren Variante ergeben. In diesem Fall ändert sich die Beschriftung des Buttons der A/B-Testing-Leiste von Läuft zu Aktualisieren und der Status wird anhand des bekannten Farbschemas visualisiert (vgl. Abbildung zu aktualisierendes Experiment).

Abbildung 30. zu aktualisierendes Experiment

Für die Auswertung des Erfolgs der einzelnen Varianten müssen diese während der Laufzeit des Experiments verfolgt werden. In dieser Story wird dafür Google Analytics eingesetzt, da es für die Verwendung des mitgelieferten Tracking Plugins benötigt wird. Grundsätzlich kann jedoch ein beliebiges Analytics-Tool genutzt werden.

In Google Analytics erfolgt das Tracking über einen Custom Report, der auf ein zuvor angelegtes Segment eingeschränkt ist. Die Einschränkung auf das Segment bewirkt, dass nur die für das Experiment relevanten Besucher erfasst werden. Der Report enthält eine auf einen definierten Zeitraum eingeschränkte Übersicht der einzelnen Varianten in Form eines Diagramms und einer Tabelle (siehe auch Abbildung Google Analytics - Custom Report).

Während das Diagramm den Verlauf der Besucherzahlen innerhalb des festgelegten Zeitraums darstellt, beinhaltet die Tabelle die Informationen zu den einzelnen Varianten. Sie zeigt, wie oft das Formular zur Anforderung eines Beratungsgesprächs ausgefüllt und versandt wurde. Dabei werden die Werte sowohl absolut als auch prozentual angegeben und der Gesamtsumme gegenüber gestellt.

Weitere Informationen zu Custom Reports und Segmenten finden Sie in der Google Analytics-Hilfe unter dem Punkt Berichterstellungstools.

Abbildung 31. Google Analytics - Custom Report

Nach der Ermittlung der Variante, mit der das zuvor definierte Ziel am erfolgreichsten erreicht wird, kann das Experiment gestoppt werden. Für die Story zeigt die Abbildung Google Analytics - Custom Report , dass das veränderte Design mehr Webseiten-Besucher dazu animierte, ein Beratungsgespräch anzufordern. Die erstellte Variante ist somit nachweislich besser, als die Originalseite. Die initial formulierte Annahme wird durch die Analyse bestätigt und die Variante_1 sollte als neue Originalseite übernommen werden. Dafür muss das Experiment erneut im ContentCreator geöffnet und das zugehörige Tab selektiert werden.

Das Stoppen des Experiments erfolgt über den Button Experiment beenden in Form des Fähnchens, der eine Sicherheitsabfrage öffnet (vgl. Abbildung Sicherheitsabfrage). Diese muss bestätigt werden, um die selektierte Variante als neue Originalseite zu übernehmen.

Abbildung 32. Sicherheitsabfrage

Durch das Beenden des Experiments wird die A/B-Testing-Leiste ausgeblendet und die Seitenreferenzen der übrigen Varianten sowie des Dispatchers gelöscht. Des Weiteren erfolgt technisch eine Übertragung der URL des Dispatchers auf die neue Originalseite. Dadurch wird gewährleistet, dass alle bestehenden Referenzen auf die Seite weiterhin funktionieren und die URL nach außen immer dieselbe ist. Dies gilt unabhängig davon, welche Variante dem Besucher während des Experiments angezeigt wurde. Zusätzlich zur Übertragung der URL wird das Präfix, welches den beteiligten Seiten und Seitenreferenzen bei der Erstellung des Experiments hinzugefügt wurde, wieder entfernt. Die neue Originalseite erhält somit die ursprünglichen Anzeigenamen. Diese Änderungen werden durch eine Freigabe der Seite und der Seitenreferenz der neuen Originalseite sowie des jeweiligen Vater-Ordners in der Inhalte- und Strukturverwaltung persistiert.