A/B Testing in nativen Apps – eine Bestandsaufnahme

Der Einbau von SDKs

A/B Testing für Apps unterscheidet sich von Websites vor allem dadurch, dass Apps heruntergeladen werden und lokal auf dem Gerät laufen, anstatt dass sie über eine Live-Connection über einen Browser ausgespielt werden. Um die Tests nach dem App Release steuern zu können, muss zunächst das SDK des A/B Testing Tools eingebaut werden. Ähnlich wie ein A/B Test im Web, überprüft die App dann beim Launch zunächst ob Tests vorhanden sind und ob diese angeschaltet sind. Für angeschaltete Experiemente zeigt die App entweder Variante A oder B (oder N) an – nach Zufallsprinzip. Diese Variante speichert die App nun, sodass der User auch beim erneuten Öffnen der App dieselbe Variante ausgespielt bekommt. Die Erfahrung zeigt, dass es hier nach dem Einbau von Fremd-SDKs zu technischen Problemen kommen kann und die Diskrepanz zwischen vorhandenen Experimenten und live geschalteten Experimenten zu Crashes führen kann. Um diese zu verhindern, sollten man beim funktionellen Testen also auch das Einschalten und Pausieren von Experimenten mit einbeziehen.

Änderungen in Apps werden in der Regel nicht on-the-fly live gepusht, da die meisten Änderungen ein Release erfordern. So gilt es auch für A/B Tests, dass sie meist im Sprint zum anstehenden Release definiert und final eingebaut werden müssen, damit sie in der Zeit nach dem Release ausgespielt werden können. Dementsprechend sehen das Experiment bei Apps nur die User, die das letzte App-Update heruntergeladen haben. Im Gegensatz dazu haben, sobald man für eine Website ein Experiment live schaltet, alle User die gleiche Chance im Experiment zu landen. Wer mehr zu den Unterschieden zwischen nativen Apps und Websites im Allgemeinen wissen will, erfährt hier mehr.

Ein Pool an Testmöglichkeiten

Die gängigen A/B Testing Tools für Apps bieten im Prinzip zwei Möglichkeiten: Das Testen von verschiedenen Views über einen Visual Editor und das Testen von Features über die Code Base. Beide Möglichkeiten unterscheiden sich in der Ausführung sehr. Beim Testen von Versionen über den Visual Editor geht es darum, bestehende Elemente mit bestehenden Ressourcen zu ändern, also z.B. die bestehende Textfarbe mit einer anderen auszutauschen. Solche Tests sind relativ einfach und schnell durchführbar, da A/B Testing Tools in Verbindung mit dem eingebauten SDK die Änderungen live aussteuern können – ein Release der App ist nicht nötig. Anders sieht es aus, wenn neue Assets hinzukommen, die aktuell in der App nicht vorhanden sind. Hierfür werden Code Blocks benötigt, die ein Release der App erfordern. Durch solche Experimente wird z.B. das Testen von neuen Design Elementen oder ganzen Features ermöglicht.

Da die heutigen Apps bereits größtenteils auf den User Flow abgestimmt sind, der kleine Screen wenig ablenkende Interaktionsmöglichkeiten bietet und die User zielgerichtet zum Erfolg (bzw. Kauf) geführt werden, werden die meisten Tests sich eher auf Code Blocks beziehen. Diese Tests benötigen in der Regel immer den Support von einem Developer, der die Neuerungen einbaut, sowie ein Release der App.

Neben den Funktionen und Tests, die sich innerhalb der App bewegen, kommen noch die angrenzenden Bereiche fürs A/B Testing in Betracht. Zum einen gibt es reichlich Informationen, die der User konsumiert, bevor er sich entscheidet die App zu installieren und deren Conversion durch A/B Testing verbessert werden kann: hier kann man vor allem an die App Stores, Screenshots und das App Icon denken. Für Tests im Play Store bietet z.B. Google ein eigenes Tool an, das sich auch prima ohne Tech Knowledge bedienen lässt. Mit diesen Google Experiments kann man verschiedene Versionen des Icons, der Feature Graphic, der Short Description und Screenshots entweder auf ein Land begrenzt oder global testen. Alle Tests können relevante Ergebnisse für die Conversion Optimierung liefern.

Zudem ist es für manche Apps sinnvoll, den User per Push Notifications an bestimmte Dinge zu erinnern bzw. ihn über Dinge zu informieren. Manche Testing Tools kombinieren A/B Testing mit einem Push Notification Service. Mit Hilfe dieser lässt sich der richtige Zeitpunkt, der richtige Kontext und der richtige Inhalt für Push Notifications bestimmen.

Der große Vorteil: Staged Rollout

Für iOS gilt, dass Änderungen in der App nicht nur durch einen Release müssen, sondern dass die releaste Version zusätzlich den Apple Review Prozess überstehen muss, der nicht selten zwei Wochen in Anspruch nimmt. Sobald eine neue Version der App es durch den Review Prozess geschafft hat, kann sie mit allen ihren neuen Features und ggf. Bugs momentan nur an alle Nutzer zu 100% ausgerollt werden. Hier ergibt sich ein großer Vorteil für A/B Testing Tools: Staged Rollouts von Features! Dadurch, dass man Test-Varianten an einen bestimmten Teil der User aussteuern kann, können Features zunächst in einem kleinen User-Kreis auf Bugs und User Acceptance getestet werden. Bei einem erfolgreichen Launch des Features, kann es danach auch über das A/B Testing Tool an eine größere Gruppe bzw. an alle User releast werden. Im drauffolgenden Release der App kann der A/B Test Toggle dann wieder ausgebaut werden, sodass das Feature in der App verankert ist. Nicht der unkomplizierteste Weg, aber dennoch eine große Chance. Für Android Apps beinhaltet der Google Play Store bereits ein Feature für den Staged Rollout der kompletten App.

Und warum überhaupt App A/B Testing?

Nicht nur die Technik, das Design und der Funktionsumfang von Websites und Apps unterscheiden sich teils erheblich, sondern auch der Kontext in dem sich der User bewegt unterscheidet sich von Smartphone, Tablet und Desktop. Gerade aus diesem Grund  bietet man ja dem User unterschiedliche Plattformen und Funktionalitäten an. Für das A/B Testing heißt dies allerdings auch, dass aus Ergebnissen und Insights aus dem Web, auch aus dem Mobile Web, nur sehr begrenzt Rückschlüsse für Apps gezogen werden können. Vielmehr unterscheiden sich die Guidelines und dadurch auch das Nutzerverhalten schon zwischen Android und iOS so stark, dass Ergebnisse von einer Plattform nicht per se für die andere übernommen werden können. Es empfiehlt sich also Tests auf unterschiedlichen Plattformen durchzuführen, bevor man den Ergebnissen blind übernimmt.