Schlagwort: personas

Veröffentlicht am

Datengetriebene Personas mit Assoziationsregeln

Über Personas habe ich mich ja schon an anderer Stelle ausgelassen, in diesem Artikel geht es um die datengetriebene Generierung von Personas. Ich halte mich an die Definition des Persona-Erfinders Cooper und sehe eine Persona als Prototyp für eine Gruppe von Nutzern. Dies kann auch fürs Marketing interessant sein, denn schließlich lässt dich damit eine bedürfnis- und erfahrungsorientierte Kommunikation zum Beispiel auf einer Webseite erstellen. Personas sind keine Zielgruppen, aber dazu an anderer Stelle mehr.

Wie erstellt man eine datengetriebene Persona?

Den perfekten allgemeingültigen Weg für datengetriebene Personas habe ich auch noch nicht gefunden. Externe Daten sind nicht für alle Themen vorhanden, der ursprüngliche Ansatz von 10-12 Interviews schwierig, und interne Daten haben den Nachteil, dass sie ja nur die Daten derjenigen beinhalten, die man schon kennt, nicht derjenigen, die man vielleicht noch erreichen möchte. Die Wahrheit liegt im Zusammenlegen verschiedener Datenquellen.

Datengetriebene Persona meets Webanalyse

Webanalyse-Daten bieten einiges an Nutzungsverhalten, und je nachdem wie eine Seite aufgebaut ist (zum Beispiel ob sie schon auf die verschiedenen Bedürfnisse unterschiedlicher Personas ausgerichtet ist), lässt sich nachvollziehen, inwieweit sich die verschiedenen Nutzergruppen tatsächlich wie erwartet verhalten. Oder man versucht daten-getriebene Personas aus dem Nutzungsverhalten auf der Webseite zu generieren. Alles unter der Einschränkung, dass die Nutzer die Seite ja erst einmal finden müssen, es ist also nicht sicher, dass wirklich alle Personengruppen tatsächlich auf diese Seite zugreifen und deswegen wichtige Personas übersehen werden. In diesem Artikel geht es um einen Spezialfall dieser automatisierten Persona-Generierung aus Webanalyse-Daten, der aus algorithmischer Sicht und der dazugehörigen Visualisierung spannend ist. Über Erfolge berichtet bekanntlich jeder gerne, hier mal ein Fall, wo der Misserfolg zeigt, in welche Richtung weitere Arbeit gehen könnte.

Die Erfahrungen aus dem Web Mining werden nur selten mit Personas in Verbindung gebracht, obwohl schon vor mehr als 10 Jahren einiges an Forschung dazu betrieben worden ist; für eine Übersicht siehe zum Beispiel Facca und Lanzi, Minining interesting knowledge from weblogs: a survey, aus dem Jahr 2004 (2005 veröffentlicht). Wurden früher vor allem Weblogs (nicht Web-Blogs!) verwendet, also vom Server geschriebene Logdateien, so haben wir heute durch Google Analytics & Co die Möglichkeit, viel “bessere” Daten verwenden zu können.

Reintroducing: Assoziations-Regeln

Aber was genau ist besser? Wir können in GA & Co besser Menschen von Bots unterscheiden (von denen es mehr gibt als man denkt), Wiederkehrer werden zuverlässiger erkannt, Geräte etc. Die Frage ist, ob man die zusätzlichen Daten unbedingt verwenden muss für grundlegende datengetriebene Personas. Denn Assoziationsregeln, über die ich schon mal in einem Beitrag über das Clustering mit Google Analytics und R geschrieben habe und die auch von Facca und Lanzi erwähnt werden, können bereits grundlegende Gruppen von Nutzer identifizieren (ich hatte in dem anderen Artikel bereits erwähnt, dass ich für einen der Schöpfer des Algos, Tomasz Imilinski, mal gearbeitet hatte, aber eine Anekdote mit ihm muss ich noch loswerden: In einem Meeting sagte er mal zu mir, dass man oft denke, etwas sei eine low hanging fruit, ein schneller Erfolg, aber, “Tom, often enough, the low hanging fruits are rotten”. Er hat damit so oft Recht behalten.). Die Gruppen identifizieren sich durch ein gemeinsames Verhalten, die Co-Occurence von Seitenaufrufen zum Beispiel. In R funktioniert das wunderbar mit dem Package arules und dem darin enthaltenen Algo apriori.

