リワードシステムを含むアプリを間もなくリリースします。これらの報酬はリアルマネーであるため、直接報酬残高:$ xxxxで十分です(理論上)。基本的に、報酬はタスクの完了に対する実際の支払いです
ただし、最初のテストでは、ストーリーに2つの部分があることが示されています。 これらの報酬は減少する可能性があるため3つのシナリオがあります:残高が増加し、残高が縮小し、残高は同じままです
最初のシナリオでは、明らかに、テストはユーザーが$で示される金額に対して非常に良いレセプションを持っていることを示しています。
ただし、2番目のシナリオ(バランスが縮小)では、摩擦は屋根に向かいました 損失回避バイアス に基づいています。次に、これによりテストグループが静的になり、タスクをまったく停止します。
の3番目のシナリオでは、表示された$の量に関連して負の符号(少なくとも重要なものはありません)は見つかりませんでしたが、奇妙なしきい値パターンが見つかりました。凍結、つまりloss aversionは減少する前でも再生を開始しました。
だから私たちはポイントで行くことにしました。これまでのところ、テストユーザーの反応は良くも悪くもありませんでした。まったく興味がないように見えました。タスクの完了は、上記のしきい値パターンで多かれ少なかれ、おそらく少し高かったが、これは、3つのケースすべてで発生した:成長、縮小、失速。明るい面では、これにより限界利益が得られます
金額を表示することには多くの摩擦がありますが、その摩擦段階までに実行されるタスクが多くなります。ポイントは摩擦がはるかに少なくなりますが、ユーザーがより多くのタスクを実行できるほど魅力的ではありません。
私たちはこれを詰め込んでいるので、より多くのテストのための時間は本当に厳しいので、私の質問は:points methodまたは$メソッドは間違いなく優れていますか?
ポイントは行く方法であると想定しています、上記の問題を回避するために他の方法よりもうまく機能する方法はありますか?例えば: 1 point = 1$
OR 10 points = 1$
OR 1 point =$10
またはrangesこれは、ユーザーにとってはより少ない金額につながる可能性がありますが、より高い合計を得るために次のステップに進む必要があるため、完了率はより高くなります。例:50 to 99 points achieved = $50 . 100 to 199 points achieved = $100
編集:答えが役立つ場合に備えて、合計は数ドル(まあ、別の通貨ではより多くの数字がありますが、例のために)、極端な場合には5数字になることがあります。可能性は低いですが、可能です。ただし、ほとんどの金額は3〜4桁の範囲になります。
編集2:これはゲーミフィケーションモデルではありません。これは、実行される実際のタスクの実際のお金です。非常に厳密なNDAのため、詳しい情報を提供することはできませんが、まったく関係のない例として、クライアントがユーザーに、花びらが5〜8個の黄色、青、または赤い花を見つけてほしいと考えているとします。とても多くのユーザーが花を送るでしょう。クライアントは、花びらが5枚、1枚が6枚、1枚が7枚、1枚が8枚の黄色い花のみを必要とします。赤と青も同じです。それ以外はすべて拒否されます。
しかし、その後、多くのユーザーが5つの花びらを持つ黄色い花を送信し、多くのユーザーが6つの花びらを持つ黄色い花を送信するというようになります。このためのアルゴリズムが用意されていますが、例として、クライアントが各タイプの最初の花のみを承認するとします。
この巨大な待機時間のため、実行されたタスクを反映する必要があります。仕様が遵守されているか、一時的に承認されているか、ユーザーが進捗状況を追跡して作業の結果を確認する方法がありません。
したがって、私たちは一時的な数値を使用しており、これらの数値が最終レビューの対象であることを明確に指定します。したがって、プロセス自体には問題はありません。ほとんどの回答が指摘しているように、問題は数値にあります:金額またはポイント額、それぞれに見つかった問題
ポイントと現金の両方を報酬として含むFanDuel/DraftKingsに似たアプリケーションを以前に設計/テストしました。ポイントシステムを使用すると、ユーザーはポイントを貯めることができます-ポイントを失うか、同じままにすることができます。後で、報酬システムとして現金も含めました。 (ユーザーは報酬として現金またはポイントを選択できます)テストの観点から、これにより、どの報酬システムがユーザーの行動をより積極的に促進したかを分析できました。
私たちが発見したのは、ユーザーの行動を直接比較したところ、1日のアクティブユーザーの割合がキャッシュによって維持されていたということです。ポイントがあれば、高い割合のユーザーが1〜2週間製品を使用してから、アカウントを放棄します。ポイント報酬システムに関連しているため、ユーザーは鈍感/熱狂的ではないように見えました。現金に関連するポイントの価値を概説するときでさえ、それはまだ十分に説得力がありませんでした。
どちらのアプローチにも欠点があります...テストで明らかにわかったことです。また、現金の損失は摩擦ポイントであり、時には放棄のきっかけにもなります。それを解決する良い方法は、何らかのインセンティブで損失を埋めることです。意味...ちょっと、あなたはここでいくつかを失ったように見えます-しかし、これはxyzの量のボーナスです。または、ここであなたがポジティブに戻るために何ができるかです。
その経験から、キャッシュリワードシステムを通じてユーザーに価値を提供することが先の道であることが私には明らかになりました。あなただけの摩擦点を介して作業する必要があります。一方、ポイントシステムでは、ユーザーはエクスペリエンスの最初から熱狂的ではありません。その観点から見ると、アプリケーションを使用するときに価値がどこにあるかを示すには、さらに多くの作業が必要です。
お役に立てれば。
マネーバランスの縮小への対応は、損失回避に起因するとは思わない。ユーザーは、特定の小さな損失と可能性の低い大きな損失のどちらかを選択する必要はありません。さらに、残高はいつでもある程度縮小する可能性があるため、利益の割合と損失の割合を実際に比較することはできません。彼らはそれが起こったときにのみ損失に反応することができます。あなたの研究で観察した反応は、損失回避よりも直感的だと思います。人々は単にお金を失うことに内臓的な反応をするだけです。たとえば、たくさんのお金を使うことは 痛みを引き起こすことがわかった でした。
ユーザーがタスクの実行を停止した場合は、製品の使用を事実上停止したことを意味します。ユーザーは否定的な経験(お金を失う)があったために製品の使用を中止したと推測し、将来的にはより否定的な経験をするだろうと考えていました。彼らがそのような信念を抱いている場合、それは、製品が意志および起こりません。これは、彼らが未来が持つもの、すなわちより多くの損失について彼ら自身の悲観的な信念を形成することを意味します。
メインバランスに対して2番目に目立つ暫定バランスを作成することを検討してください。暫定的な残高により、ユーザーは潜在的な収益、つまり消去される可能性のある収益を追跡できます。ユーザーが仮残高で発生する可能性のある変動を明確に理解している場合、この残高の損失に対して強い否定的な反応を示さない可能性があります。ポイントベースのバランスの損失がタスクのパフォーマンスに影響しないことをすでにテストしたので、このバランスをポイントとして表すことを検討します。お金はより高いタスクパフォーマンスを生み出すことが示されているので、メインバランスをポイントではなくお金として表す必要があります。 「セキュリティ期間」が終了すると、暫定残高のポイントをメイン残高のお金に変換できます。
「セキュリティ期間」の調整も検討する必要があると思います。 60日間の「セキュリティ期間」とは、ユーザーが報酬を受け取るまでにかなり長い時間待たなければならないことを意味します。ユーザーはサイトからの支払いを、レンダリングされたジョブやサービスのように実行するために支払いを受ける他のアクティビティと比較することに注意してください。満足感を遅らせることでうまくやっている人もいれば、そうでない人もいます。ほとんどの成人は給与を30日間待つように「訓練」されているため、「セキュリティ期間」を最大で30日間に短縮することを検討します。これは、タスクを完了してから支払いを受け取るまでの待ち時間に耐えられないため、製品から欠陥が発生する可能性があるユーザーを軽減するのに役立ちます。
あなたの状況は私にビットコインマイニングプールを思い出させます。ユーザーは「ポイント」を「現金」に交換できる「仕事」をします。 BitCoinにも同じ問題があり、ネットワークによって作業が拒否される可能性があります。
BitcoinマイニングプールであるSlushpoolは、報酬のいくつかの価値を示します。
これにより、報酬の現在の状態が明確になります。オールタイムリワードは決して減ることはありません。確認済みの報酬は、ユーザーがポイントを使用/引き出し/などした場合にのみ下がります。
未確認の報酬残高は自然に変動します。確認済み特典に転送されるか、拒否されます。 「未確認」というラベルが付いているため、紛争が発生して報酬が取り消されるタイミングをユーザーが理解する必要があります。 (ユーザーは、成果物を提出するだけでなく、承認する必要があることを理解していますか?)
両方のアプローチを組み合わせてみる価値はあります。タスクは最終的に証明可能な目に見える金額につながるため、ユーザーにはタスクを実行するインセンティブが必要です。一方、あなたは彼らに報酬の損失をそれほど悲劇的に経験させないようにしたいです。
したがって、ユーザーがポイントで報酬を獲得できるようにし、十分に文書化された方法でポイントをお金に変換できるようにします。 (たとえば、「いつでも1000を超えるすべてのポイントを10:1のレートでお金に変換することができます」)次のキャッシュアウトのために働くインセンティブを彼らに与えます。
このようにして、ユーザーは、獲得または喪失した報酬が財布に直接影響しているとは感じませんが、ポイントは最終的にハードキャッシュに変換されるという知識を持っています。
個人的には、アプリへの関心についてあなたが発見したのと同じだと思います。現金は王様であり、私は「ポイント」をほとんど気にしません。より高い関心を生み出す現金は、あなたが本当に望んでいるものかもしれません:関心キャッシュドロップとして関心が衰えれば、それはおそらくあなたが望まないユーザーでしょう。
だから摩擦を取り除く必要がありますが、それはあなたができることではないと思います。キャッシュドロップを刺すのではなく突っ込みであると考えると、彼らはナッジを感じるが痛みは感じません。