Su una azione utente una volta al giorno: Ripristino 24 ore vs. Ripristino mezzanotte [chiuso]


24

Quando un utente è in grado di eseguire un'azione solo una volta al giorno, ad esempio ottenere un biglietto gratuito per una competizione, ci sono due possibilità che ho riscontrato nella mia esperienza.

1) Ripristino 24 ore

Se esegue l'azione il primo giorno alle 23:45, può eseguire di nuovo l'azione solo il secondo giorno alle 23:45 o dopo. Non sarà in grado di farlo alle 11:44 del giorno 2.

2) Midnight Reset (o qualsiasi orario fisso)

Indipendentemente da quando l'utente esegue l'azione il giorno 1, non appena si trasforma la mezzanotte e inizia il giorno 2, sarà in grado di farlo di nuovo.


Entrambi limitano l'utente nell'eseguire solo un'azione al giorno, ma molto spesso mi imbatto nel metodo 1, che ritengo abbastanza scomodo per due motivi:

  • Per prima cosa devo aspettare il tempo
  • e secondo per un lungo periodo di tempo, il timestamp di me che eseguirò l'azione diventerà più tardi e più tardi, poiché non sarò in grado di eseguire l'azione esattamente in quel timestamp ogni giorno, solo un paio di secondi o minuti dopo.

C'è qualche motivo tecnico per cui si preferirebbe il metodo 1, anche se a mio avviso lo svantaggio importante per l'utente dichiarato in precedenza?


Modifica, per specificare: sto parlando in particolare di un esempio, in cui ovviamente non è necessaria la timegap effettiva di 24 ore, come nell'attuale evento di spin gratuiti di Theory11 , in cui ottieni 1 giro gratuito ogni 24 ore per avere una possibilità ai premi vincenti.


5
Potrebbe esserci un motivo per limitare il tempo effettivo tra le azioni, motivo per cui dovrebbero optare per un blocco di 24 ore. Ad esempio, con l'opzione 2, è possibile eseguire l'azione alle 23:59 e alle 00:00 di nuovo.
Ivo Coumans,

21
La risposta sarebbe interamente specifica del problema, e non è difficile nemmeno trovare problemi adatti. Il software è sviluppato per implementare le regole aziendali, non viceversa.
Blrfl

4
Nota che la mezzanotte è un'ora arbitraria. Potrebbe essere altrettanto facilmente ogni volta che vuoi.
David Starkey,

2
Una specie di sidenote, la mezzanotte può essere problematica per i nottambuli. Per ovviare a questo, WoW, ad esempio, ripristina le cose "quotidiane" alle 3 o alle 4 del mattino.
Kevin,

6
Nota: esiste una varietà di giochi e tali che consentono un'azione solo ogni 21 ore. Teoricamente si potrebbe abusare di questo per ottenere> 1 al giorno, ma ciò significa svegliarsi a metà sonno, il che è abbastanza raro da non essere un grosso problema per i server. Quindi consente agli utenti di accedere "ogni mattina" senza che il timeout avanzi lentamente durante il giorno.
Mooing Duck,

Risposte:


21

Sono sorpreso come al solito mi aspetterei il ripristino di mezzanotte.

Tuttavia, presenta uno svantaggio maggiore, in quanto vi è più di una mezzanotte ogni 24 ore. Devi scegliere il tuo fuso orario.

Forse è per questo che viene scelto l'universale una volta ogni 24 ore, puoi immaginare che la società potrebbe non voler accettare che gli utenti metà in diversi paesi potrebbero avere orari di fine locali non di mezzanotte, o piuttosto che potrebbero considerare che dire "al giorno" implica mezzanotte e quindi cambiano il marketing in "per 24h" e le specifiche del software in modo che corrispondano

Anche se penso che sia abbastanza comune vedere "finisce alle 14:00 GMT" o simili in questi giorni.

Avrei pensato che la sfida di memorizzare una data dell'ultima azione per ogni utente sarebbe stata più difficile di quella di assegnare un fuso orario agli utenti o ai tipi di azione.

Modifica Penso che valga la pena notare le differenze tra i due metodi

