RealtimeTargeting - Dokumentation

Die User-Experience Pipeline (UXP) wird bei jedem Seitenaufruf eines Webseiten-Besuchers durchlaufen. Ihr Ziel ist die Ermittlung aller Zielgruppeninformationen bzw. Segmente, in denen der aktuelle Besucher enthalten ist. Dazu werden 1 bis n Profiling & Segmentation Services aufgerufen.

Standardmäßig verwendet das RealtimeTargeting-Modul genau einen solchen Service (Woopra™). Falls andere oder weitere Dienste gewünscht sind, können diese jederzeit projektspezifisch zur UXP hinzugefügt werden. Das Modul besitzt an dieser Stelle eine komplett offene Architektur und ist nicht auf einen spezifischen Dienst beschränkt.

Dieser Dienst übernimmt drei unterschiedliche Aufgaben:

Das FirstSpirit-Modul RealtimeTargeting unterstützt standardmäßig die Anbindung des Woopra™-Services (https://www.woopra.com). Woopra™ verfügt über die drei dargestellten Schnittstellen und enthält fertige Implementierungen für ihre Verwendung. Des Weiteren zeichnet sich Woopra™ durch eine fertige Integration in CRM-Systeme (http://salesforce.com) aus, wodurch weitere sinnvolle Anwendungsszenarien ermöglicht werden.

Andere Dienste sind jedoch, wie bereits beschrieben, jederzeit alternativ einsetzbar.

Die Redakteure besitzen die Aufgabe, spezifische Inhalte zu erstellen, um so eine zielgruppenorientierte Kommunikation zu erreichen. Dazu wird in der Regel zunächst eine allgemeingültige Version eines Inhalts erstellt und darauf aufbauend eine spezifische Variante entwickelt. Solch eine Variante wird anschließend einer oder mehreren Zielgruppen bzw. Segmenten zugeordnet.

Eine Webseite enthält damit (physikalisch gesehen) alle Content-Varianten. Zum Auslieferungszeitpunkt werden jedoch nur die passenden Inhalte bereitgestellt (vgl. Kapitel Content-Auslieferung).

Nach der Ermittlung der einem Besucher zugehörigen Segmenten-Liste kann die Laufzeitumgebung des Webservers die „passenden“ Inhalte der Webseite filtern und ausgeben. Es werden immer nur die gemäß der redaktionellen Parametrisierung korrekten Varianten dargestellt. Eine Auslieferung irrelevanter Inhalte findet nicht statt.

Technisch wird dafür eine Java Tag-Library verwendet. Sie vergleicht die in der UXP ermittelten Segmente mit der redaktionellen Konfiguration der Seite und liefert die passenden Inhalte aus.

Die Aktivierung der Multi Perspective Preview für die Verwendung des Persona-Simulators im ContentCreator erfolgt durch die Auswahl der Vorschau-Parameter in den Projekt-Optionen.

Öffnen Sie hierfür den ServerManager und selektieren Sie den Bereich Projekt-Eigenschaften → Optionen (vgl. Abbildung Vorschau-Parameter auswählen). Wählen Sie beim Punkt Vorschau-Parameter über den entsprechenden Button die Seiten-Vorlage Persona Preview Parameter aus. Diese Seiten-Vorlage wurde bereits bei der Konfiguration der Projekt-Komponente RealtimeTargeting Project Configuration automatisch in das Projekt importiert (siehe Kapitel Konfiguration der Projekt-Komponenten).

Abbildung 12. Vorschau-Parameter auswählen

Die einzelnen Personas im Persona-Simulator besitzen ein Bild, für das eine eigene Auflösung angelegt werden muss.

Öffnen Sie hierfür den ServerManager und selektieren Sie den Bereich Projekt-Eigenschaften → Auflösungen. Im Hauptpanel ist eine Liste aller bereits existierenden Auflösungen zu sehen.

Abbildung 13. Auflösungen

Wählen Sie in dem sich per Rechtsklick öffnenden Kontextmenü den Punkt Neu und legen Sie eine neue Auflösung mit dem Namen persona in der Größe 55x55 Pixel an.

Abbildung 14. neue Auflösung anlegen

Initial besitzen die drei genannten Web-Komponenten alle dieselbe web.xml. Für die Web-Komponente der Produktion muss diese initiale web.xml jedoch angepasst werden.

Öffnen Sie den ServerManager und wählen Sie den Bereich Projekt Eigenschaften → Web-Komponenten. Wechseln Sie im Hauptpanel auf die Registerkarte Produktion (Live) und selektieren Sie dort die RealtimeTargeting WebApplication (vgl. Abbildung Web-Komponenten Produktion (Live)).

Abbildung 16. Web-Komponenten Produktion (Live)

Ein Klick auf den Button web.xml öffnet einen Konfigurationsdialog, in dem die web.xml editiert werden kann.

Für die Kommunikation mit Woopra™ benötigt die web.xml der Produktion weitere Filter, die von den anderen beiden Web-Komponenten nicht verwendet werden (siehe auch Kapitel Pipeline-Filter). Sie sind daher initial auskommentiert. Aktivieren Sie diese Filter, indem Sie die entsprechenden Kommentar-Kennzeichnungen entfernen, und speichern Sie die Änderungen anschließend über den gleichnamigen Button.

Für die zielgruppenspezifische Ausgabe der Inhalte auf der Webseite müssen die dem Besucher jeweils aktuell zugeordneten Segmente ermittelt werden. Diese Aufgabe übernehmen die Pipeline-Filter:

Diese Filter ermöglichen die Bereitstellung einer individualisierten Darstellung der Webseite für verschiedene Zielgruppen. Sie sind modular und können beliebig erweitert werden. Die genaue Definition der jeweils verwendeten Filter erfolgt in der zugehörigen web.xml der Web-Komponenten für die Vorschau, die Produktion bzw. den ContentCreator. Anhand dieser Definition in der entsprechenden web.xml werden die Filter sukzessiv abgearbeitet.

Zusätzlich zu den bereits existierenden Filtern können weitere eigene Filter implementiert werden. Eine entsprechende Beschreibung finden Sie im Kapitel Implementierung zusätzlicher Filter für die UXP.

Für jeden in einer web.xml hinzugefügten Filter wird außerdem ein Mapping benötigt, das definiert, wann der entsprechende Filter greift. Hierbei ist darauf zu achten, dass die im Mapping festgelegte Dateiendung zu den erzeugten Seiten passt.

Struktur der Filter-Definition in der web.xml. 

<filter>
   <filter-name>FilterName</filter-name>
   <filter-class>FilterClass</filter-class>
</filter>
<filter-mapping>
   <filter-name>FilterName</filter-name>
   <url-pattern>*.DATEIENDUNG</url-pattern>
</filter-mapping>

Sollen weitere Filter zum Einsatz kommen, müssen diese nach demselben Schema ergänzt werden.

Bei der Verwendung der Web-Komponente des RealtimeTargeting-Moduls auf einem externen Server, ist es möglich, ein Logging über die Logback-Bibliothek (http://logback.qos.ch) zu konfigurieren, falls nicht bereits eine andere SLF4J-Implementierung vorgefunden wurde.

Durch die mit dem Modul ausgelieferte Konfiguration für Logback wird eine Datei namens uxp.log erzeugt, die innerhalb des entsprechenden logs-Verzeichnisses des Servlet-Containers abgelegt wird.

Standardmäßig ist das Log-Level der Web-Komponente auf INFO eingestellt. Es wird täglich eine neue Log-Datei erstellt und die Log-Dateien vergangener Tage für 30 Tage im GZ-Format archiviert. Sollte die Konfiguration angepasst werden müssen, so kann dies über die Datei logback.xml innerhalb des WEB-INF-Verzeichnisses der entsprechenden Webanwendung geschehen.

Für den Einsatz des RealtimeTargeting-Moduls muss zunächst die Dateiendung des verwendeten Seiten-Templates von html zu jsp geändert werden. Des Weiteren müssen die in der web.xml der Web-Applikation definierte Tag-Library und JSTL innerhalb dieses Seiten-Templates eingebunden werden.

Nähere Informationen zur Änderung der Dateiendung können Sie dem FirstSpirit Handbuch für Entwickler entnehmen.

Für die Nutzung des ContentTargeting-Tags wird in dieser Dokumentation nachfolgend das Präfix rtt verwendet.

Beispiel für die Einbindung der Taglib und der JSTL in JSP-Seiten. 

<%@ page language="java" contentType="text/html; charset=UTF-8" %>
<%@ taglib uri="targeting" prefix="rtt" %>
<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

Das Tag <rtt:showContent> dient zur Ein- bzw. Ausblendung des von ihm umschlossenen Inhalts. Die Sichtbarkeit des Inhalts wird über die Zugehörigkeit des Besuchers zu den definierten Segmenten bzw. über die Angabe von Zeitpunkten geregelt. Die Auswertung des Tags erfolgt über einen Vergleich der Segmente des darzustellenden Inhalts und des Webseiten-Besuchers. Nur wenn diese übereinstimmen, wird der Inhalt dem Besucher bereitgestellt.

Die Sichtbarkeit des vom Tag umschlossenen Inhalts ist außerdem abhängig von der konfigurierten Logik. Nach dieser muss sich der Besucher entweder in allen (AND) oder in mindestens einem (OR) der definierten Segmente befinden. Ist er in keinem Segment enthalten, so wird der Inhalt des Tags ausgegeben, für das kein Segment definiert wurde. Im Fall der Zugehörigkeit zu mehreren Segmenten wird der erste Inhalt ausgegeben, für den die definierte Regel erfüllt ist.

Um auf jedes definierte Segment gezielt reagieren zu können, besteht außerdem die Möglichkeit, die auszugebenden Inhaltsvarianten durch frei definierbare IDs beliebig zu gruppieren.

Über die Angabe von Start- und/oder Endzeitpunkten können die Inhalte außerdem zeitabhängig angezeigt werden, wodurch unterschiedlichste Szenarien denkbar sind. So lassen sich beispielsweise für ein Segment in verschiedenen Zeiträumen unterschiedliche Inhalte anzeigen.

Im ContentCreator können Redakteure über einen Zeitstrahl ein Datum auswählen. Auf diesem Weg wird ihnen auch die Betrachtung der Inhalte zu einem bestimmten – vergangenen oder zukünftigen – Zeitpunkt ermöglicht. Für die Berücksichtigung des Datums muss dieses jedoch als Attribut übergeben werden.

Die folgende Tabelle enthält eine Übersicht aller verfügbaren Attribute:

Beispiel für die Verwendung des ContentTargeting-Tags. 

<rtt:showContent
   segments="Architects, Homebuilders"
   logic="OR" id="300642"
   startdate="1336226501635"
   enddate="1336226503635"
   referencedate="1336226502635">

   <!-- ... anzuzeigender Inhalt -->
</rtt:showContent>

Ein ausführlicheres Beispiel finden Sie im Kapitel Persona-Simulator.

Mit den Funktionalitäten des RealtimeTargetings kann die Verwendung sogenannter Smart Forms umgesetzt werden. Dabei handelt es sich um Formulare, deren Felder beim Aufruf mit bereits bekannten Daten gefüllt sind und somit nur noch bei Bedarf editiert werden müssen. Die entsprechenden Daten werden beim ersten Versand eines Formulars erfasst und können danach für jedes andere Formular der Seite genutzt werden.

Auf diesem Weg werden für den Besucher der Webseite redundante Eingaben vermieden, was eine Verbesserung der Usability darstellt.

An dieser Stelle wird beispielhaft die Verwendung von Smart Forms anhand des FirstSpirit-Moduls FormEdit in Verbindung mit den Funktionalitäten des RealtimeTargetings skizziert. Der Nutzung des Moduls FormEdit ist natürlich keine Pflicht. Es kann auch jede andere Art von Formularen eingesetzt werden.

Ein mit FormEdit erstelltes Formular setzt sich aus den drei Teilen Anfang, Block und Ende zusammen, die durch Absatztemplates repräsentiert werden und dem Projekt bereits mit der Installation des FormEdit-Moduls hinzugefügt wurden.

In diesem Beispiel sollen nur der Name und die E-Mail-Adresse eines Besuchers vorausgefüllt werden. Zur initialen Erfassung dieser Daten muss der HTML-Bereich des Anfangs durch den folgenden Skript-Code ergänzt werden, der eine entsprechende Anpassung erfordert, wenn weitere Daten gespeichert werden sollen:

<script>
   var submit_$CMS_VALUE(fr_st_name)$ = false;
   $('#$CMS_VALUE(fr_st_name)$').submit(function(e) {
      var formName = $('#name').val();
      var formEmail = $('#email').val();
      woopra.identify({
         email: formEmail,
         name: formName
      }).push();
   setTimeout(function(){
      submit_$CMS_VALUE(fr_st_name)$ = true;
      $('#$CMS_VALUE(fr_st_name)$').submit();
   }, 2000);
   if(!submit_$CMS_VALUE(fr_st_name)$) {
      e.preventDefault();
   }});
</script>

Dieser Code liest die Eingabe des Besuchers aus dem initial verwendeten Formular aus und übermittelt sie in diesem Fall an Woopra™. Dort werden die Daten als Attribute des Besuchers gespeichert und können bei Bedarf jederzeit abgefragt werden.

Die einzelnen Felder, aus denen sich das Formular zusammensetzt, sind über eine FS_LIST innerhalb des Blocks zu definieren (vgl. Abbildung FormEdit – Formular-Block). Sie werden durch weitere Absatztemplates repräsentiert, die ebenfalls mit der Installation des FormEdit-Moduls bereitgestellt werden.

Abbildung 24. FormEdit – Formular-Block

Für alle Texteingaben, wie beispielsweise auch der Name und die E-Mail-Adresse eines Besuchers, wird das Formularelement Text verwendet. Um diese Felder in anderen Formularen mit bereits erfassten Daten vorzubefüllen, muss die If-Abfrage für die Eingabekomponente st_value innerhalb des HTML-Bereichs des zugehörigen Absatztemplates um einen Else-Fall ergänzt werden:

$CMS_SET(fr_st_value)$
   $CMS_IF(!st_value.isEmpty)$
      $CMS_VALUE(st_value)$
   $CMS_ELSE$
      <c:out value="${sessionScope['rtt.woopra.user.$CMS_VALUE(st_name)$']}"/>
   $CMS_END_IF$
$CMS_END_SET$

Des Weiteren muss innerhalb der Projekteigenschaften für die entsprechende Web-Komponente die web.xml der Woopra Web-Applikation angepasst werden, indem ihr der Pipeline-Filter GetWoopraUserInformationFilter hinzugefügt wird. Dieser Filter ermöglicht die Ermittlung der in Woopra™ zu einem Besucher gespeicherten Attribute.

Da diese Attribute initial noch nicht erfasst sind, werden dem Besucher der Webseite zunächst nur leere Formulare angezeigt, die entsprechend der Definition in der FS_LIST des Blocks strukturiert sind (vgl. Abbildung Formular mit Besucherdaten, die an Woopra(TM) übermittelt werden).

Abbildung 25. Formular mit Besucherdaten, die an Woopra(TM) übermittelt werden

Erst nach der Eingabe der entsprechenden Daten und dem Versand eines solchen Formulars werden die Daten in Woopra™ übernommen und dort gespeichert (vgl. Abbildung Woopra(TM) - gespeicherte Besucherdaten).

Abbildung 26. Woopra(TM) - gespeicherte Besucherdaten

Zusätzlich zu den übermittelten Daten werden die Aktivitäten des Besuchers auf der Seite sowie der Zeitpunkt seines letzten Besuches erfasst.

Bei dem Aufruf eines beliebigen anderen Formulars, dessen Felder Name und E-Mail-Adresse die vorgeschriebenen eindeutigen Bezeichner besitzen, werden nun die in Woopra™ gespeicherten Besucherdaten ermittelt und in das Formular geschrieben (vgl. Abbildung Vorbefüllung eines zweiten Formulars).

Abbildung 27. Vorbefüllung eines zweiten Formulars

Der Besucher besitzt in diesem Beispiel die Möglichkeit, die im Formular angezeigten Daten zu editieren. In anderen Szenarien wäre es jedoch beispielsweise auch denkbar, sie ihm nur noch anzuzeigen oder das gesamte Formular bei der Verfügbarkeit aller erforderlichen Daten auszublenden.

Wie bereits in der Einleitung unter dem Punkt 2c beschrieben, wird das Interesse eines Webseiten-Besuchers für spezifische Themen in der Regel mit einem Scoring-Mechanismus erfasst. Der Besucher erhält für den Aufruf bestimmter Inhalte eine zuvor festgelegte Anzahl von Punkten, die an den Profiling & Segmentation Service übertragen und von diesem summiert werden. Erreicht diese Summe einen definierten Schwellwert, erfolgt eine automatische Zuordnung zu einem entsprechenden Segment.

An dieser Stelle wird die Verwendung des Scorings in Verbindung mit Datensätzen skizziert. Der Mechanismus kann jedoch auch für andere FirstSpirit-Elemente eingesetzt werden.

In diesem Beispiel sollen Webseiten-Besucher durch das Lesen bestimmter Inhalte als Architekten oder Bauherren identifiziert werden. Dafür wurden die Datensätze um eine FS_LIST ergänzt, deren Einträge eine Auswahlmöglichkeit für die beiden Segmente (Architekten, Bauherren) und ein Feld für die Anzahl der zu vergebenen Punkte enthalten (vgl. Abbildung Definition eines Score-Werts für Architekten). Die Redakteure können den Datensätzen auf diesem Weg unterschiedliche Score-Werte für die beiden Segmente zuordnen.

Abbildung 28. Definition eines Score-Werts für Architekten

Die in der FS_LIST hinterlegten Segmente werden zusammen mit den für sie definierten Score-Werten in den PageContext übertragen. Dafür wurde die folgende Zeile in den HTML-Bereich der zugehörigen Tabellenvorlage eingefügt:

$CMS_SET(#global.pageContext["set_scoring"],cs_scoring)$

Der PageContext wird seinerseits über die folgende Abfrage, die im HTML-Bereich der Seiten-Vorlage hinzuzufügen ist, ausgewertet:

$CMS_IF(!#global.preview)$
   $CMS_IF(#global.pageContext["set_scoring"] != null)$
      $CMS_SET(scoring, #global.pageContext["set_scoring"])$
   $CMS_END_IF$
$CMS_END_IF$

Der zu erreichende Schwellwert und die aus ihm folgende Zuordnung sind im Profiling & Segmentation Service hinterlegt. Dafür wurde in den Einstellungen des vom RealtimeTargeting-Modul verwendeten Services Woopra™ unter dem Punkt Schema zunächst ein neues Action Data Schema hinzugefügt und dieses durch die Properties für Architekten und Bauherren ergänzt (vgl. Abbildung Woopra - Action Data Schema).

Weitere Informationen zur Konfiguration des Action Data Schemas finden Sie in der Woopra™-Dokumentation.

Abbildung 29. Woopra - Action Data Schema

Die Properties können dann bei der Konfiguration eines neuen Segments für die Definition des Schwellwertes verwendet werden.

In diesem Beispiel soll ein Webseiten-Besucher, der einen Score-Wert von 1000 für Architekten erreicht hat, automatisch als ein eben solcher identifiziert und dem Segment Architekten zugeordnet werden (vgl. Abbildung Woopra - Scoring für Architekten). Für Bauherren gilt diese Anforderung äquivalent.

Abbildung 30. Woopra - Scoring für Architekten

Die Properties des Action Data Schemas werden auch im Tracking-Code verwendet, mit dem das Verhalten der Webseiten-Besucher ermittelt wird. Der Tracking-Code wurde bereits mit der beschriebenen Installation in das Projekt importiert und muss für die Übertragung der Score-Werte an den Profiling & Segmentation Service um die folgenden Zeilen ergänzt werden:

<script>
   [...]
   $CMS_SET(hasScore, false)$
   $CMS_SET(scores, "")$
   $CMS_IF(scoring != null)$
      $CMS_FOR(entry, scoring)$
         $CMS_IF(entry.st_score_value > 0)$$CMS_SET(hasScore, true)$$CMS_END_IF$
         $CMS_IF(#for.index > 0)$$CMS_SET(scores, scores + ",")$$CMS_END_IF$
         $CMS_SET(scores, scores + entry.st_score_name + " : " + entry.st_score_value)$
      $CMS_END_FOR$
   $CMS_END_IF$

   woopra.track();

   $CMS_IF(hasScore)$
      woopra.track('scoring', {
         $CMS_VALUE(scores)$
      });
   $CMS_END_IF$
</script>

Dieser Code weist den in diesem Fall in den Datenquellen hinterlegten Score-Wert dem entsprechenden Property in Woopra™ zu, sobald der Datensatz durch einen Webseiten-Besucher betrachtet wird. In Woopra™ erscheint gleichzeitig die Information zu dieser Aktion (vgl. Abbildung Identifizierung eines potentiellen Architekten).

Abbildung 31. Identifizierung eines potentiellen Architekten

In der run()-Methode des ExampleIpFilters wird anhand des Requests die IP-Adresse des derzeitigen Besuchers ermittelt und im aktuellen Request-Kontext unter dem Variablennamen rtt.user.ip gespeichert.

RequestContext ctx = ((UxpServletRequest)servletRequest).getRequestContext();
String ipAddress = request.getHeader("X-FORWARDED-FOR");
if (ipAddress == null) {
   ipAddress = request.getRemoteAddr();
}
ctx.set("rtt.user.ip", ipAddress);

In der run()-Methode des ExampleLocationFilters wird zunächst die IP-Adresse des derzeitigen Besuchers aus der Variablen rtt.user.ip des Request-Kontextes gelesen. Im Anschluss erfolgt eine Ermittlung des zugehörigen Landes mittels des REST-Services von FreeGeoIp. Dieses wird in der aktuellen Session unter dem Variablennamen rtt.user.country gespeichert.

RequestContext ctx = ((UxpServletRequest)servletRequest).getRequestContext();
String ip = (String) ctx.get("rtt.user.ip");
String country = null;
String line;
BufferedReader in = null;
try {
   in = new BufferedReader( new InputStreamReader(new URL("http://freegeoip.net/xml/"+ip).openStream ()));
   while ((line = in.readLine ()) != null) {
      if(line.contains("CountryName")) {
         country = line.substring(line.indexOf(">")+1,line.indexOf("</CountryName>"));
         break;
      }
   }
   ctx.getRequest().getSession().setAttribute("rtt.user.country", country);
} catch (IOException e) {
   LOGGER.error("A Problem occured while getting the country!");
} finally {
   if (in != null) {
      try {
         in.close();
      } catch (IOException e) {
         LOGGER.error("A Problem occured while reading the geoip service!");
      }
   }
}

Soll zu Testzwecken eine IP vorgegeben werden, so kann dies über einen manipulierten Request-Header erfolgen, für dessen Wert X-FORWARDED-FOR die gewünschte IP vorgegeben wird.

Alternativ können für die Angabe der IP auch Request-Parameter verwendet werden. In diesem Fall muss die URL durch die Parameter ip und key erweitert werden. Der Wert für den Parameter key lautet GSJqcIQ5qXFbXiUaNyEk und darf nicht verändert werden. Als Wert für den Parameter ip ist die gewünschte IP anzugeben.

Innerhalb des Templates kann der durch die Filter gesetzte Wert aus der Session beispielweise mittels eines JSTL-Ausdrucks ausgelesen werden:

<c:out value='${sessionScope["rtt.user.country"]}'/>

Die Bereitstellung der Liste aller Segmente für die Redakteure erfolgt über das zu implementierende Interface GomIncludeValueProvider, das in der Access-API von FirstSpirit dokumentiert ist:

http://www.e-spirit.com/odfs50/dev/de/espirit/firstspirit/access/store/templatestore/gom/GomIncludeValueProvider.html

Bei dem Interface handelt es sich um eine standardmäßig von FirstSpirit bereitgestellte Schnittstelle, mit der dynamische Wertemengen an bestimmte Eingabekomponenten übergeben werden können (siehe Kapitel WoopraValueProvider).

Es wird empfohlen, die Kommunikation zwischen dem FirstSpirit-Server und dem gewünschten Profiling & Segmentation Service über einen FirstSpirit-Service zu realisieren, der wiederum aus dem GomIncludeValueProvider angesprochen wird. Des Weiteren sollte ein Cache für die zurückgelieferten Zielgruppen implementiert werden, um eine ständige Kommunikation zwischen dem Server und dem Profiling & Segmentation Service zu vermeiden.

Die zielgruppenspezifische Ausgabe der Webseiten-Inhalte wird über die dem Besucher zugeordneten Segmente geregelt. Diese Segmente werden durch die Filter vom Profiling & Segmentation Service angefordert und an die Session des Besuchers übergeben.

Soll ein anderer Profiling & Segmentation Service verwendet werden, ist ein entsprechender Filter zu implementieren, der die Ermittlung der Segmente übernimmt.

Die meisten Anbieter ermitteln das Verhalten des Webseiten-Besuchers über einen Tracking-Code. Dieser muss innerhalb des Projekts in die verwendete Seitenvorlage eingebunden werden.

Es wird die Implementierung einer Projektkomponente empfohlen, die eine den Tracking-Code enthaltende Formatvorlage in das Projekt importiert. Diese muss dann lediglich über einen CMS_RENDER-Aufruf in der Seitenvorlage referenziert werden.

Um die gewünschte Funktionalität zu erreichen, sind zunächst die Tag-Libraries in den Header der Seitenvorlage einzubinden.

<head>
   [...]
   <%@taglib prefix="rtt" uri="/WEB-INF/targeting.tld"%>
   <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>
   [...]
</head>

Des Weiteren müssen in die Seitenvorlage die CSS- und JavaScript-Dateien des RealtimeTargeting-Moduls eingebunden werden. Hier bietet es sich an, die Dateien nur in die Vorschau einzubinden, da sie nur dort benutzt werden. Die Formatvorlage persona_script beinhaltet die eigentlichen Aufrufe.

<head>
   [...]
   $CMS_IF(#global.preview)$
      $CMS_RENDER(template:"persona_script")$
   $CMS_END_IF$
   [...]
</head>

Die Previewleiste dient der Auswahlmöglichkeit von Personas im SiteArchitect. Sie simuliert dazu die Leiste der MultiPerspectivePreview aus dem ContentCreator und sollte daher auch nur in der Vorschau des SiteArchitects dargestellt werden. Die Darstellung der Personas in der Vorschau übernimmt die Formatvorlage persona_box, sowohl für den ContentCreator, als auch für den SiteArchitect.

<body>
   [...]
   $CMS_IF(#global.preview && !#global.is("WEBEDIT"))$
      $CMS_RENDER(template:"persona_previewbar")$
   $CMS_END_IF$
   $CMS_IF(#global.preview)$
      $CMS_RENDER(template:"persona_box")$
   $CMS_END_IF$
   [...]
</body>

In den Datenquellen sind in der Tabelle Persona die gewünschten Personas zu pflegen z.B.:

Abbildung 32. Neue Persona anlegen

Die Personas sind danach direkt in der Vorschau bzw. im ContentCreator sichtbar.

Abbildung 33. Persona-Simulator

Da im Beispielprojekt noch kein Absatz existiert, legen wir einen neuen Absatz Teaser an und erstellen die benötigten Eingabekomponenten für die Überschrift und den Text.

RealtimeTargeting-spezifisch kommen noch zwei Eingabekomponenten für den Gültigkeitszeitraum sowie eine Liste für die Varianten hinzu:

<CMS_INPUT_DATE name="st_startdate">
   <LANGINFOS>
      <LANGINFO lang="*" label="Startdate"/>
      <LANGINFO lang="DE" label="Startdatum"/>
   </LANGINFOS>
</CMS_INPUT_DATE>

<CMS_INPUT_DATE name="st_enddate">
   <LANGINFOS>
      <LANGINFO lang="*" label="Enddate"/>
      <LANGINFO lang="DE" label="Enddatum"/>
   </LANGINFOS>
</CMS_INPUT_DATE>

<FS_LIST name="st_rtt_sectionlist" hFill="yes">
   <DATASOURCE type="inline" useLanguages="no">
      <LABELS>
         <LABEL lang="*">
            if (#item.st_targetSegments.empty,
            if (#item.st_startdate.empty,
            if (#item.st_enddate.empty, "New variant",
            "Valid to " + #item.st_enddate.format("MM/dd/yyyy")),
            "Valid from " + #item.st_startdate.format("MM/dd/yyyy")+
            if(!#item.st_enddate.empty, " to " + #item.st_enddate.format("MM/dd/yyyy"))),
            #item.st_targetSegments.map(x -> x.getLabel("%lang%")).toString(" " + #item.st_targetSegmentLogic.getLabel("%lang%") + " ") +
		    if(!#item.st_startdate.empty, ",
		    Valid from " + #item.st_startdate.format("MM/dd/yyyy")) +
		    if(!#item.st_enddate.empty, if(#item.st_startdate.empty,",Valid") + " to " + #item.st_enddate.format("MM/dd/yyyy")))
		 </LABEL>
		 <LABEL lang="DE">
		    if (#item.st_targetSegments.empty,
		    if (#item.st_startdate.empty,
		    if (#item.st_enddate.empty, "Neue Variante",
		    "Gültig bis " + #item.st_enddate.format("dd.MM.yyyy")),
		    "Gültig von " + #item.st_startdate.format("dd.MM.yyyy") +
		    if(!#item.st_enddate.empty, " bis " +
		    #item.st_enddate.format("dd.MM.yyyy"))),
		    #item.st_targetSegments.map(x -> x.getLabel("%lang%")).toString(" " +
		    #item.st_targetSegmentLogic.getLabel("%lang%") + " ") +
		    if(!#item.st_startdate.empty, ",
		    Gültig von " + #item.st_startdate.format("dd.MM.yyyy")) +
		    if(!#item.st_enddate.empty,
		    if(#item.st_startdate.empty,",
		    Gültig") + " bis " + #item.st_enddate.format("dd.MM.yyyy")))
		 </LABEL>
      </LABELS>
	  <ACTIONS>
	     <ACTION name="ADD"/>
	     <ACTION name="REMOVE"/>
	     <ACTION name="UP"/>
	     <ACTION name="DOWN"/>
	     <ACTION name="EDIT"/>
	  </ACTIONS>
	  <COLUMNS>
	     <COLUMN show="no">#identifier</COLUMN>
	     <COLUMN show="yes" width="150">#text</COLUMN>
	  </COLUMNS>
	  <LAYOUT>
	     <ADD component="stackedview" constraint="hide"/>
	     <ADD component="toolbar" constraint="top"/>
	     <ADD component="overview" constraint="left"/>
	     <ADD component="simpleview" constraint="center"/>
	  </LAYOUT>
	  <TEMPLATES source="sectiontemplates">
	     <TEMPLATE uid="rtt_variant_text_image"/>
	  </TEMPLATES>
   </DATASOURCE>
   <LANGINFOS>
      <LANGINFO lang="*" label="Variants"/>
      <LANGINFO lang="DE" label="Varianten"/>
   </LANGINFOS>
</FS_LIST>

Im Ausgabekanal wird die Standardausgabe in zwei Punkten erweitert. Zunächst benötigt jede Variante eine eindeutige ID, die wir aus dem Kürzel rttSection und der ID des Absatzes erzeugen.

$CMS_SET(rttSection, "id=\"rttSection" + #global.section.id + "\" ")$

Diese ID wird später als ID des Divs gesetzt, das den Teaser darstellt.

<div $CMS_VALUE(rttSection)$class="col-md-4"$CMS_VALUE(editorId())$>

Als nächstes wird das ContentTargeting-Tag rtt:showContent um den Inhalt des Teasers gelegt, um diesen je nach User-Segmenten ein- oder ausblenden zu können. Als Parameter müssen die ID sowie die Gültigkeitszeiträume übergeben werden.

<rtt:showContent
   id="$CMS_VALUE(#global.section.id)$"
   $CMS_IF(st_startdate != null)$
      startdate="$CMS_VALUE(st_startdate.getTimeInMillis())$"
   $CMS_END_IF$
   $CMS_IF(st_enddate != null)$
      enddate="$CMS_VALUE(st_enddate.getTimeInMillis())$"
   $CMS_END_IF$
   referencedate="$CMS_VALUE(#global.startTime.getTimeInMillis())$" >

Die eigentlichen Varianten bekommen ein eigenes Absatztemplate, das eine Kopie des vorherigen Teaser-Absatzes ist. Bei der Kopie wird die Eingabekomponente für die Varianten entfernt. Dafür kommen zwei neue Eingabekomponenten für die Segmente und deren Verknüpfungslogik hinzu:

<CMS_INPUT_RADIOBUTTON name="st_targetSegmentLogic" gridHeight="1" gridWidth="2" hFill="yes" useLanguages="no">
   <ENTRIES>
      <ENTRY value="OR">
         <LANGINFOS>
            <LANGINFO lang="*" label="OR"/>
            <LANGINFO lang="DE" label="ODER"/>
         </LANGINFOS>
      </ENTRY>
      <ENTRY value="AND">
         <LANGINFOS>
            <LANGINFO lang="*" label="AND"/>
            <LANGINFO lang="DE" label="UND"/>
         </LANGINFOS>
      </ENTRY>
   </ENTRIES>
   <LANGINFOS>
      <LANGINFO lang="*" label="Logic to combine segments" description="Should segments be combined with OR or AND?"/>
      <LANGINFO lang="DE" label="Segmente verknüpfen mit" description="Mit welcher Logik sollen die Segmente verknüpft werden?"/>
   </LANGINFOS>
</CMS_INPUT_RADIOBUTTON>

<CMS_INPUT_CHECKBOX name="st_targetSegments" gridWidth="3" hFill="yes" useLanguages="no">
   <CMS_INCLUDE_OPTIONS type="public">
      <LABELS>
         <LABEL lang="DE">#item</LABEL>
         <LABEL lang="*">#item</LABEL>
      </LABELS>
      <NAME>com.espirit.moddev.rtt.gui.WoopraValueProvider</NAME>
   </CMS_INCLUDE_OPTIONS>
   <LANGINFOS>
      <LANGINFO lang="*" label="Show to segment(s)" description="Information is relevant and should be shown to the selected segments."/>
      <LANGINFO lang="DE" label="Relevanz für Segmente" description="Informationen sind relevant und sollen den ausgewählten Segmenten angezeigt werden."/>
   </LANGINFOS>
</CMS_INPUT_CHECKBOX>

Im Ausgabekanal wird die Standardausgabe in mehreren Punkten erweitert. Zunächst benötigt jede Variante eine eindeutige ID, die wir aus dem Kürzel rttSection und der ID des Absatzes erzeugen und dem umgebenden Div hinzufügen.

<div id="rttSection$CMS_VALUE(#global.section.id)$" [...]

Auch hier wird das ContentTargeting-Tag rtt:showContent um den Inhalt des Teasers gelegt, um diesen je nach User-Segmenten ein- oder ausblenden zu können. Als Parameter müssen – neben der ID und den Gültigkeitszeiträumen – auch die Verknüpfungslogik der Segmente sowie die selektierten Segmente selbst übergeben werden.

<rtt:showContent
   segments="$CMS_VALUE(st_targetSegments.toString(","))$" logic="$CMS_VALUE(st_targetSegmentLogic)$" id="$CMS_VALUE(#global.section.id)$"
   $CMS_IF(st_startdate != null)$
      startdate="$CMS_VALUE(st_startdate.getTimeInMillis())$"
   $CMS_END_IF$
   $CMS_IF(st_enddate != null)$
      enddate="$CMS_VALUE(st_enddate.getTimeInMillis())$"
   $CMS_END_IF$
   referencedate="$CMS_VALUE(#global.startTime.getTimeInMillis())$">

Nach dem Abschluss der Arbeiten können auf der Seite neue Absätze mit Varianten angelegt werden und mithilfe des Persona-Simulators kann der Redakteur bereits in der Vorschau die Ansicht für Benutzer, die bestimmte Segmente besitzen, testen.

Im ersten Schritt legen wir im Inhaltsbereich contentbottom ein neues Formular an, indem wir form start, form block und form end Absätze hinzufügen. Innerhalb des form block–Elements werden noch die Text-Blöcke name und email hinzugefügt.

Das FormularStart-Template muss zur Benutzung von Smart Forms erweitert werden. Über das hinzugefügte Script werden die Werte von Name und E-Mail des Benutzers vor dem Versand des Formulars an Woopra™ weiter geleitet.

<script>
   var submit_$CMS_VALUE(fr_st_name)$ = false;
   $('#$CMS_VALUE(fr_st_name)$').submit(function(e) {
      var formName = $('#name').val();
      var formEmail = $('#email').val();
      woopra.identify({
         email: formEmail,
         name: formName
      }).push();
      setTimeout(function(){
          submit_$CMS_VALUE(fr_st_name)$ = true;
          $('#$CMS_VALUE(fr_st_name)$').submit();
      }, 2000);
      if(!submit_$CMS_VALUE(fr_st_name)$) {
         e.preventDefault();
      }
   });
</script>

Um beim erneuten Aufruf des Formulars die Eingabekomponenten für Name und E-Mail mit Werten aus Woopra™ vorzubelegen, ist die Erweiterung der Vorlage formText notwendig. Wenn der Benutzer eine Eingabe vorgenommen hat, so wird dieser Wert angezeigt, ansonsten wird der gespeicherte Wert aus Woopra™ angezeigt. Dieser befindet sich aufgrund der definierten Filter (s. Anpassungen der web.xml im nächsten Kapitel) bereits in der User-Session.

$CMS_SET(fr_st_value)$
   $CMS_IF(!st_value.isEmpty)$
      $CMS_VALUE(st_value)$
   $CMS_ELSE$
      <c:out value="${sessionScope['rtt.woopra.user.$CMS_VALUE(st_name)$']}"/>
   $CMS_END_IF$
$CMS_END_SET$

Innerhalb der Projekteigenschaften für die entsprechende Web-Komponente muss die web.xml der Woopra™ Web-Applikation angepasst werden, indem ihr die Pipeline-Filter WoopraFirstVisitFilter und GetWoopraUserInformationFilter hinzugefügt werden (siehe Kapitel Pipeline-Filter und Kapitel GetWoopraUserInformationFilter). Diese Filter ermöglichen die Ermittlung der in Woopra™ zu einem Besucher gespeicherten Attribute.