A/B-Testing

e-Spirit AG

17.01.2019
Inhaltsverzeichnis

1. Einleitung

Mit FirstSpirit lassen sich komplexe Webseiten erstellen. Die Realisierung dieser Webseiten basiert meist auf einer Reihe subjektiver Entscheidungen, denen auch das Design unterliegt.

Das Design ist darauf ausgerichtet, den Besucher durch die gezielte Platzierung von Handlungsaufforderungen (Call-to-Actions) zur Interaktion zu animieren. Dabei kann es sich beispielsweise um die Anmeldung zu einem Newsletter, das Herunterladen eines Dokuments oder den Kauf eines Produkts handeln. Dieses Vorgehen zielt darauf ab, die Conversion-Rate zu maximieren. Sie gibt Auskunft darüber, wie viele Besucher einer Handlungsaufforderung folgen und dadurch zu potentiellen Kunden werden.

Zur Erreichung dieses Ziels muss der Entwickler stets abschätzen, wie und wo Call-to-Actions auf der Webseite zu platzieren sind, um die Besucher bestmöglich anzusprechen. Selten kann er diese Entscheidung auf der Grundlage bereits existierender Informationen fällen, sondern muss sie nach eigenem Ermessen treffen. Je mehr Informationen der Entwickler über die Besucher besitzt und je besser er sie somit kennt, desto präziser wird er ihr Verhalten einschätzen können.

Genau an dieser Stelle setzt das A/B-Testing-Modul an. Es bietet die Möglichkeit, unterschiedlichen Besuchern im Rahmen eines Experiments verschiedene Varianten einer Webseite anzuzeigen. Die Zuordnung erfolgt dabei gleichverteilt bzw. nach einer zuvor definierten Rate und bleibt auch bei erneuten Aufrufen der Webseite bestehen. Für die einzelnen Besucher ist die Teilnahme an dem Experiment demzufolge nicht ersichtlich.

In Verbindung mit einem Analytics-Tool können so statistisch signifikante Informationen über das Besucherverhalten ermittelt werden. Diese Handlungsweise ist auch unter dem Begriff Data Driven Marketing bekannt. Der Entwickler erhält auf diesem Weg eine Rückmeldung bezüglich des Erfolgs der einzelnen Varianten und erfährt, welche Designänderung die besten Resultate zur Maximierung der Conversion-Rate erzielt. Nach der Beendigung eines Experiments kann er diese Änderung direkt übernehmen, indem er die Gewinnervariante als neue Originalseite auswählt.

Bei zukünftigen Änderungen muss sich der Entwickler nicht mehr auf sein Gefühl verlassen. Er kann weitere Experimente starten oder auf bereits ermittelte Informationen zurückgreifen und die Webseite damit kontinuierlich optimieren.

Das A/B-Testing-Modul hat die folgenden technischen Voraussetzungen.

  • FirstSpirit (Isolated- oder Legacy-Mode) ab der Version 2018-11
  • Java 8 oder höher

2. Funktionsumfang

Das A/B-Testing-Modul stellt Redakteuren die folgenden Möglichkeiten zur Verfügung:

  • Erstellung und Durchführung von Experimenten
  • Erweiterung von Experimenten um beliebig viele Varianten
  • Definition einer Verteilung für jede einzelne Variante
  • Festlegung einer projektspezifischen Teilnahmerate

Die entsprechenden Funktionalitäten werden mit der Installation und Konfiguration des Moduls sowohl im ContentCreator als auch in der Vorschau des SiteArchitects bereitgestellt.

Die Funktionalitäten des A/B-Testing-Moduls können nicht in Verbindung mit der externen FirstSpirit-Vorschau verwendet werden.

Die Pflege eines Experiments findet über die gewohnten FirstSpirit-Mittel statt. Es werden daher keine weiteren Kenntnisse von Redakteuren, die bereits mit FirstSpirit vertraut sind, erwartet.

Die Durchführung eines Experiments erfolgt anhand eines Freigabe-Arbeitsablauf. Dieser muss stets alle an einem Experiment beteiligten Seiten und Seitenreferenzen berücksichtigen. Ein solcher Arbeitsablauf wird mit dem A/B-Testing-Modul ausgeliefert. Er basiert auf den BasicWorkflows und erfüllt die genannten Anforderungen. Soll stattdessen ein projektspezifischer Arbeitsablauf verwendet werden, ist dieser mithilfe der bereitgestellten API entsprechend anzupassen.

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 Moduls und muss projektspezifisch erfolgen. Es wird daher ein Analytics-Tool benötigt, welches frei wählbar ist. Das A/B-Testing-Modul besitzt an dieser Stelle eine komplett offene Architektur und ist nicht auf spezielle Dienste beschränkt.

