Jeder will Data Scientists haben. Hochschulen bieten Studiengänge an. Coursera & Co überschlagen sich mit Data Science-Angeboten. Angeblich kann man Data Science in einem Monat lernen. Und das ist wichtig! Denn Daten sind das neue Öl. Ohne Daten und die sie zu Gold machenden Data Scientists sei die Zukunft düster, da sind sich alle einig. Selbst wenn man keine spannenden Daten hat, so kann ein Data Scientist vielleicht aus dem Wenigen schon Goldstaub zaubern. Und eigentlich hat man eh keine Ahnung, was man mit den Daten machen kann, aber wenn man erst mal Data Scientists hat, dann wird alles gut. Auf dem Hype Cycle sind wir immer noch nicht ganz oben angekommen, aber es wird nicht mehr lange dauern, bis es runter geht ins Tal der Ernüchterung (und dann zum Plateau der Produktivität). Schuld daran haben mehrere Missverständnisse.
Es gibt keine allgemeingültige Definition von Data Science
Somit kann sich jeder Data Scientist nennen, wer das gerne möchte. Und man kann auch einen Kurs oder einen Studiengang danach betiteln, weil es gerade schick ist. Genau das passiert momentan zu häufig.
Data Science ist das Zusammenspiel aus Data Mining, Statistik und Machine Learning. Und genau das biete ich in meinen Kursen an. Und damit wir uns gleich richtig verstehen: Ein Semester ist dafür viel zu wenig. Und deshalb nennen wir das auch nicht mal Data Science, sondern Data Analytics oder Ähnliches. Wir schnuppern rein in Data Science. Aber in den 60 Stunden im Semester entwickle ich keinen neuen Data Scientist.
Im Prinzip müsste man erst einmal mindestens ein Semester Statistik unterrichten, bevor es weiter geht. Dann eine Programmiersprache richtig lernen, sei es R oder Python. Und dann würde man mit Machine Learning beginnen. Dazwischen immer mal wieder erklären, wie man mit Linux/Unix umgeht. Datenbanken. Cloud-Technologie. Damit kann man sicherlich ein ganzes Studium füllen.
Oft ist es aber nur eine Einführung in Python mit etwas scikit. Aber, wie oben schon beschrieben, das ist egal, denn der Begriff ist eh nicht geschützt. Und es merkt auch kaum jemand, denn wer soll das denn beurteilen?
Es gibt noch keine ausreichende Ausbildung
Vor kurzem habe ich mal in einen Data Science-Kurs auf Udemy reingeschnuppert (der übrigens immer nur noch wenige Stunden gerade mal ein paar Euro kostet). Der junge Mann in seinem Gamer-Stuhl konnte gut reden, aber in die Tiefe konnte er nicht gehen. Wobei, es kommt darauf an, wie man Tiefe definiert. Der inhaltliche Tiefpunkt war für mich erreicht, als er sagte, dass man gewisse Dinge mathematisch nicht verstehen muss, zum Beispiel ob man durch n oder durch n-1 teilt. Wow.
Dann habe ich auch schon mehrere Informatik- o.ä. Studierende von der Uni Hamburg etc bei mir gehabt. Abgesehen davon, dass ihnen grundlegende Kenntnisse fehlen (“Was ist eine CSV-Datei?”), haben sie zwar ein paar Techniken gelernt, die sie auch brav in die Bewerbung schreiben (“Erfahrung in ML”), aber richtig verstanden haben sie nicht, was sie da tun. So wird k-means gerne auf alles geballert, auch wenn es keine numerischen Daten sind (die kann man ja einfach umwandeln, dann sind sie ja numerisch). Dass das selten Sinn ergibt, wenn man euklidische Distanzen berechnet, nun ja. Wenn man nur einen Hammer hat, dann sieht alles aus wie ein Nagel.
Wenn aber die Ausbildung suboptimal ist, wie sollen die Data Scientists dann Gold aus Daten generieren? Für den wirklich krassen Kram wird eine solche Ausbildung nicht ausreichen. Und entweder wird dann Mist geliefert oder das Projekt geht nie zu Ende. Das erinnert mich ein bisschen an die New Economy, als plötzlich jeder HTML-Seiten bauen konnte. Nur diejenigen, die mehr als HTML konnten, haben nach dem Crash noch Chancen auf einen Job gehabt. Und zu viele Läden gingen pleite, weil sie einfach nur schwach ausgebildete Leute eingestellt hatten.
Nicht jedes Problem benötigt einen Data Scientist
Viele Probleme lassen sich auch ohne einen Data Scientist lösen. Tatsächlich sind viele Methoden bereits in der Statistik gut behandelt worden, von der Regressionsanalyse bis zur Bayesian Inferenz. Auch Klassifikation und Clustering gab es lange vor dem Data Science-Zeitalter. Support Vector Machines sind auch schon etwas älter (60er Jahre!). Das einzig Neue ist, dass es viel mehr Bibliotheken gibt, die jeder anwenden kann. Aber man muss nicht sofort an Data Science denken, wenn es um diese Themen geht. Denn da zahlt man gleich einen Hype-Bonus mit.
Und vor der Anwendung solcher Methoden steht erst einmal die Analyse von Daten. Dies ist die Kompetenz, die am meisten fehlt. Wir brauchen zunächst einmal nicht mehr Data Scientists, wir brauchen mehr Menschen, die nicht vor einer Zahlenkolonne weglaufen und es schaffen, daraus die richtigen Schlussfolgerungen zu ziehen. Und wenn man dann nicht weiß, wie man auf eine Lösung kommt, dann kann man immer noch einen Spezialisten fragen. Die häufigsten Probleme, die ich sehe, sind keine Data Science-Probleme, es sind zunächst einmal Daten-Analyse-Aufgaben. Und idealerweise werden diese Aufgaben nicht von Extra-Datenanalysten durchgeführt, sondern von den Kollegen selbst, die die Experten in einem Thema sind.
Was, wenn nicht Data Science, wird wichtig?
Natürlich wird die Arbeit mit Daten in Zukunft nicht weniger wichtig werden. Ganz im Gegenteil. Aber es ist zu befürchten, dass der gegenwärtige Hype diesem neuen Gewächs nicht gut tut. Da es dort jede Menge Geld zu verdienen gibt, stürzen sich auch Talente darauf, deren bisheriger Fokus nicht unbedingt auf Mathematik-nahen Fächern lag. Einen Udemy-Kurs kann jeder irgendwie abschließen. Aber die Qualität ist nicht bei jedem Kurs gleich gut. Und dementsprechend ist diese Art der Ausbildung sowie auch das plumpe Lernen von Methoden an der Uni nicht hilfreich, Data Science nach vorne zu treiben. Dadurch wird Data Science eher enttäuschen und in das Tal der Enttäuschung abrutschen. Denn es werden nicht alle Erwartungen erfüllt werden können.
Die Arbeit mit Daten sollte im Vordergrund stehen, nicht Data Science. Die Analyse. Die Akquise. Data Scientists sind gelangweilt, wenn sie nur als besser bezahlte Datenanalysten verwendet werden. Und der Anwender, der seine Bedürfnisse und Probleme gar nicht artikulieren kann (sofern überhaupt ein Problem vorhanden ist und nicht einfach nur nach dem “geilen Scheiß” gefragt wird), versteht die Welt nicht mehr, wenn die Data Scientists dann wieder gehen und sich eine spannendere Aufgabe suchen. Wir brauchen Anwender und Data Scientists, die zunächst einmal das zu lösende Problem verstehen und auch die entsprechenden Daten analysiert haben. Wir müssen mehr Menschen die Kompetenz geben, Daten selber analysieren zu können.
As with Google Trends, I’m always surprised at how quickly conclusions can be drawn from data without having to think about where the data actually comes from and how plausible it is. Especially with Similar Web, this is amazing, because Google has the search data and can read trends from it, but how can Similar Web have data about how many visitors a website or app has? How reliable is this data? Is the reliability sufficient to make important business decisions?
The ancestor of SimilarWeb
In 2006, my former colleague Matt Cutts had once investigated how reliable Alexa’s data is (Alexa used to be an Amazon service that had nothing to do with speech recognition). This service collected data with a browser toolbar (there’s no such thing anymore), i.e. every page a user looked at was logged. Since Alexa was especially interesting for webmasters, pages that are interesting for webmasters were logged. So they were distorted. So if you are already recording the traffic of users, then you have to somehow make sure that the user base somehow corresponds to the network population you want to find out about. That doesn’t mean that the data is completely worthless. If you compare two fashion sites with each other, then they are probably “uninteresting” for the webmaster population (a prejudice, I know), and then you could at least compare them with each other. But you couldn’t compare a fashion page with a webmaster tool page.
But where does Similar Web get the data from? On their website they give 4 sources:
An international panel
crawling
ISP data
direct measurements
Data collection via a panel
The panel is not explained in detail, but if you do only minimal research, you will quickly find browser extensions. These are probably the successors of the earlier browser toolbars. What is the advantage of the Similar Web Extension? It offers exactly what Similar Web offers: You can see with one click how many users the currently viewed page has, where they come from, and so on. The Similar Web-Extension does not only work at home if you are currently viewing the data for a page, but for every page you are viewing.
If you consider for whom such data is interesting and who then installs such an extension, then we have arrived at the data quality of the Alexa Top Sites. Webmasters, marketing people, search engine optimizers, all these people have a higher probability to install this extension than for example a teenager or my mother.
Crawling
What exactly Similar Web crawls is still a mystery to me, especially why a crawling can give information about how much traffic a page has. Strictly speaking, you only cause traffic with a crawler Similar Web says, “[we] scan every public website to create a highly accurate map of the digital world”. Probably links will be read here, maybe topics will be recognized automatically.
ISP traffic
Unfortunately, Similar Web does not say which ISPs they get traffic data from. It’s probably forbidden in Germany, but in some countries it will certainly be allowed for an Internet service provider to have Similar Web’s colleagues record all the traffic they receive through their cables. That would of course be a very good database. But not every ISP is the same. Would we trust the data if, for example, AOL users were in it (do they still exist at all)?
Direct measurements
This is where it gets exciting, because companies can link their web analytics data, in this case Google Analytics, directly to Similar Web, so that the data measured by Google Analytics is available to all Similar Web users. Then the site says “verified”. Why should you do that? You don’t get anything for it, instead you can expect more advertising revenue or strengthen your brand. Quite weak arguments, I think, but there are still some sites that do.
How reliable is Similar Web data really?
Of course, the direct measurements are reliable. It becomes difficult with all other data sources. These make up the majority of the measurements. Only a fraction of the Similar Web data is based on my sample of direct measurement data. But here you could certainly create models based on the accurately measured data and the inaccurately measured data. If I know how the data from spiegel.de is accurate and what the inaccurately measured data looks like, then I could, for example, calculate the panel bias and compensate for other pages. And I could do the same with all other data.
But does it really work? Let’s take a look at a measurement of Similar Web for one of my pages:
Apparently the number of visitors fluctuates between as good as nothing and 6,000 users. There are no clear patterns. And now we look at the real numbers from Google Analytics:
It’s the same time period. And yet the unique traffic patterns from the Google Analytics data are not recognizable in the Similar Web data. The data is simply wrong.
Result
Can you use Similar Web at all? I would advise you to be very careful if the data does not come from a direct measurement. Of course, the question can now arise as to what else to use. The counter-question is what to do with data that you can’t be sure is correct at all. If I had to make a business decision that might cost a lot of money, I wouldn’t rely on that data. For a first glance…? We also know that a “first glance” can quickly become a “fact” because it fits so well into one’s own argumentation.
Of course this is an unsatisfactory situation. No wonder that alternatives like keywordtool.io are popular. But how accurate is their data? Because I couldn’t find a clue where they got the data from, and that makes me very suspicious at first. Where would they get the data from, if not via the API? And here the access is limited. On the initiative of my esteemed colleague Christian, I then took a closer look at it. On the one hand he asked where keywordtool.io got the data from (there was no satisfactory answer). On the other hand he got a test account A first pre-test brought disappointing results, the numbers were completely different than those of AdWords. However, the colleague was no longer sure if he had chosen the same settings as I did in AdWords, so I did the test again on my own.
With the first keyword set from the pedagogy area, the surprise after the pre-test was big: Apart from a few exceptions, all keywords had exactly the same search volume. The few exceptions were that keywordtool.io did not spit out any numbers, but the keyword planner did. Here, however, there were only 2 out of almost 600 keywords. The second keyword set on the subject of acne also showed the same picture. The search volumes fit exactly except for a few exceptions. Interestingly, both keyword sets were more concerned with topics that did not necessarily stand out due to their high search volume, in some cases we are talking about 20 search queries per month. So it is very likely that the Google AdWords API will be tapped directly here, otherwise these exact numbers cannot be explained. This would also explain why you can only query 10 sets of a maximum of 700 keywords (more than 700 keywords are not possible with the Keyword Planner, but more than 10 per day). Thus keywordtool.io would be a good alternative… if not…
The third keyword set then showed a different picture, the deviations are dramatic. Unlike the previous keywords we are talking about high volume keywords like . Unfortunately there is no pattern to be seen on the plot, except for the pattern that keywordtool.io is always higher and never lower. Keywords with a high search volume can be as well off as keywords with a low search volume. It’s also not that it’s always the same deviation, we’re talking about keywords where the numbers fit exactly, and keywords that have a deviation of 16 times the volume reported by Google. There is also no order in any way. The deviations are completely random. And they’re far too big to ignore.
Of course, that won’t stop many people from using keywordtool.io, after all, people like to say “Joa, usually fits” or “It’s better than nothing”. Whether it’s really better, I question that. I wouldn’t want to make any decisions on the basis of such deviations. The keyword planner is the better option, even if it only delivers staggered values, if you don’t have enough budget.
By the way, the data of the third set are available here in an R notebook.
[Please note that this article was originally written in German in 2016; all screenshots are in German but you will understand them nevertheless. The text has been translated automatically so please excuse the English]
In September 2015, I stood on a big Google stage in Berlin and showed the advantages of the new features of Google Trends in addition to a demo of voice search. For a data lover like me, Google Trends is a fascinating tool if you understand all the pitfalls and know how to avoid them. At the same time the tool offers a lot of potential for misunderstandings Search queries are placed in <> brackets.
Misunderstanding: Not all search queries are considered.
Misunderstanding: The lines say nothing about the search volume / No absolute numbers.
Misunderstanding: Google trends search queries are different
Misunderstanding: Rising lines no longer mean search queries.
Misunderstanding: Without a benchmark, Google Trends is worthless.
1st Misunderstanding: The basis of Google Trends Data
Google Trends is not based on all the searches you enter on Google. Quote: “The Google Trends data is a random selection of data from Google searches. Only a certain percentage of the searches are used to determine the trend data. […] Trends only analyzes data for popular keywords. Low-volume search terms therefore appear as 0. […] Trends removes repeated searches from the same person within a short period of time.” There is no definition of when a term is popular or what a short period is. It is not said whether the random selection is a representative sample of the total population of all search queries (the term “random” suggests this). The first finding is that we are talking about trends, no more and no less.
2nd Misunderstanding: Graphs and search volumes in Google Trends
This is the biggest and most fatal misunderstanding. If one curve is above the other, it does not mean that one term was searched for more often than the other. Whaaaaat? Really? Yes. Fancy an example? We are looking for acne and neurodermatitis (I’ll explain below why I write this in quotation marks in the mask) for Germany in 2015. Acne and neurodermatitis alternate in search interest, but acne seems to have a higher search interest more often:
And then I take a look at the data in the Google AdWords Keyword Planner, for the same period, for the same country:
What is interesting here is not the graphic (I only made the screenshot to show that I am searching in the same country for the same period), but the two lines below, where we see the average search volume per month. Neurodermatitis is far above acne, 74,000 to 18,100.
Average values can lead us in the wrong direction, so we also look at the data plotted for each month:
We see a similarity to the Google Trends graphic, namely that the searches for neurodermatitis go down from May or the middle of the year and up again from September. And, this will become important later on, neurodermatitis will reach 100 on Google Trends, but acne never reaches this point. Otherwise the curves of the AdWords data do not touch each other once like in Google Trends. They are far apart. The second finding is that we can’t use Google Trends data to claim that one term is searched for more often than another (although Google Trends is often misused for this purpose). Google Trends does not provide absolute figures. Sorry. But why not? Let’s move on to the next misunderstanding.
3. Misunderstanding: What is a search query?
If you enter in Google or in the Google AdWords Keyword Planner, you will only search for this term. If you enter in Google Trends, you will automatically search for other terms, even if you have not selected a topic, but only this search term (see the help section of Google Trends). So you can restrict something by putting a term in quotation marks (“acne creme”), but this only restricts that is not searched for, but could be included. Which search terms are included, is not disclosed. An “exact match” does not exist, see the help section again.
In this example, we compare the search terms and . If we add quotation marks, the curves look a bit different:
Not a huge change, but there’s a difference we’ll remember for later: If we enter the terms without quotation marks, then comes close to 100, with quotation marks comes close to 100.
It is astonishing, because with a one-word term, where no synonyms are searched for, there can be no different order for the words in the search query. I can’t explain this phenomenon.
Finally, let’s look at what happens when we select the automatically identified topic “disease” (Note: Google turns automatically , which is the medical term for neurodermatitis):
Here, the trend data of terms that fit into the group of the disease are aggregated. The “search interest” in neurodermatitis approaches the topic of acne in February 2016, but acne as a topic seems to have a greater search interest than neurodermatitis. Again, we do not know which terms are grouped together. So it could be that the different data comes from the fact that Google Trends includes additional terms for both terms, but for the term acne terms whose search interest is different and therefore changes the result. However, this does not sound very plausible. Third finding: Google trend data is not comparable with AdWords data, because the input is interpreted and enriched differently and we at Google Trends do not know with what.
However, the differences between AdWords and trends are probably still not explained. What could be other reasons?
4th Misunderstanding: Everything that rises or falls is a trend in Google Trends
Now it’s getting a little mathematical. Google Trends does not offer absolute numbers, all data is displayed on a scale from 0 to 100. And now we remember the two clues above again when one of the two query curves touched 100. Touching the 100 has great significance, because from this highest point of search interest, everything else is calculated!
But it becomes even more complicated: First of all, the search interest is the search volume for a term divided by the search volume of all terms. Since we do not know the base (i.e. how many searches there were in total on that day) and this base changes every day, it is possible that the line of search interest for a term changes, although this term is searched for equally often every day. The point in time at which the maximum of this ratio search term/all search terms is reached becomes the maximum, i.e. 100 in the Google Trends diagram, and all other values, including those of comparison terms, are derived normalized from it. And only for the selected period. If this is changed, the maximum will also be recalculated. This leads to differences that could tempt you to choose exactly the period that matches what you would like to sell Examples:
Misinterpretation: Compared to the weather, interest in Trump has hardly increased in the last 12 months
Misinterpretation: In the last 30 days interest in Trump has not increased as much as interest in weather. In fact, the data from Google Trends are not yet updated, the election day and the previous day are missing.
The diagram for the last 7 days: Can we now say that Trump was searched for more often than the weather?
These last graphics are very nice because they clearly show that the Germans didn’t necessarily search less for the weather, but the search queries for the term Trump on 9.11 had a much higher share in the population of all searches compared to the 6 days before. From this one maximum everything else is calculated. But over 30 days the weather had a maximum (EDIT: Because the day after the election was not yet there and it is also two days later not! Thanks to Jean-Luc for this hint!), and then it will be calculated from there. That’s why these dates can differ so much.
Edit: If you look one day after the election and only look at the last day (i.e. data that is about 10 minutes old), then the result looks like this:
Again the weather is higher, although Trump gets close. Is it? Well, I took this screenshot in the evening, and the peak of Trump searches probably took place more than 24 hours ago. It is very likely that I would have got another image if I had made the same query this morning.
What do we take out of this misunderstanding? 1. the period of observation is immensely important, and you shouldn’t believe a trend graphic without looking at several periods of time 2. all observations start from the maximum and are then relatively visible from this maximum, but are at the same time dependent on the total volume of all search queries, which we do not know. 3. it may not be so obvious in the graphs, but in the 7-day graph it is calculated on an hourly basis, in the 30-day graph on a daily basis, in the 12-month graph on a weekly basis. The Google AdWords Keyword Planner delivers data on a monthly basis. This is another reason why the data is not comparable.
EDIT: 4th Learning: “The last 30 days” does not necessarily mean that the last 30 days are really in
5th Misunderstanding: Everything that rises or falls is a trend in Google Trends, Part 2
Depends on how you define trend. After the Brexit vote, a journalist found out through Google Trends that the British had googled only after the vote, what the Brexit means, many newspapers wrote about it, and only after a data analyst had looked at what was really happening, did everyone row back. Yes, there was more searching based on… see the 4th misunderstanding But compared to a popular search query, there was only a twitch. Data must always be put into context to get a feel for what it really means. Although I’m not a football fan, I like to use the search query , but also to see how relevant a term really is.
The weather is always searched for, but a certain seasonality can also be observed here, Bundesliga is primarily searched for by a part of the population, and that only seasonally, but interesting observations can also be made here.
We see the Friday game (first small dent in the blue curve), the Saturday games (biggest dent in the blue curve) and then again smaller dents for the Sunday games. The weather here has the highest swings, especially on Monday and Tuesday (maybe because of the snow?). So were you looking for the weather more often? No, not necessarily! Since here everything is calculated on an hourly basis, everything is calculated from the maximum on 8.11., 5 and 6 o’clock, at this time the search interest (search query/all search queries) was highest, and everything else is calculated relatively. So it can be theoretical that on Saturday afternoon you searched more often for Bundesliga than for weather on 8.11., but the total population of search queries was higher! What do we take with us? We always need a reference point, a benchmark, something with which we can compare the search interest. And best of all, we also know something about this reference point, as in this case, for example, that it snowed, and that’s why there were outliers.
Summary
The mechanism “I enter two terms into Google Trends and see which one is more popular” simply doesn’t work. This will be hard to get out of your heads, because the interface is wonderfully intuitive and literally leads to this interpretation, and it’s not completely wrong either. It’s difficult if you want to make momentous decisions based on this data, additional data is necessary. Keyword planner data are no longer available to everyone, but are not directly comparable anyway, since Google trend data do not compare pure terms.
And yet Google Trends is more than just a gimmick. You only have to invest a little more brain fat in all of the above to build a real story out of it.
Sorry for the lurid title, by the way. I wanted your attention. I hope it was worth it
Heute wirds mal etwas technischer. Über die Durchschnittliche Verweildauer in Google Analytics und anderen Webanalyse-Systemen habe ich schon viel geschrieben, sie stimmt in einer Standard-Installation nicht. In einem meiner Kurse sagte dann mal ein Teilnehmer, dass man doch einfach messen könne, wenn der Nutzer den Tab schließt, zum Beispiel mit beforeUnload. So ein Trigger ist schnell gebaut, hat aber auch Nachteile. Zunächst einmal ist das nicht zuverlässig, denn ein Benutzer kann auch einfach den Tab wechseln und nicht schließen, engagiert sich aber trotzdem nicht mit den Inhalten meiner Webseite, so dass die ermittelte Time on Site nicht richtig ist. Insbesondere auf mobilen Geräten sehe ich es eher selten, dass Nutzer ihre “Tabs” schließen. Aber darum geht es heute nicht, das ist mindestens einen weiteren Beitrag wert. In diesem Artikel geht es vor allem darum, wie wir überhaupt den Einsatz von onbeforeUnload messen debuggen können.
Das Problem: Unser Logging verschwindet, wenn der Tab geschlossen wird
Hintergrund: Wenn ein Nutzer einen Tab schließt oder im gleichen Tab eine andere Website aufruft, dann kann ich zwar das Event abfangen, aber im schlimmsten Fall verlangsamt das die User Experience, da in der Regel ein Get Request geschickt wird. Geht der Nutzer nur auf eine andere Site, dann sehe ich im GA Debugger zwar was vorher geloggt wurde; aber sollte der Nutzer den Tab schließen, dann ist auch meine Console weg. Natürlich kann ich im Echtzeit-Bericht von Google Analytics schauen, ob mein beforeUnload-Event ankommt, aber Debugging ist etwas anderes. Der Google Tag Manager Debug Mode hilft hier auch nicht, denn das beforeUnload Event ist nur ganz kurz zu sehen, wenn wir den Tab schließen.
Nutzen wir dann noch sendBeacon, dann wird es noch komplexer, denn der Google Tag Assistant kommt damit gar nicht klar, wahrscheinlich weil sendBeacon POST Requests sendet und keine GET Requests. sendBeacon hat aber den großen Vorteil, dass wir nicht die User Experience beeinträchtigen.
Die Lösung: Logging vom GA Debugger in eine Datei schreiben
Abhilfe schafft hier ein kleiner Hack. Wir starten Chrome mit einem Logging im Terminal und lassen uns dann zum Beispiel live die Logdatei ausgeben. Hier muss der GA Debugger immer noch aktiviert sein, denn er schreibt weiterhin brav in die Console, nur dass wir in der Datei sehen können, was er reingeschrieben hat, auch wenn der Tab schon geschlossen wurde.
Mit diesem Code starte ich meine Live-Ansicht des Loggings; der Parameter -f für tail bedeutet lediglich, dass ich immer sehen will, wenn an das Ende der Log-Datei etwas angehängt wird:
Ich nutze danach grep, um nur die relevanten Zeilen zu bekommen, denn Chrome loggt einiges mit; in diesem Fall schaue ich mir 11 Zeilen vor und 30 Zeilen nach dimension1 an (das kann natürlich auch irgendetwas anderes sein, ich weiß nur, dass bei mir die Dimension1 immer drin ist ). Und dann starte ich Chrome im Logging-Modus, hier der Befehl für den Mac:
Google Analytics kann mitunter fies sein, denn manche Dimensionen gepaart mit Segmenten verhalten sich nicht so, wie man das zunächst denken mag. Dank Michael Janssens und Maik Bruns‘ Kommentare auf meine Frage in der von Maik gegründeten Analyse-Gruppe kann ich heute beruhigt schlafen gehen und bin wieder ein bisschen schlauer geworden.
Die Frage kam heute im Analytics-Kurs auf: Wie kann es sein, dass ich mehr Neue Nutzer als Transaktionen habe, wenn ich in dem Segment “Hat einen Kauf getätigt” bin? Den Link zum Bericht gibt es hier, die Annahme, die ich hatte, war die: Wenn ich ein Segment von Nutzern habe, die einen Kauf getätigt haben, und dieses Segment im Bericht “Neue vs. wiederkehrende Nutzer” verwende, dann gehe ich davon aus, dass ich in dem Bereich Neue Besucher + Haben einen Kauf getätigt nur die Nutzer sehe, die in ihrem ersten Besuch etwas gekauft haben. Allerdings sehen wir hier in diesem Bericht 691 Nutzer, aber nur 376 Transaktionen. Wenn meine Erwartungshaltung stimmen würde, dann müsste die Zahl hier gleich sein. Ist sie aber nicht.
Neue Nutzer + Wiederkehrende Nutzer > Alle Nutzer
Wir sehen hier auch andere Widersprüche, und der Vollständigkeit halber fangen wir mit ihnen an. So liegt die Zahl der neuen Nutzer bei 53.263, die der wiederkehrenden Nutzer bei 14.578. Allerdings haben wir nur 58.856 Nutzer insgesamt, also weniger als die Summe der neuen und der wiederkehrenden Nutzer.
Diese Diskrepanz ist einfach erklärt: Wenn ein Nutzer innerhalb des Berichtszeitraums das erste Mal kommt, dann ist er ein Neuer Nutzer. Kommt er innerhalb des Berichtszeitraums ein zweites Mal, dann ist er auch ein Wiederkehrender Nutzer. Er wird also zwei Mal gezählt, einmal bei den Neuen Nutzern, einmal bei den Wiederkehrenden Nutzern. Bei “Alle Nutzer” wird er aber nur einmal gezählt.
Schauen wir einmal in die Spalte Transactions, so sehen wir, dass diese nicht mehrmals gezählt werden. Das ist logisch, denn sie können sich nur einmal als Transaktion definieren
Globale Seiten verzerren die Daten
Maik brachte noch den Punkt, dass globale Seiten etwas verzerrte Daten aufweisen, weil Google Analytics um Mitternacht alle Sessions neu startet, so dass ein neuer Besucher, der um 23:55 kommt und um 0:01 eine zweite Seite aufruft, an diesem zweiten Tag auch als Neuer Besucher gilt, wie am ersten Tag. Es ist derselbe Nutzer, aber er wird zwei Mal als neuer Nutzer gezählt (siehe Quelle hier). Aber kann das dazu führen, dass wir so viel mehr Neue Nutzer als Transaktionen haben? Sicherlich, der Google Merchandising Store ist globalgalaktisch aktiv, aber wird rund um die Uhr so viel gekauft?
Die Lösung: Kein Bool’sches UND
Die Lösung (Danke, Michael!) liegt darin, dass das Segment “Made a Purchase” gepaart mit “Neuer Besucher” nicht mit einem UND verknüpft sind, d.h. wir können hier Nutzer drin haben, die irgendwann gekauft haben, aber nicht unbedingt im ersten Besuch. Das wird deutlich, wenn wir unsere beiden Segmente mit einem Segment vergleichen, das Michael gebaut hat:
Michaels Segment ist so gebaut, dass es die UND-Verknüpfung nutzt:
Wir haben hier Sessions, in denen ein Nutzer neu sein muss und gleichzeitig mindestens eine Transaktion. Und wir sehen plötzlich, dass wir für die 376 Transaktionen 373 Nutzer haben, d.h. es muss Nutzer gegeben haben, die in ihrem Besuch mehrere Transaktionen gehabt haben. Mit anderen Worten, die Neuen Besucher in unserem Segment “Made a Purchase” haben zwar alle einen Purchase gemacht, aber 691 minus 376 Transaktionen wurden von diesen Neuen Besuchern nicht während ihres ersten Besuchs gemacht, sondern in einem späteren. Die Verknüpfung des Berichts und des Segments könnte man so formulieren: Zeig mir alle Benutzer, die in irgendeiner Session eine Transaktion hatten und innerhalb des Berichtszeitraums auch ihren ersten Besuch.Sie bedeutet nicht, zeig mir alle Nutzer, die in ihrer ersten Session auch eine Transaktion haben.
In Zukunft werde ich etwas genauer schauen, wie die Verknüpfung eines Segments mit einem Bericht zu interpretieren habe. Denn das war, wie gesagt, etwas fies
This is not a love song. Dies ist auch keine Liebesgeschichte. Zumindest nicht über dieses Produkt. Dies ist die Geschichte des Kickstarter-Projekts von Revols, in dem es um eine super Idee ging, die aber irgendwie nicht zu einer Erfolgsstory wurde. Im Januar 2016 finanzierte ich die Kickstarter-Kampagne von Revols mit, $219 für Kopfhörer, die sich automatisch meinem Ohr anpassen. Eine super Geschichte, dachte ich, denn meinen Ohrschutz, den ich bei Konzerten oder beim Schlagzeugspielen immer trage, habe ich beim Hörgeräte-Akustiker auch für knapp 200€ damals erstellen lassen, und ich bin nach vielen Jahren immer noch schwer überzeugt davon. Für das gleiche Geld dann Wireless Kopfhörer bekommen? Wunderbare Idee.
Hier das Kickstarter-Video, das mich überzeugt hatte:
Im Juni 2016 sollten die Kopfhörer ankommen. Mit etwas mehr als zwei Jahren Verspätung kam das Produkt tatsächlich an. Knapp 40€ Zoll noch drauf. Ärgere ich mich darüber? Nein, kein bisschen, Es geht hier um ein komplett neues Produkt, und man kann die Gründer nur bewundern, dass sie trotz aller Widerstände durchgehalten haben. Zwischendurch wurden sie von Logitech gekauft, die Wahrscheinlichkeit nix mehr zu sehen war also gering. Es ist auch nicht mein erstes Produkt, das ich bei Kickstarter gekauft habe, das Vi war auch so ein Projekt, das erst mal ein paar Kinderkrankheiten überstehen musste. Das ist halt das Risiko eines Early Adopters
Was an den Revols suboptimal ist
[
as stört mich also? Zunächst einmal, die Kopfhörer sind riesengroß. Ja, das hätte mir schon im Video auffallen müssen. Aber wenn man sie dann wirklich in der Hand hat, dann wirken sie irgendwie größer. Ich hab sie zum Vergleich mal auf ein Reclam-Heft gelegt, das hat den Vorteil, dass wahrscheinlich jeder die Größe eines Reclam-Hefts kennt und so selber einschätzen kann, wie groß die Hörer sind. Ich frage mich, ob es nicht kleiner gegangen wäre.
Und dann… passen sie nicht einmal sonderlich gut. Sie fallen mir aus dem Ohr. Und ja, ich habe die Anleitung genau befolgt. Der Sound ist nicht besonders toll. Das kann natürlich daran liegen, dass sie nicht richtig sitzen. Aber selbst wenn ich sie mir ins Ohr drücke, dann klingen sie eher naja. Der Sound wirkt auf mich leise, der Bass kommt nicht richtig, selbst die Vi-Hörer sind besser.
Aus den angekündigten 8+6 Stunden Akku-Laufzeit (8 Stunden die Kopfhörer selbst und 6 Stunden der Zusatzakku) sind 5+5 Stunden geworden. Ich komme auf ca. 4+4 Stunden. Kommuniziert wurde die verringerte Akku-Laufzeit meines Wissens nach nicht.
[
ann sind hier trotz Wireless jede Menge Kabel zu sehen. Das Aufladekabel wirkt nicht sehr stabil, und da an dem Kabel gezogen werden muss, wenn man die Auflademuscheln von den Aufladestäben trennen will, dann habe ich immer Angst, dass das dürre Kabel reisst. Zwar soll das so geprüft worden sein, aber so richtig stabil wirkt es eben nicht.
Insgesamt habe ich 250€ ausgegeben, und für das Geld hätte ich wahrscheinlich weniger Kabelsalat, mehr Qualität und eine schnellere Lieferung gehabt, dafür nur keine angepassten Hörer, die bei mir aber eh nicht gut passen. Tatsächlich stehe ich auch nicht allein da mit meiner Meinung, wenn ich mir andere Reviews auf YouTube ansehe:
Aber wie der Autor dort selbst sagt, auf Kickstarter verzichten würde ich trotz mancher Enttäuschungen nicht. Denn man hat die Chance, neue Technologien zu erleben, bevor sie die große Masse in die Hand bekommt. Oder manchmal auch einfach eine smarte Idee zu finanzieren, die das Leben einfacher macht. Insgesamt habe ich schon eine kleine zweistellige Anzahl von Kickstarter- und Indiegogo-Projekten unterstützt. Manche wurden gecancelt wie das MOTI, manche Firmen gingen nach Auslieferung pleite wie die Hersteller vom Backbone, der Hangbird war eine der besten Anschaffungen überhaupt (und nicht wirklich Hightech), auf die Dokumentation über Dieter Rams freue ich mich wie ein Kleinkind, und auch wenn der Reward von Mine Kafon Drone eher symbolischer Natur war, die Idee die Welt von Landminen zu befreien, ist einfach nur wunderbar.
Ü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
Google Optimize ist eines meiner Lieblings-Tools, denn es ermöglicht jedem schnell a/b-Tests zu bauen; in meinen Kursen staunen die Teilnehmer häufig, wie schnell so ein Test online sein kann. Natürlich ist die Vorarbeit, das saubere Erstellen einer Hypothese, nicht so schnell getan, aber es macht auch keinen Spaß, monatelang auf die Live-Schaltung eines Tests zu warten. Über die Vorzüge von Google Optimize will ich auch gar nicht weiter eingehen, sondern stattdessen auf drei Feinheiten hinweisen, die nicht so offensichtlich sind.
Google-Optimize-Daten in Google Analytics Rohdaten verwenden
Die Google Analytics API erlaubt auch den Zugriff auf Google Optimize-Daten, die in Analytics reinlaufen, was ermöglicht, dass die Analytics-Rohdaten zu einem Google Optimize-Test analysiert werden können. Das ist vor allem dann interessant, wenn etwas nicht als KPI in Optimize verwendet werden kann, man in Google Optimize vergessen hat, einen KPI einzustellen oder Nebeneffekte analysiert werden sollen. Einiges davon geht auch hinterher mit Segmenten, aber hey, hier geht es ums Hacken (im Sinne von Tüftler, nicht Krimineller), da macht man auch Dinge, weil man sie machen kann, nicht weil sie immer notwendig sind
Die beiden wichtigen Optimize-Dimensionen heißen ga:experimentId und ga:experimentVariant, mittlerweile existiert auch eine Kombination, die ga:experimentCombination heißt. Wobei, wenn man nur einen Test fährt, dann reicht es auch, nur die Dimension ga:experimentVariant abzufragen. 0 ist die Originalvariante (Kontrollgruppe), danach wird pro Variante hochgezählt. Hat man mehrere Tests am laufen, so einfach in der Google Optimize-Oberfläche die ID nachschauen; sie findet sich in der rechten Spalte unter Google Analytics. Sie ist meistens sehr kryptisch, wie man auf dem Bild sehen kann.
In meinem Beispiel habe ich zwei Experimente am Laufen, so dass ich mir die Kombination ausgeben lasse neben drei Custom Dimensions (Client ID, Hit Type und UNIX Timestamp) sowie Seitentitel (die Client ID hab ich auf dem Bild etwas abgeschnitten, da es ja nur ein pseudonymisiertes Datum ist). Wir sehen auf dem zweiten Bild die beiden Experimente und die jeweiligen Varianten in einem Feld. In dem Test, der mit c-M startet, hatte ein Kursteilnehmer die Hypothese aufgestellt, dass die Besucher meiner Seite mehr Seiten ansähen und mehr Zeit verbrächten, wenn das Suchfenster weiter oben wäre. Ich habe nicht daran geglaubt, aber Glauben ist nicht Wissen, also haben wir den Test gefahren mit dem KPI Session Duration. Vergessen hatte ich hier, die Anzahl der Suchen als zweiten KPI einzustellen. Nun gut, dass ich die Rohdaten habe, auch wenn ich dafür natürlich auch ein Segment bauen könnte.
Wie wir in dem Screenshot auch sehen können, sind die Nutzer gleichzeitig in zwei Tests, da der andere Test keinen Einfluss auf den ersten Test haben sollte. Nun gab es während der Test-Laufzeit von 4 Wochen auf meiner Seite nur 3 Nutzer, die nach etwas gesucht haben, einer der Nutzer hat eine Query mehrmals gesucht, ein Nutzer hat zwei verschiedene Terme gesucht. Bei einer so geringen Fallzahl brauchen wir erst gar nicht über Signifikanz nachdenken. Zwischenzeitlich sah es mal so aus, als würde tatsächlich die Suchfenster oben-Variante gewinnen, aber dazu im letzten Abschnitt mehr. Die Frage ist nun, warum überhaupt die Variante besser sein kann, wenn doch kaum gesucht wurde? Oder hat allein die Präsenz der Suchbox zu einer längeren Session Duration geführt? Sehr unwahrscheinlich!
Das sollten wir uns einmal genauer anschauen…
Zu beachten ist in den Rohdaten, dass es nun für jeden Hit eines Nutzers zwei Einträge gibt, einen pro Test. Außerdem wird nicht jeder Nutzer in einem Test sein, auch wenn 100% des Traffics getargeted sind, was man aber auch schon in Google Analytics sehen kann. Ebenso können wir überprüfen, ob durch die zufällige Auswahl von Test- und Kontrolgruppenteilnehmern eine einigermaßen gleichmäßige Aufteilung der Nutzer erfolgt ist (z.B. Mobile versus Desktop etc). Auch das ist natürlich mit dem Interface möglich.
Das erste, was auffällt, wenn ich die Daten aus der API ziehe, ist, dass die Werte nicht mit denen aus der GUI übereinstimmen. Das ist zunächst einmal ziemlich beunruhigend. Schaue ich mir nur Users und Sessions an, so stimmen die Werte genau überein. Nehme ich die Dimension experimentCombination hinzu, so passen die Zahlen nicht mehr, und es liegt nicht an den Unterschieden zwischen API v3 und v4. Es ist nicht ungewöhnlich, dass die Daten nicht zusammen passen, meistens geschieht das durch Sampling, aber das kann hier nicht der Fall sein. Interessanterweise stimmen auch die Zahlen innerhalb der GUI nicht überein, wenn ich mir die Daten unter Experiments ansehe und sie mit dem Dashboard zur Zielgruppe vergleiche. Die Zahlen aus der API stimmen aber mit den Daten aus dem Experiments-Bericht überein. Vorsicht also wer Segmente bildet!
Ziehe ich die Daten inklusive meiner ClientID-Dimension, so habe ich etwas weniger Users, was sich dadurch erklärt, dass nicht jeder User eine solche ID in die Custom Dimension reinschreibt, d.h. er hat diese Client ID wahrscheinlich (oder sicherlich, denn sonst könnte GA ihn nicht als einzelnen Nutzer identifizieren), aber ich schaffe es irgendwie nicht die ID in die Dimension zu schreiben, so dass dort zB “False” steht.
Nun schauen wir uns einmal ein paar Daten an. Mich interessiert zum Beispiel, ob Optimize es schafft, die gleiche Verteilung über Devices hinzubekommen wie ich sie auf der Seite habe:
Der Großteil meines Traffics findet noch auf dem Desktop statt. Wie sieht es in Optimize aus?
Die Verteilung ist definitiv eine andere. Das ist auch wenig verwundertlich, denn auf AMP-Seiten sollte kein Optimize-Experiment ausgespielt werden; es ist also eher verwunderlich, warum hier überhaupt noch Experimente auf Mobilgeräten stattgefunden haben. Und diese Fälle haben andere Werte in Bezug auf den Ziel-KPI, wie man auch in Analytics sehen kann:
Wir können also nicht von den Testergebnissen auf die ganze Seite schließen, wir wissen aber auch nicht, wie groß der Effekt der unerwarteten Mobile-User auf das Testergebnis ist. Hierzu müssten wir also den Gewinner neu ermitteln. Doch wie wird der Gewinner überhaupt ermittelt? Wir könnten zum Beispiel einen Chi-Square-Test verwenden mit der Beobachtung der durchschnittlichen SessionDuration:
chisq.test(x) Pearson’s Chi-squared test with Yates‘ continuity correction data: x X-squared = 1.5037, df = 1, p-value = 0.2201`
In diesem Fall ist p über 0.05, zu p im nächsten Abschnitt mehr. Sollte der Chi-Square-Test überhaupt der richtige Test sein, so ergäbe er, dass der Unterschied nicht statistisch signifikant ist. Allerdings ist das nicht der Test, den Google Optimize verwendet.
Bayessche Inferenz versus NHST
Was passiert da eigentlich genau unter der Motorhaube? Schauen wir uns an, wie Google Optimize berechnet, ob eine Variante gewonnen hat oder nicht. Im Gegensatz zu Adobe Test & Target zum Beispiel oder den meisten Signifikanzrechnern wie dem von Konversionskraft (wobei Konversionskraft nicht mal sagt, was für einen Test sie nutzen), basiert Google Optimize nicht auf einem t-Test, Mann-Whitney-U- oder Chi Square-Test, sondern auf einem Bayes-Inferenz-Verfahren. Was bedeutet das?
Hier treffen zwei unterschiedliche Vorstellungen aufeinander, die der sogenannten Frequentists (NHST steht für Null Hypothesis Significance Testing) und die der Bayesschen Inferenz-Anhänger. Diese wurden und werden zum Teil immer noch in der Statistik intensiv diskutiert, und ich bin nicht der Richtige, um hier ein Urteil zu fällen. Aber ich versuche, diese beiden Ansätze für Nicht-Statistiker zu beleuchten.
In den meisten A/B-Test-Tools werden Hypothesen-Tests durchgeführt. Man hat zwei Gruppen von ungefähr gleicher Größe, die eine Gruppe wird einem “Treatment” ausgesetzt, und dann wird beobachtet, ob sich der definierte KPI in der Testgruppe “signifikant” ändert. Für Signifikanz wird meistens auf den p-Wert geschaut; sofern dieser unter 0,05 liegt oder wie auch immer das Signifikanz-Niveau definiert wurde, wird die Null-Hypothese abgelehnt. Zwar sieht man auf den Tool-Oberflächen nichts von Null-Hypothesen etc, wahrscheinlich um die Nutzer nicht zu verwirren, aber das Denkkonstrukt dahinter geht davon aus. Wird zum Beispiel getestet, ob ein roter Button häufiger angeklickt wird als ein blauer, so würde die Null-Hypothese lauten, dass beide gleich häufig angeklickt werden. Der Hintergrund davon ist, dass sich eine Hypothese nicht immer belegen lässt. Wenn aber das Gegenteil der Hypothese eher unwahrscheinlich ist, so kann angenommen werden, dass eine Hypothese eher wahrscheinlich ist. Von nichts anderem handelt der p-Wert.
Nun ist der p-Wert keine einfache Geschichte, nicht einmal Wissenschaftler schaffen es, den p-Wert so zu erklären, dass es verständlich ist, und es wird diskutiert, ob er überhaupt sinnvoll ist. Der p-Wert sagt nichts darüber aus, wie “wahr” ein Testergebnis ist. Er sagt lediglich etwas darüber aus, wie wahrscheinlich es ist, dass dieses Ergebnis auftritt, wenn die Null-Hypothese wahr ist. Bei einem p-Wert von 0,03 bedeutet das also, dass die Wahrscheinlichkeit, dass ein Ergebnis auftritt bei einer wahren Null-Hypothese, bei 3% liegt. Das bedeutet umgekehrt nicht, wie “wahr” die Alternative Hypothese ist. Der umgekehrte p-Wert (97%) bedeutet also nicht eine Wahrscheinlichkeit, dass eine Variante eine andere Variante schlägt.
Ein häufiges Problem mit a/b-Tests ist zudem, dass die Sample-Größe nicht vorher definiert wird. Der p-Wert kann sich über die Laufzeit eines Experiments ändern, und so können statistisch signifikante Ergebnisse nach ein paar Tagen schon nicht mehr signifikant sein, da sich die Anzahl der Fälle geändert hat. Außerdem interessiert nicht nur die Signifikanz, sondern auch die Stärke/Trennschärfe/Power eines Tests, die nur in den wenigsten Test-Tools angezeigt wird.
Das sind aber vor allem Probleme der Tools, nicht des Frequentists-Ansatzes, der von den meisten Tools genutzt wird. Das “Problem” des Frequentists-Ansatzes ist, dass sich ein Modell nicht ändert, wenn neue Daten hereinkommen. So kann bei wiederkehrenden Besuchern eine Änderung auf der Seite irgendwann gelernt werden, so dass ein anfänglicher a/b-Test zwar große Wirkung prophezeit, die tatsächliche Wirkung aber viel geringer ist, weil im Frequentists-Ansatz einfach nur die Gesamtzahl von Conversions gezählt wird, nicht die Entwicklung. In der Bayesschen Inferenz werden neu hereinkommende Daten aber berücksichtigt, um das Modell zu verfeinern; geringer werdende Conversion-Raten würden das Modell beeinflussen. Daten, die sozusagen “vorher” vorhanden sind und die Annahmen über den Einfluss in einem Experiment beeinflussen, werden Anfangswahrscheinlichkeit oder “Priors” genannt (ich schreibe Priors, weils schneller geht). Das Beispiel in der Google-Hilfe (das auch anderswo gerne bemüht wird), ist, dass, wenn man sein Handy im Haus verlegt, nach der Bayesschen Inferenz das Wissen, dass man sein Handy gerne mal im Schlafzimmer vergisst, verwenden und auch einem Klingeln “hinterherlaufen” darf. Bei den Frequentists darf man das nicht.
Und hier genau tut sich das Problem auf: Woher wissen wir, dass die “Priors” relevant sind für unsere aktuelle Fragestellung? Oder, wie es im Optimizely-Blog gesagt wird:
The prior information you have today may not be equally applicable in the future.
Die spannende Frage ist nun, wie Google in Optimize auf die Priors kommt? Dazu wird folgende Aussage gemacht:
Despite the nomenclature, however, priors don’t necessarily come from previous data; they’re simply used as logical inputs into our modeling.
Many of the priors we use are uninformative – in other words, they don’t affect the results much. We use uninformative priors for conversion rates, for example, because we don’t assume that we know how a new variant is going to perform before we’ve seen any data for it.
An diesen beiden Blogauszügen wird schon deutlich, wie unterschiedlich das Verständnis von der Nützlichkeit der Bayesschen Inferenz ist Gleichzeitig ist offensichtlich, dass uns wie in jedem anderen Tool auch Transparenz darüber fehlt, wie genau die Berechnungen zustande gekommen sind. Ein weiterer Grund, dass man, wenn man auf Nummer sicher gehen will, die Rohdaten benötigt, um eigene Tests durchzuführen.
Der Bayes-Ansatz erfordert mehr Rechenzeit, was wahrscheinlich der Grund dafür ist, dass die meisten Tools nicht diesen Ansatz nutzen. Es existiert auch Kritik an der Bayes-Inferenz. Das Hauptproblem aber ist, dass die meisten Nutzer viel zu wenig wissen von dem, was genau die a/b-Test-Tools tun und wie belastbar die Ergebnisse sind.
Warum ein A/A-Test auch heilsam sein kann
Nun stellt sich die Frage, warum überhaupt ein Unterschied sichtbar war bei der Session Duration, wenn doch kaum jemand gesucht hat. Hier kann ein A/A-Test helfen. A/A-Test? Richtig gelesen. Auch sowas gibt es. Und ein solcher Test hilft dabei, die Varianz der eigenen Seite zu identifizieren. So hatte ich einen wunderbaren Test, bei dem ich die AdSense-Klickrate nach einer Design-Änderung getestet hatte. Die Änderung war sehr erfolgreich. Um ganz sicher zu gehen habe ich noch mal getestet; dieses Mal hatte die Änderung schlechtere Werte. Nun kann es natürlich sein, dass einfach schlechtere Ads geschaltet wurden und sich deswegen die Klickrate verschlechtert hatte. Es könnte aber auch einfach sein, dass die Seite selber eine Varianz hat. Und diese kann man herausfinden, indem man einen A/A-Test fährt (oder die vergangenen Rohdaten für einen solchen Test nutzt). Bei so einem Test wird in der Test-Variante einfach nichts geändert und dann geschaut, ob sich einer der Haupt-KPIs ändert oder nicht. Rein theoretisch sollte sich nichts ändern. Aber wenn doch? Dann habe wir eine Varianz identifiziert, die in der Seite und dem Traffic selbst liegt. Und die wir in zukünftigen Tests berücksichtigen sollten.
Fazit
Unterschiede in Test-Ergebnissen können durch eine bereits bestehende Varianz einer Seite zustande kommen. Hier hilft ein A/A-Test, um die Varianz kennen zu lernen.
Die Ergebnisse können sich unterscheiden, wenn unterschiedliche Tools eingesetzt werden, da die Tools unterschiedliche Herangehensweisen haben, wie sie die “Gewinner” ermitteln.
Rohdaten können helfen, eigene Test-Statistiken zu verwenden oder Test-Ergebnisse zu verifizieren, da die Tools wenig Transparenz darüber bieten, wie sie zu den jeweiligen Tests gekommen sind. So kann es zum Beispiel wie in meinem Beispiel sein, dass der Test gar nicht gleichmäßig ausgespielt wurde und daher die Ergebnisse nicht so eindeutig verwendbar sind.
Die Rohdaten unterscheiden sich zum Teil stark von den Werten in der GUI, was nicht erklärbar ist.
Der p-Wert ist nur ein Teil der Wahrheit und wird häufig missverstanden.
Bei a/b-Tests sollte man sich bei den Frequentists-Ansätzen vorher überlegen, wie groß die Sample-Größe sein sollte.
Alles geht auf Philiosophie zurück. Und das Internet wäre ohne die Briten nicht möglich gewesen. Erinnert mich etwas an den UK-Pavilion auf der Expo 2000, in dem der iMac ausgestellt wurde. Schließlich wurde auch dieser von einem Briten, Jonathan Ive, entworfen. Ansonsten eine absolut empfehlenswerte Dokumentation, hier auf der BBC-Seite zu sehen.