Datengetriebene Personas mit Google Analytics & Co.

Wie bereits in dem früheren Artikel erwähnt: Eine Standard-Installation von Google Analytics ist nicht ausreichend (ist sie sowieso nie). Entweder hat man die 360-Variante oder “hackt” die kostenlose Version (“hacken” in Bezug auf “tüftlen”, nicht “kriminell sein”) und zieht sich die Daten via API. Bei Adobe Analytics können die Daten aus dem Data Warehouse gezogen werden oder auch über eine API. Einfach Google Analytics verwenden und daraus Personas ziehen ist also nicht möglich bei diesem Ansatz. Man muss außerdem nachdenken, welches Datum aus GA am besten verwendet wird neben der Client ID, um Transaktionen zu repräsentieren. Das kann von Website zu Website ganz unterschiedlich sein. Und wenn man ganz geschickt sein will, dann ist ein PageView allein vielleicht nicht Signal genug.

Hier geht es aber zunächst um die Visualisierung und welche Einschränkung der apriori-Ansatz hat für die automatisierte Generierung von datengetriebenen Personas. Für die Visualisierung arbeite ich mit dem Package arulesViz. Die daraus entstehenden Grafiken sind nicht ganz einfach zu interpretieren, wie ich an der HAW, aber auch mit Kollegen erlebt habe. Wir sehen hier unten die Visualisierung von Assoziationsregeln, die aus den Daten dieser Seite gewonnen werden, und zwar mit dem GA-Datum pagePathLevel1 (der bei mir leider gleichzeitig ein Artikel-Titel ist). Hier fällt bereits eines auf: Ich kann hier eigentlich nur zwei Gruppen identifizieren, und das ist ganz schön dürftig.

Was sehen wir hier genau? Wir sehen, dass Nutzer, die auf der Homepage sind, auch in den Bereich Lehrveranstaltungen gehen und umgekehrt. Der Lift ist hier hoch, der Support nicht so. Und dann sehen wir, dass sich Nutzer zwischen meinen vier Artikeln über Scalable Capital bewegen, mit ungefähr gleichem niedrigen Lift, aber unterschiedlich hohem Support. Lift ist der Faktor, um den die Co-Occurence von zwei Items höher ist als deren wahrscheinliches Auftreten, wenn sie unabhängig voneinander wären. Support ist die Häufigkeit. Der Support war beim Erstellen der Assoziationsregeln auf 0.01 definiert worden, die Konfidenz ebenso auf 0.01. Für Details siehe meinen ersten Artikel.

Warum aber sehe ich hier keine anderen Seiten? Mein Artikel über Google Trends ist ein sehr häufig gelesener Artikel, ebenso der über den Thermomix oder AirBnB. Es liegt also nicht daran, dass es nicht mehr Nutzergruppen gäbe. Der Nachteil dieses Ansatzes ist einfach, dass Nutzer mehr als eine Seite besucht haben müssen, damit überhaupt eine Regel hier entstehen kann. Und da einige Nutzer über eine Google-Suche kommen und anscheinend kein Interesse an einem zweiten Artikel haben, weil ihr Informationsbedürfnis vielleicht schon befriedigt ist oder weil ich diese nicht gut genug anpreise, sind hier in diesen Regeln anscheinend nur Studierende sowie Scalable Capital-Interessierte zu identifizieren.

Auswege aus dem apriori-Dilemma?

