Caractéristiques des tests d'hypothèses pour les applications mobiles

Combien de temps dure un test d'hypothèse pour une application mobile? Comptons:

1. Développement d'une application qui fonctionne dans différents modes pour différents groupes d'utilisateurs.
2. Test du résultat.
3. Mettre l'application dans les magasins d'applications et attendre l'approbation.
4. En attente de mise à jour de l'application par les utilisateurs. En 2019, la plupart des mises à jour automatiques sont activées, mais tout le monde ne l'a pas.
5. Collecte et analyse de statistiques.
6. Amener l'application à l'état de l'hypothèse gagnante, en parallèle avec le développement des éléments suivants ...

Si vos développeurs travaillent sur Scrum avec des itérations de deux semaines, cela signifie généralement que tester une hypothèse prend un mois complet. Avec d'autres méthodologies, cette période peut être raccourcie, mais pas de manière significative.

Cet état de fait ne permet pas d'atteindre le rythme des «5 hypothèses par semaine», ce que recherchent de nombreuses équipes produits.

Ci-dessous, je vais vous dire comment vous pouvez accélérer et améliorer ce processus et indiquer un certain nombre de solutions prêtes à l'emploi que vous pouvez utiliser.

Allons-y.

Allumer et éteindre

Avant de plonger dans les détails, vous devez entrer un terme supplémentaire - le modèle d'indicateur de fonction (bascule de fonction) .

Pour les lecteurs sans formation technique, des clarifications peuvent être nécessaires:

Lors du développement d'une nouvelle fonctionnalité, le programmeur introduit un «commutateur» dans le code d'application qui active cette fonctionnalité. En règle générale, cette solution est utilisée pour conserver les fonctionnalités inachevées dans le code de programme général, mais, bien sûr, elle peut également être utilisée pour tester des hypothèses.

Pour utiliser le modèle d'indicateur de fonctionnalité dans le test de l'expérience, vous aurez besoin de:

1. Fonctionnalité entièrement développée sur laquelle expérimenter.
2. Le commutateur correspondant est dans l'état par défaut «Off».
3. Contrôle à distance du commutateur depuis le serveur.

La question est, quel est le gain de temps si la fonctionnalité doit encore être développée avant d'effectuer des tests A / B? Essayons d'analyser les étapes de l'expérience:

Que voyons-nous ici?

Tout d'abord, en utilisant l'indicateur de fonctionnalité, nous pouvons télécharger l'application dans les magasins d'applications avant de tester complètement les erreurs. Nous devons simplement nous assurer que lorsque la nouvelle fonctionnalité est désactivée, l'application se comporte comme auparavant - et cela peut être fait avec des autotests précédemment écrits. Le reste peut être testé pendant que l'application est distribuée aux utilisateurs.

Deuxièmement, une fois l'expérience terminée, vous pouvez utiliser l'indicateur de fonctionnalité pour activer / désactiver la fonctionnalité pour tous les utilisateurs jusqu'à ce que la prochaine version soit prête, où l'indicateur ne sera plus utilisé.

C'est par ce principe que le service Apptimize fonctionne , fournissant un système prêt à l'emploi pour les tests A / B.

Analyser

Pour mener une expérience, vous devez faire plusieurs choses:

1. Sélectionnez un segment d'utilisateurs si l'expérience n'est pas pour tout le monde.
2. Choisissez la taille de votre audience.
3. Collectez des données, et pas seulement celles qui sont vérifiées par expérience. Le reste des mesures commerciales sera nécessaire pour garantir que l'expérience ne casse rien dans les autres mesures.
4. Recueillez et analysez le résultat.

Si vous n'utilisez pas la solution prête à l'emploi d'Apptimize, l'approche la plus simple serait une combinaison de Google Analytics pour Firebase pour l'analyse et de Firebase Remote Config pour définir des configurations individuelles (segments et tests). Ces outils sont conçus pour fonctionner ensemble.

En conséquence, vous avez besoin de:

1. Utilisez Google Analytics pour Firebase pour suivre les statistiques de l'entreprise.
2. Utilisez Firebase Remote Config pour gérer les indicateurs de fonction.
3. Utilisez Firebase Remote Config pour spécifier des segments et des paramètres d'expérimentation.
4. Analysez les données de Google Analytics à l'aide des clés de Firebase Remote Config dans l'analyse. Cette fonctionnalité est fournie par ces outils «prêts à l'emploi».

Nous optimiserons davantage

Nous avons examiné comment raccourcir le cycle de test d'hypothèse pour les applications mobiles, en réduisant le temps de test et de diffusion des résultats de l'expérience. Mais cette approche ne permet pas de se débarrasser du temps d'approbation et de distribution de la candidature. L'objectif de «5 hypothèses par semaine» avec cette approche n'est pas encore très réaliste.

Pour accélérer les expériences, vous devez pouvoir développer et envoyer de nouvelles fonctionnalités sans avoir à mettre à jour l'application. Cela peut être réalisé, vous devez utiliser une interface utilisateur dynamique. Cependant, cette approche a des problèmes:

D'une part, il existe des limites techniques à la construction de l'interface en fonction des paramètres reçus de l'extérieur. La plupart des frameworks de développement mobile utilisent une approche déclarative là où c'est impossible ou très difficile.

D'un autre côté, la politique de magasin d'applications interdit le téléchargement et l'exécution de code arbitraire, car il peut être utilisé pour des fonctionnalités qui violent les règles des magasins d'applications.

Une autre limitation est la quantité de données transférées à partir de Firebase Remote Config. Il ne peut pas être utilisé pour transférer l'intégralité de l'interface. Il est optimal d'y stocker uniquement la «clé» d'une version spécifique de l'interface, et lors du changement de ce code, chargez l'interface à partir d'un service tiers. En soi, il ne limite pas le choix du cadre de développement mobile, mais il nécessite des efforts de mise en œuvre supplémentaires.

La solution optimale est une approche dans laquelle seule l'interface utilisateur est construite dynamiquement et la logique métier reste fixe. Étant donné que la grande majorité des expériences de produits concernent spécifiquement l'interface, vous pouvez maintenir un rythme de travail élevé. Dans le même temps, des expériences qui nécessitent un raffinement de la logique métier peuvent être effectuées en parallèle, selon le processus décrit ci-dessus avec des indicateurs.

Techniquement, cette approche est plus facilement mise en œuvre dans un cadre qui présente les caractéristiques suivantes:

1. Une interface utilisateur réactive et performante qui n'utilise pas d'approche déclarative par défaut.
2. Prise en charge de Google Analytics pour Firebase et Firebase Remote Config.
3. Une solution multiplateforme est souhaitable pour accélérer globalement le développement.

De manière optimale, le framework Flutter répond à ces critères. Preuve de concept de cette approche, il existe pour lui une bibliothèque qui permet de créer une interface dynamique .

En utilisant l'interface dynamique créée dans Flutter, Google Analytics pour Firebase et Firebase Remote Config, vous pouvez développer des applications qui peuvent être comparées à des sites Web avec une facilité de test d'hypothèse.