Działania użytkownika raz dziennie: resetowanie 24 godzin vs. resetowanie północy [zamknięte]

Gdy użytkownik jest w stanie wykonać akcję tylko raz dziennie, na przykład otrzymać bezpłatny bilet na zawody, mam dwie możliwości.

1) 24-godzinny reset

Jeśli wykona akcję w dniu 1 o godzinie 23:45, może wykonać ją ponownie tylko w dniu 2 w dniu lub po godzinie 23:45. Nie będzie w stanie tego zrobić 11:44 w dniu 2.

2) Reset o północy (lub dowolny ustalony czas)

Bez względu na to, o której godzinie użytkownik wykona czynność pierwszego dnia, gdy tylko skończy się północ i rozpocznie się drugi dzień, będzie mógł to zrobić ponownie.

Oba ograniczają użytkownika do wykonywania tylko jednej czynności dziennie, ale najczęściej spotykam metodę 1, która moim zdaniem jest dość niewygodna z dwóch powodów:

• Najpierw muszę czekać na czas
• i sekundę w długim okresie czasu, znacznik czasu, w którym wykonuję akcję, stanie się później i później, ponieważ nie będę w stanie wykonywać akcji dokładnie o tej godzinie każdego dnia, tylko kilka sekund lub minut później.

Czy istnieje jakikolwiek techniczny powód, aby preferować metodę 1, chociaż moim zdaniem istotna wada dla użytkownika wskazana wcześniej?

Edytuj, aby sprecyzować: Mówię szczególnie o przykładzie, w którym faktyczna przerwa czasowa 24 godzin nie jest oczywiście potrzebna, na przykład w bieżącym wydarzeniu z darmowym obrotem w teorii 11 , w którym dostajesz 1 darmowy obrót co 24 godziny, aby uzyskać szansę w zdobywaniu nagród.

Jestem zaskoczony, jak zwykle oczekiwałbym resetu o północy.

Ma jednak poważną wadę, ponieważ co godzinę jest więcej niż jedna północ. Musisz wybrać strefę czasową.

Być może dlatego wybrano opcję uniwersalną raz na 24 godziny, możesz sobie wyobrazić, że firma może nie chcieć zaakceptować faktu, że użytkownicy w połowie różnych krajów mogą mieć lokalne godziny końcowe o północy, a raczej nie uważają, że powiedzenie „na dzień” implikuje północ i w ten sposób zmieniają marketing na „na 24h” i specyfikację oprogramowania do dopasowania

Chociaż myślę, że w dzisiejszych czasach jest to dość powszechne, gdy „kończy się o 14:00 GMT” lub podobnie.

Myślałem, że wyzwanie przechowywania daty ostatniej akcji dla każdego użytkownika byłoby trudniejsze niż przypisanie strefy czasowej użytkownikom lub typom akcji.

Edytuj Myślę, że warto zauważyć różnice między tymi dwiema metodami

Zasada 24 godzin

• Otrzymam stały strumień wydarzeń, stawka ograniczona do mniej niż 1 na 24 godziny.
• Kiedy to zakończę, niektórzy użytkownicy otrzymają mniej wydarzeń.
• Muszę przechowywać ostatnie zdarzenie każdego użytkownika
• Gdy czas letni powoduje długi lub krótki dzień, nie będę miał 1 zdarzenia dziennie
• Ludzie nie będą w stanie trafić dokładnie kropką dokładnie 24 godziny, więc naturalnie otrzymam średnio mniej niż 1 dziennie

Reguła 1 na dzień kalendarzowy

• Dostaję wydarzenia zbiorcze w ciągu 50 godzin (? UTC + 14 do -12?) Przypisanych do dnia kalendarzowego
• realistycznie muszę zapisać ostatnie zdarzenie każdego użytkownika jako „dni” na okrążeniu
• Mam definitywny koniec dnia w którym mogę powiedzieć wszystkie wydarzenia po teraz nie są w ciągu dnia.
• Muszę znać lokalizację użytkownika, aby wiedzieć, którego dnia dotyczy jego wydarzenie
• Niektórzy ludzie budzą się znacznie wcześniej w ciągu „dnia” niż inni

1 na dzień kalendarzowy w regule UTC

• Dostaję ładny mundur 24 godziny na dobę
• Mogę organizować wydarzenia
• Wiem, kiedy jest początek i koniec dnia
• Oszczędności w ciągu dnia zmieszają ludzi.
• Ludzie mogą mieć 1 wydarzenie dziennie
• Ludzie nie mieszkający w pobliżu Greenwich będą mieli zabawne czasy rozpoczęcia i zakończenia
• Może mogę zrobić sprytną optymalizację i po prostu zapisać listę użytkowników, którzy weszli? (prawdopodobnie skończę na przechowywaniu każdego zdarzenia i czasu każdego użytkownika)

* Grupowanie wydarzeń będzie bardzo przydatne do różnych celów sprawozdawczych. na przykład. powiedz, że mam 10 nagród do wygrania co 24 godziny i różnią się one w czasie. Ilu uczniów zgłosiło się w dniu 10? itp

Z czubka mojej głowy:

• Implementacja wersji „24 godziny od ostatniej akcji” może być łatwiejsza
• Jeśli użytkownik nie wykona czynności dokładnie 24 godziny po ostatnim czasie, może w końcu stracić całą 24-godzinną przerwę, ponieważ reset musi nastąpić, gdy śpi lub pracuje. Być może robią to o 7 rano przed wyjazdem do pracy i wychodzą do pracy o 20:00. Następnego dnia robią to o 7:15, potem o 7:30, a potem o 7:45, a ostatniego dnia pozostają do 8:00, aby wykonać akcję tuż przed wyjazdem. Następnego dnia nie są skłonni zostać do 8:15, więc po prostu przegap ten poranek i zrób to po powrocie z pracy o 18:00, czyli 34 godziny przerwy. Jeśli wynik działania jest dla firmy kosztowny, oszczędność może być ważniejsza niż niedogodność.

Jak wspomniano w innych odpowiedziach, metoda 24-godzinna jest bardziej przyjazna dla wielu stref czasowych i jest tak samo łatwa do kodowania, jak zapisanie ostatniej pomyślnej sygnatury czasowej dla każdego użytkownika.

Ma również dodatkową „zaletę” polegającą na tym, że użytkownik musi codziennie wchodzić w interakcje z aplikacją, aby uzyskać wszystkie codzienne czynności. Jeśli powiedzą reset północy, użytkownik może wykonać akcję o 23:59, a następnie ponownie o 12:00. Mogli to robić co drugi dzień i nadal otrzymywać wszystkie działania. W przypadku niektórych aplikacji celem codziennych czynności jest zachęcenie użytkownika do codziennej interakcji z aplikacją, co jest mniej idealne.

Istnieje trzecia alternatywa, która pozwala uniknąć pułapek interfejsu użytkownika obu, ale jest nieco trudniejsza do kodowania.

3) Brak serii więcej niż n akcji w ciągu (n-0,75) * 24 godziny

Wymaga do przechowywania dwóch zmiennych, ale pozwala komuś, kto nie próbuje nadużywać systemu, korzystać z jednej akcji w dowolnym momencie dnia bez martwienia się o strefy czasowe i resetowania.

Zapobiega także użyciu przez użytkownika więcej niż 1 „dodatkowej” akcji.

W rzeczywistości zaimplementuj algorytm, w którym musisz zapisać czas rozpoczęcia serii, ostatni czas gry i liczbę akcji w serii.

Śledzenie czasu ostatniej akcji pozwala odrzucić dwie akcje, które są zbyt blisko siebie. Możesz ograniczyć ten limit do mniej niż 24 godzin, ponieważ smuga zapobiega pełzaniu wcześniej w ciągu dnia.

Smuga trwa tak długo, jak codziennie podejmujesz działania. Jeśli wykonanie akcji oznaczałoby, że w serii masz więcej akcji niż dni, zostanie ona odrzucona. Zapobiega to powoli pełzającym naprzód, pakując się w „dodatkowe” działania, ponieważ czas rozpoczęcia twojej serii nie zmienia się.

jakiś pseudo kod do wdrożenia kontroli i śledzenia czasów:

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

Jako dodatkowy bonus otrzymujesz licznik serii, jeśli chcesz.

Jeśli chodzi o Twój problem z 24-godzinnym czasem trwania między działaniami, niektóre firmy zamiast tego używają 22-godzinnego czasu, w ten sposób użytkownicy uzyskują swobodę w dokładnym momencie dnia, w którym działanie jest wymagane, i nadal zachęcają użytkowników do faktycznego wykonania działania raz dziennie -nie 23:59 - 00:00 luka.

