Sur une action de l'utilisateur une fois par jour: Réinitialisation 24 heures contre réinitialisation minuit [fermé]

Lorsqu'un utilisateur ne peut effectuer une action qu'une seule fois par jour, par exemple en obtenant un ticket gratuit pour une compétition, il y a deux possibilités que j'ai rencontrées dans mon expérience.

1) Réinitialisation 24 heures

S'il exécute l'action le jour 1 à 23 h 45, il ne peut effectuer à nouveau l'action que le jour 2 à 23 h 45 ou après. Il ne pourra pas le faire à 11 h 44 le jour 2.

2) Réinitialisation de minuit (ou toute heure fixe)

Quelle que soit l'heure à laquelle l'utilisateur exécute l'action le jour 1, dès qu'il aura minuit et que le jour 2 commencera, il pourra recommencer.

Les deux limitent l'utilisateur à effectuer une seule action par jour, mais je rencontre le plus souvent la méthode 1, qui, je pense, est assez gênante pour deux raisons:

• Je dois d'abord attendre le temps
• et deuxièmement sur une longue période, l'horodatage de moi effectuant l'action deviendra de plus en plus tard, car je ne pourrai pas exécuter l'action exactement à cet horodatage tous les jours, seulement quelques secondes ou minutes plus tard.

Y a-t-il une raison technique , que l'on préfère la méthode 1, bien que, à mon avis, l'inconvénient important pour l'utilisateur indiqué au préalable?

Modifier, pour spécifier: je parle surtout d'un exemple, où l'intervalle de temps réel de 24 heures n'est pas évidemment nécessaire, comme dans l' événement de rotation libre actuel de Theory11 , où vous obtenez 1 rotation gratuite toutes les 24 heures pour avoir une chance à gagner des prix.

Je suis surpris comme d'habitude je m'attendrais à la réinitialisation de minuit.

Cependant, cela présente un inconvénient majeur, car il y a plus d'un minuit toutes les 24h. Vous devez choisir votre fuseau horaire.

C'est peut-être pour cela que l'universel une fois par 24h est choisi, vous pouvez imaginer que la société pourrait ne pas accepter que les utilisateurs à moitié dans différents pays aient des heures de fin locales non minuit, ou plutôt qu'ils pourraient considérer que dire "par jour" impliquait minuit et donc ils changent le marketing en "par 24h" et les spécifications du logiciel pour correspondre

Bien que je pense que c'est assez courant de voir "se termine à 14 heures GMT" ou similaire de nos jours.

J'aurais pensé que le défi de stocker une dernière date d'action pour chaque utilisateur serait plus difficile que d'attribuer un fuseau horaire aux utilisateurs ou aux types d'actions.

Edit je pense qu'il vaut la peine de noter les différences entre les deux méthodes

Règle des 24h

• J'obtiendrai un flux constant d'événements, taux limité à moins de 1 par 24h.
• Lorsque je termine la chose, certains utilisateurs obtiendront moins d'événements.
• J'ai besoin de stocker le dernier événement de chaque utilisateur
• Lorsque l'heure d'été cause une journée longue ou courte, je n'aurai pas 1 événement par jour
• Les humains ne pourront pas frapper exactement 24h sur le coup, donc j'obtiendrai naturellement moins de 1 par jour en moyenne

1 règle par jour civil

• Je reçois des événements regroupés sur une période de 50 heures (? UTC + 14 à -12?) Affectés à un jour civil
• de façon réaliste, je dois encore stocker le dernier événement de chaque utilisateur comme «jours» sur le tour
• J'ai une fin de journée bien définie où je peux dire que tous les événements qui se déroulent après ne sont pas dans la journée.
• J'ai besoin de connaître l'emplacement de l'utilisateur pour savoir à quel jour son événement s'applique
• Certaines personnes sont éveillées bien plus tôt dans la «journée» que d'autres

1 par jour calendaire en règle UTC

