Mich fragte neulich ein Kollege, ob ich ihm erklären könne, wie man den Audience Manager implementiert. Je länger ich darüber nachdenke, desto unschlüssiger bin ich, was die Implementierung eigentlich genau sein soll. Mittlerweile gibt es für den Audience Manager im einfachsten Fall gar keinen eigenständigen Basis Code mehr. „Die Implementierung“ als solches ist somit schwer zu definieren.  Wollen wir also über Implementierung im Sinne von Datensammlung sprechen, müssen wir unterscheiden, welche Daten und Systeme wir integrieren. Anfangen werde ich nun mit den Webanalyse-Daten, die in einer DMP die Datengrundlage bilden sollten.

Webanalyse-Daten ist eigentlich auch nicht der richtige Begriff. Ich werde von nun an einfach von Online-Verhaltensdaten sprechen, da wir im Notfall eigentlich kein Webanalyse-System wie Adobe Analytics oder Google Analytics benötigen, um die Daten in die DMP zu bekommen bzw. gar nicht direkt mit diesen Systemen integrieren können. Mehr dazu aber später. In den folgenden Sätzen gehe ich immer davon aus, dass der Audience Manager als DMP genutzt wird.

Adobe Analytics

Der einfachste Fall bei der Anbindung von Online-Verhaltensdaten stellt die Integration von Adobe Analytics mit dem Audience Manager dar. Dazu muss nur ein Javascript Modul (AppMeasurement_Module_AudienceManagement.js) in die s_code gesetzt werden. Es folgt ein Funktionsaufruf, der kunden- bzw. accountspezifische Parameter enthält. Der Code selbst ist dabei nicht mal für das Tracking (wenn man das so nennen kann) verantwortlich, sondern sorgt lediglich dafür, dass die ID Syncs zu den angebundenen Plattformen stattfinden (DSP, AdServer etc.). An dieser Stelle übrigens noch einmal einen herzlichen Dank an Jan Exner, der dies damals herausgefunden hat. Mir war das lange Zeit nicht bewusst.

Das „Tracking“ erfolgt bei der Integration mit Adobe Analytics server-seitig. Mit jedem Hit werden alle Variablen aus Analytics direkt an den Audience Manager weitergegeben.  Wir benutzen bei diesem Verfahren den Begriff „Server-side Forwarding“. Das ist schon ziemlich cool, weil es eine Reihe von Vorteile mit sich bringt:

• Weniger Pixel-Calls (HTTP Requests) auf der Seite verbessern die Ladegeschwindigkeit
• Die Datenweitergabe erfolgt nach dem Processing auf dem Analytics-Server, d.h. wenn ich meine Analytics-Daten nach dem Tracking noch manipuliere (z.B. dynamic Variables, Classification Rules), werden diese auch manipuliert an AAM übergeben
• Features wie Audience Analytics bauen auf Server Side Forwarding (SSF) auf.

Sobald der Code in der s_code gepublished ist, laufen die Daten im Audience Manager ein. Der Zeitaufwand ist gering und die Anzahl der verfügbaren Daten ist von Beginn an hoch: 1000 Events, 75 props, 200 eVars, wenn bereits ein ausreichendes Tracking vorhanden ist. Die Daten sind dann in real-time verfügbar.

Man muss dazu sagen, dass diese Form der Integration nur zwischen Adobe Analytics und dem Adobe Audience Manager besteht. Sobald eins der beiden Tools (andere DMP oder anderes Analyse-System) nicht vorhanden ist, wird die Integration direkt aufwändiger bei geringerer Datenqualität.

Dazu muss ich erwähnen, dass dieses Feature „erst“ seit knapp 2 Jahren verfügbar ist. Wer also noch die alte Integration mit DIL (client-seitiges Javascript, dass den Analytics-Call quasi kopiert und als Pixel-Call an AAM übergibt) benutzt, sollte dringend überlegen, auf SSF umzustellen.

Google Analytics

