Adobe Target: Infrastruktur und Architektur – Was passiert technisch gesehen?

Bevor wir über die Implementierung und Nutzung von Adobe Target sprechen, ist es mir wichtig, ein paar Worte über die Technik zu verlieren, die die Funktionalität des Tools gewährleistet. Nur, wenn Sie sich darüber bewusst sind, was das Tool auf der technischen Ebene macht, werden Sie in der Lage sein, das Optimum aus dem Tool herauszuholen und abzuschätzen, was Sie mit dem Tool umsetzen können. Viele fortgeschrittene Setups werden Sie nur dann erstellen können, wenn Sie verstehen, wie das Tool arbeitet. Dieser Beitrag soll Ihnen dabei das Grundwissen vermitteln.

Adobe Target ist ein Testingtool, dass per Javascript im Browser des Nutzers arbeitet. Die komplette Magie passiert also im Frontend, während Ihr Server die Seiten wie gewohnt an den User ausliefert. Sobald der Browser die Seite liest, zwingt Adobe Target ihn per Javascript bestimmte Manipulationen durchzuführen, um die Seite wie vorgesehen anzuzeigen. Dabei gibt es zwei Möglichkeiten:

• Redirect auf eine andere URL
• Manipulation des „Default Contents“ mittels Javascript Injection

„Default Content“ meint dabei die vom Server ausgelieferte Seite ohne Manipulation. Also die von Ihnen gewohnte Seite, die sie gegen Variationen in einem A/B- oder multivariaten Test überprüfen möchten.

Folgendes Schaubild visualisiert einen Request an den Server bis zur Ausspielung der Testvariante:

Gehen wir diese Abbildung einmal der Reihe nach durch. Als Beispiel soll dabei ein Test auf Ihrer Homepage dienen. Sie wollen verschieden Images in der Hauptbühne testen.

Browser Request an Ihren Server

Wenn ein User die URL Ihrer Startseite eingibt, erfolgt ein Request an Ihren Server (1). Der Server sucht die entsprechende HTML und liefert diese an den Browser, der den Request geschickt hat, aus(2).

Rendering

Der Browser liest (rendert) die HTML und stößt dabei auf ein Javascript, das die Kommunikation zum Adobe Target Server herstellt. Dadurch wird ein neuer Request an den Target Server erfolgen(3).

Auslieferung des alternativen Contents durch Adobe Target

Der Adobe Target Server liest die Informationen, die über das Javascript übermittelt wurden und schaut, ob eine Kampagne / Activity zu den Informationen auf dem Target Server erstellt wurde(4). Ist dies der Fall, wählt die Target Engine eine der in der Activity hinterlegten Varianten (hier: Images) aus(5) und liefert diese an den Browser zurück(6). Der User sieht dann die Variante, die der Target Server für ihn ausgewählt hat. Nach welchen Regeln diese Auswahl geschieht, können Sie im Tool definieren. Mehr dazu in einem Artikel über die Erstellung eines A/B-Tests.

Gleichzeitig zeichnet der Target Server diesen Request auf. Er merkt ihn sich und zählt die Aufrufe und die definierten Conversions, nach denen Sie den Test bewerten möchten (7).

Kommen wir nun zu dem Javascript, das diese Kommunikation gewährleistet. Dabei möchte ich den technischen Aspekt so gering wie möglich und so ausführlich wie nötig halten.

Als Erstes müssen sie eine Javascript-Datei (die mbox.js oder at.js), die Sie im Tool herunterladen können, auf Ihrer Webseite implementieren. Die JS-Datei muss dabei im Head der Seite (am besten auf allen Seiten) möglichst weit unten platziert werden – am besten direkt vor dem schließenden Head-Tag. Die Datei liefert alle grundsätzlichen Funktionen, die Sie für die Nutzung von Adobe Target benötigen.

Um diese Funktionen müssen Sie die Mbox allerdings „callen“, also eine Javascript-Funktion aufrufen. Dies müssen Sie auf den Seiten tun, auf der Sie den Test ausspielen möchten und wo Messungen stattfinden sollen. Die Funktionsaufrufe unterscheiden sich dabei allerdings nicht. Hauptsächlich werden Sie dabei mit zwei Funktionen arbeiten:

MboxCreate()

Mit MboxCreate() können Sie bei Seitenaufruf einen Mbox-Call durchführen. Der Call erfolgt während des Ladens der Seite und wird ausgeführt, bevor der DOM geladen wird. Wenn Sie die Implementierung nicht mit einem Tag Manager durchführen, müssen Sie folgenden Code direkt nach dem öffnenden Body-Tag der entsprechenden Seiten bringen:

Der Code besteht aus einem DIV-Container und dem Funktionsaufruf. In den DIV-Container wird Target den Code setzen, der zur Manipulation der Seite notwendig ist. Über den Funktionsaufruf wird dieser Code quasi geladen. Innerhalb der Klammern des Funktionsaufrufs muss ein Mbox-Name geschrieben werden. Dieser Name ist von Ihnen frei wählbar. Target nutzt diesen Name als Identifier, um bei einem Call zu schauen, welche Activity oder welche Messung mit diesem Mbox-Namen definiert ist und wird dann die notwendige Aktion (Ausspielung einer Variante oder Durchführung einer Conversion-Messsung) durchführen.

Sie können dem Mbox-Aufruf auch noch weitere Parameter mitgeben. Da das Thema „Parameter“ recht komplex ist, werde ich dazu einen gesonderten Artikel schreiben. Für die grundsätzliche Funktionalität reicht jedoch erstmal das Setzen eines Mbox-Namens als Parameter.

Wenn der Browser nun die HTML liest, führt er das Javascript aus, bevor die restlichen Elemente geladen werden. Dadurch, dass der Funktionsaufruf zu Beginn der Seite stattfindet, sieht der Nutzer den Default Content nicht, sondern bekommt lediglich die Seite zu sehen, die Target für ihn nach den definierten Regeln aussucht.

MboxUpdate()

Im Gegensatz zu MboxCreate() handelt es sich bei MboxUpdate() um einen AJAX-Aufruf. Wenn Sie also die Seite nach einem initialen Pageload manipulieren möchten, werden Sie nicht mit MboxCreate() arbeiten können. Dafür benötigen Sie dann einen Funktionsaufruf durch MboxUpdate(). Das klassische Beispiel für die Nutzung von dieser Funktion ist eine Manipulation der Seite auf Basis eines Events wie der Klick auf ein bestimmtes Element. Wenn der User auf dieses Element klickt, wird per onclick-Event die Mbox „ge-updated“. Der Funktionsaufruf sähe bei Klick eines Links (Anchor-Tag) folgendermaßen aus:

Für diesen Aufruf ist ein bisschen mehr Code notwendig. Im Grunde handelt es sich sogar um zwei Funktionaufrufe (mboxDefine() und mboxUpdate()). Auch hier wird wieder ein DIV-Container nach dem öffnenden Body-Tag definiert, in den der für diesen Mbox-Namen hinterlegte Code gesetzt wird.

Um die Mbox zu „updaten“ muss sie jedoch zuerst „definiert“ werden. Das geschieht über mboxDefine(). Innerhalb der Klammern dieses Funktionsaufrufs müssen zwei Parameter gesetzt werden. Der erste muss die ID des DIV-Containers beinhalten und der zweite den Mbox-Namen.

Danach können Sie diese Mbox updaten, wo immer Sie möchten. Wir nutzen das mboxUpdate() um per onclick-Event auf einem Link, der zur URL „http://meineSeite.de“ weiterleitet, diese Mbox zu callen. Wie bereits erwähnt, können wir die Mbox für eine Conversion-Messung (bspw. „Clickout auf Deeplink“) oder für die Aussteuerung eines Tests bzw. für die Manipulation der Seite nutzen.

Sie kennen nun das Grundwerkzeug, um mit Adobe Target einfache Tests aufzusetzen. Sie wissen, wie ein HTTP-Request aussieht, wenn auf dieser Seite ein Test definiert bzw. Adobe Target implementiert ist und wissen auch, wie Sie Mboxen callen können. Es wird Zeit, dass wir nun anfangen, über die spannenden Dinge zu sprechen und ein wenig mehr ins Detail gehen.