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


24

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.


5
Il pourrait y avoir une raison de limiter le temps réel entre les actions, c'est pourquoi ils opteraient pour un verrouillage de 24 heures. Par exemple, avec l'option 2, vous pouvez effectuer à nouveau l'action à 23:59 et à 00:00.
Ivo Coumans

21
La réponse serait entièrement spécifique au problème, et il n'est pas difficile de trouver des problèmes qui conviennent non plus. Le logiciel est développé pour mettre en œuvre des règles métier, et non l'inverse.
Blrfl

4
Notez que minuit est une heure arbitraire. Cela pourrait tout aussi bien être à tout moment.
David Starkey

2
Sorte de sidenote, minuit peut être problématique pour les oiseaux de nuit. Pour contourner cela, WoW, par exemple, réinitialise les choses "quotidiennes" à 3 ou 4 heures du matin.
Kevin

6
Remarque: Il existe une variété de jeux et tels qui n'autorisent qu'une action toutes les 21 heures. Théoriquement, on pourrait en abuser pour obtenir> 1 par jour, mais cela signifie se réveiller en milieu de sommeil, ce qui est assez rare pour ne pas être si grave pour les serveurs. Il permet ensuite aux utilisateurs de se connecter "tous les matins" sans que le délai ne progresse lentement tout au long de la journée.
Mooing Duck

Réponses:


21

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


Vous touchez clairement mon train de pensées alors que je suis tout aussi surpris. Je pense qu'il serait assez paresseux de procéder à la réinitialisation de 24 heures, mais comme l'indique la réponse de @Richard Ward, il pourrait être plus difficile de respecter tous les fuseaux horaires et pourrait même déclencher des problèmes de communication à partir du début et de la fin de l'événement.
RUL

hmm je pense que vous avez confondu vos réponses. Mais après réflexion, je pense que c'est probablement un problème de communication entre les entreprises et les développeurs. Je peux juste imaginer la réunion de planification ... Ventes: "Donc, les utilisateurs ne doivent être autorisés à prendre l'offre qu'une fois par jour .." Dev: "que faire s'ils volent et franchissent la ligne de date internationale? Peuvent-ils passer deux commandes? " Ventes: "..... non ... disons 1 par 24h" Dev: "OK, hmm gona a besoin de plus de tables pour stocker toutes ces données!" Ventes: "whateves"
Ewan

Je vois, vous pensez que l'approche en 24 heures est moins complexe? Parce que je ne pense pas qu'en dehors d'avoir une table supplémentaire, il est beaucoup plus simple de dire simplement 24 heures que de vérifier et de calculer dans différents fuseaux horaires. Mais vous avez un bon point: en quittant le fuseau horaire, vous pouvez en fait obtenir plus d'un tour.
RUL

4
Je pense que c'est moins complexe à expliquer
Ewan

10
Cette. Les éléments dépendants du fuseau horaire ouvrent une boîte de vers que vous pouvez simplement laisser fermée en utilisant la règle de délai d'attente de 24h. Et ce n'est pas exactement plus difficile à stocker lorsqu'une action s'est produite que de mémoriser qu'elle s'est produite un jour spécifique.
cmaster

14

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.

3
Bon point sur la raison du marketing sournois, pour faire manquer un jour aux utilisateurs.
RUL

1
@RUL Ou, probablement plus au point, un utilisateur est plus susceptible d'acheter un "spin supplémentaire payé" (ou autre) s'il en manque un gratuit. Le coût de donner des tours peut être trivial, mais les ventes supplémentaires occasionnelles peuvent en valoir la peine.
TripeHound

J'ai joué à un jeu basé sur l'époque zoulou lorsque j'étais aux États-Unis. Ce n'était pas trivial de rester droit quand je pouvais ou ne pouvais pas faire une activité.
Cort Ammon - Rétablir Monica

2
Le point 2 est la raison pour laquelle Blizzard (etc.) évite la minuterie de réinitialisation de 24 heures dans WoW et d'autres MMORPG et effectue plutôt une réinitialisation quotidienne.
Adonalsium

8
Il convient de noter que certaines entreprises utilisent simplement un "quotidien" moins strict - League of Legends utilise un lock-out de 21 heures pour la "première victoire de la journée". Suffisant pour conserver les bonus à peu près quotidiennement, tout en étant pratique pour les joueurs. Peut-être en partie à cause de l'idée que vous ne gagnerez pas toujours votre premier match et que les parties prennent environ 30 à 50 minutes, donc une horloge stricte serait vraiment ennuyeuse (puisque vous risquez de reculer le temps d'environ 30 minutes) un jour, à quel point ce n'est pas alléchant car vous n'avez que du temps de jeu pour obtenir la première victoire tous les 3 jours sur un horaire chargé).
Delioth

