1日1回のユーザーアクション：24時間リセットと深夜リセット
ユーザーが1日1回だけアクションを実行できる場合（たとえば、コンテストの無料チケットを取得する場合）、私の経験で2つの可能性があります。
1）24時間リセット
1日目の午後11時45分にアクションを実行する場合、2日目の午後11時45分以降にのみアクションを再度実行できます。彼は2日目の11:44にそれを行うことができません。
2）真夜中のリセット（または任意の固定時間）
ユーザーが1日目にアクションを実行する時間に関係なく、それが真夜中になって2日目が始まるとすぐに、ユーザーは再びそれを実行できるようになります。
どちらもユーザーが1日に1つのアクションしか実行できないことを制限しますが、ほとんどの場合、方法1に遭遇します。これは2つの理由でかなり不便だと思います。
- 最初に私は時間を待たなければなりません
- 長い時間をかけて秒を数えると、アクションを実行するタイムスタンプが次第に遅くなります。これは、そのタイムスタンプで正確にアクションを毎日、数秒または数分後に実行することができないためです。
私の考えではユーザーにとって重要な不利な点は前に述べましたが、方法1を好む技術的な理由はありますか？
編集して、指定します： current free spin eventなどのように、24時間の実際のタイムギャップが明らかに必要ない例について特に話しています。 of Theory11 、24時間ごとに1回の無料スピンを獲得して、賞品を獲得するチャンスを得ます。
通常は真夜中のリセットを期待しているので、私は驚いています。
ただし、24時間ごとに真夜中が2つ以上あるという大きな欠点があります。タイムゾーンを選択する必要があります。
多分これが24時間に1回のユニバーサルが選択される理由であり、会社が異なる国の半分のユーザーにローカルエンドタイムを午前0時以外に設定することを受け入れたくない、または「1日あたり」が午前0時を暗示すると考えるのではなく、したがって、彼らはマーケティングを「24時間ごと」に変更し、ソフトウェア仕様を一致させる
これは、最近「グリニッジ標準時午後2時」またはこれに類似するものを見るのはかなり一般的だと思います。
すべてのユーザーの最終アクション日付を保存するという課題は、ユーザーまたはアクションタイプにタイムゾーンを割り当てるよりも難しいと思いました。
編集私は2つの方法の違いに注意する価値があると思います
24時間ルール
- 24時間に1回未満に制限されたイベントの一定のストリームを取得します。
- 終わりにすると、一部のユーザーはイベントが少なくなります。
- すべてのユーザーの最後のイベントを保存する必要があります
- 夏時間が長くて短い日が発生する場合、1日に1つのイベントはありません
- 人間はドットを24時間正確にヒットすることができないので、平均して1日あたり1未満が自然に得られます。
暦日のルールごとに1つ
- 暦日に割り当てられた50時間（？UTC + 14から-12？）の期間にわたってバケット化されたイベントを取得します
- 現実的には、すべてのユーザーの最後のイベントをラップの「日」として保存する必要があります
- nowの後のすべてのイベントがその日ではないと言える、明確な1日の終わりがあります。
- イベントが適用される曜日を知るには、ユーザーの場所を知る必要があります
- 一部の人々は他の人よりも「日」のはるかに早く起きています
UTCルールでは1日あたり1
- 私は24時間長いナイスユニフォームを取得します
- イベントをバケツにすることができます
- 一日の始まりと終わりがいつになるか知っています
- 夏時間は人々を混乱させるでしょう。
- 人間は1日に1つのイベントを持つことができます
- グリニッジの近くに住んでいない人間は面白い開始時間と終了時間を持っています
- 多分私は賢い最適化を行い、入力したユーザーのリストを保存することができますか？ （おそらく私はすべてのユーザーのイベントと時間を保存することになります）
*イベントのバケット化は、さまざまなレポート作成の目的で非常に役立ちます。例えば。 24時間ごとに当選する賞品が10あり、それらは時間とともに異なります。 10日目に何人の学生が入学しましたか？等
私の頭の上から：
- 「最後のアクションから24時間」バージョンを実装する方が簡単かもしれません
- ユーザーが最後の時間から正確に24時間後にアクションを実行しない場合、リセットはスリープまたは作業中に発生する必要があるため、最終的には24時間全体を逃す可能性があります。おそらく、彼らは出勤前の午前7時にそれを行い、午後8時に出勤します。翌日7時15分、7時30分、7時45分に実行し、最終日は8時まで待機して、出発直前にアクションを実行します。彼らは翌日8:15まで滞在するつもりはないので、その朝を逃して、午後6時に仕事から家に帰った後、34時間のギャップを空けてください。アクションの結果が会社にとって高額な場合、節約は不便さよりも重要かもしれません。
他の回答が述べたように、24時間方式は複数のタイムゾーンに対応し、各ユーザーの最後に成功したタイムスタンプを格納するだけで簡単にコーディングできます。
また、実際にユーザーが毎日アプリを操作してすべての毎日のアクションを取得する必要があるという「利点」も追加されています。真夜中のリセットがある場合、ユーザーは午後11時59分にアクションを実行し、その後午前12時にアクションを実行できます。彼らはこれを一日おきに行うことができ、それでもすべてのアクションを取得できます。一部のアプリでは、毎日のアクションの目的は、ユーザーがアプリを毎日操作できるようにすることであり、これはあまり理想的ではありません。
両方のUIの落とし穴を回避する3番目の代替策がありますが、コーディングが少し難しいです。
）（n-0.75）* 24時間でnを超えるアクションのストリークはありません
格納には2つの変数が必要ですが、システムを悪用しようとしない人でも、タイムゾーンやリセットを気にすることなく、いつでも1つのアクションを使用できます。
また、誰もが複数の「追加」アクションを使用できないようにします。
したがって、実際には、ストリークの開始時間、最後の再生時間、ストリークのアクション数を格納するために必要なアルゴリズムを実装します。
最後のアクション時間を追跡することで、近すぎる2つのアクションを拒否できます。この制限により、24時間未満にすることができます。
あなたが毎日あなたの行動をとっている限り、ストリークは続きます。アクションを実行すると、連勝日数よりも多くのアクションが発生することになる場合は、拒否されます。ストリークの開始時刻が変更されないため、これにより、ゆっくりと前方に忍び寄り、「余分な」アクションが詰め込まれなくなります。
チェックを実装して時間を追跡するためのいくつかの疑似コード：
//precondition: streakStart and lastAction are initialized as in the far past
// streakCount is initialized as 0
graceHours=18;
checkAllowed(currentTime,&streakStart,&streakCount, &lastAction){
diffhours=hoursDifferent(lastAction,currentTime);
if(diffhours< 24 - graceHours){
return false;
}
diffhours=hoursDifferent(streakStart,currentTime);
if(diffhours <= 24*streakCount - graceHours){
return false;
}
if(diffhours > 24*(streakCount+2)-graceHours){
streakStart=currentTime;
streakCount=0;
}
streakCount++;
lastActionTime=currentTime;
return true;
}
追加のボーナスとして、ストリークカウンターを取得します（必要な場合）。
アクション間の24時間の持続時間に関する問題について、一部の企業では代わりに22時間の持続時間を使用しています。これにより、ユーザーはアクションが必要な正確な瞬間に少し余裕があり、実際にアクションを実行するようユーザーを促すことができます。 1日1回-23:59-00:00抜け穴なし。
答えはありませんが、コメントするための十分なポイントがありません。
tl/dr: 24 hour resets are the lazy man's way of minimizing load spikes
上記の回答に加えて、真夜中のリセットはトラフィックの急増を促進します。特定の時間にすべての参加者がアクションを使用できるようになった場合、多くの人が同時にアクションを試行するインセンティブになります。これは、ほとんどの州で、運転免許証が決まった日付（米国）ではなく誕生日に期限切れになるのと同じ理由です。DMVは、1月1日に全員の運転免許証が期限切れになると、追いつくことができません。
小さめ：コンピュータシステムが多数のユーザーに対して1日に1回アクションを実行する必要がある場合、同じ質問をすることができます。両方を組み合わせたものです。 2つのcronタスクを想像できます。
- 真夜中に実行し、すべてのレコードを検索して、アクションを実行します
- 毎分（または一定の頻度で）実行し、昨日の00:00以降にアクションを実行していないすべてのレコードを検索し、アクションを実行し、そのアクションが実行されたことを記録します
実際には、前者はもろいことがわかった。実行中にcronタスクが中断した場合、一部の番号でアクションが適用されない可能性があり、システムがどこにあったかを記憶し、中断したところから再開するために追加の作業が必要になることがあります。また、cronタスクが適切な制限時間内にすべてのレコードを処理できないほどのレコードを取得した場合、問題が発生する可能性があり、終了する前にシャットダウンされます。
後者は、これらの懸念の両方を処理します。 24時間間隔ですべてを処理することを目的とはしていませんが、cronタスクが毎日すべてのアクションを簡単に実行できる限り、それらはかなり近くにありますおよび全員が実際の日に実行されることを保証します（つまり、24時間を超えてゆっくりとバラバラにならないようにします）。ただし、最も重要なのは、何らかの理由で問題が発生した場合に、中断したところから簡単に再開できることです。
TfL（ロンドン交通）でのバス/電車のチケットは、午前4時30分から午前4時30分まで有効です。人々が眠っているときに切り替えを行います。多くの人が8:30から深夜0時までのサービスを使いたいと思います
真夜中のリセットには、解決しようとしている問題に応じて、望ましい場合と有害な場合がある特定の条件があります。つまり、1日11:59:58にアクションを実行し、00：00：01に再びアクションを実行できます。問題のスペースが何らかの種類の競争である場合、これは深夜近くにアクションを実行することを選択する人々に不当な利点を与える可能性があります。 24時間のリセットルールは、誰かが何時に利用できるかに関係なく、利用可能なアクションを公平に分配する唯一の方法です。
24時間のリセットがどんどん遅くなることの影響は、許容範囲を設けることで軽減できます。たとえば、アクションが実際に記録されていない（または実行されない）限り、リセットが発生してから15分以内にアクション要求を受け入れることができます。効果）リセットが発生するまで。これにより、ソリューションが少し複雑になりますが、真夜中のリセットの場合のように、1日2回のアクションを1秒間隔で実行できるようにするための緩和策は考えられません。
24時間ルールが定期的な定期訪問を奨励しているという事実に言及したことは誰も見たことがありません。多くのゲームでは、1日1回のログイン/勝利報酬があり、48時間ごとに2倍ではなく24時間ごとに短時間チェックインするため、24時間後にリセットされます。チケットの景品をホストするWebサイトでも同様だと思います。