Die Verbindung zwischen dem Analytics-Tool und dem FirstSpirit-Server regelt ein Tracking Plugin in Form einer Formatvorlage. Ein solches Plugin wird bereits mit dem Modul bereitgestellt. Es ist auf Google Analytics ausgelegt und kann mit geringem Konfigurationsaufwand direkt verwendet werden. Besteht der Wunsch, ein anderes Analytics-Tool einzusetzen, ist ein entsprechendes Tracking Plugin zu implementieren.

Das A/B-Testing-Modul legt beim Aufruf einer Seite, die Teil eines Experiments ist, Cookies an. Daher wird empfohlen, den Besucher in Anlehnung an die Cookie-Richtlinie der EU und - speziell in Deutschland - § 15 Abs. 3 des Telemediengesetzes auf die Nutzung von Cookies hinzuweisen, sofern dies nicht bereits geschieht.

3. Quick Start

Der Quick Start skizziert die möglichen Zustände eines Experiments. Er richtet sich an Redakteure und ist darauf ausgelegt, diesen eine erste Übersicht zu bieten. Der Inhalt des Kapitels ist daher bewusst knapp gehalten und beschreibt lediglich die Basisfunktionen des A/B-Testing-Moduls. Eine ausführliche Erläuterung mit zusätzlichen Informationen enthalten die Kapitel Lebenszyklus eines Experiments und Verwendung in FirstSpirit.

Jedes Experiment durchläuft während seiner Laufzeit einen bestimmten Zyklus, der in der nachfolgenden Grafik vereinfacht abgebildet ist (vgl. Abbildung einfacher Lebenszyklus eines Experiments.)

einfacher Lebenszyklus eines Experiments
Abbildung 1. einfacher Lebenszyklus eines Experiments


Der Zyklus beginnt mit der Erstellung und dem Start eines Experiments. Dadurch wird ein Arbeitsablauf angestoßen, der alle dem Experiment zugehörigen Seiten und Seitenreferenzen freigeben muss.

Nach einem erfolgreichen Start läuft das Experiment. Der Zyklus stoppt mit der Beendigung eines Experiments und der Auswahl einer neuen Originalseite. Auf dieser kann potentiell ein neues Experiment erstellt werden.

3.1. Experiment erstellen

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

ContentCreator
Die Erzeugung eines Experiments für die angezeigte Seite erfolgt im ContentCreator über den Menüpunkt AktionenExperiment erstellen. Soll sich das Experiment auf eine andere Seite beziehen, muss diese zunächst aufgerufen werden.
SiteArchitect
Im SiteArchitect erfolgt die Erzeugung eines Experiments über den Button Experiment erstellen (vgl. Abbildung Button zur Experimenterstellung im SiteArchitect). Dieser kann nur auf Seitenreferenz verwendet werden. In der Struktur-Verwaltung muss daher zunächst die gewünschte Seitenreferenz, für die ein Experiment durchgeführt werden soll, selektiert werden.
Button zur Experimenterstellung im SiteArchitect
Abbildung 2. Button zur Experimenterstellung im SiteArchitect


Ist die gewählte Seitenreferenz bereits Teil eines Experiments oder ist für sie die Erstellung eines Experiments nicht erlaubt, wird der Menüpunkt bzw. Button Experiment erstellen ausgeblendet.

Ist der Menüpunkt bzw. Button sichtbar, aber deaktiviert, liegt ein Konfigurationsfehler vor oder es fehlen die Rechte zur Durchführung eines Experiments. In diesem Fall muss der zuständige Administrator kontaktiert werden.

Die Funktionalitäten des A/B-Testing-Moduls können nicht in Verbindung mit der externen FirstSpirit-Vorschau verwendet werden.

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).

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


3.2. Experiment bearbeiten

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.

Variante hinzufügen
Neue Varianten können über den Button Variante hinzufügen in Form des Plus-Zeichens oder per Duplizierung über das Dropdown-Menü jedes Tabs erzeugt werden.
Variante löschen
Bestehende Varianten lassen sich über den Punkt Variante löschen im Dropdown-Menü des entsprechenden Tabs aus dem Experiment entfernen. Im Fall der Originalseite muss dabei eine Sicherheitsabfrage bestätigt werden.