• Je reçois de beaux uniformes 24h de longues journées
• Je peux regrouper mes événements
• Je sais quand le début et la fin d'une journée sont
• L'heure d'été va dérouter les gens.
• Les humains peuvent avoir 1 événement par jour
• Les humains ne vivant pas près de Greenwich auront des heures de début et de fin amusantes
• Peut-être que je peux faire une optimisation intelligente et simplement stocker une liste d'utilisateurs qui ont entré? (je finirai probablement par stocker chaque événement et heure des utilisateurs)

* Le regroupement des événements va être super utile à diverses fins de rapport. par exemple. dis que j'ai 10 prix à gagner par période de 24h et ils varient dans le temps. Combien d'élèves sont entrés le jour 10? etc

Du haut de ma tête:

• Il peut être plus facile d'implémenter la version "24 heures depuis la dernière action"
• Si l'utilisateur n'effectue pas l'action exactement 24 heures après la dernière fois, il peut éventuellement manquer une période complète de 24 heures car la réinitialisation doit se produire lorsqu'il est en veille ou qu'il travaille. Peut-être le font-ils à 7 heures du matin avant de partir travailler et partent à 20 heures. Le lendemain, ils le font à 7 h 15, puis à 7 h 30, puis à 7 h 45, et le dernier jour, ils restent jusqu'à 8 h 00 pour effectuer l'action juste avant de partir. Le lendemain, ils ne sont pas disposés à rester jusqu'à 8 h 15, alors manquez ce matin et faites-le après le retour du travail à 18 h, soit un intervalle de 34 heures. Si le résultat de l'action est coûteux pour l'entreprise, l'économie peut être plus importante que les inconvénients.

Comme d'autres réponses l'ont mentionné, la méthode 24h est plus conviviale pour plusieurs fuseaux horaires et est tout aussi facile à coder que vous enregistrez simplement le dernier horodatage réussi pour chaque utilisateur.

Il a également l'avantage supplémentaire d'exiger de l'utilisateur d'interagir avec l'application chaque jour pour obtenir toutes les actions quotidiennes. S'il y a, par exemple, une réinitialisation à minuit, un utilisateur peut effectuer une action à 23 h 59, puis à nouveau à 12 h 00. Ils pouvaient le faire tous les deux jours et obtenir toutes les actions. Pour certaines applications, le but des actions quotidiennes est d'amener l'utilisateur à interagir avec l'application quotidiennement, ce qui est moins idéal.

Il existe une troisième alternative qui évite les pièges de l'interface utilisateur des deux, mais est un peu plus difficile à coder.

3) Aucune séquence de plus de n actions en (n-0,75) * 24 heures

Il nécessite deux variables pour le stockage, mais il permet à une personne qui n'essaie pas d'abuser du système d'utiliser sa seule action à tout moment de la journée sans avoir à se soucier des fuseaux horaires et des réinitialisations.

Il empêche également quiconque d'utiliser plus d'une action "supplémentaire".

Donc, implémentez l'algorithme dont vous avez besoin pour stocker l'heure de début de la séquence, la dernière durée de lecture et le nombre d'actions dans votre séquence.

Garder une trace du dernier temps d'action vous permet de rejeter deux actions qui sont trop proches l'une de l'autre. Vous pouvez cependant faire cette limite en moins de 24 heures, car la séquence empêche de ramper plus tôt dans la journée.

Une séquence continue aussi longtemps que vous agissez quotidiennement. Si prendre une action signifie que vous auriez plus d'actions que de jours dans votre séquence, elle sera rejetée. Cela évite d'avancer lentement et d'accumuler des actions "supplémentaires" car l'heure de début de votre séquence ne change pas.

un pseudo code pour implémenter la vérification et suivre les temps:

//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;
}

En prime, vous obtenez un compteur de séquences, si vous en voulez un.

À propos de votre problème avec la durée de 24 heures entre les actions, certaines entreprises utilisent plutôt une durée de 22 heures, de cette façon, les utilisateurs obtiennent un peu de latitude au moment exact de la journée où l'action est requise et continuent d'encourager les utilisateurs à réellement effectuer l'action une fois par jour - pas 23:59 - 00:00 échappatoire.

