A / B-Tests auf Android von A bis Z.

Die meisten Artikel zu A / B-Tests widmen sich der Webentwicklung, und trotz der Relevanz dieses Tools für andere Plattformen bleibt die mobile Entwicklung zu Unrecht fern. Wir werden versuchen, diese Ungerechtigkeit zu beseitigen, indem wir die Hauptschritte beschreiben und die Merkmale der Implementierung und Durchführung von A / B-Tests auf mobilen Plattformen aufdecken.

A / B-Testkonzept

Ein A / B-Test ist erforderlich, um Hypothesen zu testen, die auf die Verbesserung der wichtigsten Anwendungsmetriken abzielen. Im einfachsten Fall werden Benutzer in zwei Gruppen unterteilt: Kontrolle (A) und Experiment (B). Ein Feature, das die Hypothese implementiert, wird nur für die Versuchsgruppe bereitgestellt. Basierend auf einer vergleichenden Analyse der Metrikindikatoren für jede der Gruppen wird eine Schlussfolgerung zur Relevanz des Merkmals gezogen.

Implementierung

1. Teilen Sie Benutzer in Gruppen ein

Zuerst müssen wir verstehen, wie wir Benutzer im richtigen Prozentsatz in Gruppen einteilen, um sie dynamisch ändern zu können. Eine solche Möglichkeit ist besonders nützlich, wenn sich plötzlich herausstellt, dass eine neue Funktion die Conversion um 146% erhöht und beispielsweise nur von 5% der Benutzer eingeführt wird! Sicherlich werden wir es jetzt für alle Benutzer bereitstellen wollen - ohne die Anwendungen im Store und die damit verbundenen Zeitkosten zu aktualisieren.

Natürlich können Sie eine Störung auf dem Server organisieren und jedes Mal, wenn Sie etwas ändern müssen, die Backend-Entwickler ziehen. Im wirklichen Leben wird das Backing jedoch häufig auf der Seite des Kunden oder eines dritten Unternehmens entwickelt, und Serverentwickler haben genug zu tun, sodass es nicht immer möglich ist, die Aufteilung schnell anzupassen, mit Dritten zusammenzuarbeiten oder fast nie, sodass diese Option nicht zu uns passt. Und dann kommt Firebase Remote Config zur Rettung!

In der Firebase-Konsole befindet sich in der Gruppe "Erweitern" eine Registerkarte "Remote-Konfiguration", auf der Sie Ihre eigene Konfiguration erstellen können, die Firebase den Benutzern Ihrer Anwendung bereitstellt.


Die Konfiguration ist eine Zuordnung <Parameterschlüssel, Parameterwert> mit der Fähigkeit, einen Parameterwert entsprechend der Bedingung zuzuweisen. Für Benutzer mit einer bestimmten Version der Anwendung lautet der Wert beispielsweise X, für alle anderen - Y. Weitere Informationen zur Konfiguration finden Sie im entsprechenden Abschnitt der Dokumentation .



Ebenfalls in der Grow-Gruppe gibt es eine Registerkarte A / B-Tests. Hier können wir die Tests mit allen oben genannten Brötchen durchführen. Die Schlüssel aus unserer Remote-Konfiguration werden als Parameter verwendet. Theoretisch können Sie neue Parameter direkt im A / B-Test erstellen. Dies führt jedoch nur zu unnötiger Verwirrung. Sie sollten dies also nicht tun. Es ist einfacher, den entsprechenden Parameter zur Konfiguration hinzuzufügen. Der darin enthaltene Wert ist traditionell der Standardwert und entspricht der Kontrollgruppe, und der experimentelle Wert des Parameters, der nicht der Standardwert ist, ist experimentell.



Hinweis Die Kontrollgruppe heißt normalerweise Gruppe A, die Versuchsgruppe heißt B. Wie Sie im Screenshot sehen können, heißt die Standard-Versuchsgruppe in Firebase „Variante A“, was zu Verwirrung führt. Aber nichts hindert daran, seinen Namen zu ändern.

Führen Sie als Nächstes den A / B-Test aus. Firebase teilt Benutzer in Gruppen auf, die unterschiedlichen Werten des Parameters entsprechen. Nach dem Empfang der Konfiguration auf dem Client erhalten wir den erforderlichen Parameter und verwenden die neue Funktion basierend auf dem Wert. Traditionell hat der Parameter einen Namen, der dem Feature-Namen entspricht, und zwei Werte: True - das Feature wird angewendet, False - wird nicht angewendet. Weitere Informationen zu den Einstellungen von A / B-Tests finden Sie im entsprechenden Abschnitt der Dokumentation .

2. Code

Wir werden uns nicht direkt mit der Integration in Firebase Remote Config befassen - sie wird hier ausführlich beschrieben.

