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:
Y a-t-il une technique raison, que l'on préfère la méthode 1, bien que, à mon avis, le désavantage important pour l'utilisateur indiqué au préalable?
Modifier, pour spécifier: je parle en particulier d'un exemple, où l'intervalle de temps réel de 24 heures n'est évidemment pas nécessaire, comme dans le événement de rotation libre actuel de Theory11 , où vous obtenez 1 tour gratuit toutes les 24 heures pour avoir une chance de 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 la raison pour laquelle l'universel une fois par 24h est choisi, vous pouvez imaginer que l'entreprise 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
1 règle par jour civil
1 par jour calendaire en règle UTC
* 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:
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 à 00 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.
) Aucune séquence de plus de n actions en (n-0,75) * 24 heures
Il nécessite deux variables à stocker, mais il permet à quelqu'un 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 tous les jours. 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 conçois généralement ce doit être une combinaison des deux. Vous pourriez imaginer deux tâches cron:
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 garantissez que tout le monde s'exécute chaque jour (c.-à-d. que 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.
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, par exemple 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'exécuter 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 à intervalles 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.