Wie Mboxen definiert und aufgerufen werden, habe ich Ihnen bereits in dem Beitrag zur Architektur und Infrastruktur von Adobe Target erklärt. Nun möchte ich auf die Parameter eingehen, die sie in die Mboxen schreiben können. Diese Informationen können Sie nutzen, um bestimmte Mboxen zu klassifizieren, näher zu spezifizieren oder aber User zu flaggen, um sie auch in Folgesessions anhand der Parameter wiederzuerkennen. Dann sprechen wir von sog. Profile Parameters, die über die gesamte Cookielaufzeit von laufenden 14 Tagen (erweiterbar auf bis zu 90 Tage) verfügbar sind. Ich werde Ihnen die Parameter nun vorstellen und danach Beispiele geben, wann sie diese Parameter nutzen können oder sollten.

Grundsätzlich bestehen die Parameter aus Key-Value-Pairs, die Sie in die Mbox schreiben können:

mboxCreate(„mboxName“, „parameter1=value1″, „parameter2=value2″);

Mir ist nicht bekannt, dass sie in der Anzahl der verwendeten Parameter innerhalb eines Mbox-Calls limitiert sind. Ich selbst habe schon Mboxen platziert, die neun Parameter enthielten. Allerdings sollten Sie mit den Parametern schon sinnvoll umgehen, weshalb sie hier nicht blind Informationen mitgeben sollten, sondern diese nur dann implementieren, wenn Sie sie auch wirklich benötigen.

Nehmen wir einmal an, sie wollen eine Produktdetailseite testen. Dabei handelt es sich meist, um ein Template, dass für alle Produkte genutzt wird. Grundsätzlich würden sie folgende Mbox auf der Seite bzw. dem Template platzieren:

mboxCreate(„produktdetailseite“);

Wenn diese Mbox aufgerufen wird, weiß der Adobe Target Server, dass es sich um eine Produktdetailseite handelt und schaut nach, ob für diese Mbox ein Test oder eine Conversion definiert wurde, um entweder einen Test auszuspielen oder eine Conversion zu zählen. Um welches Produkt oder welche Kategorie es sich auf der Seite handelt, von dem dieser Mbox-Aufruf ausgeht, weiß Target nicht. Um nun die Performance in einem Test nicht nur für die Produktdetailseite insgesamt, sondern auch nach Kategorie oder gar nach Produkten zu analysieren, müssen Sie solche Informationen auch an Adobe Target übermitteln. Genau, dazu verwenden Sie Parameter!

Um sowohl die Produkte als auch die Kategorien zu tracken, schreiben Sie sie als Parameter in die Mbox:

mboxCreate(„produktdetailseite“, „productID=123456″, „category=xyz“);

Durch diese Maßnahme sind Sie nicht nur in der Lage, die Performance pro Kategorie oder Produkt auszuwerten, sondern können auch für bestimmte Produkte oder Kategorien andere Manipulationen durchführen bzw. andere Experiences definieren, also ein Targeting auf Kategorie- oder Produktbasis erstellen. Die Persistenz also die Dauer der Verfügbarkeit der Informationen, die sie über den Parameter mitgeben, beträgt nur diesen PageView. Auf der nächsten Seite ist diese Information nicht mehr vorhanden.

Sie können über Mbox Parameter auch Profile über einen Nutzer anlegen, um ihn zu kennzeichnen. Dafür verwenden wir Profile Parameter. Die Implementierung ist ziemlich ähnlich, nur, dass sie die Parameter mit einem Prefix „profile.“ kennzeichnen:

mboxCreate(„produktdetailseite“, „profile.category=xyz“);

Dieser Profil-Parameter wird im Profil des Users gespeichert und solange gültig, wie die ID des Users vorhanden ist. Die ID des Users wird im Mbox-Cookie gespeichert und hat eine Laufzeit von 14 Tagen, die jedoch erweiterbar auf bis zu 90 Tage ist. Sie können damit also User kennzeichnen, die sich bestimmte Inhalte angesehen oder bestimmte Aktionen durchgeführt haben, um auf Basis dieser Informationen Segmente bzw. Audiences zu bilden, die Sie für die Auswertung eines Tests oder für das Targeting nutzen können. Die Profil-Parameter stellen die Basis der Personalisierung mittels Adobe Target dar. Bei der Personalisierung targeten sie nämlich nicht den einzelnen User, sondern immer eine Gruppe von Nutzern, die gleiche Eigenschaften bzw. Profile haben. Alles andere wäre, auch wenn wünschenswert, überhaupt nicht zu handhaben. Stellen Sie sich vor, Sie hätten monatlich 3 Millionen Unique Visitors und müssten für jeden einzelnen Nutzer eigene Experiences definieren. Das werden Sie nicht managen können. Stattdessen bilden Sie sinnvolle Segmente auf Basis von Profil-Parametern und definieren für diese Segmente Experiences. Dabei achten Sie natürlich auf eine sinnvolle Größe dieser Segmente, um eine vertretbare Kosten-Nutzen-Relation zu erreichen, da die Erstellung und die Pflege der Segmente und Experiences selbstverständlich Kosten verursacht.

