Im
allerersten Beitrag habe ich einige der Fragestellungen angesprochen, die einen Performance-Marketing-Analysten heute interessieren. Die Komplexität dieser Anforderungen bringt es mit sich, dass ein einfaches, tabellen-basiertes Reportingsystem nicht mehr ausreicht. Antworten ziehen unweigerlich Folgefragen nach sich, die nur durch Rückgriff auf die aufbereiteten Detaildaten beantwortet werden können.
Was sind aufbereitetete Detaildaten? Das heißt, dass jedes einzelne Trackingereignis noch aufrufbar sein soll, man möchte also möglichst nicht aggregieren. Jedoch sollen die Daten bereinigt und auf einen gemeinsamen Nenner gebracht worden sein. Allein schon dieser Schritt kann aufwendig umzusetzen sein, gerade wenn man Daten aus verschiedenen Quellen zusammenführt. Dies ist aber im Onlinemarketing regelmäßig der Fall. Hinzu kommt, dass die Datenlandschaft vergleichsweise schnell evolviert. Ein Vermarktungspartner ändert seine Datenmodellierung, oder es kommt ein ganz neuer Partner hinzu.
Gefragt ist also die Mächtigkeit einer Data-Warehouse-Architektur und die Flexibilität, schnell Änderungen an der Datenmodellierung selbst vorzunehmen. Außerdem entstehen ganz eigene Anforderungen an die Visualisierung der Ergebnisse. (Dieses Thema ist aber schon an sich so komplex, dass ich es demnächst in einem eigenen Beitrag behandeln möchte.) Wie bekommt man diese Anforderungen unter einen Hut?
Exkurs in die GeschichteErinnern wir uns an die Phase Ende der Neunziger. Man war damals darauf gekommen, dass man Unternehmensdaten gut in verallgemeinerten, mehrdimensionalen "Würfeln" darstellen kann. Ein Bericht über einen bestimmten Zeitraum oder Geschäftsbereich ist dann gleichsam eine Schnittebene durch den Würfel. Die damalige Hardware war jedoch nicht leistungsfähig genug, um solch einen Würfel in seiner Gesamtheit zu erfassen und zu analysieren.
Eine mögliche Lösung bestand darin, mit verkleinerten Teilwürfeln zu arbeiten, die entweder den Analysebereich (quantitativ) oder die Analysemöglichkeiten (qualitativ) einschränkten. Das führte zu überaus komplexen Modellierungsvorgängen, um alle Anforderungen abzubilden.
Pioniere wie Ralph Kimball entwarfen multidimensionale Datenmodelle auf der Basis relationaler Datenbanksysteme, die diese Schwierigkeit umgehen sollten. Dieser Ansatz führt jedoch bei großen Datenmengen zu vergleichsweise langen Antwortzeiten.
Beiden Ansätzen ist gemeinsam, dass die Projekte zur Umsetzung der Anforderungen oft teuer und langwierig waren. Und während das Geschäftsmodell eines, sagen wir, Kaufhauses sich über die Zeit hinweg nur wenig ändert, ist die Online-Branche schnelllebiger.
Was tun?Was gebraucht wird, ist also ein zügiges Deployment und schnelle Reaktion auf neue Anforderungen sowie Tools und Architekturen, die dies gestatten.
Moderne In-Memory-Analysetools wie
QlikView oder
Panoratio ermöglichen es, große Datenbestände in detaillierter Form im RAM eines entsprechend dimensionierten Servers vorzuhalten. Diese Werkzeuge bringen Möglichkeiten zur Datenmodellierung und zum Data Cleansing mit sich, die auch von einem versierten Fachanwender eingesetzt werden können.
Die Projektplanung muss sich von der Idee monolithischer Projekte verabschieden, deren Umfang und Ziele von Anfang an festgelegt werden. An deren Stelle tritt eine Projektmethode, die seit einigen Jahren als
Agile Programming in der klassischen Anwendungsentwicklung große Erfolge gezeigt hat. Dabei werden in kurzen Zyklen die Anforderungen jeweils neu festgelegt. Als Basis dienen dabei sogenannte User Stories, die direkt im Gespräch mit Fachanwendern erfragt werden. Solch eine User Story ist immer auf die Rolle des Fragenden bezogen und umreißt neben dem gewünschten Ergebnis auch den Nutzen, den dieses Ergebnisses für den Fragenden haben soll.
