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を好むという技術的な理由はありますか？

編集して、指定します。特に、現在の 24時間ごとに1つのフリースピンを獲得するTheory11のフリースピンイベントのように、24時間の実際のタイムギャップは明らかに必要ではない例について話しています。入賞時。

通常、真夜中のリセットが予想されるので驚いています。

ただし、24時間ごとに深夜が複数あるという大きな欠点があります。タイムゾーンを選択する必要があります。

多分これが24時間に1回のユニバーサルが選択された理由です。異なる国の半分のユーザーは現地時間の深夜以外の時間を受け入れることを望まないかもしれません。したがって、マーケティングを「24時間ごと」に変更し、ソフトウェア仕様をそれに合わせて変更します

私はこれが「GMTで午後2時に終了」または類似したものを見るのはかなり一般的だと思いますが。

すべてのユーザーの最終アクション日付を保存することは、ユーザーまたはアクションタイプにタイムゾーンを割り当てることよりも難しいと思います。

編集2つの方法の違いに注目する価値があると思います

24時間ルール

• 24時間に1回未満に制限されたイベントの一定のストリームを取得します。
• 話を終えると、一部のユーザーのイベントが少なくなります。
• すべてのユーザーの最後のイベントを保存する必要があります
• 夏時間により長い日または短い日が発生する場合、1日あたり1つのイベントはありません
• 人間はドットで正確に24時間ヒットすることができないので、自然に1日あたり平均1未満になります

暦日のルールごとに1

• カレンダーの日に割り当てられた50h（？UTC + 14から-12？）の期間にバケットイベントを取得します。
• 現実的には、すべてのユーザーの最後のイベントを「日」として重ねて保存する必要があります
• 私は一日の終わりがあり、今からすべてのイベントはその日ではないということができます。
• イベントが適用される日を知るには、ユーザーの場所を知る必要があります
• 一部の人々は、他の人々よりもはるかに早く「日」に起きています

UTCルールで暦日ごとに1

• 24時間長い素敵な制服を着る
• イベントをバケツできます
• 私は一日の始まりと終わりがいつかを知っています
• 夏時間は人々を混乱させます。
• 人間は1日に1つのイベントを持つことができます
• グリニッジの近くに住んでいない人間は、面白い開始時刻と終了時刻を持ちます
• 巧妙な最適化を行い、入力したユーザーのリストを保存することはできますか？（おそらくすべてのユーザーのイベントと時間を保存することになります）

*イベントのバケティングは、さまざまなレポートの目的に非常に役立ちます。例えば。24時間ごとに10個の賞品を獲得できますが、それらは時間とともに異なります。10日目に何人の学生が入学しましたか？等

私の頭の上から：

• 「最後のアクションから24時間」バージョンを実装する方が簡単な場合があります
• ユーザーが最後の24時間後にアクションを正確に実行しないと、スリープ中または作業中にリセットが必要になるため、最終的に24時間全体を見逃す可能性があります。おそらく彼らは仕事に出る前に午前7時にそれをし、午後8時に仕事に出る。翌日、彼らは7:15に、それから7:30に、それから7:45にそれを行い、最終日には8:00まで残り、アクションを実行します。翌日は8時15分まで滞在しないので、その朝は欠場し、午後6時に職場から帰宅してから34時間のギャップを空けてください。アクションの結果が企業にとって高額な場合、節約は不便よりも重要かもしれません。

他の回答で述べたように、24時間方式は複数のタイムゾーンに対してより使いやすく、各ユーザーの最後に成功したタイムスタンプを保存するのと同じくらい簡単にコーディングできます。

また、毎日のアクションをすべて取得するために、ユーザーが毎日アプリと対話することを実際に要求するという「利点」が追加されています。真夜中にリセットが発生した場合、ユーザーは午後11時59分にアクションを実行し、その後午前12:00にアクションを実行できます。彼らは一日おきにこれを行うことができ、それでもすべてのアクションを取得できます。一部のアプリでは、毎日のアクションの目的は、ユーザーがアプリを毎日操作できるようにすることであるため、あまり理想的ではありません。