Sie kennen nun die beiden grundsätzlichen Arten von Mbox Parametern und sind nun in der Lage, Profile zu schreiben. In Kürze werden wir auch hier noch weiter ins Detail gehen, und über Profil-Skripte oder Category Affinity-Messungen zu sprechen, die auf solchen Profilen aufbauen.

Der Beitrag Adobe Target: Mbox Parameter erschien zuerst auf Conversion Notes.

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.

Der Beitrag Adobe Target: Infrastruktur und Architektur – Was passiert technisch gesehen? erschien zuerst auf Conversion Notes.

Adobe Target ist ein Tool mit dem ich Content an bestimmte Usergruppen bzw. Segmente ausspielen kann. Target ist jedoch kein Content Delivery System, sondern liefert lediglich das Werkzeug zum Ausspielen von definiertem Content. Ich kann also mit etwas JavaScript-Zauberei Texte, Images, Seitenstrukturen oder Funktionalitäten im Frontend d.h. im Browser des Users verändern. Dabei wird eine Webseite wie gewohnt an den Browser durch den Server ausgeliefert und dieser Content im Browser mittels JavaScript-Injection manipuliert. Wie die Technik bzw. Architektur dahinter aussieht werde ich in einem anderen Artikel erläutern. Dies soll nicht Gegenstand dieses Beitrags sein.

In Adobe Target lassen sich verschiedene sogenannte Activities anlegen. Da das Tool in unterschiedlichen Varianten (Standard, Premium) zu erwerben ist, unterscheidet sich die Anzahl der erstellbaren Activities je nach Variante. Die einzelnen Activities möchte ich kurz vorstellen. Eine vertiefende Vorstellung werde ich dann in späteren Artikeln vornehmen. Dies soll nur ein Überblick sein:

• A/B-Tests (Standard und Premium)
• Automated Personalization (Premium)
• Multivariate Tests (Standard und Premium)
• Experience Targeting (Standard und Premium)
• Recommendations (Premium)

A/B-Tests:

A/B-Tests stellen die klassische Art von Webseitentests dar. Dabei werden zwei oder mehr Varianten einer Webseite gegeneinander laufen gelassen. Es wird ein Hauptziel (auch Macro-Conversion oder Main Goal) definiert, nach dem der Test bewertet wird. Wenn bspw. ein Formular in zwei verschiedenen Varianten getestet wird, bietet sich an, den erfolgreichen Submit des Formulars als Conversion zu definieren und danach die Varianten zu bewerten. Es ist hierbei natürlich auch möglich, sog. Micro-Conversion bzw. Zwischenziele zu definieren. In dem Formularbeispiel könnte dies das Erreichen von einzelnen Formularschritten sein.

Automated Personalization (kurz AP):

AP ist ein Premium-Feature und damit (derzeit) nur für Target Premium-Kunden nutzbar. Das Feature in Kürze zu erklären, ist nicht ganz einfach, da die Technik dahinter schon recht komplex ist. Im Grunde nutzt Target dabei alle über den User verfügbaren Informationen wie Browser, Wochentag, Referrer, Previous Pages, Betriebssystem, Geo-Location usw. um Content personalisiert auszuspielen. Dies erfolgt automatisch. Es werden also lediglich verschiedene Varianten angelegt und Target entscheidet selbst, welche der Varianten ausgespielt wird, um die bestmögliche Performance zu erzielen. Dabei wird ein Ziel definiert, auf das der dahinter liegende Algorithmus optimiert. Es können keine Zwischenziele definiert werden. Wenn also bspw. fünf verschiedene Variationen bzw. Images für die MainStage auf einer Homepage personalisiert ausgespielt werden sollen und man lediglich die beste Performance erzielen möchte, bietet sich dieses Feature dafür an. Die Ausspielung erfolgt auf Basis von Trainingsdaten, die der Algorithmus zu Beginn jeder AP-Activity sammelt. Sobald genug Daten vorhanden sind, entscheidet der Algorithmus auf Basis der verfügbaren Informationen über einen User selbstständig, welche Variante dem User angezeigt wird. Auch hier werde ich einen gesonderten Artikel schreiben, um das Feature in aller Tiefe zu vorzustellen.

