Les tests A / B constituent-ils une utilisation intéressante des ressources pour l'utilisateur final d'une application mobile?
Les sites Web peuvent activer les tests A/B en servant une page différente, par exemple. Une application mobile devrait collecter des données et les renvoyer. Par principe, est-il acceptable d'avoir un logiciel "phone home" pour optimiser certaines parties de l'affichage? Devrait-il être divulgué à l'utilisateur pourquoi je demande cette autorisation, même s'il ne voit pas l'avantage dans l'application actuelle?
EDIT: Pour clarifier, même s'il est révélé à l'utilisateur que je le ferais (ce que je ferais absolument), les tests A/B sont-ils suffisamment importants pour l'utilisateur final pour que cela en vaille la peine d'avoir le logiciel téléphone parfois à la maison? J'ai modifié la question pour refléter cela, au lieu de ma question d'origine avant de me détourner.
Si vous pensez que c'est assez important à faire et que l'utilisateur est heureux de vous laisser le faire, je ne vois pas le problème. Vous n'allez pas vous renvoyer d'énormes quantités de données, donc je ne vois pas pourquoi cela dérangerait l'utilisateur. La plupart des utilisateurs de smartphones ont de toute façon un contact Internet illimité (au moins au Royaume-Uni, ils viennent tous avec un, à l'exception de certains Blackberry).
Vous pouvez essayer quelque chose comme MixPanel si vous voulez simplement voir comment les utilisateurs utilisent votre application et comment vous pouvez l'améliorer. Je ne l'ai jamais utilisé, mais ça a l'air intéressant.
Nous avons mis en place un certain type de test A/B pour les applications mobiles dans nos applications avec un certain succès. Ce qui est important à retenir, c'est que les frais de données varient selon les réseaux et les pays. Je pense qu'il est préférable de minimiser autant que possible l'utilisation des données. En tant que tel, nous avons implémenté notre test A/B comme deux "thèmes" différents pour l'application. les utilisateurs pouvaient sélectionner le thème de leur choix, et sur la page des options, il y avait une option pour voter sur leur thème préféré et soumettre des commentaires.
En fin de compte, la collecte des commentaires des utilisateurs n'est pas facile sur n'importe quelle plate-forme mobile, même les plus avancées. Vous êtes vraiment coincé en comptant sur les utilisateurs prêts à faire un effort supplémentaire et à vous contacter directement ...
Je pense que la façon dont vous formulez la question est un peu confuse, mais je vais essayer de répondre quand même.
La meilleure pratique pour les applications installables est de faire savoir à l'utilisateur ce qui va se passer et de leur offrir la possibilité de le désactiver. Un bon exemple de cela est Google Chrome, qui informe les utilisateurs qu'il transmettra des données à Google et vous offre la possibilité de les désactiver de temps en temps. Elle est également similaire aux alertes que l'iPhone vous enverra lorsqu'une application souhaite "vous envoyer des notifications Push". Soyez franc, clair et honnête et les utilisateurs vous en remercieront.
Quant à la question "les tests A/B sont-ils suffisamment importants pour l'utilisateur final" - je ne pense pas que la question soit très pertinente. Que les utilisateurs finaux trouvent que les tests A/B sont importants ou non ne devrait pas vous empêcher de vouloir améliorer votre application, car si vous le faites, ils seront finalement plus heureux de toute façon. Faites les tests A/B, mais assurez-vous d'être honnête sur les données que vous transmettez - ce sont deux sujets distincts.
Généralement, vous souhaiterez vous concentrer sur la vente et le support d'une application une fois qu'elle sera lancée en production. Passer un temps non négligeable à tester les ajustements de l'interface lorsque vous devriez commercialiser ou corriger des bogues peut ne pas être souhaitable.
Si vous souhaitez exécuter des tests A/B (ou des tests multivariés s'il y a une complexité dans l'application), je préparerais la version du logiciel et la publierais en version bêta. En version bêta, vous pouvez
- renoncer à décourager les utilisateurs en suggérant que leur expérience peut être différente de celle de quelqu'un d'autre (c'est une version bêta, les choses seront un peu volatiles),
- publier de nouvelles variantes de test (c'est-à-dire des "mises à jour") aussi souvent que vous le souhaitez, et
- recueillir de meilleurs commentaires (c'est-à-dire tester les métriques) en le proposant comme échange pour une utilisation gratuite ou un accès anticipé au logiciel.
Comme le dit matto1990, plus d'informations sont nécessaires, mais en principe, je dirais que l'utilisateur devrait être informé en cas de dépenses.
De plus, même si l'appel est gratuit, il peut toujours affecter l'utilisateur de manière problématique. Imaginez que l'utilisateur attend un appel important, mais il ne parvient pas à passer car à ce moment précis, l'application a lancé un appel.