von Rostyslav Mykhajliw Gründer von TrueSocialMetrics.com ~ 4 min
Das klassische A/B-Testing ist eine Verteilung zwischen verschiedenen Zuständen. Beginnen wir mit einem allgemeinen Beispiel, das jeder verwendet. Wir haben eine Seite mit einem Anmelde-Button, derzeit ist er blau, aber wir wollen eine neue Farbe rot testen.
Dann weisen wir dort etwas Verkehr zu und warten auf einiges. Es gibt einen einfachen Rechner für statistical significance.
Option A: 50.000 Besuche – 500 Anmeldungen Optionen B: 50.000 Besucher – 570 Anmeldungen – Gewinner
B ist ein Gewinner, es ist klar. Mehr Anmeldungen, statistische Signifikanz.
Warten Sie ein wenig! Was wir veröffentlichen etwas Neues. Zum Beispiel fügen wir eine Schaltfläche „Demo“ hinzu, um einen Überblick über die Schritt-für-Schritt-Anleitung durch das Produkt zu erhalten.
Wenn wir einer einfachen Logik von A/B-Tests folgen – es funktioniert nicht! Weil wir Äpfel nicht mit Birnen vergleichen können. Wir können nichts mit etwas vergleichen! Es ist völlig falsch. Wenn es keine Demo-Schaltfläche gibt, erhalten Benutzer möglicherweise eine schlechtere Erfahrung als diejenigen, die diese Option haben. Diese Option hilft jedoch möglicherweise nur Benutzern, die sich bereits für das Produkt interessieren oder bereits erklärt haben, das Produkt kürzlich zu verwenden. Selbst wenn Sie Millionen von Traffic haben, können Sie nicht sagen, wie es in ein paar Stunden/Tagen funktioniert, da sich die Ergebnisse zeitlich verschieben können.
Denn eine neue Funktionalität sollte linear als enteraler Freigabeprozess freigegeben werden. Erst dann können wir uns das nach einiger Zeit ansehen und herausfinden, ob es einen Einfluss auf das Kundenerlebnis hatte oder nicht, aber die Geschäftskennzahlen verfolgen. A/B-Tests gelten NICHT für eine neue Funktionalität.
Kehren Sie mit der Anmeldeschaltfläche zum ersten Beispiel zurück. Wenn unsere Vermutung richtig ist, können wir mehr A-Optionen und mehr B-Optionen hinzufügen und nichts ändert sich, weil B den Kampf immer noch gewinnen kann.
Dann schauen Sie sich die Ergebnisse an:
A1: 50.000 Besuche – 500 Anmeldungen A2: 50.000 Besucher – 580 Anmeldungen – Gewinner B1: 50.000 Besucher – 570 Anmeldungen – Gewinner B2: 50.000 Besucher – 500 Anmeldungen
WAS! WAS! WAS! Sie können sagen, dass es unmöglich ist, aber diese Situation zeigt einen Unterschied, wenn die Besucherzuweisung Auswirkungen auf die Testergebnisse hat. Und diese Ergebnisse zeigen eine stabile statistische Signifikanz von 95 %, aber niedriges Vertrauen.
Wenn wir zum Anfang des Artikels zurückgehen, werden wir einen enormen Datenverkehr von 50.000 Besuchern und 500 Übergängen feststellen, die erforderlich sind, um aussagekräftige Ergebnisse zu erhalten. Allerdings haben nicht alle Seiten diese Möglichkeiten. Nicht alle Startups sind gut genug, um einen solchen Traffic zu generieren, oder es kann sich um Seiten mit geringem Traffic wie Einstellungen/Abrechnungen usw. handeln. In all diesen Fällen benötigen klassische a/b-Tests sehr viel Zeit, um Monate/Halbjahre Daten zu sammeln oder so. Der nächste Nachteil des allgemeinen Ansatzes ist, dass mindestens 50.000 Besucher (von 100.000, die dem Test zugewiesen wurden) ein schlechteres Kundenerlebnis haben. Wir warten also lange und verlieren Kunden durch die Zuordnung zu einem „Verlierer“-Test. Macht es irgendeinen Sinn ? Im Gesundheitswesen kreuzten die Ärzte die Fallthemen an, aber in einer Tabelle war das Leben der Menschen. Wenn wir in der Hexe einen Test machen, sterben 50% der Patienten wegen „Noch-nicht-getestet-Versorgung“. Und es ist verdammt verrückt. Hier ist ein Typ, Marvin Zelen, der auf die Idee des adaptiven Testens kam und jetzt Zelen’s design heißt.
Stellen wir uns vor, wir haben 2 Möglichkeiten: rote und blaue Bälle, also statistisch gesehen 50 % Wahrscheinlichkeit.
Zum Beispiel ordnen wir Besucher zufällig „blau“ zu und „blau“ ist ein besseres Erlebnis, weil wir Käufe erzielt haben. In diesem Fall gewinnt „blau“, deshalb fügen wir dem Pool eine zusätzliche „blaue“ Kugel hinzu.
Als Ergebnis änderte sich die Wahrscheinlichkeit „rot“ - 33 % und „blau“ - 67 %
Hört sich gut an! Aber der nächste Besucher mit "blau" tut nichts. „Blau“ verliert also, deshalb müssen wir einen „blauen“ Ball aus dem Pool entfernen und wir haben unseren vorherigen Zustand.
Pluspunkte: + funktioniert für wenig Verkehr + bietet adaptiv eine bessere Pflege für Benutzer Minuspunkte: - erfordert, dass Entwickler arbeiten, um während des Testvorgangs zu ermitteln, ob Tests gewonnen/verloren werden