Tests A / B sur Android de A à Z

La plupart des articles sur les tests A / B sont consacrés au développement web, et malgré la pertinence de cet outil pour d'autres plateformes, le développement mobile reste injustement à distance. Nous allons essayer d'éliminer cette injustice en décrivant les principales étapes et en révélant les caractéristiques de la mise en œuvre et de la conduite des tests A / B sur les plateformes mobiles.

Concept de test A / B

Un test A / B est nécessaire pour tester les hypothèses visant à améliorer les mesures clés des applications. Dans le cas le plus simple, les utilisateurs sont répartis en 2 groupes contrôle (A) et expérimental (B). Une fonctionnalité qui implémente l'hypothèse est déployée uniquement au groupe expérimental. De plus, sur la base d'une analyse comparative des indicateurs métriques pour chacun des groupes, une conclusion est tirée sur la pertinence de la caractéristique.

Implémentation

1. Divisez les utilisateurs en groupes

Nous devons d'abord comprendre comment nous allons diviser les utilisateurs en groupes dans le bon pourcentage avec la possibilité de le changer dynamiquement. Une telle opportunité sera particulièrement utile s'il s'avère soudainement qu'une nouvelle fonctionnalité augmente la conversion de 146% et est déployée, par exemple, par seulement 5% des utilisateurs! Nous voudrons sûrement le déployer à tous les utilisateurs et dès maintenant - sans mettre à jour les applications dans le magasin et les coûts de temps associés.

Bien sûr, vous pouvez organiser une panne sur le serveur et chaque fois que vous devez changer quelque chose, tirez sur les développeurs backend. Mais dans la vraie vie, le support est souvent développé du côté du client ou par une troisième entreprise, et les développeurs de serveurs ont assez de choses à faire, il n'est donc pas toujours possible d'ajuster rapidement la panne, de travailler avec des tiers, ou plutôt, presque jamais, donc cette option ne nous convient pas. Et puis Firebase Remote Config vient à la rescousse!

Dans la console Firebase, dans le groupe Agrandir, il y a un onglet Configuration à distance où vous pouvez créer votre propre configuration que Firebase fournira aux utilisateurs de votre application.


La configuration est une carte <clé de paramètre, valeur de paramètre> avec la possibilité d'attribuer une valeur de paramètre en fonction de la condition. Par exemple, pour les utilisateurs avec une version spécifique de l'application, la valeur est X, pour tous les autres - Y. Pour plus d'informations sur la configuration, consultez la section correspondante de la documentation .



Le groupe Grow contient également un onglet A / B Testing. Ici, nous pouvons exécuter les tests avec tous les petits pains ci-dessus. Les clés de notre configuration à distance sont utilisées comme paramètres. En théorie, vous pouvez créer de nouveaux paramètres directement dans le test A / B, mais cela ne fera qu'ajouter une confusion inutile, alors ne le faites pas, il est plus facile d'ajouter le paramètre correspondant à la configuration. La valeur qu'il contient est traditionnellement la valeur par défaut et correspond au groupe de contrôle, et la valeur expérimentale du paramètre, autre que la valeur par défaut, est expérimentale.



Remarque Le groupe de contrôle est généralement appelé groupe A, le groupe expérimental est appelé B. Comme vous pouvez le voir sur la capture d'écran, dans Firebase, le groupe expérimental par défaut est appelé «Variante A», ce qui introduit une certaine confusion. Mais rien n'empêche de changer son nom.

Ensuite, exécutez le test A / B, Firebase divise les utilisateurs en groupes qui correspondent à différentes valeurs du paramètre, après avoir reçu la configuration sur le client, nous obtenons le paramètre nécessaire et utilisons la nouvelle fonctionnalité en fonction de la valeur. Traditionnellement, le paramètre a un nom correspondant au nom de l'entité et 2 valeurs: True - l'entité est appliquée, False - n'est pas appliquée. En savoir plus sur les paramètres des tests A / B dans la section correspondante de la documentation .

2. Code