24h regola

  • Riceverò un flusso costante di eventi, tasso limitato a meno di 1 ogni 24 ore.
  • Quando finisco la cosa, alcuni utenti riceveranno meno eventi.
  • Devo archiviare l'ultimo evento di tutti gli utenti
  • Quando l'ora legale provoca una giornata lunga o breve non avrò 1 evento al giorno
  • Gli umani non saranno in grado di colpire esattamente 24 ore in punto, quindi otterrò in media meno di 1 al giorno

1 per regola del giorno di calendario

  • Ricevo eventi concatenati in un periodo di 50 ore (? UTC + 14 a -12?) Assegnato a un giorno di calendario
  • realisticamente devo ancora memorizzare l'ultimo evento di tutti gli utenti come "giorni" sul giro
  • Ho una fine definita di una giornata in cui posso dire che tutti gli eventi dopo ora non sono nel giorno.
  • Devo conoscere la posizione dell'utente per sapere a quale giorno si applica il loro evento
  • Alcune persone si svegliano molto prima nel "giorno" di altre

1 per giorno di calendario nella regola UTC

  • Ottengo una bella uniforme 24 ore lunghe
  • Posso seccare i miei eventi
  • So quando è l'inizio e la fine di una giornata
  • L'ora legale confonderà le persone.
  • Gli umani possono avere 1 evento al giorno
  • Gli umani che non vivono vicino a Greenwich avranno divertenti orari di inizio e fine
  • Forse posso fare un'ottimizzazione intelligente e archiviare un elenco di utenti che sono entrati? (probabilmente finirò per archiviare tutti gli eventi e i tempi degli utenti)

* Il bucket degli eventi sarà super utile per vari scopi di reporting. per esempio. dire che ho 10 premi da vincere ogni 24 ore e differiscono nel tempo. Quanti studenti sono entrati il ​​giorno 10? eccetera


Mi tocchi chiaramente il mio treno di pensieri mentre sono ugualmente sorpreso. Penso che sarebbe abbastanza pigro andare per il reset di 24 ore, ma come afferma la risposta di @Richard Ward, potrebbe essere più difficile rispettare tutti i fusi orari e potrebbe anche innescare problemi di comunicazione a partire dall'inizio e dalla fine dell'evento.
REG

hmm penso che tu abbia confuso le tue risposte. Ma riflettendo, sto pensando che è molto probabile che si tratti di un problema di comunicazione tra business e sviluppatori. Posso solo immaginare la riunione di pianificazione ... Vendite: "Quindi agli utenti deve essere consentito di prendere l'offerta una volta al giorno .." Dev: "cosa succede se volano e attraversano la data internazionale? Possono effettuare due ordini? " Vendite: "..... no ... diciamo 1 ogni 24 ore" Dev: "OK, hmm gona hanno bisogno di più tabelle per memorizzare tutti quei dati!" Vendite: "whateves"
Ewan

Vedo, pensi che l'approccio delle 24 ore sia meno complesso? Perché non credo che a parte avere una tabella aggiuntiva sia molto più semplice dire solo 24 ore che controllare e calcolare in diversi fusi orari. Ma hai un buon punto lì: lasciando il fuso orario potresti effettivamente ottenere più di un giro.
REG

4
Penso che sia meno complesso da spiegare
Ewan il

10
Questo. Le cose dipendenti dal fuso orario aprono un'intera lattina di worm che puoi semplicemente lasciare chiusi usando la regola del timeout 24 ore. E non è esattamente più difficile archiviare quando si è verificata un'azione che memorizzarla in un giorno specifico.
cmaster

14

In cima alla mia testa:

  • Potrebbe essere più semplice implementare la versione "24 ore dall'ultima azione"
  • Se l'utente non esegue l'azione esattamente 24 ore dopo l'ultima volta, alla fine potrebbe perdere un intero periodo di 24 ore perché il ripristino deve avvenire quando è addormentato o lavora. Forse lo fanno alle 7 del mattino prima di partire per lavoro, e partono per il lavoro alle 20:00. Il giorno successivo lo fanno alle 7:15, poi alle 7:30, poi alle 7:45, e l'ultimo giorno rimangono fino alle 8:00 per eseguire l'azione poco prima di partire. Il giorno successivo non sono disposti a rimanere fino alle 8:15, quindi perdete quella mattina e fatelo dopo il ritorno a casa dal lavoro alle 18:00, un intervallo di 34 ore. Se il risultato dell'azione è costoso per l'azienda, il risparmio potrebbe essere più importante dell'inconveniente.

3
Un buon punto sul subdolo motivo di marketing, per far perdere agli utenti un giorno.
REG

1
@RUL O, probabilmente più precisamente, un utente ha maggiori probabilità di acquistare uno "spin extra pagato" (o qualsiasi altra cosa) se ne perde uno gratuito. Il costo di dare giri potrebbe essere banale, ma le vendite extra occasionali potrebbero valerne la pena.
TripeHound,

Ho giocato a un gioco basato sull'epoca Zulu quando ero negli Stati Uniti. Non è stato banale restare dritti quando potevo o non potevo fare un'attività.
Cort Ammon - Ripristina Monica il

2
Il punto 2 è il motivo per cui Blizzard (ecc.) Evita il timer di ripristino di 24 ore in WoW e altri MMORPG e invece effettua un ripristino giornaliero.
Adonalsium,

8
Vale la pena notare che alcune aziende usano solo un "quotidiano" meno rigoroso: League of Legends utilizza un blocco di 21 ore per la "prima vittoria della giornata". Sufficiente per mantenere i bonus all'incirca ogni giorno, pur essendo conveniente per i giocatori. Potrebbe essere in parte dovuto all'idea che non vincerai sempre il tuo primo gioco e che i giochi impiegheranno circa 30-50 minuti, quindi un orologio rigoroso sarebbe davvero fastidioso (poiché è probabile che tu riporti indietro di 30 minuti circa) un giorno, a quel punto non è allettante perché hai solo tempo di gioco per ottenere la prima vittoria ogni 3 giorni in un programma intenso).
Delioth,

8

Come hanno già detto altre risposte, il metodo 24 ore è più intuitivo per più fusi orari ed è altrettanto facile da codificare, poiché memorizzi l'ultimo timestamp di successo per ciascun utente.

Ha anche l'ulteriore "vantaggio" di richiedere effettivamente all'utente di interagire con l'app ogni giorno per ottenere tutte le azioni quotidiane. Se si dice un ripristino di mezzanotte, un utente può eseguire un'azione alle 23:59, quindi di nuovo alle 12:00. Potrebbero farlo a giorni alterni e ottenere comunque tutte le azioni. Per alcune app lo scopo delle azioni quotidiane è di far interagire l'utente con l'app su base giornaliera, quindi questo è meno ideale.

C'è una terza alternativa che evita le insidie ​​dell'interfaccia utente di entrambi, ma è un po 'più difficile da codificare.

3) Nessuna sequenza di più di n azioni in (n-0,75) * 24 ore

Richiede due variabili da memorizzare, ma consente a qualcuno che non sta tentando di abusare del sistema di utilizzare la propria azione in qualsiasi momento della giornata senza doversi preoccupare di fusi orari e ripristini.

Inoltre impedisce a chiunque di utilizzare più di 1 azione "extra".

Quindi implementa effettivamente l'algoritmo di cui avresti bisogno per memorizzare l'ora di inizio della sequenza, l'ultima ora di gioco e il numero di azioni nella sequenza.

Tenere traccia dell'ultimo tempo di azione consente di rifiutare due azioni troppo vicine tra loro. Puoi limitare questo limite a meno di 24 ore, perché la striscia impedisce di strisciare all'inizio della giornata.

Una serie continua finché si esegue l'azione ogni giorno. Se intraprendere un'azione significherebbe che avresti più azioni di giorni nella tua serie, allora verrà respinta. Questo impedisce di avanzare lentamente, inserendo azioni "extra" perché l'ora di inizio della sequenza non cambia.

alcuni pseudo codici per implementare il controllo e tenere traccia dei tempi:

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

Come bonus aggiuntivo, ottieni un segnalino serie, se lo desideri.


Penso che questa sia probabilmente la risposta migliore poiché "funziona" per l'utente. L'unico aspetto negativo è che potrebbe essere difficile da capire, ma ciò dovrebbe interessare solo le persone che cercano di giocare al sistema. Le 18 GraceHours potrebbero essere spiegate nel testo, dal momento che penso che sia importante per far funzionare questo (penso che dovrebbe essere inferiore però)
rtpax

Approccio interessante, tutto sommato, potresti elaborare più a parole, come funziona?
REG

@RUL L'idea fondamentale è che il tempo di ripristino per un utente sia bloccato una volta che eseguono la prima azione. Non è bloccato nel momento esatto in cui agiscono, ma un po 'prima di allora (18 ore prima, in questo caso) per fornire un'esperienza utente migliore. Ciò consente a un utente di avanzare leggermente (possono eseguire le prime due azioni in sole 6 ore), ma non si verificano errori cumulativi poiché l'avvio è ancora bloccato - se hanno raggiunto il limite massimo del periodo di tolleranza, dovranno attendere a almeno 24 ore per l'azione successiva.
Jacob Raihle,

5

A proposito del tuo problema con la durata di 24 ore tra le azioni, alcune aziende usano invece una durata di 22 ore, in questo modo gli utenti ottengono un po 'di margine di manovra nel momento esatto del giorno in cui l'azione è richiesta e continuano a incoraggiare gli utenti a eseguire effettivamente l'azione una volta al giorno -no 23:59 - 00:00 scappatoia.

Non è una risposta ma non ho abbastanza punti per commentare.


Penso che questo sito lo faccia con cose sacrificabili come i voti. Non si ripristinano ogni 24 ore ma ogni 16 o giù di lì (non sono sicuro del numero esatto). Immagino abbia senso - diciamo che inizi la giornata alle 8 e inizi a votare su / giù - finisci i voti in 6 ore alle 14:00. Con una reimpostazione rigorosa di 24 ore dall'azione, se si sceglie l'orario di reimpostazione sull'ultimo voto, è necessario attendere di nuovo fino alle 14:00 per iniziare a votare invece del normale orario e potrebbe non avere tempo. Se scegli il primo voto, allora hai un problema se un giorno inizi a votare alle 10, ma alle 8 il prossimo.
VLAZ,

Anche se ora che ci penso, non sono sicuro che siano davvero 16 le ore di ripristino azzerate. Potrebbero essere 24 ore e mi è capitato di averlo rilevato 8 ore dopo il ripristino giornaliero. Ma immagino che la logica valga: se hai 24 timer individuali, potrebbe non essere conveniente per un utente.
VLAZ,

Questo ha il problema opposto del reset di 34 ore, in cui gli utenti sono in grado di impacchettare in azioni extra se agiscono sempre il più presto possibile (ovviamente ciò richiederebbe un terribile programma di sonno ...)
Rick

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

Oltre alle risposte di cui sopra, il ripristino di mezzanotte incoraggia picchi di traffico. Se l'azione diventa disponibile per tutti i partecipanti in un determinato momento, allora ci sarà un incentivo per molte persone a tentare l'azione contemporaneamente. Questo è lo stesso motivo per cui la maggior parte degli stati fa scadere la patente il giorno del tuo compleanno invece che a una data fissa (USA): il DMV non sarebbe in grado di tenere il passo se il primo gennaio scade la patente.

Piccolo : se un sistema informatico deve intervenire una volta al giorno per un gran numero di utenti, puoi porre la stessa domanda, e in genere lo progetto come una combinazione di entrambi. Potresti immaginare due compiti cron:

  1. Corri a mezzanotte, trova tutti i record, agisci
  2. Corri ogni minuto (o qualche frequenza regolare), trova tutti i record che non hanno preso provvedimenti dalle 00:00 di ieri, agisci, registra che l'azione è stata intrapresa

In pratica ho trovato la prima fragile. Se un'attività cron si interrompe durante l'esecuzione, un certo numero potrebbe non applicare l'azione e potrebbe essere necessario un lavoro aggiuntivo per il sistema per ricordare dove si trovava e riprendere da dove era stato interrotto. Può anche causare problemi se si ottengono abbastanza record che l'attività cron non è in grado di elaborarli tutti entro un limite di tempo ragionevole e viene chiuso prima di terminare.

Quest'ultimo si occupa di entrambe queste preoccupazioni. Non ha lo scopo di elaborare tutto esattamente a distanza di 24 ore, ma fino a quando l'attività cron può facilmente eseguire tutte le azioni ogni giorno, saranno abbastanza vicine e garantirai che tutti vengano eseguiti ogni giorno effettivo (ad es. non avrai cose che si allontanano lentamente per più di 24 ore). Ma soprattutto, riprenderà facilmente da dove si era interrotto se le cose si guastassero per qualche motivo.

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


0

I biglietti giornalieri di autobus / treno presso TfL (Transport for London) sono validi dalle 4:30 alle 4:30. Fai il passaggio quando le persone dormono. Molte persone vorranno utilizzare un servizio dire dalle 8:30 a mezzanotte


4
Questo va bene per un uso strettamente locale, ma se ti aspetti interazioni da Internet, non puoi scegliere un orario di ripristino adatto a tutti. Anche a livello locale le persone hanno tempi di sonno diversi: turni di lavoro, ecc. Obiezioni minori, non sufficienti per un -1.
Corey,

@Corey Steam collega la maggior parte dei timer alle 10 del Pacifico. Più specificamente, ciò sta cambiando rispetto a qualsiasi promozione: giornaliera (10:00 tutti i giorni), infrasettimanale (10:00 martedì - 10 venerdì venerdì) o fine settimana (10:00 venerdì - 10:00 lunedì). Come negozio internazionale, questo è applicato a tutti, ovvero alle 19:00 ora dell'Europa centrale o alle 13:00 a New York. Forse non è conveniente per ogni fuso orario ma è coerente. E, francamente, anche se stessi usando PT, quindi le 10 del mattino non sarebbero molto convenienti - Sono in Europa, quindi la serata è migliore per me.
VLAZ

0

Il ripristino di mezzanotte presenta una condizione specifica che potrebbe essere desiderabile o dannosa, a seconda del problema che si sta tentando di risolvere e cioè: posso eseguire l'azione un giorno alle 11:59:58 e di nuovo alle 00:00:01. Se lo spazio problematico è un qualsiasi tipo di competizione, ciò potrebbe dare un ingiusto vantaggio alle persone che scelgono di eseguire le loro azioni verso mezzanotte. La regola di ripristino 24 ore su 24 è l'unico modo per garantire un'equa distribuzione delle azioni disponibili indipendentemente dall'ora del giorno in cui qualcuno ha a disposizione.

Le conseguenze del ripristino delle 24 ore che diventano successive e successive possono essere mitigate fornendo una tolleranza, ad esempio accettando una richiesta di azione entro 15 minuti dal ripristino che si verifica fino a quando l'azione non viene effettivamente registrata (o non accetta effetto) fino al ripristino. Questo introduce un po 'più di complessità nella soluzione, ma non riesco a pensare a nessuna strategia di mitigazione per essere in grado di eseguire due azioni quotidiane a distanza di pochi secondi come nel caso di reset di mezzanotte.


0

Non ho visto nessuno menzionare il fatto che la regola delle 24 ore incoraggia le visite regolari di routine. Molti giochi hanno una ricompensa di accesso / vittoria una volta al giorno che si ripristina dopo 24 ore perché preferiscono effettuare il check-in per un breve periodo ogni 24 ore anziché per il doppio ogni 48 ore. Immagino che sia simile per i siti Web che ospitano omaggi di biglietti.


1
Entrambi i metodi impongono una rivisitazione di 24 ore, ad eccezione di poche persone, che attendono le 48 ore ed eseguono l'azione alle 23:59:59 e alle 00:00:01, ma penso che sia abbastanza irrilevante.
REGOLAMENTO

@RUL Uso il metodo di check in due volte consecutive per molti giochi che hanno ripristinato i tempi in un comodo fuso orario per me. Quindi non penso sia irrilevante come pensi. In genere non accedo ogni 48 ore, ma quasi sempre ottengo 2 azioni ogni volta che accedo.
Rick,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.