両方のUIの落とし穴を回避する3番目の選択肢がありますが、コーディングが少し難しくなります。

3）（n-0.75）* 24時間でnを超えるアクションの縞がない

2つの変数を保存する必要がありますが、システムを悪用しようとしない人は、タイムゾーンやリセットを気にすることなく、1日中いつでも1つのアクションを使用できます。

また、誰もが複数の「余分な」アクションを使用できないようにします。

そのため、ストリークの開始時間、最終再生時間、ストリークのアクション数を保存するために必要なアルゴリズムを実際に実装します。

最終アクション時間を追跡することにより、近すぎる2つのアクションを拒否できます。ただし、ストリークにより1日の早い段階でクリープが防止されるため、この制限を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

上記の回答に加えて、深夜リセットはトラフィックの急増を促します。特定の時間にすべての参加者がアクションを利用できるようになると、多くの人々が同時にアクションを試みるインセンティブが得られます。これは、ほとんどの州で一定の日付（米国）ではなく誕生日に運転免許証の有効期限が切れるのと同じ理由です。1月1日に全員の運転免許証の有効期限が切れると、DMVは維持できなくなります。

余談：コンピュータシステムが多数のユーザーに対して1日に1回アクションを実行する必要がある場合、同じ質問をすることができます。通常、両方を組み合わせて設計します。次の2つのcronタスクを想像できます。

1. 真夜中に実行し、すべてのレコードを検索して、アクションを実行します
2. 毎分（または一定の頻度）ごとに実行し、昨日00:00以降にアクションを実行していないすべてのレコードを検索し、アクションを実行し、アクションが実行されたことを記録します

実際には、前者は脆いことがわかりました。実行中にcronタスクが破損した場合、一部の番号にアクションが適用されない可能性があり、システムが現在の場所を記憶し、中断した場所を特定するために追加の作業が必要になる場合があります。また、cronタスクが妥当な制限時間内にすべてを処理できないほど十分なレコードを取得すると、問題を引き起こし、終了する前にシャットダウンされます。

後者は、これらの懸念の両方を処理します。すべてを24時間正確に処理することを目的とはしていませんが、cronタスクが毎日すべてのアクションを簡単に実行できる限り、それらは非常に近く、誰もが実際の日に実行されることを保証します（つまり、 24時間を超えてゆっくりと物事がばらばらになることはありません）。最も重要なことは、何らかの理由で故障した場合、中断したところから簡単に再開できることです。

https://www.youtube.com/watch?v=hoMO1yYC7pQ

TfL（ロンドンへの交通機関）の毎日のバス/電車のチケットは、午前4時30分から午前4時30分まで有効です。眠っているときに切り替えます。多くの人が8:30から深夜1時までのサービスを利用したいと思うでしょう。

真夜中のリセットには、解決しようとしている問題に応じて、望ましいまたは有害な特定の条件があります。つまり、1日11:59:58と00:00:01にアクションを実行できます。問題空間が何らかの競争である場合、これは真夜中近くに行動を実行することを選択する人々に不公平な利点を与える可能性があります。24時間のリセットルールは、誰かが利用できる時間に関係なく、利用可能なアクションの公平な分散を保証する唯一の方法です。

24時間のリセットの遅延の結果は、許容範囲を設けることで緩和できます。たとえば、アクションが実際に記録されない（または実行されない）限り、リセットが発生してから15分以内にアクションリクエストを受け入れる効果）リセットが発生するまで。これにより、ソリューションが少し複雑になりますが、深夜リセットの場合のように、2日間の毎日のアクションを数秒離して実行できるようにするための緩和戦略は考えられません。

私は、24時間ルールが定期的な定期訪問を奨励しているという事実を誰も言及していない。多くのゲームでは、1日1回のログイン/勝利報酬が24時間後にリセットされます。これは、48時間ごとに2倍の時間ではなく、24時間ごとに短時間でチェックインするためです。チケットプレゼントをホストしているウェブサイトでも同様だと思います。