Im SiteArchitect ist es nur möglich, Varianten zu löschen, die gerade nicht im Fokus sind.

Teilnahmerate und Verteilung definieren
Der Button Einstellungen bearbeiten in Form dreier ineinandergreifender Zahnräder öffnet einen Dialog. In diesem kann die Teilnahmerate sowie die Verteilung der Varianten definiert werden (vgl. Abbildung Einstellungen bearbeiten ). Eine ausführliche Erläuterung des Einstellungsdialogs finden Sie im Kapitel Experiment konfigurieren.
Einstellungen bearbeiten
Abbildung 4. Einstellungen bearbeiten


3.3. Experiment starten

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.

Unter bestimmten Umständen ist es möglich, ein Experiment zu erstellen und zu bearbeiten, ohne dass es anschließend gestartet werden kann. Stattdessen erscheint ein Hinweisdialog und das Experiment verharrt im initialen Zustand.

Weist der Dialog darauf hin, dass der Arbeitsablauf nicht ermittelt werden kann, ist die bei der Konfiguration des A/B-Testing-Moduls getroffene Auswahl fehlerhaft. Bei der Erstellung eines Experiments werden die Informationen lediglich auf ihre Existenz, nicht jedoch auf potentielle Fehler, geprüft. Diese Prüfung erfolgt erst bei dem Versuch, ein Experiment zu starten.

Wenden Sie sich in diesem Fall bitte an den zuständigen Administrator.

3.4. Experiment beenden

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.

Befindet sich noch ein Element des Experiments im Arbeitsablauf, kann dieses nicht beendet werden. Der Redakteur erhält daraufhin einen entsprechenden Hinweis und das Experiment bleibt erhalten.

4. Installation & Konfiguration

Für die Verwendung der Funktionalitäten des A/B-Testing-Moduls ist die Installation und Konfiguration unterschiedlicher Komponenten notwendig. Die dafür erforderlichen Schritte werden in den nachfolgenden Unterkapiteln erläutert.

4.1. Installation des Moduls

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-EigenschaftenModule.

Modulverwaltung in den Server-Eigenschaften
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).

Nach jeder Installation oder Aktualisierung eines Moduls ist ein Neustart des FirstSpirit-Servers notwendig.

4.2. Konfiguration der Projekt-Komponente

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-EigenschaftenProjekt-Komponenten.

Projekt-Komponenten in den Projekt-Eigenschaften
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).

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.

Solange kein Arbeitsablauf ausgewählt ist, wird die Beschriftung der Combobox rot dargestellt. In diesem Fall sowie bei jeglichen anderen Konfigurationsfehlern ist die Erstellung eines Experiments nicht möglich. Der entsprechende Button bzw. Menüeintrag ist dann zwar in beiden Clients sichtbar, aber deaktiviert.

Bei der Erstellung eines Experiments wird lediglich eine Nullprüfung durchgeführt. Potentiell fehlerhafte Informationen sind für diese Prüfung irrelevant und werden nicht berücksichtigt. Wird der in der Combobox ausgewählte Arbeitsablauf innerhalb des Projekts gelöscht, ist die Erstellung eines Experiments daher weiterhin möglich.

Ein Check auf die Richtigkeit der Daten erfolgt erst bei dem Versuch, ein Experiment zu starten, fortzusetzen oder zu aktualisieren. In diesen Fällen wird dem Redakteur ein entsprechender Hinweisdialog angezeigt und das Experiment verharrt im aktuellen Zustand.

Beim Starten des Experiments über die A/B-Testing-Leiste wird der Arbeitsablauf nur auf der Dispatcher Seite ausgeführt. Dabei müssen automatisch auch alle Varianten des Experiments von ihm berücksichtigt werden (siehe auch Kapitel API). Dies ist besonders dann zwingend notwendig, wenn der Arbeitsablauf ein Deployment enthält.

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.

Kann die priorisierte Transition nicht ermittelt werden oder wurde sie nicht definiert, so wird die Transition mit dem Referenznamen ab_testing_prioritized ausgeführt. Es handelt sich dabei um einen Default-Wert. Existiert auch diese Transition nicht, erhält der Redakteur einen entsprechenden Hinweis.

Enthält der ausgewählte Arbeitsablauf für jeden Status nur genau eine ausgehende Transition, ist keine Entscheidung notwendig. Sie wird immer ausgeführt und die Angabe einer priorisierten Transition im Konfigurationsdialog kann entfallen.

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.