Nous ne nous attarderons pas directement sur l'intégration avec Firebase Remote Config - elle est décrite en détail ici .

Voyons comment organiser le code pour les tests A / B. Si nous changeons simplement la couleur du bouton, parler de l'organisation n'a pas de sens, car il n'y a rien de spécial à organiser. Nous considérerons une variante dans laquelle, selon le paramètre de Remote Config, l'écran actuel (pour le groupe de contrôle) ou nouveau (pour l'expérimental) est affiché.

Vous devez comprendre qu'après l'expiration du test A / B, l'une des options d'écran devra être supprimée.À cet égard, le code doit être organisé de manière à minimiser les changements dans l'implémentation actuelle. Tous les fichiers associés au nouvel écran doivent être appelés avec le préfixe AB et placés dans des dossiers avec le même préfixe.

Si nous parlons de MVP dans la couche Présentation, cela ressemblera à ceci:



La hiérarchie de classes la plus flexible et transparente semble être:



BaseOrderStatusFragment contiendra toutes les fonctionnalités de l'implémentation actuelle, à l'exception des méthodes qui ne peuvent pas être placées dans une classe abstraite en raison des limitations de l'architecture. Ils seront situés dans OrderStatusFragment.

AbOrderStatusFragment remplacera les méthodes qui diffèrent dans la mise en œuvre et ont les supplémentaires nécessaires. Ainsi, dans l'implémentation actuelle, seule la répartition d'une classe en deux changera et certaines méthodes de la classe de base deviendront protégées ouvertes au lieu de privées.

Remarque: si l'architecture et le cas spécifique le permettent, vous pouvez vous passer de la création d'une classe de base et hériter directement AbOrderStatusFragment de OrderStatusFragment.

Dans le cadre d'une telle organisation, il est très probablement nécessaire de s'écarter du CodeStyle adopté, ce qui est autorisé dans ce cas, car le code correspondant sera supprimé ou refactorisé à la fin du test A / B (mais, bien sûr, dans les endroits où CodeStyle est violé, vous devez laisser un commentaire)

Une telle organisation nous permettra de supprimer rapidement et sans douleur une nouvelle fonctionnalité si elle s'avère non pertinente, car tous les fichiers qui lui sont associés sont faciles à trouver par préfixe et sa mise en œuvre n'affecte pas la fonctionnalité actuelle. Si la fonctionnalité a amélioré la métrique clé et qu'il a été décidé de la laisser, nous devons encore travailler sur la suppression de la fonctionnalité actuelle, ce qui affectera le code de la nouvelle fonctionnalité.

Pour obtenir la configuration, cela vaut la peine de créer un référentiel séparé et de l'injecter au niveau de l'application afin qu'il soit accessible partout, car nous ne savons pas quelles parties de l'application affecteront les futurs tests A / B. Pour les mêmes raisons, il vaut la peine de le demander dès que possible, par exemple, en même temps que les informations de base nécessaires au fonctionnement de l'application (généralement, de telles demandes se produisent lors du démarrage, bien qu'il s'agisse d'un sujet holistique, mais il est important qu'elles existent quelque part).

Eh bien, et, bien sûr, il est important de ne pas oublier de jeter la valeur du paramètre de la configuration dans les paramètres d'événement d'analyse, afin que vous puissiez comparer les mesures

Analyse des résultats

Il existe de nombreux articles détaillant comment analyser les résultats des tests A / B, par exemple . Afin de ne pas nous répéter, nous indiquons simplement l'essence. Vous devez comprendre que la différence entre les métriques dans les groupes de contrôle et expérimentaux est une variable aléatoire, et nous ne pouvons pas conclure que la fonctionnalité n'est pertinente que sur la base que la métrique dans le groupe expérimental est meilleure. Il est nécessaire de construire un intervalle de confiance (le choix du niveau de fiabilité doit être confié aux analystes) pour la variable aléatoire décrite ci-dessus et de mener l'expérience jusqu'à ce que l'intervalle soit complètement dans le demi-plan positif ou négatif - alors une conclusion statistiquement valide peut être faite.

Pièges

1. Erreur lors de l'obtention de la configuration à distance

Une analyse comparative est effectuée sur les nouveaux utilisateurs, car les utilisateurs ayant la même expérience utilisateur et seuls ceux qui ont vu la seule option de mise en œuvre devraient participer aux expériences. Rappelons que la réception de la configuration est une demande de réseau et peut échouer, auquel cas la valeur par défaut, traditionnellement égale à la valeur du groupe de contrôle, sera appliquée.

Prenons le cas suivant: nous avons un utilisateur que Firebase a affecté au groupe expérimental. L'utilisateur démarre l'application pour la première fois et la demande de configuration à distance renvoie une erreur - l'utilisateur voit l'ancien écran. Au prochain démarrage, la demande de configuration à distance est traitée correctement et l'utilisateur voit un nouvel écran. Il est important de comprendre qu'un tel utilisateur n'est pas pertinent pour l'expérience, vous devez donc comprendre comment filtrer un tel utilisateur du côté du système d'analyse, ou prouver que le nombre de ces utilisateurs est négligeable.

En fait, de telles erreurs se produisent rarement, et la dernière option vous conviendra probablement, mais il existe essentiellement un problème similaire, mais beaucoup plus urgent - le temps d'obtenir la configuration. Comme mentionné ci-dessus, il est préférable de coller la demande de configuration à distance au début de la session, mais si la demande prend trop de temps, l'utilisateur sera fatigué d'attendre et quittera l'application. Par conséquent, vous devez résoudre une tâche non triviale - pour choisir un délai d'expiration de la réinitialisation de la demande de configuration à distance. S'il est trop petit, alors un grand pourcentage d'utilisateurs peut être dans la liste des non pertinents pour le test, s'il est trop grand - nous courons le risque de colère des utilisateurs. Nous avons collecté des statistiques sur l'heure de réception de la config:



Remarque Données des 30 derniers jours. Nombre total de demandes 673 529 . La première colonne, en plus des requêtes réseau, contient la réception de la configuration du cache, elle est donc supprimée du formulaire de distribution générale.


2. Mise à jour de la molette Configuration à distance

Vous devez comprendre que Firebase met en cache une demande de configuration à distance. La durée de vie par défaut du cache est de 12 heures. Le temps peut être ajusté, mais Firebase a une limite sur la fréquence des demandes, et s'il est dépassé, Firebase nous interdira et retournera une erreur sur la demande de configuration. possible pour un nombre limité d'appareils).