Pas une réponse mais je n'ai pas assez de points pour commenter.

tl/dr: 24 hour resets are the lazy man's way of minimizing load spikes

En plus des réponses ci-dessus, la réinitialisation de minuit encourage les augmentations de trafic. Si l'action devient accessible à tous les participants à un moment donné, alors de nombreuses personnes seront incitées à tenter l'action en même temps. C'est la même raison pour laquelle la plupart des États ont votre permis de conduire expirer le jour de votre anniversaire plutôt qu'à une date fixe (États-Unis): le DMV ne pourrait pas suivre si tout le monde avait son permis de conduire expirer le 1er janvier.

Petit côté : si un système informatique doit intervenir une fois par jour pour un grand nombre d'utilisateurs, vous pouvez poser la même question, et je le conçois généralement comme une combinaison des deux. Vous pourriez imaginer deux tâches cron:

1. Courez à minuit, trouvez tous les enregistrements, passez à l'action
2. Exécuter toutes les minutes (ou à une fréquence régulière), trouver tous les enregistrements qui n'ont pas pris de mesures depuis 00h00 hier, prendre des mesures, enregistrer que des mesures ont été prises

Dans la pratique, j'ai trouvé le premier fragile. Si une tâche cron se casse en cours d'exécution, il se peut que l'action ne soit pas appliquée à un certain nombre, et un travail supplémentaire peut être nécessaire pour que le système se souvienne où il était et reprenne là où il s'était arrêté. Cela peut également causer des problèmes si vous obtenez suffisamment d'enregistrements pour que votre tâche cron ne puisse pas tous les traiter dans un délai raisonnable, et elle est arrêtée avant la fin.

Ce dernier répond à ces deux préoccupations. Il ne vise pas à ce que tout soit traité exactement 24 heures d'intervalle, mais tant que votre tâche cron peut facilement exécuter toutes les actions chaque jour, elles seront assez proches et vous garantirez que tout le monde s'exécute chaque jour réel (c.-à-d. vous n'aurez pas les choses qui s'écartent lentement de plus de 24 heures). Plus important encore, il reprendra facilement là où il s'était arrêté si les choses tombent en panne pour une raison quelconque.

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

Les billets quotidiens de bus / train à TfL (Transport for London) sont valables de 4h30 à 4h30. Faites le changement lorsque les gens dorment. Beaucoup de gens voudront utiliser un service, disons de 8h30 à une heure après minuit

La réinitialisation de minuit a une condition spécifique qui pourrait être souhaitable ou préjudiciable, selon le problème que vous essayez de résoudre, à savoir: je peux effectuer l'action un jour à 11:59:58 et à nouveau à 00:00:01. Si l'espace problématique est un type de concurrence, cela pourrait conférer un avantage injuste aux personnes qui choisissent d'effectuer leurs actions vers minuit. La règle de réinitialisation de 24 heures est le seul moyen d'assurer une répartition équitable des actions disponibles, quelle que soit l'heure à laquelle quelqu'un dispose.

La conséquence d'une réinitialisation de 24 heures plus tard et plus tard peut être atténuée en prévoyant une tolérance, par exemple en acceptant une demande d'action dans les 15 minutes suivant la réinitialisation, tant que l'action n'est pas réellement enregistrée (ou ne prend pas effet) jusqu'à ce que la réinitialisation se produise. Cela introduit un peu plus de complexité dans la solution, mais je ne peux penser à aucune stratégie d'atténuation pour pouvoir prendre deux actions quotidiennes à des secondes d'intervalle comme dans le cas de réinitialisation de minuit.

Je n'ai vu personne mentionner que la règle des 24 heures encourage les visites régulières de routine. De nombreux jeux ont une récompense de connexion / victoire une fois par jour qui se réinitialise après 24 heures, car ils préfèrent que vous vous enregistriez pendant une courte période toutes les 24 heures plutôt que deux fois plus longtemps toutes les 48 heures. J'imagine que c'est similaire pour les sites Web hébergeant des cadeaux.