Lassen Sie uns herausfinden, wie der Code für A / B-Tests organisiert wird. Wenn wir nur die Farbe der Schaltfläche ändern, ist es nicht sinnvoll, über die Organisation zu sprechen, da nichts Besonderes zu organisieren ist. Wir werden eine Variante betrachten, bei der abhängig vom Parameter von Remote Config der aktuelle (für die Kontrollgruppe) oder neue (für das Experiment) Bildschirm angezeigt wird.

Sie müssen verstehen, dass nach Ablauf des A / B-Tests eine der Bildschirmoptionen gelöscht werden muss. In diesem Zusammenhang muss der Code so organisiert sein, dass Änderungen in der aktuellen Implementierung minimiert werden. Alle Dateien, die dem neuen Bildschirm zugeordnet sind, sollten mit dem Präfix AB aufgerufen und in Ordnern mit demselben Präfix abgelegt werden.

Wenn wir in der Präsentationsebene über MVP sprechen, sieht es ungefähr so ​​aus:



Die flexibelste und transparenteste Klassenhierarchie scheint zu sein:



BaseOrderStatusFragment enthält alle Funktionen der aktuellen Implementierung, mit Ausnahme von Methoden, die aufgrund von Architekturbeschränkungen nicht in eine abstrakte Klasse eingefügt werden können. Sie befinden sich in OrderStatusFragment.

AbOrderStatusFragment überschreibt Methoden, die sich in der Implementierung unterscheiden und über die erforderlichen zusätzlichen Methoden verfügen. In der aktuellen Implementierung ändert sich daher nur die Aufteilung einer Klasse in zwei, und einige Methoden in der Basisklasse werden offen statt privat geschützt.

Hinweis: Wenn die Architektur und der spezielle Fall dies zulassen, können Sie auf das Erstellen einer Basisklasse verzichten und AbOrderStatusFragment direkt von OrderStatusFragment erben.

Im Rahmen einer solchen Organisation ist es höchstwahrscheinlich erforderlich, vom akzeptierten CodeStyle abzuweichen, was in diesem Fall zulässig ist, da der entsprechende Code nach Abschluss des A / B-Tests gelöscht oder überarbeitet wird (aber an den Stellen, an denen CodeStyle verletzt wird, lohnt es sich natürlich, einen Kommentar zu hinterlassen).

Eine solche Organisation ermöglicht es uns, eine neue Funktion schnell und problemlos zu entfernen, wenn sie sich als irrelevant herausstellt, da alle damit verbundenen Dateien leicht nach Präfixen zu finden sind und ihre Implementierung die aktuelle Funktionalität nicht beeinträchtigt. Wenn die Funktion die Schlüsselmetrik verbessert hat und beschlossen wurde, sie zu belassen, müssen wir noch daran arbeiten, die aktuelle Funktionalität auszuschneiden, was sich auf den Code der neuen Funktion auswirkt.

Um die Konfiguration zu erhalten, sollten Sie ein separates Repository erstellen und auf Anwendungsebene einfügen, damit überall darauf zugegriffen werden kann, da wir nicht wissen, welche Teile der Anwendung zukünftige A / B-Tests beeinflussen werden. Aus den gleichen Gründen lohnt es sich, so früh wie möglich danach zu fragen, beispielsweise zusammen mit den grundlegenden Informationen, die für das Funktionieren der Anwendung erforderlich sind (normalerweise treten solche Anforderungen während des Splashs auf, obwohl dies ein ganzheitliches Thema ist, aber es ist wichtig, dass sie irgendwo vorhanden sind).

Nun, und natürlich ist es wichtig, nicht zu vergessen, den Parameterwert aus der Konfiguration in die Analyseereignisparameter zu werfen, damit Sie Metriken vergleichen können

Ergebnisanalyse

Es gibt viele Artikel, in denen beispielsweise detailliert beschrieben wird, wie die Ergebnisse von A / B-Tests analysiert werden. Um uns nicht zu wiederholen, geben wir einfach die Essenz an. Sie müssen verstehen, dass der Unterschied in den Metriken in der Kontroll- und Versuchsgruppe eine Zufallsvariable ist, und wir können nicht schließen, dass das Merkmal nur auf der Grundlage relevant ist, dass die Metrik in der Versuchsgruppe besser ist. Es ist notwendig, ein Konfidenzintervall (die Wahl des Zuverlässigkeitsniveaus sollte den Analysten anvertraut werden) für die oben beschriebene Zufallsvariable zu erstellen und das Experiment durchzuführen, bis das Intervall vollständig in der positiven oder negativen Halbebene liegt - dann kann eine statistisch gültige Schlussfolgerung gezogen werden.

Fallstricke

1. Fehler beim Abrufen der Remote-Konfiguration

Eine vergleichende Analyse wird für neue Benutzer durchgeführt, da Benutzer mit derselben Benutzererfahrung und nur diejenigen, die die einzige Implementierungsoption gesehen haben, an den Experimenten teilnehmen sollten. Denken Sie daran, dass das Empfangen der Konfiguration eine Netzwerkanforderung ist und möglicherweise fehlschlägt. In diesem Fall wird der Standardwert angewendet, der traditionell dem Wert für die Kontrollgruppe entspricht.