Par conséquent, par exemple, si nous voulons terminer le test A / B et déployer une nouvelle fonctionnalité à 100%, nous devons comprendre que la transition n'aura lieu que dans les 12 heures, mais ce n'est pas le problème principal. Prenons le cas suivant: nous avons effectué un test A / B, l'avons terminé et préparé une nouvelle version, dans laquelle il existe un autre test A / B avec la configuration correspondante. Nous avons publié une nouvelle version de l'application, mais nos utilisateurs ont déjà une configuration mise en cache à partir du test A / B précédent, et si le cache n'a pas encore expiré, la demande de configuration ne récupérera pas de nouveaux paramètres, et nous obtiendrons à nouveau des utilisateurs affectés au groupe expérimental, qui, à la première demande, recevra les valeurs par défaut de la configuration et gâchera à l'avenir les données de la nouvelle expérience.

La solution à ce problème est très simple - vous devez forcer la demande de configuration lors de la mise à jour de la version de l'application en réinitialisant la durée de vie du cache:

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

Comme les mises à jour ne sont pas publiées aussi souvent, nous ne dépasserons pas les limites
En savoir plus sur ces problèmes ici .

Conclusions

Firebase fournit un outil de test A / B très pratique et simple à utiliser, en accordant une attention particulière aux goulots d'étranglement décrits ci-dessus. L'organisation proposée du code minimisera le nombre d'erreurs lors des modifications associées au cycle des tests A / B.

Bonne chance à tous, tests A / B réussis et augmentation de 100,5% des conversions.