Wie lange dauert ein Hypothesentest für eine mobile Anwendung? Zählen wir:
- Entwicklung einer Anwendung, die in verschiedenen Modi für verschiedene Benutzergruppen arbeitet.
- Ergebnis testen.
- Stellen Sie die Anwendung in die App Stores und warten Sie auf die Genehmigung.
- Warten auf Benutzer, um die Anwendung zu aktualisieren. Im Jahr 2019 haben die meisten die automatische Aktualisierung aktiviert, aber nicht jeder hat sie.
- Sammlung und Analyse von Statistiken.
- Die Anwendung auf den Stand der Gewinnerhypothese bringen, parallel zur Entwicklung der folgenden ...
Wenn Ihre Entwickler mit zweiwöchigen Iterationen an Scrum arbeiten, bedeutet dies normalerweise, dass das Testen einer Hypothese einen ganzen Monat dauert. Mit anderen Methoden kann dieser Zeitraum verkürzt werden, jedoch nicht wesentlich.
Dieser Zustand macht es unmöglich, den Rhythmus von „5 Hypothesen pro Woche“ zu erreichen, den viele Produktteams anstreben.
Im Folgenden werde ich Ihnen erklären, wie Sie diesen Prozess beschleunigen und verbessern können, und eine Reihe von vorgefertigten Lösungen angeben, die Sie verwenden können.
Lass uns gehen.
Ein- und Ausschalten
Bevor Sie sich mit Details befassen, müssen Sie einen zusätzlichen Begriff eingeben - das Feature-Flag-Muster (Feature-Toggle) .
Für Leser ohne technischen Hintergrund kann eine Klarstellung erforderlich sein:
Bei der Entwicklung einer neuen Funktion führt der Programmierer im Anwendungscode einen „Schalter“ ein, der diese Funktion aktiviert. Normalerweise wird diese Lösung verwendet, um unvollendete Funktionen im allgemeinen Programmcode fernzuhalten, aber natürlich kann sie auch zum Testen von Hypothesen verwendet werden.
Um das Feature-Flag-Muster beim Testen des Experiments zu verwenden, benötigen Sie:
- Voll entwickelte Funktionalität zum Experimentieren.
- Der Schalter dafür befindet sich im Standardzustand „Aus“.
- Fernschaltersteuerung vom Server.
Die Frage ist, wie viel Zeit gespart wird, wenn die Funktionalität vor der Durchführung von A / B-Tests noch entwickelt werden muss. Versuchen wir, die Phasen des Experiments zu analysieren:
Was sehen wir hier?
Erstens können wir mithilfe des Feature-Flags die Anwendung in Anwendungsspeicher hochladen, bevor wir sie vollständig auf Fehler testen. Wir müssen nur sicherstellen, dass sich die Anwendung beim Ausschalten der neuen Funktionalität wie zuvor verhält - und dies kann mit zuvor geschriebenen Autotests erfolgen. Der Rest kann getestet werden, während die Anwendung unter den Benutzern verteilt wird.
Zweitens können Sie nach Abschluss des Experiments das Feature-Flag verwenden, um die Funktionalität für alle Benutzer zu aktivieren / deaktivieren, bis die nächste Version fertig ist, in der das Flag nicht mehr verwendet wird.
Nach diesem Prinzip funktioniert der Apptimize-Dienst und bietet ein vorgefertigtes System für A / B-Tests.
Analysieren
Um ein Experiment durchzuführen, müssen Sie verschiedene Dinge tun:
- Wählen Sie ein Benutzersegment aus, wenn das Experiment nicht für alle geeignet ist.
- Wählen Sie die Größe des Publikums.
- Sammeln Sie Daten und nicht nur solche, die durch Experimente überprüft wurden. Der Rest der Geschäftsmetriken wird benötigt, um sicherzustellen, dass das Experiment nichts in anderen Metriken unterbricht.
- Sammeln und analysieren Sie das Ergebnis.
Wenn Sie die vorgefertigte Lösung von Apptimize nicht verwenden, ist der einfachste Ansatz eine Kombination aus Google Analytics für Firebase für Analytics und Firebase Remote Config zum Festlegen einzelner Konfigurationen (Segmente und Tests). Diese Tools arbeiten zusammen.
Dementsprechend benötigen Sie:
- Verwenden Sie Google Analytics für Firebase, um Geschäftsmetriken zu verfolgen.
- Verwenden Sie Firebase Remote Config, um Feature-Flags zu verwalten.
- Verwenden Sie Firebase Remote Config, um Segmente und Experimentparameter anzugeben.
- Analysieren Sie Daten aus Google Analytics mithilfe der Schlüssel aus Firebase Remote Config in der Analyse. Diese Funktion wird von diesen Tools "out of the box" bereitgestellt.
Wir werden weiter optimieren
Wir haben untersucht, wie der Hypothesentestzyklus für mobile Anwendungen verkürzt, der Zeitaufwand für das Testen und die Verbreitung der Versuchsergebnisse verringert werden kann. Dieser Ansatz erlaubt es jedoch nicht, die Zeit für die Genehmigung und Verteilung des Antrags zu verlieren. Das Ziel von „5 Hypothesen pro Woche“ mit diesem Ansatz ist immer noch nicht sehr realistisch.
Um die Experimente zu beschleunigen, müssen Sie in der Lage sein, neue Funktionen zu entwickeln und zu senden, ohne die Anwendung aktualisieren zu müssen. Um dies zu erreichen, müssen Sie eine dynamische Benutzeroberfläche verwenden. Dieser Ansatz hat jedoch Probleme:
Einerseits gibt es technische Einschränkungen beim Aufbau der Schnittstelle entsprechend den von außen erhaltenen Einstellungen. Die meisten Frameworks für die mobile Entwicklung verwenden einen deklarativen Ansatz, bei dem dies unmöglich oder sehr schwierig ist.
Andererseits verbietet die Anwendungsspeicherrichtlinie das Herunterladen und Ausführen von beliebigem Code, da er für Funktionen verwendet werden kann, die gegen die Regeln von Anwendungsspeichern verstoßen.
Eine weitere Einschränkung ist die Datenmenge, die von Firebase Remote Config übertragen wird. Es kann nicht zum Übertragen der gesamten Schnittstelle verwendet werden. Es ist optimal, nur den „Schlüssel“ einer bestimmten Version der Schnittstelle darin zu speichern und beim Ändern dieses Codes die Schnittstelle von einem Drittanbieter-Dienst zu laden. An sich schränkt es die Auswahl des mobilen Entwicklungsframeworks nicht ein, erfordert jedoch zusätzliche Implementierungsbemühungen.
Die optimale Lösung ist ein Ansatz, bei dem nur die Benutzeroberfläche dynamisch erstellt wird und die Geschäftslogik fest bleibt. Da sich die überwiegende Mehrheit der Produktexperimente speziell auf die Benutzeroberfläche bezieht, können Sie ein hohes Arbeitstempo beibehalten. Gleichzeitig können Experimente, die eine Verfeinerung der Geschäftslogik erfordern, parallel gemäß dem oben beschriebenen Prozess mit Flags durchgeführt werden.
Technisch lässt sich dieser Ansatz am einfachsten in einem Framework implementieren, das die folgenden Merkmale aufweist:
- Eine reaktive, leistungsstarke Benutzeroberfläche, die standardmäßig keinen deklarativen Ansatz verwendet.
- Unterstützung für Google Analytics für Firebase und Firebase Remote Config.
- Eine plattformübergreifende Lösung ist wünschenswert, um die Entwicklung insgesamt zu beschleunigen.
Optimalerweise erfüllt das Flutter-Framework diese Kriterien. Als Proof-of-Concept dieses Ansatzes gibt es für ihn eine Bibliothek, mit der Sie eine dynamische Schnittstelle erstellen können .
Mithilfe der in Flutter, Google Analytics für Firebase und Firebase Remote Config erstellten dynamischen Oberfläche können Sie Anwendungen entwickeln, die mit einfachen Hypothesentests mit Websites verglichen werden können.