Bisher habe ich drei Lösungswege für dieses Dilemma identifiziert, und alle erfordern Mehrarbeit:

  • Ich teste, ob ich Nutzer durch ein besseres relevantes Angebot dazu bekomme, dass sie sich mehr als eine Seite ansehen, zum Beispiel mit Google Optimize, und erhalte im Erfolgsfall bessere Daten.
  • Ich nutze die apriori-Daten nur als Basis und merge sie mit anderen Daten (auch sehr schön, werde ich aber nicht hier behandeln)
  • Ich setze den Support und die Konfidenz herunter.

Am schönsten ist der erste Ansatz, meiner Meinung nach, aber dieser erfordert Zeit und Gehirn. Und dass etwas herauskommt ist nicht gesagt. Der letzte Ansatz ist unschön, da wir hier halt mit Fällen zu tun haben, die seltener vorkommen und daher nicht unbedingt belastbar. Bei einem Support von 0.005 sieht die Visualisierung zwar anders aus:

Aber wieder habe ich das Problem, dass die Einzelseiten nicht auftauchen. Es ist also anscheinend extrem selten, dass sich jemand von dem Google Trends-Artikel zu einem anderen Artikel hinbewegt, so dass das Herabsenken des Support-Werts nix gebracht hat. Aus der Erfahrung kann ich sagen, dass dieses Problem mehr oder weniger stark auftaucht auf den meisten Seiten, die ich ansonsten sehe, aber es taucht immer irgendwie auf. Das Dumme ist, wenn man schon gute Personas ablesen kann, dann ist man eher geneigt, sich den Rest nicht mehr anzusehen, auch wenn der vom Umfang her sehr groß sein könnte.

Wir sehen in der Grafik außerdem ein weiteres Problem, denn die Nutzer im rechten Strang müssen von Pfeil zu Pfeil nicht dieselben sein. Anders ausgedrückt: Es ist nicht gesagt, dass sich Besucher, die Fotografie-Seiten und Lehrveranstaltungen ansehen, auch die Veröffentlichungen ansehen, auch wenn das in der Visualisierung so aussieht. Wenn A und B sowie B und C, dann gilt hier nicht A und C! Um dies zu lösen, müssten die Assoziationsregeln in der Visualisierung noch eine ausschließende Kennzeichnung haben. Die existiert nicht und wäre eine Aufgabe für die Zukunft.

Fazit

Der Weg über Assoziationsregeln ist spannend für die Erstellung Daten-getriebener Personas mit Google Analytics oder anderen Webanalyse-Tools. Er wird momentan in der Regel aber nicht ausreichend sein, da a) das Problem von Eine-Seite-Besuchern hier nicht gelöst wird, b) die Regeln nicht ausreichend über unterschiedliche Gruppen informieren, die nur Überschneidungen haben und c) er eh nur über diejenigen Gruppen etwas aussagen kann, die bereits auf der Seite sind. An a) und b) arbeite ich momentan nebenbei, über Gedanken von außen freue ich mich dabei immer

Veröffentlicht am

Clustering mit Google Analytics und R

Manche Fragen lassen sich nicht so einfach oder auch gar nicht mit der Benutzeroberfläche von Google Analytics beantworten (das gilt übrigens auch für Adobe Analytics, Piwik, etc). Zwar bietet Google Analytics eine mächtige und einfach zu nutzende Funktionalität an, um Segmente oder Personas basierend auf Geräte, Akquisitionskanäle oder Browser manuell zu bilden und miteinander zu vergleichen, aber sobald es über diese Standardsegmente hinaus oder zu Kombinationen mehrerer Dimensionen geht, wird der Aufwand komplex. Oft genug wird dann auch einfach nur in den Daten “gestochert” und gehofft, dass man etwas Wertvolles findet. Genau hier kommen die Vorteile der Kombination von Google Analytics und R ins Spiel. Eine Möglichkeit, Google Analytics und R miteinander zu verbinden ist das R Package googleAnalyticsR von Mark Edmonson, das in diesem Artikel beispielhaft verwendet wird.

Segmentierung, Clustering und Klassifizierung

Bevor wir ins Praktische gehen, soll noch einmal kurz der Unterschied zwischen Segmentierung, Clustering und Klassifizierung erläutert werden. Bei einer Segmentierung wird versucht, Kunden oder Nutzer in Gruppen zu unterteilen, die sich anhand von Merkmalen unterscheiden, sei es ein Interesse, ein Zugangskanal, eine Marketingkampagne, über die ein Kunde kam, usw. Bei Clustering wird versucht, solche Gruppen und die sie jeweils unterscheidenden Dimensionen oder Features automatisiert zu identifizieren, wohingegen bei der Klassifizierung versucht wird vorherzusagen, zu welcher Gruppe ein Kunde oder Nutzer gehört. Klassifizierung ist ein gutes Beispiel für supervised Machine Learning, Clustering ein gutes Beispiel für unsupervised Machine Learning. Nicht immer kommt etwas Sinnvolles heraus, daher der häufige Gebrauch des Wortes “versucht”

In diesem Beispiel geht es um Clustering, also das Identifizieren von Gruppen auf Basis von Strukturen in den Daten mit Machine Learning-Algorithmen. Im Hierarchical Clustering werden Gruppen anhand ihrer Ähnlichkeit identifiziert, beginnend mit einem eigenen Cluster für jeden Datenpunkt und auf jeder weiteren Ebene mehr Cluster anhand der jeweiligen Ähnlichkeit zusammenzufassend, bis alle Cluster zusammengeführt sind (siehe das Dendrogram). Ein toller Algorithmus, der idealerweise numerische Daten als Input benötigt, denn Ähnlichkeit wird hier als Distanz berechnet. Zwar könnte man mit DAISY auch nicht-numerische Daten verwenden, aber für den ersten Schritt führt das zu weit.

Für unser Beispiel verwenden wir einen anderen Ansatz, wir wollen einfach nur herausfinden, ob Cluster auf Basis der angesehenen Inhalte oder Produkte einer Seite gebildet werden können. So vermute ich, dass die Besucher dieser Website, die sich Roller Derby-Fotos ansehen, sehr wahrscheinlich nicht an den Artikeln über Fintechs interessiert sind. Aber vielleicht interessieren sich die Google Analytics-Artikel-Leser für Fintechs, so dass ihnen Artikel zu diesem Thema angeboten werden könnten. Wir kennen das von Amazon (“Wird oft zusammen gekauft”), und meistens sind die Vorschläge nützlich. Natürlich kann ich mir auch den Nutzerfluss-Bericht in Google Analytics ansehen (bei den wenigen Seiten auf meiner Homepage reicht das auch völlig aus), aber sobald mehr Seiten oder Produkte vorhanden sind, kommen wir mit diesem Bericht nicht weiter. Hier helfen uns Association Rules weiter, auch als Market Basket Analysis bekannt (mit einem der Schöpfer, Tomas Imielinski, habe ich bei Ask.com sogar mal zusammengearbeitet). Dieser Machine Learning-basierte Ansatz versucht interessante Beziehungen zwischen Variablen in großen Datenbeständen zu identifizieren.

Generell hängt die Auswahl eines Algorithmus auch und vor allem zunächst einmal von dem Business-Problem ab, das gelöst werden soll. Dies ist ein extrem wichtiger Punkt: Welche Frage wollen wir eigentlich beantworten? In diesem Fall kann ich nur die Frage beantworten, welche Seiten in einem “Warenkorb” gelandet sind auf Basis der Nutzung durch Webseitenbesucher. Natürlich könnte ich eine “Ähnlichkeit” auch auf Basis des Inhalts maschinell berechnen.

Augen auf bei der Interpretation der Ergebnisse

