Zum Jubiläum der Website Boosting (60. Ausgabe!) gibt es hier einen Deep Dive, wie man einen benutzerdefinierten Bericht zu den bis zum Ende gelesenen Texten erstellen kann. Dies ist eine Ergänzung zu meiner vierteiligen Serie “Webanalyse: Wie aus Daten Taten folgen”, in der 60. Ausgabe findet sich der 3. Teil. Grundsätzlich hatte ich über das Thema auch schon einmal hier geschrieben im Vergleich zur Scrolltiefe. Dies ist ein Beispiel dafür, wie benutzerdefinierte und berechnete Messwerte verwendet werden können.
In dem Screenshot wird pro Seite angegeben:
Wie viele Wörter ein Text hat
Wie häufig eine Seite aufgerufen wurde
Der Anteil der Aufrufe, der zu einem Ausstieg geführt hat
Die Anzahl der Sichtbarkeit des YARPP-Elements (YARPP steht für Yet Another Related Posts Plugin, welches ähnliche Artikel am Schluss eines Artikels anzeigt. Ist dieses Element auf dem Bildschirm des Nutzers sichtbar, so wird davon ausgegangen, dass der Artikel über dem Element zu Ende gelesen wurde)
Der Anteil der Sichtbarkeit des YARPP-Elements mit Hinblick auf alle Seitenaufrufe
Die Anzahl der Klicks auf einen YARPP-Link
Der Anteil der Klicks auf einen YARPP-Link in Bezug auf die Sichtbarkeit des Elements
Welches Problem wird mit diesem Bericht gelöst?
Wird ein Text seltener zu Ende gelesen als andere Texte, dann scheint dieser Text nicht so interessant geschrieben zu sein.
Die Länge des Textes könnte ein Prädiktor dafür sein, ob ein Text zu Ende gelesen wird; wird aber ein kürzerer Text nicht zu Ende gelesen, so könnte das ein noch stärkeres Signal dafür sein, dass der Text optimierungswürdig ist.
Werden die Links zu ähnlichen Artikel nicht angeklickt, obwohl sie sichtbar sind, so scheinen sie nicht relevant zu sein.
Erstellen der benutzerdefinierten Dimension und Messwerte
In Analytics auf Verwaltung (links unten) gehen und dann in der Property-Spalte auf Benutzerdefinierte Definitionen klicken.
Zunächst auf Benutzerdefinierte Messwerte und dann auf den roten Button Neuer Benutzerdefinierter Messwert klicken
Einen verständlichen Namen auswählen (z.B. “YARPP Seen”)
Der Umfang (Scope) ist Treffer (Hit)
Der Formatierungstyp ist Ganzzahl (Integer)
Die restlichen Werte können leer gelassen werden
Auf Speichern klicken.
Den Prozess noch einmal wiederholen, dieses Mal für die “YARPP Clicks”. Die Einstellungen sind dieselben.
Der erste Eintrag sollte nun den Index-Wert 1 haben, der zweite Eintrag den Index-Wert 2, es sei denn, es wurden schon einmal benutzerdefinierte Variablen definiert.
Sollte auch die Anzahl der Wörter eines Textes erfasst werden, so ist dazu eine benutzerdefinierte Dimension notwendig. Der Prozess ist ähnlich, hier wieder einen passenden Namen auswählen und den Umfang Treffer. Auch hier muss der Index-Wert für diese benutzerdefinierte Dimension in Erinnerung oder notiert werden, da er später im Google Tag Manager verwendet werden soll.
Implementierung im Google Tag Manager
Sind die benutzerdefinierten Definitionen und Messwerte implementiert, so können nun Werte in diese Variablen geschrieben werden. Dies geschieht mit dem Tag Manager. Zunächst einmal muss das Element ausgewählt werden auf der Seite, bei dem der Trigger der Sichtbarkeit ausgelöst werden soll. Die dazu notwendigen Schritte sind bereits in diesem Artikel beschrieben. Dann wird der folgende Trigger konfiguriert:
Der Trigger feuert einen Tag, der nun auch noch konfiguriert werden muss:
Wichtig ist in diesem Schritt, dass die Einstellungen überschrieben werden, da nur so ein Messwert als benutzerdefinierter Messwert (im Screenshot Custom Metrics) übergeben werden kann. Hier muss dann der Indexwert gewählt werden, der in dem Schritt oben von Analytics definiert wurde. Der Wert des Messwerts ist hier 1, da für jede Sichtung der Zähler um 1 nach oben springt.
Die Variable Scroll Depth Threshold ist nicht notwendig, eventuell muss sie zunächst konfiguriert werden. Dieser Schritt muss dann noch einmal wiederholt werden für die Klicks auf einen YARPP-Link und gegebenenfalls für die benutzerdefinierte Dimension der Anzahl Wörter pro Text. Diese können aber bereits in den Google Analytics Einstellungen übergeben werden, die als Variable definiert werden. In meinem Fall sieht die Konfiguration so aus:
Wie man schön sehen kann, ist an meiner Konfiguration einiges speziell, aber der WordCount wird in eine benutzerdefinierte Dimension mit dem Indexwert 7 übergeben.
Erstellen des berechneten Messwerts
Damit eine Ratio beziehungsweise Conversion Rate angezeigt werden kann, wird ein berechneter Messwert erstellt. Dies sind die Spalten “YARPP Seen CVR” und “YARPP Click CVR” in dem Beispiel-Bericht im ersten Screenshot. Hinweis: Es kann etwas dauern, bis die benutzerdefinierten Messwerte hier sichtbar sind! Das heißt, dass dieser Arbeitsschritt eventuell erst nach einigen Stunden oder sogar erst nach einem Tag durchführbar ist.
In dem Screen Verwaltung in der ganz rechten Spalte findet sich der Eintrag Berechnete Messwerte. Hier auf den roten Button Neuer Berechneter Messwert klicken und dann im folgenden Screen die folgenden Einstellungen übernehmen. Es reicht, die ersten Buchstaben des Variablennamens einzutippen, Analytics vervollständigt die Namen. Dies ist die Einstellung für die Click CVR:
Für die Seen CVR wird die Formel {{YARPP seen}} / {{Seitenaufrufe}} verwendet.
Erstellen des benutzerdefinierten Berichts
Zu guter Letzt wird nun ein Bericht erstellt, so wie er im ersten Screenshot oben zu sehen ist. Unter Anpassung (links oben) und Benutzerdefinierte Berichte kann ein neuer Bericht erstellt werden. Hier werden alle gerade benutzerdefinierten und relevante ab Bord verfügbare Metriken ausgewählt und dazu die passende Dimension ausgewählt. Leider kann hier keine sekundäre Dimension bereits ausgewählt werden; dies muss dann manuell geschehen, wenn der benutzerdefinierte Bericht aufgerufen wird.
Ich habe den Sinn eines bestimmten Diagramms in Google Analytics nie verstanden, und zwar den des Tortendiagramms, das das Verhältnis der neuen Nutzer zu den wiederkehrenden Nutzern zeigt. Es war früher im Standard-Dashboard, das ein Nutzer nach dem Login sah, und ich hatte mich immer für dieses Diagramm entschuldigt, wenn ich während meiner Zeit bei Google eine Google Analytics-Demo gezeigt hatte.
Tortendiagramm: Nur für statische Zusammensetzungen
Was ist so schlimm an diesem Diagramm? Zunächst einmal wird ein Tortendiagramm für statische Zusammenstellungen verwendet. Wenn ich wissen möchte, wie die Geschlechteraufteilung meines Kurses ist, dann ergibt ein Tortendiagramm Sinn. Die Geschlechter werden sich größtenteils nicht ändern während des Kurses.
Die meisten Webseiten wollen aber die Anzahl ihrer Besucher erhöhen, sei es durch neue Nutzer, wiederkehrende Nutzer oder beides. Eine Entwicklung ist also das Ziel, und somit ist ein Tortendiagramm nicht sinnvoll, da es ja statische Konstellationen zeigt. Ein Liniendiagramm, das die Entwicklung über die Zeit zeigt, ist in den meisten Fällen sicherlich eine bessere Wahl.
Die beiden Metriken sind unabhängig voneinander
Ich gehe jetzt aber noch einen Schritt weiter und behaupte, dass diese beiden Metriken nichts miteinander zu tun haben und deswegen auch nie in einem Diagramm dargestellt werden sollten. Neue Benutzer können wiederkehrende Nutzer werden, müssen es aber nicht. Und wiederkehrende Nutzer können in dem gleichen Zeitraum auch neue Nutzer gewesen sein, sie werden dann zwei Mal gezählt. Wenn ein Nutzer also in beiden Teilen des Tortendiagramms auftauchen kann, was sagt das Verhältnis der beiden Teile zueinander dann aus?
Neue Nutzer entstehen durch Marketing. Idealerweise kommen wiederkehrende Nutzer dadurch zustande, dass die Inhalte so toll sind, dass die Nutzer nicht mehr ohne sie leben wollen. Wenn ich keine neuen Nutzer bekomme, dann muss ich mein Marketing optimieren. Wenn meine Nutzer nicht wiederkehren, dann muss ich meine Inhalte optimieren. Da wir immer auf der Jagd nach sogenannten “Actionable Insights” sind, warum sollten wir dann zwei Metriken in einem Diagramm darstellen, wenn sie unterschiedliche korrigierende Maßnahmen erfordern?
Außerdem: Ich kann zwei Wochen lang viel Geld für Marketing ausgeben, so dass sich der Anteil neuer Nutzer massiv erhöht und der Anteil wiederkehrender Nutzer in der Ratio dadurch stark verringert. Selbst wenn die absolute Zahl wiederkehrender Nutzer gleich bleibt, würde die Ratio uns vermitteln, dass wir weniger wiederkehrende Nutzer hätten. Aus diesem Grund sollten diese beiden Metriken nie zusammen als Ratio, sondern stets getrennt angezeigt werden. Serviervorschlag: Ein Graph mit der Entwicklung der neuen Nutzer mit den Akquisekanälen, ein Graph mit den wiederkehrenden Nutzern und den Inhalten, die für die Wiederkehr verantwortlich sein könnten.
Was ist eigentlich mit den nicht-wiederkehrenden Nutzern?
Diese Frage stellte heute eine Kursteilnehmerin, und diese Frage finde ich aus mehreren Gründen gut. Wir wissen nicht, ob neue Nutzer wiederkehrende Nutzer sein werden (abgesehen von denjenigen neuen Nutzern, die in unserem Zeitraum neu als auch wiederkehrend sind, weil sie 2 Mal kamen, aber sie könnten sich natürlich in der Zukunft gegen einen weiteren Besuch entscheiden). Insofern könnte jeder Nutzer, der einmal dagewesen ist, irgendwann einmal in der Zukunft wiederkommen. Technisch gesehen kann kein Nutzer, der seine Cookies gelöscht hat, als wiederkehrender Nutzer bei uns wieder auftauchen, von User ID-Gebrauch einmal abgesehen. Aber dennoch finde ich die Frage spannend, da ich mich in einem anderen Kontext mit ihr beschäftigt habe: Ab wann muss ich einen Kunden bei einem Produkt, das regelmäßig gekauft wird, als verloren ansehen?
Die Grafik soll meine Gedanken dazu verdeutlichen. Wir haben einen Punkt “Heute” und drei Nutzer, blau, rot und grün. Nutzer blau kommt in mehr oder weniger regelmäßigen Abständen vorbei. Bei dem Zeitpunkt “Heute” würde ich davon ausgehen, dass er auch in Zukunft wiederkommt, zumindest scheint die Wahrscheinlichkeit hoch zu sein. Nutzer grün war erst vor kurzem da. Er hatte vielleicht keine Chance, wiederzukommen. Nutzer rot war vor langer Zeit da, und verglichen mit den Zeitabständen, die Nutzer blau zwischen seinen Käufen hat, scheint die Wahrscheinlichkeit einer Wiederkehr gering zu sein. Er kann wiederkommen, aber ihn würde ich eher mit einem Incentive anlocken als Nutzer grün, der eventuell eh wiederkommen wird (pull-forward cannibalization).
Wir können also nichts Genaues über nicht-wiederkehrende Nutzer sagen, denn wir kennen die Zukunft nicht. Aber wir können mit Wahrscheinlichkeiten rechnen. Bei reinen Nutzern eventuell nicht so spannend. Aber bei Shop-Kunden schon spannender.
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.
