qrios

Die meisten Nutzer von Web-Analytics-Lösungen sind früher oder später vom Output ihrer Tools desillusioniert. Oft wegen der Zahlen selbst, aber häufiger ob der (geringen) Aussagefähigkeit der Kurven, Torten und Tabellen. Die versprochenen “Insights” verstecken sich in einem Wust banaler, irrelevanter und teils absurder Aussagen. Was wäre, wenn ein Automat die wichtigen von den unwichtigen Bezügen trennen könnte? Wäre Artificial Intelligence also Machine Learning dazu in der Lage?

Zu viele Fragestellungen an Web-Analyse-Tools

Die meisten Lösungen für Web-Analytics decken ein zu großes Zielpublikum ab. Marketingabteilung, HR, Vertrieb und Support stellen meistens sehr unterschiedliche Fragen an die Tools. Bei vielen Kunden wird dann nur ein geringer Teil des tatsächlich Möglichen implementiert und alle Abteilungen erhalten wesentlich weniger “Insights” als ursprünglich erwartet.

Für alle Abteilungen einer mittelständischen Firma könnte eine wichtige Fragestellung an ein Web-Analyse sein: Wie viele Besucher, die auf der Suche nach einer spezifischen Information (z.B. Stellenanzeige, Produktdokumentation oder Ansprechpartner) sind, finden diese Information nicht. Eine klassische Lösung kann diese Frage nicht beantworten. Der Nutzer müsste sich komplexe Filter zusammenbauen und würde dennoch nur eine Teilantwort erhalten. Mit Hilfe von Machine Learning wäre diese Frage beantwortbar.

Konfiguration eines Netzes

Im Gegensatz zu typischen Anwendungen wie beispielsweise Bild- oder Spracherkennung stellt sich bei der Web-Analyse eine besondere Hürde für die Verwendung eines neuronalen Netzes: die Anzahl der Parameter für den Input ist im Prinzip unbegrenzt. Zu einer User-Session gehören grundsätzlich neben den aufgerufenen Seiten und dem Referrer alle Eigenschaften des Netzes wie des Browsers.

Diese Parameter sind jedoch variabel. D.h. dass beispielsweise Referrer sich im Laufe sehr kurzer Zeit verändern, ebenso wie die User-Agent-Strings oder die (möglicherweise anonymisierte) IP. Einige dieser Parameter komplett zu ignorieren würde jedoch viele mögliche Aussagen (z.B. “Stellensuche funktioniert nicht mit Safari”) im Vorfeld ausschliessen.

Der Umgang mit den Parametern – das Encoding – bestimmt die Art und vor allem Größe des verwendeten Netzes. In den Daten gibt es grundsätzlich zwei verschiedene Arten von Daten. Fast alle Daten lassen sich in der Form key=value aufbereiten. Dabei lassen sich alle Values gruppieren (z.B. Browser=Safari|Firefox|Chrome…). Im Prinzip sind damit auch die Timestamps modellierbar.

Ausgehend vom ImageNet erschien allerdings ein anderer Ansatz zielführender. Betrachtet man die für das Training verwendeten Bilder, so enthalten sie natürlich zuerst die Bilddaten selbst. Darüber hinaus ist jedes Bild jedoch auch mit Metadaten qualifiziert. D.h. wenn auf einem Bild eine Axt zu sehen ist, dann enthält die Beschreibung diese Information zusammen mit den Koordinaten.

Der ImageNet (2011) Browser für die Beispielbilder (Quelle: http://imagenet.stanford.edu/synset?wnid=n02764044 )

Jedes Bild kann also verschiedene Objekte enthalten. Bezogen auf Web-Tracking-Daten heisst das: jede Session kann verschiedene Objekte enthalten. Und Objekte können dann Attribute wie Referrer, PageImpressions oder Zeitangaben sein.

Unter der Voraussetzung, dass das Netz korrekt trainiert wird kann es dann aus den Live-Daten direkte Aussagen über die Intention eines Nutzers machen. Etwa: Nutzer sucht eine Stelle in München oder Dokumentation für Produkt XYZ wird von 300 Usern gesucht.

Allerdings:

Das Problem bei dieser Vorgehensweise ist das Problem jedes Trainings-Encodings: Wie kann man eine große Anzahl bestehender Daten mit der notwendigen Metainformation versehen? In einem konkreten Fall hatten wir tausende User-Sessions, die klassifiziert werden sollten. Aber woher soll das Netz wissen, dass der eine Nutzer nach einer Stelle in Freiburg gesucht hat und der nächste ein PDF über ein Produkt von vor zwanzig Jahren suchte? Der Aufwand für diese Klassifizierung wäre signifikant aufwändiger als die Web-Analyse selbst.

Als – funktionierender – Workaround bot sich die dynamische Generierung eines Samplesets an. Mit Hilfe von Zufallszahlen wurden insgesamt 5080 theoretisch mögliche Sessions generiert. Dabei wurde auf ein Set von realen Werten für die Parameter (z.B. Referrer, Browser, etc.) aus den Log-Files zurückgegriffen. Bestimmte Schlüssel wie Stellensuche oder Supportanfrage wurden als Metainformationen hinzugefügt.

Als Testset kamen lediglich 605 vorher ausgewählte Sessions, die manuell klassifiziert wurden. Um den Aufwand dafür zu minimieren, mussten in dem eingesetzten Tool (Google Analytics) verschiedene Filter erstellt werden. Die gefilterten Events wurden exportiert und mit Python in das Eingabeformat (HDF5) für das verwendete Netz konvertiert.

Gewichtete Klassifizierung auf Basis realer Daten nach dem Training

Ergebnis

In der Analyse der Ergebnisse zeigte sich, dass es sich das Netz bei vielen Klassifizierungen “zu leicht” macht. Es kann – wie zu erwarten – keine Userabsichten erkennen, die nicht im Rahmen des Trainings angelegt wurden. Diese Tatsache ist selbstverständlich der vereinfachten Generierung der Trainingsdaten geschuldet. Für ein mittelständisches Unternehmen wäre jedoch ein höherer Aufwand nicht zu vertreten gewesen.

Als nicht erwarteten Erfolg zeigte sich, dass das Netz viele Sessions mehreren Intentionen zuordnen konnte. User, die von einer Job-Site kamen (also eindeutig klassifizierbar waren), informierten sich oft auch über spezifische Produkte. Das wären in einer üblichen Web-Analyse Sessions, die von einem falschen Filter erfasst würden.

Das Netz war mit nur 6 hidden Layers (u.a. Sigmoid, Hyperbolic Tangent, BNLL) sehr knapp designed. Die Kalkulation ist mit CUDA auf einer älteren GeForce-Karte in Caffe umgesetzt und benötigt weniger als 50ms/Record. Effektiv wäre es damit sogar möglich, in akzeptabler Zeit, Einfluss auf die Inhalte einer Seite zu nehmen.