Individuelle und personalisierbare Websites mit pimcore 2.0

Meine Zielgruppe, mein Inhalt
Kommentare

Pimcore ist ein Open Source Enterprise CMF mit klarem Focus auf Time to Market von hoch individualisierten Websites und Webapplikationen und bringt alle dazu notwendigen Tools in einer Suite zusammen. Es positioniert sich damit ganz klar als Open-Source-Alternative zu bereits etablierten Systemen wie Adobe Experience Manager und Sitecore. Die vor Kurzem freigegebene Version 2.0 bietet unter anderem auch eine komplette Targeting und Personalisierungs-Engine, mit der sich Inhalte flexibel an einzelne Zielgruppen anpassen lassen.

In dem folgenden Tutorial wird Schritt für Schritt der Aufbau einer einfachen Website anhand der Beispieldaten von pimcore erklärt und anschließend einige Inhalte speziell an Zielgruppen angepasst. Die Beispieldaten beinhalten Templates, die auf dem beliebten Frontend-Framework Bootstrap in der aktuellsten Version 3 basieren, diese sind daher auch full-reponsive, einfach anzupassen und eignen sich ideal für die ersten Schritte mit pimcore.

Konzept, Idee und Anwendung

Da es sich bei pimcore um ein Content-Management-Framework handelt, das speziell für die Realisierung von professionellen und individuellen Lösungen entwickelt wurde, gibt es einige nennenswerte Unterschiede zu anderen gängigen CMS. Der größte Unterschied besteht sicherlich darin, dass es kein Out-of-the-box-System ist, das nur mit verschiedenen Plug-ins und Themes an die eigenen Bedürfnisse angepasst wird. Jeder der bereits sehr individuelle Websites mit jenen Systemen umgesetzt hat, kennt sicher die Probleme, die beim Anpassen von bestehenden Themens und Plug-ins warten. Oft bedeutet dies Abstriche bei Funktionen und Design oder bestehende Module müssen zeitintensiv erweitert werden, wodurch sie dann oft auch die Updatefähigkeit verlieren. Pimcore setzt genau hier an und verspricht dadurch, den Workflow eines gesamten Projekts zu vereinfachen. So muss z. B. bei der Konzeption nicht auf die Funktionalitäten von bestehenden Plug-ins und Erweiterungen geachtet werden. Das Design wird ohne Rücksicht auf vorgegebene Layoutelemente oder Komponenten entwickelt und kann dann mit beliebigen Frontend-Technologien in HTML/CSS und JavaScript mit eigenem HTML-Markup umgesetzt werden, bevor dieses dann in pimcore integriert wird.

Einen kleinen Haken hat die Sache allerdings, da pimcore auf dem Zend Framework aufbaut, sollte man für anspruchsvolle Implementierungen sehr gute Kenntnisse in objektorientierten PHP und den gängigen MVC-Frameworks haben, um schnell ans gewünschte Ziel zu gelangen.

Vorbereitungen und Installation