Brak odpowiedzi, ale nie mam wystarczającej liczby punktów do skomentowania.

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

Oprócz powyższych odpowiedzi resetowanie o północy sprzyja wzrostowi natężenia ruchu. Jeśli akcja stanie się dostępna dla wszystkich uczestników w określonym czasie, wiele osób będzie zachęcać do podjęcia akcji w tym samym czasie. Jest to ten sam powód, dla którego w większości stanów wasze prawo jazdy wygasa w dniu urodzin zamiast w ustalonym terminie (USA): DMV nie byłby w stanie dotrzymać kroku, gdyby wszyscy mieli prawo jazdy wygasające 1 stycznia.

Małe na bok : jeśli system komputerowy musi podejmować działania dla dużej liczby użytkowników raz dziennie, możesz zadać to samo pytanie, a ja zwykle projektuję je jako połączenie obu. Można sobie wyobrazić dwa zadania crona:

1. Biegnij o północy, znajdź wszystkie rekordy, podejmij działania
2. Uruchom co minutę (lub jakąś regularną częstotliwość), znajdź wszystkie rekordy, które nie podjęły działania od 00:00 wczoraj, podejmij działanie, zapisz, że działanie zostało podjęte

W praktyce uważam, że to pierwsze jest kruche. Jeśli zadanie CRON zepsuje się podczas działania, pewna liczba może nie mieć zastosowanej akcji, a system może potrzebować dodatkowej pracy, aby zapamiętać, gdzie była i odebrać od miejsca, w którym została przerwana. Może również powodować problemy, jeśli uzyskasz wystarczającą liczbę rekordów, że zadanie cron nie może przetworzyć ich wszystkich w rozsądnym terminie i zostanie zamknięte przed zakończeniem.

Ten ostatni rozwiązuje oba te problemy. Nie ma na celu rozdzielenia wszystkiego dokładnie 24 godziny od siebie, ale tak długo, jak twoje zadanie cron może z łatwością wykonywać wszystkie działania każdego dnia, będą one dość blisko i zagwarantujesz, że każdy biegnie każdego dnia (tj. rzeczy nie będą się powoli rozpadać o więcej niż 24 godziny). Najważniejsze jednak, że z jakiegoś powodu z łatwością zejdzie z miejsca, w którym zostało przerwane.

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

Dzienne bilety autobusowe / kolejowe w TfL (Transport do Londynu) są ważne od 4:30 do 4:30. Wykonaj zmianę, gdy ludzie śpią. Wiele osób będzie chciało skorzystać z usługi, powiedzmy od 8:30 do godziny po północy

Resetowanie o północy ma określony warunek, który może być pożądany lub szkodliwy, w zależności od tego, jaki problem próbujesz rozwiązać, a mianowicie: Mogę wykonać akcję pewnego dnia o 11:59:58 i ponownie o 00:00:01. Jeśli przestrzenią problemową jest jakakolwiek konkurencja, może to przynieść niesprawiedliwą przewagę osobom decydującym się na wykonywanie swoich działań blisko północy. Reguła resetowania w ciągu 24 godzin jest jedynym sposobem na zapewnienie sprawiedliwego podziału dostępnych działań niezależnie od pory dnia, w której ktoś ma do nich dostęp.

Konsekwencją późniejszego i późniejszego resetu 24-godzinnego można złagodzić, wprowadzając tolerancję, na przykład akceptując żądanie akcji w ciągu 15 minut od zresetowania, o ile akcja nie jest faktycznie zarejestrowana (lub nie jest podejmowana efekt), aż nastąpi reset. Wprowadza to nieco więcej złożoności do rozwiązania, ale nie mogę wymyślić żadnej strategii łagodzenia dla możliwości podjęcia dwóch codziennych działań w odstępie kilku sekund, jak w przypadku resetu o północy.

Nie widziałem nikogo wspominającego o tym, że zasada 24 godzin zachęca do rutynowych regularnych wizyt. Wiele gier ma nagrodę za logowanie / zwycięstwo raz dziennie, która resetuje się po 24 godzinach, ponieważ wolą, abyś odprawiał się przez krótki czas co 24 godziny, a nie dwa razy dłużej co 48 godzin. Wyobrażam sobie, że podobnie jest w przypadku stron internetowych z biletami.