Système de récompenses: des points ou de l'argent?
Scénario
Nous avons bientôt une application qui comprendra un système de récompenses. Ces récompenses sont de l'argent réel, donc un solde de récompenses direct : xxxx $ devrait suffire (en théorie). En gros, les récompenses sont un vrai paiement pour une tâche accomplie
Cependant, nos premiers tests montrent qu'il y a 2 parties dans l'histoire. Puisque ces récompenses peuvent diminuer il y a 3 scénarios: L'équilibre augmente, l'équilibre rétrécit, l'équilibre reste le même
Dans le premier scénario , les tests ont évidemment montré que les utilisateurs ont une très bonne réception pour le montant indiqué en $.
Cependant, sur le deuxième scénario (l'équilibre diminue), le frottement est allé au toit, basé sur biais d'aversion à la perte . À son tour, cela conduit les groupes de test à devenir statiques et à cesser de faire des tâches.
Pour troisième scénario , nous n'avons pas trouvé de signes négatifs (du moins rien d'important) par rapport au montant $ affiché, mais nous avons trouvé un modèle de seuil curieux : après une certaine somme, ils ont gelé, ce qui signifie l'aversion à la perte a commencé à jouer avant même de diminuer.
Solution proposée
Nous avons donc décidé d'aller avec des points. Jusqu'à présent, les utilisateurs des tests n'ont pas réagi bien ou mal, ils ne semblaient pas du tout intéressés. L'achèvement de la tâche était plus ou moins sur le modèle de seuil mentionné ci-dessus, peut-être légèrement plus élevé, mais cela s'est produit pour les 3 cas : croissance, rétrécissement, décrochage. Du côté positif, cela nous permet de réaliser un profit marginal
Conclusions actuelles
Tout en montrant des montants d'argent a beaucoup de friction, il a plus de tâches effectuées jusqu'à cette étape de friction. Les points ont beaucoup moins de friction, mais ils ne sont pas suffisamment attrayants pour que les utilisateurs effectuent plus de tâches.
Des questions)
Puisque nous sommes sur le point d'emballer cela, les temps sont vraiment serrés pour plus de tests, donc ma question est: y a-t-il une étude montrant que la méthode des points ou la méthode $ est définitivement meilleure?
En supposant que les points sont le chemin à parcourir , existe-t-il un moyen qui fonctionne mieux que les autres pour éviter les problèmes mentionnés ci-dessus? Par exemple: 1 point = 1$ OR 10 points = 1$ OR 1 point =$10
ou des plages qui peuvent conduire à moins d'argent pour les utilisateurs mais à un taux d'achèvement plus élevé car ils devront passer à l'étape suivante pour un montant plus élevé. Exemple: 50 to 99 points achieved = $50 . 100 to 199 points achieved = $100
EDIT: Juste au cas où cela serait utile pour la réponse, les sommes peuvent passer de quelques dollars (enfin, une autre devise qui a plus de chiffres, mais par exemple) à 5 chiffres dans les cas extrêmes. Peu probable, mais possible. Cependant, la plupart des montants seront de l'ordre de 3-4 chiffres
EDIT 2: Ce n'est pas un modèle de gamification. C'est de l'argent réel pour de vraies tâches effectuées. En raison d'un NDA très strict, je ne peux pas fournir plus d'informations, mais à titre d'exemple totalement indépendant: supposons que le client souhaite que les utilisateurs trouvent des fleurs jaunes, bleues ou rouges avec 5 à 8 pétales. Tant d'utilisateurs enverront des fleurs. Le client ne voudra qu'une fleur jaune pne avec 5 pétales, une avec 6, une avec 7, une avec 8. Idem pour le rouge et le bleu. Tout le reste sera rejeté.
Mais ensuite, nous constaterons qu'il y a de nombreux utilisateurs qui envoient des fleurs jaunes avec 5 pétales, de nombreux utilisateurs qui envoient des fleurs jaunes avec 6 pétales et ainsi de suite. Nous avons un algorithme en place pour cela, mais à titre d'exemple, disons que le client n'approuvera que la première fleur de chaque type.
En raison de ce temps d'attente énorme, nous devons refléter les tâches effectuées et tant que les spécifications ont été suivies, approuvées temporairement ou que les utilisateurs n'auront aucun moyen de suivre leurs progrès et de voir le résultat de leurs efforts.
Nous utilisons donc des chiffres temporaires et spécifions clairement que ces chiffres sont soumis à un examen final, nous n'avons donc aucun problème avec le processus lui-même, comme le soulignent la plupart des réponses, le problème vient des chiffres: montant en argent ou montant en points, avec les problèmes que nous avons trouvés pour chacun
J'ai précédemment conçu/testé une application similaire à FanDuel/DraftKings qui incluait à la fois des points et de l'argent en récompense. Avec le système de points, l'utilisateur peut accumuler des points - les perdre ou les garder inchangés. Plus tard, nous avons également inclus l'argent comptant comme système de récompense. (Les utilisateurs pouvaient choisir de l'argent ou des points comme récompense) Du point de vue des tests, cela nous a permis d'analyser quel système de récompense a conduit le comportement des utilisateurs de manière plus positive.
Ce que nous avons constaté, c'est que dans une comparaison directe du comportement des utilisateurs, l'argent comptant a maintenu un pourcentage plus élevé d'utilisateurs actifs quotidiens. Avec des points, un pourcentage élevé d'utilisateurs utiliseraient le produit pendant 1 à 2 semaines, puis abandonneraient leur compte. Les utilisateurs semblaient désensibilisés/peu enthousiastes en ce qui concerne le système de récompense par points. Même en décrivant la valeur d'un point en ce qui concerne l'argent, il n'était toujours pas suffisamment convaincant.
Il y a des inconvénients aux deux approches ... que vous avez clairement trouvés grâce aux tests. Nous avons également constaté que la perte de liquidités est un point de friction et même parfois un catalyseur d'abandon. Un bon moyen de résoudre ce problème est de compenser la perte avec une sorte d'incitation. Ce qui veut dire ... hé, on dirait que vous en avez perdu ici - mais voici un bonus de xyz. Ou voici ce que vous pouvez faire pour revenir dans le positif.
De cette expérience, il est devenu clair pour moi que fournir de la valeur à l'utilisateur via le système de récompense en espèces était la voie à suivre. Il vous suffit de passer par les points de friction. Alors qu'avec le système de points, les utilisateurs ne sont pas enthousiastes dès le début de l'expérience. De ce point de vue, il faut beaucoup plus de travail pour leur montrer où la valeur existe lors de l'utilisation de votre application.
J'espère que cela t'aides.
Je ne pense pas que la réponse à un solde monétaire en baisse puisse être attribuée à l'aversion aux pertes. Vos utilisateurs n'ont pas à choisir entre certaines petites pertes et des pertes importantes moins probables. De plus, parce que l'équilibre peut rétrécir de n'importe quel degré à tout moment, ils ne peuvent pas vraiment comparer les proportions de gains aux proportions de pertes. Ils ne peuvent réagir à la perte que lorsqu'elle se produit. Je pense que la réponse que vous avez observée dans votre recherche est plus intuitive que l'aversion aux pertes. Les gens ont simplement une réaction viscérale à perdre de l'argent. Par exemple, dépenser beaucoup d'argent a été cause de la douleur .
Si les utilisateurs ont cessé d'effectuer des tâches, cela signifie qu'ils ont effectivement cessé d'utiliser votre produit. Je suppose que les utilisateurs ont cessé d'utiliser votre produit car ils ont eu une expérience négative (perdre de l'argent) et pensaient qu'ils auraient plus d'expériences négatives à l'avenir. S'ils détiennent une telle croyance, cela signifie que le produit n'a pas fait assez bien pour les éduquer sur ce que va et ne se produira pas . Cela signifie qu'ils forment leurs propres croyances pessimistes sur ce que l'avenir réserve, c'est-à-dire plus de pertes.
Envisagez de créer un équilibre provisoire qui a une importance secondaire par rapport à l'équilibre principal. Le solde provisoire permettrait à l'utilisateur de garder une trace des gains potentiels, c'est-à-dire des gains susceptibles d'être effacés. Si l'utilisateur a une compréhension claire des fluctuations qui peuvent avoir lieu avec un solde provisoire, il peut ne pas avoir une forte réaction négative aux pertes de ce solde. Comme vous avez déjà testé que les pertes sur un solde basé sur des points n'affectent pas les performances de la tâche, je considérerais de représenter ce solde sous forme de points. Comme il a été démontré que l'argent produit des performances de tâche plus élevées, vous souhaitez que votre solde principal soit représenté comme de l'argent au lieu de points. Une fois la "période de sécurité" expirée, vous pouvez convertir les points du solde provisoire en argent du solde principal.
Je pense que vous devriez également envisager d'ajuster votre "période de sécurité". La "période de sécurité" de 60 jours signifie que les utilisateurs doivent attendre assez longtemps avant de recevoir leurs récompenses. Gardez à l'esprit que les utilisateurs compareront les paiements de votre site à d'autres activités où ils sont payés pour effectuer des travaux et des services similaires. Certaines personnes réussissent bien à retarder la gratification tandis que d'autres ne le font pas. J'envisagerais de raccourcir la "période de sécurité" à une période de 30 jours au maximum, car la plupart des adultes ont été "formés" à attendre 30 jours pour un salaire. Cela aiderait à atténuer les utilisateurs qui pourraient être défectueux du produit car ils ne peuvent pas attendre entre la fin d'une tâche et la réception d'un paiement.
Votre situation me rappelle les pools de BitCoin Mining. Les utilisateurs "travaillent" contre des "points" qui peuvent être échangés contre des "espèces". BitCoin a le même problème, où le travail peut être rejeté par le réseau.
Slushpool, un pool minier BitCoin, affiche plusieurs valeurs de vos récompenses.
- Récompense confirmée
- Récompense non confirmée
- Récompense de tous les temps
Cela rend clair l'état actuel de vos récompenses. Toutes les récompenses temporelles ne diminueront jamais. La récompense confirmée ne diminue que lorsqu'un utilisateur dépense/retire/etc des points.
Le solde des récompenses non confirmées fluctuera naturellement. Soit en étant transféré vers Confirmed Rewards, soit en étant rejeté. Puisqu'il est étiqueté "Non confirmé", vos utilisateurs devraient être plus compréhensifs lorsqu'un conflit survient et qu'une récompense est supprimée. (Vos utilisateurs savent que le travail doit être accepté, pas seulement soumis, pour une récompense, non?)
Il pourrait être utile d'essayer de combiner les deux approches. Les utilisateurs devraient être incités à effectuer des tâches, car les tâches conduiront éventuellement à un montant d'argent prouvable et visible. D'un autre côté, vous voulez qu'ils subissent une perte de récompenses moins tragiquement.
Alors, laissez les utilisateurs gagner des récompenses en points, mais permettez de convertir des points en argent d'une manière bien documentée. (Par exemple, quelque chose comme "Vous pouvez convertir tous les points supérieurs à 1000 à tout moment en argent à un taux de 10: 1") Donnez-leur une incitation à travailler pour le prochain retrait.
De cette façon, les utilisateurs ne sentent pas que la récompense gagnée ou perdue touche directement leur sac à main, mais ils savent toujours que les points finiront par se traduire en espèces.
Personnellement, j'aurais dit, et je pense, la même chose que ce que vous avez découvert concernant l'intérêt pour votre application. L'argent est roi et je me soucie peu des "points". L'argent générant des intérêts plus élevés pourrait être ce que vous voulez vraiment: des intérêts. Si les intérêts diminuent à mesure que l'argent baisse, ce sont peut-être des utilisateurs dont vous ne voulez pas.
Donc, la friction est ce qui doit être supprimé, mais je suppose que ce n'est pas ce que vous pouvez faire. Vous pourriez considérer la goutte d'argent comme un coup de poing plutôt qu'un coup de couteau afin qu'ils ressentent le coup de pouce mais pas la douleur.