Zunächst aber erst einmal eine fette Warnung: Das, was sich die Nutzer ansehen, hängt zu einem großen Maße auch davon ab, wie die Navigation oder weitere Elemente auf der Seite ausssehen. Wenn auf der Seite zum Beispiel schon ein Empfehlungssystem wie YARPP eingebunden ist, dann ist allein aufgrund dieses Plugins die Wahrscheinlichkeit höher, dass manche Seiten eher zusammen mit anderen Seiten aufgerufen werden. Aber auch Kleinigkeiten auf einer Seite können dazu führen, dass Zusammenhänge gesehen werden, die eigentlich gar nicht da sind, und sei es nur ein kleines Icon, dass die Aufmerksamkeit der Nutzer auf sich zieht und zum Klicken verführt.

Dann sollte auch noch darauf hingewiesen werden, dass das Ansehen von Seiten ein nicht ganz so starkes Signal ist wie das Kaufen eines Produktes. Nur weil jemand eine Seite aufruft, heißt das noch lange nicht, dass die Person auch lange auf dieser Seite geblieben und den Text gelesen hat. Man könnte das einfließen lassen, indem man zum Beispiel die Verweildauer auf der jeweiligen Seite misst und nur die Kombinationen zulässt, wo “genug” Zeit verbracht wurde, aber die Verweildauer in den Web Analyse-Systemen ist leider häufig unbrauchbar.

Voraussetzungen

Für das Clustering mit Google Analytics und R werden Analytics-Daten auf User-Level benötigt, das heißt, dass die Nutzer einer Standard-Installation der kostenlosen Variante von Google Analytics nicht ohne Weiteres ein Clustering durchführen können. Die Standard-Variante verfügt zwar über den neuen Nutzer-Explorer, über den man sich das Verhalten einzelner anonymisierter Nutzer anschauen kann, aber diese Daten sind nicht herunterladbar. Lediglich die Käufer der Pro-Variante können a priori auf User-Level Daten zugreifen, in der kostenlosen Variante sind nur aggregierte Daten im Angebot. Allerdings gibt es einen kleinen Hack, mit dem man das ändern kann, ansonsten ist hier ein weiteres Argument für Piwik zumindest als Zweitsystem. Der Vorteil von Piwik ist neben Zugriff auf die Rohdaten unter anderem auch, dass die Daten sofort zur Verfügung stehen. Und auch für Piwik existiert ein R Package. Aber in diesem Artikel soll die Lösung mit Google Analytics und R gezeigt werden.

Google Analytics und R mit googleAnalyticsR verbinden

Nun gehts ans Eingemachte. Ich werde nicht erklären, wie man ein R Package installiert, für das, was wir vorhaben, wird zum einen das Package googleAnalyticsR und das Package googleAuthR benötigt, zum andern das Package arules. Die R-Hilfe ist Dein Freund.

Wir laden zunächst einmal die beiden Packages und melden uns dann mit einem Google-Konto an (dafür geht ein Browser-Fenster auf):

library("googleAuthR")<l ibrary("googleAnalyticsR")<g a_auth()

Ist man übrigens bereits angemeldet und möchte auf ein anderes Konto wechseln, so gibt man

ga_auth(new_user = TRUE)

ein und meldet sich mit dem anderen Konto an. Als nächstes holen wir uns die Liste unserer Accounts und Properties, die mit diesem Google Account verbunden sind:

my_accounts <- ga_account_list()

In diesem Datenframe suchen wir in der Spalte viewName nach der Datenansicht, die wir verwenden wollen, und suchen in der Zeile nach der viewId. Diese viewId ist elementar, da wir mit ihr die Daten unserer Datenansicht abrufen werden. Wir speichern die viewID in einer Variable:

ga_id=XXXXXX

wobei XXXXXX für die viewId steht. Welche Daten stehen uns nun zur Verfügung? Einfach

meta <- google_analytics_meta()

eingeben und alle Dimensionen und Metriken sind im Data Frame meta abrufbar. Uns interessiert vor allem die Custom Dimension 1, in der die User Level ID gespeichert ist, und ga:pagePath:

gadata <- google_analytics(id = ga_id,<br /> start="2017-04-20", end="2017-05-06",<br /> dimensions = c("ga:dimension1", "ga:pagePath"),<br /> max = 2000)