Multivariate Tests

Nehmen wir an, sie haben bereits eine gute Seitenstruktur ihrer Webseite gefunden und wollen nun verschiedene Headlines, Images, Wordings und Call To Action Buttons testen. Wenn sie außerdem auch über genügend Traffic auf der zu testenden Seite verfügen, dann – aber auch nur dann – kommt ein multivariater Test in Frage. Warum benötigen Sie viel Traffic? Die möglichen Kombinationen ergeben sich aus der Multiplikation ihrer Ausprägungen der Testelemente. Wenn sie also zwei Headlines, drei Images und zwei verschiedene CTAs testen wollen, besteht ihre Activity aus 2x3x2 = 12 Varianten. Dementsprechend viel Traffic werden Sie benötigen, bis die Ergebnis statistisch gesichert bzw. konfident sind. Sie können entweder lange warten oder eben mit viel Traffic arbeiten, bis die Daten stimmen. Mit zunehmender Testdauer nimmt allerdings der Einfluss möglicher saisonaler Schwankungen zu, wodurch ihre Tests weniger Aussagekraft haben. Dies ist einer der Gründe, warum ich immer wieder empfehle, iterativ und kleinschrittig zu testen, anstatt multivariate Tests durchzuführen. Die Frage, ob mit A/B- oder Multivariattests gearbeitet, löst immer wieder Diskussionen aus. Es gibt kein richtig oder falsch und jede der Testvariationen hat seine Vorteile. Eventuell widme ich mal einem Beitrag diesem heißen Eisen.

Experience Targeting

Über diese Activities werden Targetings durchgeführt. Es ist also ein Feature, worüber Personalisierung realisiert wird. Es wird pro Segment eine Experience definiert und dann ausgespielt. In Target sind sie dabei nicht gezwungen, dies seitengebunden durchzuführen, sondern können Experiences für einen kompletten Conversion-Funnel definieren und targeten. Wie Sie Segmente in Target definieren oder ein solches Targeting aufsetzen, werde ich später erläutern. Wichtig ist im Augenblick lediglich, dass Sie wissen, dass Sie mit dem Experience Targeting kein Testing machen, sondern im Idealfall bereits geteste Varianten für die Segmente ausspielen, die auf diese Varianten in den Tests gut reagiert haben. Und das ist auch das Kernstück der Conversion Optimierung: Eine segmentbasierte Auswertung ihrer Tests durchführen, um die Segmente anschließend mit der bestmöglichen Experience zu targeten. Also zuerst testen, dann targeten. Ganz einfach, aber viele meinen zu wissen, welche Experience für welche Segmente in Frage kommen. Auch wenn es noch so offensichtlich ist, möchte ich immer empfehlen, Ihre Hypothesen zu testen, bevor Sie über Targeting nachdenken – immer, wirklich immer! Wir sprechen ja nicht umsonst von Hypothesen.

Recommendations

Auch Recommendations ist ein Premium-Feature und somit nur über Target Premium nutzbar. Die Funktion von Recommendations kennt jeder Internetnutzer. Es geht um Produktempfehlungen, die auf Basis von mathematischen Modellen ausgespielt werden. Die wohl bekanntesten Recommendations sind bei Amazon zu finden. Ich weiß gar nicht, ob Amazon der erste Anbieter war, der dieses Feature nutzte, aber es ist wohl der bekannteste. Es geht im Grunde genommen um die Empfehlungen, die man vorwiegend auf Start- und Produktdetailseiten findet und die mit Headlines wie „andere Kunden kauften auch“, „Kunden, die dieses Produkt gesehen haben, haben auch..“ oder „Ähnliche Artikel wie die, die Sie bereits angesehen haben“ deklariert sind. Die Implementierung von Recommendations ist ein wenig aufwendiger, weil Sie für eine erfolgreiche Ausspielung eine Adobe Datenbank füttern müssen. Diese Datenbank muss neben Produktinformationen auch entsprechende Verkaufsdaten zu diesen Produkten enthalten. Wie eine Implementierung vonstatten geht und welche Möglichkeiten sie dabei für das Setup der sog. Recos haben, werde ich noch einmal genauer beleuchten.

Sie kennen nun die grundlegenden Funktionen innerhalb von Adobe Target. Ich werde Ihnen nun nach und nach die einzelnen Activities vorstellen und im Detail erklären. Dabei werde ich allerdings einige technische Details erklären müssen, auf die ich auch gesondert eingehen werde. Alles der Reihe nach! Für einen groben Überblick sollte dieser Beitrag aber ausreichen.

Der Beitrag Adobe Target – Eine kurze Vorstellung der Features erschien zuerst auf Conversion Notes.