8

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.


Je pense que c'est probablement la meilleure réponse car cela "fonctionne juste" pour l'utilisateur. Le seul inconvénient est qu'il peut être difficile à comprendre, mais cela ne devrait affecter que les personnes essayant de jouer au système. Les 18 heures de grâce pourraient être expliquées dans le texte, car je pense qu'il est important de faire ce travail (je pense qu'il devrait être plus bas cependant)
rtpax

Approche intéressante, tout de même, pourriez-vous élaborer plus en mots, comment celle-ci fonctionne?
RUL

@RUL L'idée fondamentale est que le temps de réinitialisation d'un utilisateur est verrouillé une fois qu'il a effectué sa première action. Ce n'est pas verrouillé au moment exact où ils prennent leurs mesures, mais un peu avant (18 heures avant, dans ce cas) pour offrir une meilleure expérience utilisateur. Cela permet à un utilisateur d'obtenir un peu d' avance (il peut effectuer ses deux premières actions en seulement 6 heures), mais il n'y a pas d'erreur cumulative car le démarrage est toujours verrouillé - s'il a dépassé le délai de grâce, il devra attendre à au moins 24 heures pour la prochaine action.
Jacob Raihle

5

À 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.


Je pense que ce site Web fait cela avec des choses consommables comme des votes. Ils ne se réinitialisent pas toutes les 24 heures mais toutes les 16 environ (pas sûr du nombre exact). Je suppose que cela a du sens - disons que vous commencez votre journée à 8 heures du matin et commencez à voter haut / bas - vous manquez de votes en 6 heures à 14 heures. Avec une réinitialisation stricte de 24 heures à partir de l'action, si vous choisissez l'heure de réinitialisation lors du dernier vote, vous devrez attendre jusqu'à 14 heures pour recommencer à voter au lieu de votre heure habituelle et vous n'aurez peut-être pas le temps à ce moment-là. Si vous choisissez le premier vote, alors vous avez un problème si un jour vous commencez à voter à 10h mais à 8h le lendemain.
VLAZ

Bien que maintenant que j'y pense - je ne suis pas sûr que ce soit vraiment 16 heures de réinitialisation qui ont désactivé les actions. Cela pourrait être 24 heures et il se trouve que je l'ai attrapé 8 heures après la réinitialisation quotidienne. Mais je suppose que la logique est vraie - si vous avez 24 minuteries individuelles, cela pourrait ne pas être pratique pour un utilisateur.
VLAZ

Cela a le problème opposé de la réinitialisation de 34 heures, des utilisateurs pouvant intégrer des actions supplémentaires s'ils agissent toujours dès qu'ils le peuvent (bien sûr, cela nécessiterait un horrible horaire de sommeil ...)
Rick

3
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


0

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


4
C'est très bien pour une utilisation strictement locale, mais si vous attendez des interactions d'Internet, vous ne pouvez pas choisir une heure de réinitialisation qui convient à tout le monde. Même localement, les gens ont des heures de sommeil différentes - travailleurs postés, etc. Objection mineure, pas assez pour un -1.
Corey

@Corey Steam lie la plupart de leurs minuteries à 10 h, heure du Pacifique. Plus précisément, cela change au fil des promotions - Quotidienne (10 h tous les jours), Midweek (10 h le mardi - 10 h le vendredi) ou Week-end (10 h le vendredi - 10 h le lundi). En tant que magasin international, cela s'applique à tout le monde - ce serait 19h00 heure d'Europe centrale ou 13h00 à New York. Ce n'est peut-être pas pratique pour tous les fuseaux horaires, mais c'est cohérent. Et, franchement, même si j'utilisais PT, alors 10 heures du matin ne serait pas très pratique - je suis en Europe, donc la soirée est meilleure pour moi.
VLAZ

0

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.


0

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.


1
Les deux méthodes forcent une révision de 24 heures, à l'exception de quelques personnes, qui attendent les 48 heures et effectuent l'action à 23:59:59 et à 00:00:01, mais je pense que c'est assez peu pertinent.
RUL

@RUL J'utilise la méthode d'enregistrement deux fois de suite pour de nombreux jeux qui ont réinitialisé les heures dans un fuseau horaire qui me convient. Je ne pense donc pas que ce soit aussi hors de propos que vous le pensez. Je ne me connecte généralement pas toutes les 48 heures, mais j'obtiens presque toujours 2 actions chaque fois que je me connecte.
Rick
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.