In meinem Dataframe gadata habe ich nun die Daten wie oben beschrieben plus zwei weitere Spalten (sessions und bounceRate), da mir GA die Dimensionen nicht ohne Metriken ausgibt. Die Daten müssen transformiert werden, so dass sie ungefähr so aussehen:

<br /> user id 1, page 1, page 2<br /> user id 2, page 1<br /> user id 3, page 3

Dies geschieht mit dem Code

i <- split(gadata$pagePath,gadata$dimension1)

Wir haben jetzt jede “Transaktion” eines Nutzers in einer Zeile. Dies ist der benötigte Input für unseren Algorithmus.

Market Basket Analysis

Jetzt ist der Zeitpunkt, das R Package arules zu laden und die Daten für den Algorithmus zu modifizieren:

library(arules)<br /> txn <- as(i, "transactions")

Beim Aufruf des Algorithmus werden die Parameter sup für Support und conf für Confidence genutzt, d.h. wir sagen ihm im folgenden Beispiel, dass wir Regeln haben wollen, die mindestens in 0,1% der Fälle anwendbar sind und bei denen eine Konfidenz von 0,1% besteht. Das klingt erst einmal verdammt wenig, aber stellen wir uns vor, dass wir es mit einem “Warenkorb” zu tun haben, in den ganz viele verschiedene Kombinationen “gelegt” werden können, je nach Größe eines Online-Shops oder einer Webseite. Natürlich wollen wir mit den Regeln so viele Vorgänge wie möglich abdecken, aber je mehr Möglichkeiten vorhanden sind, desto wahrscheinlicher ist es, dass wir mit einem niedrigen Support-Wert hineingehen müssen.

basket_rules <- apriori(txn, parameter = list(sup = 0.001, conf = 0.001, target="rules"))

Hier kann ganz schön viel Prozessorzeit und Arbeitsspeicher draufgehen, und je nach Ausstattung beendet R den Prozess mit einer Fehlermeldung. Eine Möglichkeit, den Algorithmus zu begrenzen, ist, die Parameter sup und/oder conf zu vergrößern. Ist alles gut gegangen, so können die identifizierten Regeln begutachtet werden:

inspect(head(sort(basket_rules, by="lift"),20))

Hiermit werden die Top 20 Regeln angezeigt, sortiert nacht Lift. Der Lift sagt uns, wie viel höher die Abhängigkeit der Items ist im Vergleich zu ihrer Unabhängigkeit, von der man bei einem Lift von 1 ausgehen muss. Der Output bei mir sieht wie folgt aus (nicht für diese Webseite):

Regel zwei sagt zum Beispiel aus, dass ein kleiner Teil der Transaktionen beinhaltet, dass ein Nutzer sich einen Artikel über Kommunikationsmethoden anschaut und mit einer Konfidenz von 30% auch den Artikel über Kommunikationstechnologie lesen wird. Diese Verbindung hat einen extrem hohen Lift von 521, so dass wir davon ausgehen können, dass diese Verbindung viel wahrscheinlicher ist als ihr zufällig gemeinsames Auftreten.

Zusammenfassung Google Analytics und R

Dieses kleine Beispiel zeigt die Mächtigkeit von R und den Packages. Mit wenigen Zeilen Code können Daten ohne Umwege aus Google Analytics in R importiert und für komplexe Analysen verwendet werden. Diese Analyse wäre in der Benutzeroberfläche nicht möglich gewesen.

Wir sehen hier aber auch, wie wichtig es ist, Daten auf User-Level zu haben, wobei einschränkend gesagt werden muss, dass wir es hier nicht einmal mit User-Level-Daten zu haben, sondern mangels Cross-Device-Tracking eher mit Browser-Level-Daten. Eine nächster Schritt könnte also sein, dass die identifizierten Regeln noch mal auf Basis von segmentierten Daten erstellt werden, um Unterschiede zu identifizieren.