Als Produktbesitzer steht man häufig vor der Frage, ob man mit Option A oder Option B fortfahren soll. Oder welche Version des Bildschirms sollte implementiert werden, um bessere Ergebnisse zu erzielen? Solche Entscheidungen zu treffen kann eine Herausforderung sein, insbesondere wenn Sie unter engen Fristen und begrenzten Ressourcen stehen. Darüber hinaus werden solche Entscheidungen auf der Grundlage persönlicher Beurteilung oder des Nachahmens des Ansatzes eines Konkurrenten getroffen, was zu suboptimalen Ergebnissen führen kann.
Die gute Nachricht ist, dass man solche Fallstricke vermeiden kann, indem man eine einfache Experimentierumgebung einrichtet, die relativ wenig Aufwand erfordert. In diesem Artikel beschreiben wir, wie Sie dies erreichen können.
Die Einrichtung einer Experimentierumgebung ist aus zwei Gründen wichtig:
Erstens können Sie so sicherstellen, dass Sie nach der Implementierung neuer Funktionen auf der Grundlage eines datengesteuerten Ansatzes die beste Option auswählen.
Zweitens ermöglicht es Ihnen, die bestehende Funktionalität Ihres Produkts kontinuierlich zu verbessern, indem Sie „Ist-Zustände“ mit hypothetischen „zukünftigen“ Optionen vergleichen und eine „Was-wäre-wenn“-Analyse durchführen.
Bevor wir mit dem Ansatz fortfahren, wollen wir einige der Mythen entlarven, die Produktbesitzer normalerweise in die Irre führen:
Ich benötige viele Ressourcen, um eine komplexe Umgebung einzurichten, die die Durchführung von Experimenten und A/B-Tests ermöglicht
Falsch : Der beschriebene Ansatz beansprucht weniger als eine Woche der Ressourcen Ihres Softwareentwicklers.
Ich benötige einen gut etablierten Datenerfassungsprozess und eine detaillierte Ereignisverfolgung
Falsch : Sie können sich auf eine vorhandene Datenbank verlassen, die Informationen über den Lebenszyklus der Haupteinheit Ihres Produkts speichert. Zum Beispiel Bestellstatus, wenn Sie ein Lieferdienst sind.
Ich brauche ein engagiertes Team von Analysten, das meine Anfragen täglich bearbeitet
Falsch : Sobald Sie den Ansatz und die Metriken Ihres Experiments verstanden haben, können Sie mithilfe einer einfachen SQL-Abfrage regelmäßig selbst Daten abrufen.
Um Ihre Experimentierumgebung einzurichten, wird empfohlen, die folgenden Schritte auszuführen:
Bevor Sie sich an Ihren Produktdesigner wenden, definieren Sie die Ziele und Kennzahlen, die im Rahmen Ihres Experiments gemessen werden sollen. Bei einer klassischen „Option A oder Option B“-Frage ist in der Regel klar, was Sie mit der Umsetzung einer Änderung erreichen möchten. Beispielsweise könnten Sie einen bestimmten Teil des Trichters ansprechen.
Nehmen wir zur Veranschaulichung an, dass Sie in einem Lieferunternehmen arbeiten und sich derzeit auf das Auftragserstellungsformular konzentrieren. Sie möchten einen relativ geringen Prozentsatz an Nutzern ansprechen, die ihre Lieferadresse angeben und dann eine Versandart auswählen. Stellen Sie sich außerdem vor, Sie hätten zwei neue Versionen der Reise:
Aktuelle Version : Auf einem Bildschirm müssen Adressen eingegeben und die Karte mit einer Stecknadel basierend auf der angegebenen Adresse angezeigt werden. Auf dem nächsten Bildschirm können Sie eine Versandart basierend auf der angegebenen Adresse auswählen.
Neue Version : Auf dem Einzelbildschirm müssen Sie die Adresse eingeben und dort die Versandart auswählen.
Ziel ist es herauszufinden, welche der Optionen zu einem höheren Anteil an Nutzern führt, die ihre Adresse angegeben und eine Versandart ausgewählt haben. Die Kennzahlen sind recht einfach: % der Benutzer, die ihre Adresse angegeben und eine Versandart ausgewählt haben.
Tatsächlich gibt es zwei Möglichkeiten, solche Daten zu messen :
Basierend auf den Daten, die durch die Gestaltung Ihres Backends bereits verfügbar sind . Stellen Sie sich beispielsweise eine Datenbank vor, die Informationen zum Lebenszyklus der Bestellung enthält. Ihre Bestellung könnte Zustände oder Status haben wie:
Entwurf erstellt
Versuchen Sie, Versandarten zu finden
Versandoptionen gefunden/ Versandoptionen nicht gefunden
Ereignisverfolgung – Dies funktioniert nicht sofort und erfordert daher zusätzlichen Aufwand für die Implementierung. Die Ereignisverfolgung ermöglicht Ihnen jedoch eine detailliertere Analyse, z. B. können Gerätetyp und Browsername als Parameter Ihrer Ereignisse übergeben werden.
In den nächsten Abschnitten dieses Artikels konzentrieren wir uns auf den ersten Ansatz, also die bestehende Datenarchitektur ohne Ereignisverfolgung.
Im Experimentablauf sollten zwei Hauptschritte abgeschlossen sein:
Die Idee besteht darin, ein leichtes A/B-Test-Framework zu entwickeln, das so einfach wie möglich sein sollte und es Ihnen ermöglichen sollte, Experimente mit den folgenden Parametern zu erstellen:
Durch die Möglichkeit, diese Parameter zu konfigurieren, können Sie ein Stichprobenlimit festlegen und die Kandidaten für das Experiment nach dem Zufallsprinzip auswählen, bis die gewünschte Stichprobengröße erreicht ist.
Hierfür sind sowohl beim Client als auch beim Server Änderungen erforderlich: Der Server sollte die Anzahl der Kandidaten pro Experiment verfolgen und das Backend entscheidet, ob der aktuelle Benutzer an einem Experiment teilnehmen soll oder nicht. Das Backend entscheidet anhand der aktuellen Stichprobengröße und einer festen Wahrscheinlichkeit, ob der authentifizierte Benutzer Teil des Experiments sein soll. Darüber hinaus sollte das Backend eine Sammlung von Benutzern verwalten, die Teil eines bestimmten Experiments sind, um den Benutzern konsistente Erfahrungen zu bieten und die Experimentergebnisse ordnungsgemäß zu berechnen.
So könnte der Endpunkt für die Konfiguration des Experiments aussehen:
POST /api/your-service/experiment-create
Anfrage:
{ experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e", maximum_sample_size: 250, groups: { { group_name: "old_journey", probability_of_falling_in: 0.5 }, { group_name: "new_journey", probability_of_falling_in: 0.5 },}
Antwort:
{
200,
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
Sie benötigen einen separaten Endpunkt, der für die Zuweisung eines bestimmten Benutzers zum Experiment und der entsprechenden Gruppe verantwortlich ist. Nennen wir es experiment-enrollments
.
Beim Entwerfen der gesamten Umgebung sollten Sie sich darüber im Klaren sein, in welcher Phase der User Journey der experiment-enrollments
Endpunkt aufgerufen werden soll. Darüber hinaus kann es vorkommen, dass nicht alle Nutzer an dem Experiment teilnehmen sollten. Aus diesem Grund wäre es sinnvoll, auch einem Endpunkt ein Benutzerauthentifizierungstoken bereitzustellen.
Wenn wir uns in unserem Beispiel nur auf neue Benutzer konzentrieren möchten, die ihre erste Bestellung aufgeben, können wir mithilfe der Benutzerauthentifizierung bestimmen, um welchen Benutzertyp es sich handelt und ob einer für das Experiment angemeldet werden sollte. Stellen Sie außerdem sicher, dass nach dem Aufruf des Endpunkts alle erforderlichen Informationen verfügbar sind und berücksichtigen Sie die Besonderheiten Ihrer Reise und Ihres Lebenszyklus.
Der Endpunkt experiment-enrollments
wird unten beschrieben. Es kann zu einem bestimmten Zeitpunkt der Reise (z. B. vor der Landung auf dem Bildschirm mit der Anforderung einer Lieferadresse) für bestimmte Benutzertypen aufgerufen werden (z. B. nur für neue Benutzer, die die Adresse noch nicht angegeben haben) und berechnet, ob der aktuelle Benutzer teilnehmen soll in einem bestimmten Experiment oder nicht:
POST /api/your-service/experiment-enrollments
, Benutzerauthentifizierungstoken ist erforderlich
Anfrage:
\ {
experiment_id: "f380739f-62f3-4316-8acf-93ed5744cb9e"
}
Antwort:
{200, enrolled: true/false, group_name: group_1,}
Um zu veranschaulichen, wie der theoretische Datenfluss aussehen würde, nehmen wir das gleiche Beispiel für den Bestellerstellungsfluss im Lieferunternehmen an. Sie wählen zwischen zwei Optionen für den Auftragserstellungsbildschirm.
Die folgenden Endpunkte werden im Diagramm unten erwähnt, nämlich:
/create-order-draft (Schritt 3)
/find-shipping-method (Schritt 16)
/Bestellung absenden (Schritt 20)
werden zur Unterstützung des veranschaulichenden Beispiels bereitgestellt und sind keine notwendigen Teile der Experimentierumgebung
Außerdem wird im Folgenden die veranschaulichende und vereinfachte Architektur von Datenbanken bereitgestellt.
Es gibt 3 Haupttabellen:
Experiments set
– es enthält alle Experimente, die Sie zuvor erstellt haben. Die Datenbank wird jedes Mal aktualisiert, wenn Sie den Endpunkt /experiment-create
aufrufen.
Experiments database
– sie enthält alle Datensätze, die mit jeder Registrierung eines bestimmten Benutzers verknüpft sind. Die Datenbank wird jedes Mal aktualisiert, wenn Sie den Endpunkt experiment-enrollments
aufrufen
Order lifecycle database
– sie wird bereitgestellt, um das illustrierte Beispiel zu unterstützen, wie experimentelle Daten gespeichert werden können. Der Punkt ist, dass Sie anhand dieser Tabelle (oder einer ähnlichen Tabelle, die den Besonderheiten Ihres Produkts entspricht) sehen können, ob die Eingabe (z. B. die Auftragserstellung) für den bestimmten Benutzer, der in einer der von Ihnen ausgewählten Versuchsgruppen registriert ist, erfolgreich war oder nicht. Ich habe es eingestellt. In unserem Beispiel können wir uns auf den Status „Versandart ausgewählt“ verlassen, der den Schluss zulässt, dass der Benutzer die Versanddetails erfolgreich angegeben und dann eine der vorgeschlagenen Versandarten ausgewählt hat.
Vorteile:
Nachteile:
Aufgaben und indikative Schätzungen:
Sobald Sie Ihr Backend entworfen haben, stimmen Sie mit Ihrem Frontend-Team ab, wie es die Informationen am besten erhalten kann und in welcher Phase des Ablaufs.
Beachten Sie die wichtigsten Abhängigkeiten und reduzieren Sie diese:
Sobald Ihr Experiment über eine ausreichende Zeitspanne läuft, ist es wichtig, die Ergebnisse zu analysieren und zu interpretieren, um aussagekräftige Schlussfolgerungen zu ziehen.
Definieren Sie die Liste der Felder, die Sie benötigen, um die Auswirkung auf Metriken zu berechnen, auf die Sie sich zuvor konzentriert haben.
Aus dem veranschaulichenden Beispiel oben wären die Datenquellen zwei Tabellen:
Experiments database
:Eingabe : Experiment-ID, nach der Sie Ergebnisse suchen
Ausgabe : Liste aller Benutzer-IDs, die Teilnehmer eines bestimmten Experiments sind, die Gruppe, der jeder Benutzer zugewiesen wurde, und Zeitstempel, wann der Benutzer zugewiesen wurde
Order lifecycle database
Basierend auf diesen Daten können Sie den Prozentsatz erfolgreich erstellter Bestellungen für jede der Experimentgruppen berechnen.
Bei der Analyse Ihrer Ergebnisse ist es wichtig, über die reinen Zahlen hinauszuschauen. Sie sollten auch nach statistischer Signifikanz suchen, um sicherzustellen, dass alle Unterschiede, die Sie zwischen Ihren Testgruppen beobachten, nicht nur auf zufällige Zufälle zurückzuführen sind. Ich werde mich nicht zu sehr auf diesen Teil konzentrieren, da ich in dieser und anderen Online-Ressourcen bereits zahlreiche Artikel zu diesem Thema sehe. Übermäßige Kenntnisse sind hier jedenfalls nicht erforderlich: Meiner Meinung nach würde es ausreichen, den Z-Test oder T-Test anwenden zu können, um die Signifikanz des Unterschieds zwischen den beiden Gruppen zu überprüfen.
Sobald Sie jedoch festgestellt haben, dass Ihre Ergebnisse statistisch signifikant sind, können Sie damit beginnen, Schlussfolgerungen darüber zu ziehen, welche Option Ihres Produkts besser abschneidet.
Nachdem Sie ein Experiment erfolgreich durchgeführt und ein ausreichendes Maß an Vertrauen hinsichtlich der besten Option gewonnen haben, besteht der nächste Schritt darin, Ihre Änderungen auf Ihr Produkt auszuweiten. Es kann mehrere Ansätze geben:
Am einfachsten ist es, die Konfiguration Ihres Experiments so anzupassen, dass 100 % der Benutzer zu der Gruppe gehören, die bessere Ergebnisse zeigt . Sie müssen sich in Zukunft etwas Zeit nehmen, um den Code zu bereinigen, damit die Anzeige dieses speziellen Teils der Benutzeroberfläche unabhängig von der Experimentierumgebung ist
Weniger einfach ist es, wenn Ihr Produkt auf mehreren Plattformen verfügbar ist. Seien Sie besonders vorsichtig bei der Annahme, dass die Ergebnisse von Experimenten zum Web-Flow auf den mobilen App-Flow zutreffen (und umgekehrt). Manchmal ist es besser, auf Nummer sicher zu gehen und ein separates Experiment auf ähnliche Weise durchzuführen, jedoch auf einer anderen Plattform.
Eine eigene Experimentierumgebung ist für jeden Produktmanager ein sehr praktisches Werkzeug. Unabhängig davon, in welchem Reifegrad sich Ihr aktuelles Produkt befindet, sollte die Erstellung einer Experimentierumgebung nicht allzu viel Zeit in Anspruch nehmen. Wenn Sie relativ geringe einmalige Kosten zahlen, um es zum Laufen zu bringen, werden Sie ziemlich schnell den Return on Investment sehen.
Abschließend noch ein paar Tipps, um sicherzustellen, dass die Ergebnisse des Experiments Sinn ergeben:
Indem Sie diese Best Practices befolgen, können Sie eine effektive Experimentierumgebung einrichten, die Ihnen dabei helfen kann, datengesteuerte Entscheidungen zu treffen und Ihre Konversionsraten im Laufe der Zeit zu steigern.