Wie schon gesagt, existieren neben der Adobe Analytics-Audience Manager Integration keine direkten Integrationen zwischen Analyse-System und DMP auf dem Markt. Verwendet man Google Analytics, kann man sich zwar einer bestimmten Javascript-Funktion bedienen, die bestimmte Daten zurückgibt. Wirklich ergiebig ist dies jedoch nicht, sodass die Verwendung der Funktion nicht ausreichen sollte, um notwendige Daten in die DMP zu bekommen.

Wer Google Analytics benutzt, kann es ja einfach mal ausprobieren und in der Console ga.getAll() aufrufen und schauen, was zurückkommt. Hier ein Beispiel, was die Funktion zurückgibt, wenn ich sie auf einer Produktdetailseite eines Fiat 500 auf http://www.mobile.de in der Console ausführe:

Im Gegensatz zu 200 eVars, 200 Events und 1000 möglichen props in Adobe Analytics (einfachster Fall) kann man schnell erkennen, wie limitiert die Datengenerierung über Google Analytics ist. Google macht dem Namen „Walled Garden“ alle Ehre. Da geht zwar viel rein, aber wenig wieder raus.

Integrieren wir den Audience Manager mit Google Analytics erfordert dies entgegen der oben beschriebenen Vorgehensweise mit Adobe Analytics einen Javascript-Code (DIL Code), den man dahingehend anpasst, dass er diese Funktion aufruft und die Daten aus der Funktion dann über einen Tracking-Call (HTTP Request) an den Audience Manager weitergibt. Ob andere Hersteller im Falle einer Verwendung von Google Analytics auch so arbeiten, kann ich nicht sagen. Allerdings weiß ich, dass Google selbst nur diese Möglichkeit bietet.

Wem die Daten via ga.getAll() nicht ausreichen, muss auf die Art der Integration ausweichen, die wir für alle sonstigen Analyse-Systeme auch empfehlen: Tracking über Data Layer!

Data Layer

Diesem Thema könnte ich eigentlich auch einen eigenen Beitrag widmen. Da ich hier aber nicht allzu weit ausholen möchte, verweise ich einfach auf den Data Layer nach W3C Standard. Ich empfehle die Erstellung eines Data Layers grundsätzlich für alle Webseiten, die in irgendeiner Form getrackt werden müssen. Wer dies heute noch nicht tut, sollte spätestens mit der Einführung einer DMP darüber nachdenken.

Die meisten DMPs auf dem Markt – und vor allem die, die keine direkte Integration mit einem Analytics-Tool haben – holen sich die Verhaltensdaten aus dem Data Layer einer Seite. In den meisten Fällen existiert dabei dann doch ein Basiscode für die DMP, den man so anpassen muss, dass er sich alle Daten aus dem Layer zieht und auch dynamisch trackt, sobald sich die Daten im Layer verändern. Dieses Verfahren ist ein bisschen aufwändiger. Deswegen verzichte ich in diesem Zug auf die Erklärung des Ganzen. Jedenfalls wird in diesen Fällen  direkt ein Tracking-Call (HTTP Request) initialisiert. Passiert auf der Seite relativ viel, kann das natürlich auch gerne mal in einem Tracking-Gewitter enden, das die Performance der Seite dann unter Umständen auch in die Knie zwingt. Ach, man sollte schnell erkennen, wie vorteilhaft eine direkte Server-Kommunikation doch sein kann, um genau dies zu vermeiden.

Normalerweise nutzt man auch Data Layer für das Tracking eines Analytics-Tools, sodass wir hier dann nicht von einem direkten Zusammenspiel von Analytics-Tool und DMP reden, sondern der Data Layer sozusagen als Mediator dient. Dies ist zwar nicht Best Practice aber dann doch die übliche Vorgehensweise bei DMPs anderer Hersteller als Adobe.

Damit ist „die Implementierung“ zwar noch nicht vollständig, weil man die Daten ja auch irgendwo hinschicken möchte. Aber wir haben schon mal die Daten im System. Ich würde jetzt empfehlen, entweder über den Import von CRM-Daten nachzudenken oder einfach auf Basis der Online-Daten schon mal erste Segmente zu bauen und dann eine DSP auszusuchen, die wir integrieren.  Mir würde das als Erstes erstmal reichen. Deswegen werde ich wohl zuerst auf die DSP Integration eingehen, bevor ich mich mit CRM-Daten befasse.