Bei der Konfiguration des Projekt-Komponente ist initial keine Vorlage ausgewählt. Die Beschriftung der Liste wird daher in diesem Fall rot dargestellt und die Erstellung von Experimenten ist unzulässig. Der Button bzw. Menüpunkt Experiment erstellen ist somit in beiden Clients ausgeblendet, bis die Selektion mindestens einer Vorlage erfolgt.

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.

Bestehen auf der initialen Originalseite noch weitere Referenzen anderer Seitenreferenzen, wird sie auf jeden Fall beibehalten. Dies gilt auch dann, wenn die Checkbox Seiten löschen aktiviert ist und sie nicht als Gewinnervariante gewählt wird. Andernfalls besäßen die anderen Seitenreferenzen keine zugehörige Seite mehr und es käme bei ihrem Aufruf zu Exceptions.

Die Seitenreferenzen der nicht verwendeten Varianten sowie des Dispatchers werden in jedem Fall und unabhängig vom Status der Checkbox 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.

4.3. Aktivierung der Web-Komponente

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

Web-Komponenten in den Projekt-Eigenschaften
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.

Als aktiver Webserver wird ein Webserver mit einer Servlet-Engine in der Version 3.0 oder höher und JSTL in der Version 1.0 oder höher vorausgesetzt.

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

4.4. Angabe der Metadaten-Vorlage

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-EigenschaftenOptionen. 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.

Optionen in den Projekt-Eigenschaften
Abbildung 9. Optionen in den Projekt-Eigenschaften


4.5. Analytics-Tool

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.

Arbeiten Sie bereits mit einem anderen Analytics-Tool, sollten Sie in Erwägung ziehen, ein eigenes Plugin für das Tracking zu implementieren. Die Nutzung der Google Analytics-Funktionalitäten empfiehlt sich nur dann, wenn Sie Google Analytics auch anderweitig einsetzen. Andernfalls sollten Sie ein anderes Analytics-Tool wählen.

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

5. Anpassungen im FirstSpirit-Projekt

Nach der Installation und Konfiguration der verschiedenen Komponenten sowie der Registrierung eines Analytics-Tools müssen innerhalb des verwendeten Projekts diverse Anpassungen vorgenommen werden. Die dafür notwendigen Schritte werden in den nachfolgenden Unterkapiteln erläutert.

5.1. Erweiterung der Metadaten-Vorlage

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.

5.2. Erweiterung der Seitenvorlage

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.

A/B-Testing Head
Diese Formatvorlage registriert die eingebundenen Plugins und bindet das CSS für die A/B-Testing-Leiste in der Vorschau ein.
A/B-Testing Body
Diese Formatvorlage übernimmt den Tracking Code des eingebundenen Tracking Plugins und stellt ihn bereit, indem sie die Formatvorlage A/B-Testing Tracking referenziert. Sie wird außerdem für die Ein- und Ausblendung der A/B-Testing-Leiste benötigt.
Traffic Allocation Plugin
Das Traffic Allocation Plugin stellt den Einstellungsdialog der A/B-Testing-Leiste zur Verfügung. In ihm werden die Teilnahmerate für das gesamte Experiment sowie die Verteilungen der einzelnen Varianten festgelegt und gespeichert.
Tracking Plugin
Das Tracking Plugin muss jeweils projektspezifisch implementiert werden, wenn eine Verwendung des mitgelieferten Google Analytics Plugins nicht gewünscht ist. Es enthält unter anderem den benötigten Tracking Code, um den Erfolg der Varianten eines Experiments zu erfassen. Des Weiteren dient es der Abfrage potentiell weiterer spezifischer Daten.

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>

An dieser Stelle ist der Referenzname des einzubindenden Tracking Plugins anzugeben.

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).

Dateiendung definieren
Abbildung 10. Dateiendung definieren


5.3. Rechtedefinition

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.

RechtInhalteStrukturErläuterung

Sichtbar / Lesen

Sowohl die Sichtbarkeit von Objekten als auch die Möglichkeit, Inhalte zu lesen, werden standardmäßig vorausgesetzt.

Ändern

Verschiedene Schritte eines Experiments setzen die Möglichkeit voraus, Objekte zu ändern:

Sowohl während der Erstellung als auch bei der Beendigung eines Experiments wird die URL zwischen der Originalseite und dem Dispatcher gewechselt. Beide Seiten werden dadurch geändert.

Des Weiteren wird für jede neue Variante eine bidirektionale Verknüpfung zwischen ihr und dem Dispatcher erstellt. Dieser Schritt erfordert ebenfalls einer Änderung des Dispatchers.

Für die Bearbeitung bestehender Varianten ist das Ändern-Recht selbsterklärend.

Objekt anlegen

Bei der Erstellung eines Experiments wird automatisch der Dispatcher sowie die erste Variante erstellt. Jede weitere Variante ist manuell hinzuzufügen. In beiden Fällen wird das Recht zum Anlegen von Objekten benötigt.

Ordner anlegen

Dieses Recht wird nicht für die Durchführung von Experimenten benötigt.

Objekt löschen

Bei der Beendigung eines Experiments wird das Projekt von den Seitenreferenzen und je nach Konfiguration von den Seiten der verworfenen Varianten und des Dispatchers bereinigt.

Gleiches gilt für die Entfernung von Varianten aus einem bestehenden Experiment.

Das Recht zum Löschen von Objekten ist für diese Aktionen unverzichtbar.

Ordner löschen

In Verbindung mit einem Experiment werden keine Ordner gelöscht.

Freigabe

Sowohl während des Starts als auch bei der Beendigung sowie bei der Fortführung eines Experiments wird eine Freigabe verschiedener Objekte durchgeführt.

Metadaten sehen

Die Sichtbarkeit der Metadaten ist fundamental für die Durchführung eines Experiments. Ohne sie kann ein Experiment weder gestartet noch fortgesetzt, aktualisiert oder beendet werden. Des Weiteren wird das Sichtbarkeitsrecht für die Bearbeitung der Einstellungen benötigt.

Metadaten ändern

Bei der Erstellung eines Experiments sowie neuer Varianten, wird eine bidirektionale Verknüpfung zwischen den Varianten und dem zugehörigen Dispatcher erzeugt. Da die Verknüpfung in den Metadaten der jeweiligen Seitenreferenzen festgehalten wird, müssen diese verändert werden können.

Rechte ändern

Dieses Recht wird nicht für die Durchführung von Experimenten benötigt.

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 ExtrasRechte ändern und öffnen Sie darüber die Rechtevergabe. Teilen Sie im darauf sichtbaren Dialog den Redakteuren Ihres Projekts die entsprechenden Rechte zu.

Mit der Beendigung eines Experiments werden die Seitenreferenzen und abhängig von der Konfiguration auch die Seiten der verworfenen Varianten und des Dispatchers aus dem Projekt entfernt. Des Weiteren wird die URL des Dispatchers auf die neue Originalseite übertragen.

Diese Änderungen werden durch eine Freigabe der Seite und der Seitenreferenz sowie des jeweiligen Vater-Ordners in der Inhalte- und Strukturverwaltung persistiert. Aus diesem Grund ist das Freigabe-Recht explizit auch für die Beendigung eines Experiments unverzichtbar.

5.4. Freigabe-Arbeitsablauf

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.

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.

5.4.1. API

Bei der Durchführung eines Experiments müssen stets alle beteiligten Seiten und Seitenreferenzen freigegeben werden. Wurde während der Konfiguration der Projektkomponente ein projektspezifischer Arbeitsablauf ausgewählt, muss dessen Funktionalität entsprechend erweitert werden. Die A/B-Testing-API stellt dafür einige Methoden bereit, die im Folgenden kurz beschrieben werden. Zusätzlich befindet sich im Order abtesting-api der Auslieferung eine Javadoc-Dokumentation.

isDispatcher
Diese Methode ermittelt, ob die übergebene Seitenreferenz der Dispatcher eines Experiments ist. Sie liefert true oder false zurück.
hasExperiment
Mit dieser Methode lässt sich überprüfen, ob eine Seitenreferenz Teil eines Experiments ist. Liefert die Methode true zurück, handelt es sich bei der Seitenreferenz um eine Variante.
getVariants
Diese Methode ermittelt alle Varianten eines Experiment, wenn ihr der zugehörige Dispatcher übergeben wird. Erhält sie stattdessen eine andere Variante oder eine Seitenreferenz, die sich keinem Experiment zuordnen lässt, ist die zurückgelieferte Liste leer.
findDispatcherPageRef / findDispatcherPageRefForVariant
Diese beiden Methoden besitzen dieselbe Funktionalität und unterscheiden sich nur anhand ihres Übergabeparameters. Bei der ersten dient die Uid und bei der zweiten die Seitenreferenz einer Variante als Grundlage für die Ermittlung des zugehörigen Dispatchers.
loadPageRefByUid
Anhand einer übergebenen Uid liefert diese Methode die zugehörige Seitenreferenz zurück.
isDispatcherInWorkflow
Diese Methode prüft für eine übergebene Variante, ob sich die Seite oder die Seitenreferenz des zugehörigen Dispatchers bereits in einem Arbeitsablauf befindet. Ist dies der Fall, liefert die Methode true zurück und die Ausführung des manuell auf der Variante gestarteten Arbeitsablaufs muss abgebrochen werden. Andernfalls können falsche Statusanzeigen des Experiments und Inkonsistenzen im Live-Stand auftreten.
isRemainingVariant
Beim Beenden eines Experiments wird der in der Projekt-Komponente ausgewählte Arbeitsablauf auf der Gewinnervariante ausgeführt. Dabei ist (ausschließlich in diesem Fall) sicherzustellen, dass der Arbeitsablauf automatisch durchläuft und der Redakteur keine Möglichkeit erhält, ihn abzubrechen. Andernfalls würde es zu Inkonsistenzen kommen. Mit dieser Methode kann daher geprüft werden, ob es sich bei einer übergebenen Seitenreferenz um die Gewinnervariante eines zu beendenden Experiments handelt. Ist dies der Fall, liefert sie true zurück.
finalizeExperiment
Während des Beendens eines Experiments wird das Metadaten-Feld verwendet, das bei der Anpassung des Projekts hinzugefügt wurde. Nachdem die Gewinnervariante ausgewählt und das Experiment beendet wurde, ist dieses Feld wieder zu leeren. Diese Möglichkeit wird durch die Methode bereitgestellt.

Die Methoden können in einem Skript verwendet werden, das einer Aktivität des verwendeten Freigabe-Arbeitsablaufs hinzuzufügen ist. Es ist sinnvoll, hierfür die erste Aktivität auszuwählen.

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-EigenschaftenContentCreator. Ändern Sie anschließend den Eintrag des Element Status Providers auf den Eintrag BasicWorkflows Status Provider und speichern Sie die Änderung mit OK.

Auswahl des Element Status Providers
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.

Import der Skripte
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.

6. Tracking

Ein Experiment ist nur dann sinnvoll, wenn es ein aussagekräftiges Ergebnis liefert. Dieses hängt wiederum von dem Erfolg der Varianten ab. Für die Auswertung des Erfolgs der einzelnen Varianten müssen sie während der Laufzeit des Experiments verfolgt werden.

Das Tracking ist nicht Teil des A/B-Testing-Moduls und muss projektspezifisch erfolgen. Zusätzlich zu einem beliebig wählbaren Analytics-Tool wird dafür innerhalb des Projekts ein Tracking Plugin benötigt. Es entspricht einer Formatvorlage und muss unter anderem den Tracking Code bereitstellen.

Mit dem während der Konfiguration der Projekt-Komponente durchgeführten Import wurde dem Projekt bereits das Google Analytics Plugin hinzugefügt. Es erfordert für seinen Einsatz wenige Konfigurationsschritte, die im nachfolgenden Unterkapitel beschrieben sind. Die Nutzung des Plugins sollte nur dann in Erwägung gezogen werden, wenn Google Analytics auch anderweitig zum Einsatz kommt.

Andernfalls empfiehlt sich die Wahl eines anderen Analytics-Tools. In diesem Fall wird ein projektspezifisches Tracking Plugin benötigt, welches mit geringem Aufwand selbst zu implementieren ist. Die notwendigen Anforderungen werden ebenfalls nachfolgend erläutert.

6.1. Google Analytics Plugin

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.

Registrierung eines Google Analytics-Kontos
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.

6.1.2. Einbindung des Plugins

Das Google Analytics Plugin wird während der Konfiguration der Projektkomponente in das Projekt importiert. Es wird in Form einer Formatvorlage bereitgestellt und enthält den Tracking Code zur Erfassung des Erfolgs der Varianten. Des Weiteren dient es zur Abfrage der Dimension Id, die während der Konfiguration eines Experiments anzugeben ist.

Für seine Verwendung muss das Google Analytics Plugin über einen $CMS_RENDER$-Aufruf in allen zulässigen Seitenvorlagen eingebunden werden. Dabei ist darauf zu achten, dass der Aufruf im Kopf der Seite nach der Referenzierung des A/B-Testing Heads zu positionieren ist.

Referenzierung des Google Analytics Plugins 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:"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 AdminAccountPropertyTracking InfoTracking Code.

Pfad zur Ermittlung der Google Analytics Id
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-EigenschaftenOptionen. 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.