Stellen Sie sich den folgenden Fall vor: Wir haben einen Benutzer, den Firebase der Versuchsgruppe zugewiesen hat. Der Benutzer startet die Anwendung zum ersten Mal und die Remote Config-Anforderung gibt einen Fehler zurück - der Benutzer sieht den alten Bildschirm. Beim nächsten Start wird die Remote-Konfigurationsanforderung korrekt verarbeitet und der Benutzer sieht einen neuen Bildschirm. Es ist wichtig zu verstehen, dass ein solcher Benutzer für das Experiment nicht relevant ist. Sie müssen daher herausfinden, wie ein solcher Benutzer auf der Seite des Analysesystems herausgefiltert werden kann, oder nachweisen, dass die Anzahl dieser Benutzer vernachlässigbar ist.

Tatsächlich treten solche Fehler selten auf, und höchstwahrscheinlich passt die letztere Option zu Ihnen, aber es gibt im Wesentlichen ein ähnliches, aber viel dringlicheres Problem - die Zeit, um die Konfiguration zu erhalten. Wie oben erwähnt, ist es besser, die Remote-Konfigurationsanforderung zu Beginn der Sitzung zu speichern. Wenn die Anforderung jedoch zu lange dauert, hat der Benutzer keine Lust mehr zu warten und beendet die Anwendung. Daher müssen Sie eine nicht triviale Aufgabe lösen, um ein Zeitlimit auszuwählen, um das die Remote-Konfigurationsanforderung zurückgesetzt wird. Wenn es zu klein ist, ist möglicherweise ein großer Prozentsatz der Benutzer in der Liste der für den Test irrelevanten Benutzer aufgeführt. Wenn es zu groß ist, besteht das Risiko, dass Benutzer verärgert sind. Wir haben Statistiken zum Zeitpunkt des Empfangs der Konfiguration gesammelt:



Hinweis Daten für die letzten 30 Tage. Gesamtzahl der Anfragen 673 529 . Die erste Spalte enthält zusätzlich zu den Netzwerkanforderungen den Empfang der Konfiguration aus dem Cache. Daher wird sie aus dem allgemeinen Verteilungsformular entfernt.


2. Rändel-Update Remote Config

Sie müssen verstehen, dass Firebase eine Remote-Konfigurationsanforderung zwischenspeichert. Die Standardlebensdauer des Caches beträgt 12 Stunden. Die Zeit kann angepasst werden, aber Firebase hat eine Begrenzung für die Häufigkeit von Anforderungen. Wenn diese überschritten wird, sperrt Firebase uns und gibt einen Fehler bei der Konfigurationsanforderung zurück. möglich für eine begrenzte Anzahl von Geräten).

Wenn wir beispielsweise den A / B-Test abschließen und eine neue Funktion zu 100% einführen möchten, müssen wir verstehen, dass der Übergang nur innerhalb von 12 Stunden erfolgt, dies ist jedoch nicht das Hauptproblem. Stellen Sie sich den folgenden Fall vor: Wir haben einen A / B-Test durchgeführt, ihn abgeschlossen und eine neue Version vorbereitet, in der es einen weiteren A / B-Test mit der entsprechenden Konfiguration gibt. Wir haben eine neue Version der Anwendung veröffentlicht, aber unsere Benutzer haben bereits eine Konfiguration aus dem vorherigen A / B-Test zwischengespeichert. Wenn der Cache noch nicht abgelaufen ist, ruft die Konfigurationsanforderung keine neuen Parameter auf und wir werden erneut Benutzer der Versuchsgruppe zuweisen. die bei der ersten Anfrage Standardwerte der Konfiguration erhalten und in Zukunft die Daten des neuen Experiments verderben.

Die Lösung für dieses Problem ist sehr einfach: Sie müssen die Konfigurationsanforderung beim Aktualisieren der Anwendungsversion erzwingen, indem Sie die Cache-Lebensdauer zurücksetzen:

val cacheExpiration = if (isAppNewVersion) 0L else TWELVE_HOURS_IN_SECONDS FirebaseRemoteConfig.getInstance().fetch(cacheExpiration) 

Da Updates nicht so oft veröffentlicht werden, werden wir die Grenzwerte nicht überschreiten
Lesen Sie hier mehr über diese Themen.

Schlussfolgerungen

Firebase bietet ein sehr praktisches und einfaches A / B-Testwerkzeug, das verwendet werden sollte, wobei den oben beschriebenen Engpässen besondere Aufmerksamkeit zu widmen ist. Die vorgeschlagene Organisation des Codes minimiert die Anzahl der Fehler, wenn Änderungen im Zusammenhang mit dem Zyklus der A / B-Tests vorgenommen werden.

Viel Glück für alle, erfolgreiche A / B-Tests und 100,5% mehr Conversions.