Um die Beispieldaten von pimcore zu installieren, benötigt man erst eine lokale Entwicklungsumgebung oder einen entsprechenden Webspace mit mindestens PHP 5.4 und MySQL 5.5 – detaillierte Informationen zu den Systemvoraussetzungen befinden sich auch im Wiki der Projektseite und können später auch noch direkt während der Installation geprüft werden. In den folgenden Schritten wird von einem lokalen Webserver (http://localhost) ausgegangen. Als Nächstes werden die Beispieldaten (pimcore.org/download) benötigt, nach dem Download wird das ZIP-Paket einfach im Document-Root entpackt. Anschließend kann der Installer bereits mit http://localhost/ im Browser aufgerufen werden. Für die Installation wird eine MySQL-Datenbank benötigt, die vorweg noch mittels create database ‚pimcore-demo‘ charset=utf8; erstellt werden muss. Im Installer müssen nun nur noch die benötigten Felder für die MySQL-Verbindung und die gewünschten Adminzugangsdaten ausgefüllt werden. Bevor man die Installation startet, sollte man noch mit einem Klick auf „Check Requirements“ die Systemvoraussetzungen prüfen lassen. Gibt es bei der Prüfung keine rot markierten Einträge, ist alles in Ordnung und die Installation kann durchgeführt werden. Nach der Installation kann man sich mit den angegebenen Login-Daten bereits im Backend unter http://localhost/admin/ einloggen und sich ein Bild von der Adminoberfläche machen. Im Frontend unter http://localhost/ sollte eine Beispielseite angezeigt werden, und man kann sich durch die verschiedenen Beispiele klicken.

Die Ordnerstruktur

Bevor man loslegt, ist es wichtig, zu wissen, wo welche Dateien liegen und was welche Funktion hat. Pimcore setzt direkt auf das ZF (Zend Framework 1) auf – jemand, der Erfahrungen mit diesem Framework hat, wird mit der Ordnerstruktur auf Anhieb vertraut sein. Im Document-Root befinden sich nach der Installation drei Ordner, eine index.php (Bootstrapping) und eine .htaccess. Der Ordner /pimcore beinhaltet alle für pimcore notwendigen Bibliotheken sowie auch die ZF-Module für das Admininterface und darf unter keinen Umständen modifiziert werden. In /plugins können eigene Plug-ins installiert oder welche aus dem Plug-in-Hub heruntergeladen werden. Plug-ins sind wiederrum auch nur ZF-Module, die zusätzlich initialisiert werden. Am wichtigsten ist der /website-Ordner, der natürlich auch wieder ein ZF-Modul ist. Dies ist der Bereich, in dem die Implementierung der Website bzw. Applikation gemacht wird. Darin befindet sich ein Ordner für die Controller der Website (/controllers), die Viewskripte (/views) sowie auch Platz für eigene Modelle (/models) und Bibliotheken (/lib), die automatisch geladen werden, wenn diese mit PSR-0 kompatibel sind. Zusätzlich können auch statische Daten wie Grafiken, Style Sheets und JavaScripts direkt im Websiteordner (/static) abgelegt werden, dies ist allerdings kein Muss, sondern nur eine Empfehlung – da die Einbindung ohnehin manuell direkt im Template gemacht wird, spielt es keine Rolle, wo sich diese befinden.

Editierbare und frei gestaltbare Seiten

In pimcore werden editierbare Seiten Dokumente genannt, diese sind neben der Mediendatenbank (Assets) und den Datenobjekten (Objects) eines der Hauptmodule von pimcore. Dokumente werden dazu verwendet, um klassische seitenbasierte Websites in einer Baumstruktur zu erstellen, dazu stehen mehrere Typen von Dokumenten zur Verfügung, die die Arbeit mit den verschiedenen Inhalten erleichtern. Am wichtigsten ist der Typ Page, dieser stellt eine normale Seite dar, daneben gibt es noch so genannte Snippets für geteilte Inhalte wie Teaser und Sidebars sowie Ordner, Links, E-Mails und Hardlinks. Letztere dienen nur zur Organisation, haben eine definierte Funktion und können nicht mit eigenen Funktionalitäten belegt werden. Pages und Snippets dagegen haben immer einen Controller und eine Action zugewiesen sowie ein optionales Template (View) für den Fall, dass sich der Pfad zur View nicht automatisch aus Controller/Action ergibt oder man eine Action mit verschiedenen Views verwenden möchte. Mit diesem System im Hintergrund lassen sich also auch in einem CMS die eigene Logik und Funktion optimal von der Darstellung trennen.

Erstellen eines eigenen Inhaltstyps

Um einen eigenen Inhaltstyp zu erstellen, legt man als Erstes einen neuen Controller an, den wir in diesem Beispiel Topic nennen. Natürlich könnte man dazu auch einen bestehenden Controller um eine Action erweitern. Wir erstellen nun aber eine neue Datei bzw. Controller unter /website/controllers/TopicController.php mit folgendem Inhalt:

<?php
class TopicController extends Website_Controller_Action {
  public function exampleAction() {
  }
}

Die Controller sind übliche ZF-Controller und sollten sich von der Klasse Website_Controller_Action ableiten, die pro Projekt angepasst werden kann und sich in letzter Instanz von Zend_Controller_Action ableitet. Damit können alle Action Helper und andere Funktionen, die vom ZF-MVC bereitgestellt werden, problemlos in den Actions verwendet werden. So könnte man z. B. den JSON Action Helper dazu verwenden, um alle Inhalte eines Dokuments oder Objekts per JSON auszugeben. In diesem Beispiel befindet sich bereits eine Action namens example im Controller, solange keine zusätzliche Funktionalität benötigt wird, kann die Action vorerst leer bleiben. Nun wird noch ein passendes Template zu der Action benötigt, dazu muss man folgende Datei erstellen: /website/views/scripts/topic/example.php. Die Ordnerstruktur für die Views ergibt sich aus den ZF-Richtlinien und folgt dem einfachen Schema controller/action.php.

In das Template kopieren wir das bereits vorbereite Bootstrap-HTML-Markup, das aus einer Überschrift, einem Bild und drei Spalten Text besteht (Listing 1).

Listing 1
<div class="page-header">
  <h1>Text</h1>
</div>
<section>
  <img src="http://placehold.it/750x150" />
</section>
<div class="row">
  <div class="col-md-4">Text</div>
  <div class="col-md-4">Text</div>
  <div class="col-md-4">Text</div>
</div>

Um den Text und das Bild im Markup editierbar zu machen, müssen von pimcore bereitgestellte Platzhalter verwendet werden, die so genannten Editables. Diese Editables sind normaler PHP-Code und können so einfach wie ZF-View-Helper verwendet werden. Es stehen für alle gängigen Datentypen Editables zur Verfügung. Eine Übersicht findet man in der Projektdokumentation.

Ein Editable besteht immer aus dem Typ, einem eindeutigen Namen und einer optionalen Konfiguration:

<?= $this->wysiwyg("myName", array()); ?>

In diesem Beispiel ist wysiwyg der Typ, myName der Name und array() die Konfiguration, die auch einfach weggelassen werden kann.

Für unser Template verwenden wir vorerst nur den WYSIWYG-, IMAGE- und INPUT-Platzhalter, wir ersetzen nun also Text und den <img>-Tag mit unseren Platzhaltern, sodass das Template dann wie in Listing 2 aussieht.

Listing 2
<div class="page-header">
  <h1><?= $this->input("headline"); ?></h1>
</div>
<section>
  <?= $this->image("myImage"); ?>
</section>
<div class="row">
  <div class="col-md-4"><?= $this->wysiwyg("myName1"); ?></div>
  <div class="col-md-4"><?= $this->wysiwyg("myName2"); ?></div>
  <div class="col-md-4"><?= $this->wysiwyg("myName3"); ?></div>
</div>

Da es sich bei den Platzhaltern um normales PHP handelt, können wir das Template auch noch vereinfachen, und die drei Spalten mit identischem HTML-Code in eine for-Schleife packen. Die vereinfachte Version würde dann wie in Listing 3 aussehen.

Listing 3
<div class="page-header">
  <h1><?= $this->input("headline"); ?></h1>
</div>
<section>
  <?= $this->image("myImage"); ?>
</section>
<div class="row">
  <?php for ($i=1; $i<=3; $i++) { ?>
    <div class="col-md-4"><?= $this->wysiwyg("myName" . $i); ?></div>
  <?php } ?>
</div>

Damit haben wir schon ein einfaches und editierbares Template, mit dem wir bereits eine neue Seite im pimcore-Backend erstellen könnten. Um es für einen Redakteur einfacher zu machen, erstellen wir im Backend erst noch einen neuen vordefinierten Dokumententyp, damit dieser nicht mit Controller und Actions in Berührung kommt. Dazu klicken wir auf Setting | Document Types und anschließend auf ADD. In dem neu erstellten Eintrag vergeben wir nun einen Namen für den Dokumententyp z. B. Topic Example und füllen die Felder Controller und Action entsprechend mit topic und example aus. Die fertige Konfiguration sollte nun wie in Abbildung 1 aussehen.

Abb. 1: Dokumententypen

Abb. 1: Dokumententypen

Nun kann man im Dokumentenbaum mit einem Rechtsklick auf /EN dann Add Page | Topic Example eine neue Seite des neuen Dokumententyps anlegen. Nach der Eingabe eines Keys sowie des Namens/Titels (für die Navigation und den <title>-Tag) und anschließender Bestätigung öffnet die neue Seite automatisch. Im Tab Edit können wir nun sehen, dass fünf editierbare Felder untereinander angezeigt werden: ein Eingabefeld, ein Bildplatzhalter und drei WYSIWYG-Felder. Es ist nun schon möglich, die Felder mit Inhalten zu füllen und die Seite zu speichern und zu veröffentlichen. Danach ist die Seite auch schon über das Frontend abrufbar, die Adresse entspricht dem Pfad im Baum, z. B. http://localhost/en/example. Die neue Seite sollte sich auch schon in der Navigation der Startseite befinden.

Natürlich macht dieses Beispiel jetzt noch nicht viel Sinn, es fehlt noch das komplette Layout rundherum und die drei Texte sollten in Spalten nebeneinander angezeigt werden. Da das HTML-Markup in unserem Template bereits den von Bootstrap bereitgestellten Spalten entspricht, müssen wir nur noch ein Layout mit den Bootstrap-Styles um das neue Template laden.

Dazu wird vom ZF eine Layout-Engine bereitgestellt, die, nachdem die View gerendert worden ist, das gewünschte Layout um das Template legt. Ein Layout ist ebenfalls ein ganz normales Viewskript, in dem auch die pimcore Editables verwendet werden können. Zusätzlich befindet sich in einem Layout noch ein Platzhalter (<?= $this->layout()->content ?>), damit der Renderer weiß, wo die Inhalte in der View einzufügen sind.

Für dieses Beispiel verwenden wir das von den Beispieldaten bereitgestellte Layout. Um dieses zu laden, muss erst die Layout-Engine aktiviert werden, was in der Action mit dem einfachen Aufruf von $this->enableLayout(); gemacht wird. Die Action sieht nun also wie folgt aus:

public function exampleAction() {
  $this->enableLayout();
}

Das wars auch schon: Die Layout-Engine verwendet automatisch das Standardlayout in /website/views/layout/layout.php, das von den Beispieldaten bereits befüllt ist. Möchte man ein anderes Layout verwenden, z. B. custom.php, kann dies direkt in der entsprechenden View mit folgendem Code umgestellt werden:

<?php $this->layout()->setLayout("custom"); ?>

Für dieses Beispiel belassen wir es aber bei der bereits fertiggestellten und funktionierenden layout.php aus den Beispieldaten.

Zurück im pimcore-Backend können wir nun mit einem Klick auf „Reload“ im Tab „Edit“ die Seite neu laden. Nun sollte unser Template von einem Layout umgeben sein und die drei WYSIWYG-Felder sind in drei Spalten nebeneinander (Abb. 2).

Abb.2: Template mit Layout

Abb.2: Template mit Layout

Zusätzlich können wir sehen, dass auch vom Layout zwei Platzhalter im Headerbereich für einen Claim bereitgestellt werden. Zum Bearbeiten der Textfelder klickt man nun einfach in die entsprechenden Felder. Das Bildfeld befüllt man, indem man ein Bild aus dem Baum im Asset-Modul auf den Platzhalter zieht, analog dazu funktioniert auch das Einfügen eines Bilds in den WYSIWYG oder das Verlinken eines Texts. Zusätzlich hat jedes Feld auch noch ein Kontextmenü, das weitere Optionen, wie z. B. eine Suche, bereitstellt.

Die Bilder werden nun noch nicht automatisch verkleinert, sondern als Original eingebunden. Damit dies geschieht, muss man erst noch eine Thumbnail-Konfiguration erstellen. Dazu öffnet man im pimcore-Backend die Thumbnail-Verwaltung unter Setting | Thumbnails | Image Thumbnails. Darin kann man individuelle Thumbnail-Konfigurationen erstellen, die auch mehrere nacheinander abzuarbeitende Transformationen unterstützten. So lassen sich z. B. auch Bildtransformationen beliebig miteinander kombinieren. Durch die Beispieldaten existieren bereits einige Konfigurationen, die wir für dieses Beispiel einfach weiterverwenden können. Ein Thumbnail weist man einem IMAGE-Editable über die optionale Konfiguration zu, z. B.:

<?= $this->image("myImage", array("thumbnail" => "exampleCover")); ?>

Nun möchte man dem Redakteur z. B. auch noch die Möglichkeit geben, beliebig viele Bilder untereinander einzufügen und zusätzlich noch jeweils ein fixes Bild ganz oben in den drei Textspalten. Für Ersteres verwenden wir das spezielle Editable BLOCK, das wir in einer normalen while-Schleife um das IMAGE-Editable legen. Für die drei zusätzlichen Bilder über den WYSIWYG-Feldern fügen wir einfach zusätzlich ein IMAGE-Editable innerhalb der for-Schleife ein. Das Template sieht nun also aus wie in Listing 4.

Listing 4
<div class="page-header">
  <h1><?= $this->input("headline"); ?></h1>
</div>

<?php while($this->block("myImages")->loop()) { ?>
  <section>
    <?= $this->image("myImage", array("thumbnail" => "content")); ?>
  </section>
<?php } ?>

<div class="row">
  <?php for ($i=1; $i<=3; $i++) { ?>
    <div class="col-md-4">
      <p>
        <?= $this->image("colImage".$i, array("thumbnail" => "exampleCover")); ?>
      </p>
      <?= $this->wysiwyg("myName" . $i); ?>
    </div>
  <?php } ?>
</div>

Die while-Schleife mit dem BLOCK-Element generiert nun im Editiermodus einen Button, mit dem man beliebig viele Bilder einfügen kann. Alles, was sich innerhalb der while-Schleife des BLOCK-Elements befindet, wird entsprechend der Anzahl der hinzugefügten Blöcke wiederholt. Die fertige und befüllte Seite sollte nun in etwa wie in Abbildung 3 aussehen.

Abb. 3: Einfaches Template

Abb. 3: Einfaches Template

Dynamische Inhaltsblöcke

Das aktuelle Template kann nun schon gut bearbeitet werden, allerdings ist der Redakteur auf ein fixes Layout fixiert und kann den Inhalt nicht frei aus individuellen Inhaltsblöcken zusammenstellen. Um dies zu ermöglichen, gibt es ein spezielles Editable, den AREABLOCK. Die Funktion des AREABLOCK ist sehr ähnlich zum BLOCK-Element, und grundsätzlich ließe sich die Funktion damit auch umsetzen, allerdings macht es der AREABLOCK in vielerlei Hinsicht einfacher.

Wir wollen nun also unseren dreispaltigen Text in einen dynamischen Inhaltsblock, genannt Area-Brick umwandeln. Dazu nehmen wir im ersten Schritt den Code aus dem Template und ersetzen ihn mit dem AREABLOCK-Editable. Das Template sieht nun wie folgt aus:

<div class="page-header">
  <h1><?= $this->input("headline"); ?></h1>
</div>

<?= $this->areablock("contentblocks"); ?>

Anschließend erstellen wir einen neuen Area-Brick. Dieser befindet sich in /website/views/areas, wo sich bereits einige von den Beispieldaten befinden.

Im ersten Schritt erstellen wir einen neuen Ordner, dessen Namen der ID des neuen Bricks entspricht – in diesem Beispiel text3columns. Ein Brick muss immer mindestens zwei Dateien beinhalten: area.xml und view.php. Die area.xml beinhaltet Metadaten und würde für dieses Beispiel so aussehen wie in Listing 5.

Listing 5
<?xml version="1.0"?>
<zend-config xmlns:zf="http://framework.zend.com/xml/zend-config-xml/1.0/">
  <id>text3columns</id>
  <name>3 Spalten</name>
  <description></description>
</zend-config>

Bei der view.php handelt es sich wiederrum um ein ganz gewöhnliches Viewskript. Wir können dieses also einfach mit dem bereits vorhin verwendeten Code für die drei Spalten befüllen (Listing 6).

Listing 6
<div class="row">
  <?php for ($i=1; $i<=3; $i++) { ?>
    <div class="col-md-4">
      <p>
        <?= $this->image("colImage".$i); ?>
      </p>
      <?= $this->wysiwyg("myName" . $i); ?>
    </div>
  <?php } ?>
</div>

Damit ist der Area-Brick fertig. Da es sich dabei um eine Extension handelt, muss dieser nur noch im Extension-Manager aktiviert werden, um im AREABLOCK verwendet werden zu können. Dazu muss man unter Extras | Extensions | Manage Extensions den entsprechenden Eintrag mit dem neuen Area-Brick aktivieren.

Nun können wir unsere Seite im Editiermodus wieder neu laden. Auf der linken Seite sollte nun eine Toolbar erscheinen und die Inhalte von vorher sollten verschwunden sein (Abb. 4). In der Toolbar befinden sich alle Area-Bricks, die von den Beispieldaten kommen plus dem gerade eben neu erstellen 3-Spalten-Brick. Um diesen nun im Inhaltsbereich zu verwenden, zieht man den Button aus der Toolbar einfach auf einen der grün markierten Platzhalter. Die Platzhalter erscheinen erst, nachdem man mit dem Ziehen begonnen hat. Nun kann man alle verfügbaren Area-Bricks beliebig miteinander kombinieren und so den Inhalt frei anhand definierter Vorlagen gestalten, ohne dies in einem einzigen WYSIWYG-Editor machen zu müssen. Damit wird mitunter auch auf komfortable Art und Weise sichergestellt, dass CD-Richtlinien auch von den Redakteuren eingehalten werden.

Abb. 4: Das Area-Template

Abb. 4: Das Area-Template

Dynamische Eigenschaften

Oft ist es notwendig, Seiten zusätzliche Eigenschaften zu geben, um z. B. kleinere Änderungen am Layout oder der Funktion vorzunehmen, ohne einen gänzlich neuen Inhaltstypen zu erstellen. Ein weiteres Beispiel wäre die Vererbung von allgemeinen Inhalten wie Hintergrundbilder, Sidebars, Footer und der Navigation. Diese Inhalte sollte man idealerweise nicht auf jeder einzelnen Seite wieder von Neuem einfügen müssen. Da solche Einstellungen im eigentlichen Inhalt nicht passend wären, gibt es dafür die so genannten Properties.

Properties können frei oder aus vorher zu definierenden Voreinstellungen einem Dokument, Objekt oder Asset hinzugefügt werden. Unterstützt werden mehrere Datentypen wie Text, Boolean und Relationen zu anderen Entitäten sowie auch die Vererbung der Eigenschaften entlang des Baums. Die Vererbung erlaubt es damit relativ einfach, Vorgabewerte ganz oben im Baum zu vergeben, die dann individuell pro Bereich oder Seite vom Redakteur überschrieben werden können. Die Werte von Properties können dann in der Action oder in der View aus dem Dokumentenobjekt abgerufen werden.

Die Beispieldaten implementieren bereits einige Eigenschaften, so lässt sich damit z. B. festlegen, von wo aus im Baum die Navigation in der linken Sidebar aufgebaut werden soll, oder ob diese überhaupt angezeigt werden soll.

Für das Beispiel in Abbildung 5 nutzen wir die Properties, um festzulegen, welche Farbe die Überschrift haben soll. Dazu wechseln wir in dem oben erstellten Dokument in den Tab „Properties“ und legen anschließend eine neue Eigenschaft mit dem Namen headlineColor vom Typ TEXT an. Als Wert geben wir eine beliebige Farbe im Hex-Code mit vorangestellter Raute an.

Abb. 5: Die Properties

Abb. 5: Die Properties

Um das Property im Template abzurufen, benötigt man den folgenden Code:

<?= $this->document->getProperty("headlineColor"); ?>

$this->document beinhaltet immer das Objekt des aktuellen Dokuments, mit der Methode getProperty() können wir das gewünschte Property abrufen. Integriert in das Template sollte dies nun wie folgt aussehen:

<div class="page-header" style="color: <?= $this->document->getProperty("headlineColor"); ?>">
  <h1><?= $this->input("headline"); ?></h1>
</div>

<?= $this->areablock("contentblocks"); ?>

Die Farbe der Überschrift kann nun frei vom Redakteur geändert werden. Natürlich handelt es sich hierbei um ein sehr einfaches Beispiel, es sollte aber die Funktionsweise von Properties gut darstellen.

Inhalte für verschiedene Zielgruppen anpassen

Pimcore bietet für die Anpassung von Inhalten an verschiedene Zielgruppen sowie auch der direkten Personalisierung verschiedene Konzepte und Werkzeuge an. Im Folgenden sehen wir uns eine der einfacheren Anwendungen an. Ziel soll sein, den Inhalt der oben erstellen Seite für zwei unterschiedliche Zielgruppen zu individualisieren, und zusätzlich soll das System automatisch auf Grund der bereits besuchten Seiten oder eines definierten Referrers entscheiden, welcher Zielgruppe der aktuelle Besucher zuzuordnen ist.

Dazu müssen anfangs die zwei Zielgruppen (Personas) im Backend unter Marketing | Personalization/Targeting | Target Group angelegt werden. Für unser Beispiel erstellen wir die Zielgruppen PHP Coder und Designer. Für eine Zielgruppe kann man in diesem Schritt auch Eingangsbedingungen definierten – also Regeln, die beim ersten Kontakt mit dem Besucher geprüft werden, um diesen bereits beim Erstkontakt einer Zielgruppe zuzuordnen. Dafür stehen definierte Bedingungen zur Verfügung, die frei miteinander kombiniert und individuell angepasst werden können. So kann man z. B. aufgrund des Orts des Besuchers oder des Referrers entscheiden, welcher Zielgruppe der Besucher vermeintlich angehört.

Für unser Beispiel erstellen wir für die Zielgruppe PHP Coder zwei Bedingungen: eine, die den Referrer auf phpmagazin.de prüft und eine, ob das Betriebssystem Linux ist (Abb. 6). Die beiden Regeln werden per OR verknüpft. Für die Zielgruppe Designer benötigen wir vorerst keine Eingangsbedingungen.

Abb. 6: Bedienungen für unsere Zielgruppe

Abb. 6: Bedienungen für unsere Zielgruppe

Damit das System nun automatisch „lernen“ kann, müssen noch verschiedene Dokumentenseiten einer Zielgruppe zugewiesen werden. Dazu öffnet man ein paar bestehende Dokumente, im Tab „Settings“ kann dann im Bereich „Associate Target Group“ eine oder mehrere Zielgruppen dem Dokument zugewiesen werden. Jedes Mal, wenn nun ein Besucher eine jener Seiten besucht, wird dies lokal beim Besucher gespeichert. So kann im Hintergrund ein Profil des Besuchers erstellt werden und aufgrund verschiedener Algorithmen abgefragt werden, welche der definierten Zielgruppen am ehesten zu dem Besucher passt.

Ein wichtiger Punkt ist hier, dass alle Daten nur lokal im Browser als LocalStorage-Objekte gespeichert werden und alle Logik ebenfalls nur als clientseitiges JavaScript implementiert ist. Es werden also für das ganze Targeting keine Daten des Besuchers an den Server übertragen. Dies hat zwei Vorteile: zum einen den Datenschutz, da die gesammelten Daten immer nur beim Besucher im Browser bleiben, zum anderen ist für das Targeting keine serverseitige Session notwendig, was weiterhin exzessives Caching (z. B. mit Varnish) erlaubt.

Nun fehlen nur noch die individualisierten Inhalte auf unserer Beispielseite von oben. Dazu laden wir die Seite im Backend neu, im Tab „Edit“ ganz rechts gibt es nun eine Auswahl der Zielgruppen. Wir selektieren hier nun PHP-Coder. Die Seite im Editierfenster lädt neu und alle Felder sind nun ausgegraut. Nun kann mit der Individualisierung begonnen werden. Dazu klickt man mit der rechten Maustaste auf das Feld, das man bearbeiten möchte und anschließend auf „Overwrite“. Abbildung 7 zeigt das Resultat.

Abb. 7: Der auf die Zielgruppe angepasste Inhalt

Abb. 7: Der auf die Zielgruppe angepasste Inhalt

Somit kann man einzelne Felder überschreiben, während die anderen Inhalte von der Hauptversion unverändert übernommen werden. Die gleiche Prozedur kann man nun auch noch mit der Zielgruppe Designer machen.

Um nun das Targeting zu testen, muss man im Frontend einige der vorher zu Zielgruppen zugewiesenen Seiten besuchen, um Daten zu sammeln, und anschließend die gerade individualisierte Seite. Je nachdem, welche Zielgruppe nun relevanter ist, wird nun die abgeänderte Version der Seite entweder für PHP-Coder oder für Designer angezeigt.

Mit diesem flexiblen System und den weiteren Tools, die dafür zur Verfügung stehen, lassen sich sehr komplexe Anwendungsfälle realisieren. Denkbar sind z. B. gezieltes Marketing und Rabatte für wiederkehrende Besucher oder auch spezielle Aktionen für Besucher aus einer bestimmten geografischen Region.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -