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

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.

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

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.

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.

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.

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

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

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.

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.