Действие пользователя один раз в день: 24-часовой сброс против полуночного сброса [закрыто]

Когда пользователь может выполнять действие только один раз в день, например, получая бесплатный билет на соревнование, в моем опыте есть две возможности.

1) Сброс 24 часа

Если он выполняет действие в 1-й день в 23:45, он может выполнить действие снова только в 2-й день после 11:45. Он не сможет сделать это 11:44 во второй день.

2) Сброс полуночи (или любое фиксированное время)

Независимо от того, в какое время пользователь выполняет действие в первый день, как только наступит полночь и начнется второй день, он сможет сделать это снова.

Оба ограничивают пользователя в выполнении только одного действия в день, но я чаще всего сталкиваюсь с методом 1, который я считаю довольно неудобным по двум причинам:

• Сначала я должен ждать времени
• и, во-вторых, в течение длительного периода времени отметка времени, в течение которого я выполняю действие, будет становиться позже и позже, поскольку я не смогу выполнять действие точно в эту отметку каждый день, всего пару секунд или минут спустя.

Есть ли какая-либо техническая причина, по которой кто-то предпочел бы способ 1, хотя, на мой взгляд, важный недостаток для пользователя, указанный ранее?

Изменить, чтобы указать: я особенно говорю о примере, в котором фактический временной интервал в 24 часа явно не требуется, например, в текущем событии бесплатного вращения в Theory11 , где вы получаете 1 бесплатное вращение каждые 24 часа, чтобы получить шанс на выигрышных призах.

Я удивлен, как обычно, я ожидал бы сброса полуночи.

Тем не менее, это имеет большой недостаток, поскольку каждые 24 часа больше полуночи. Вам нужно выбрать часовой пояс.

Возможно, именно поэтому выбирается универсальное значение один раз в сутки, вы можете себе представить, что компания может не захотеть признать, что пользователи, находящиеся в разных странах, могут иметь конечное время не в полночь по местному времени, или вместо того, чтобы считать, что выражение «в день» подразумевает полночь и, таким образом, они меняют маркетинг на «за 24 часа» и программное обеспечение, чтобы соответствовать

Хотя я думаю, что это довольно часто, чтобы увидеть "заканчивается в 2 часа дня по Гринвичу" или подобное в эти дни.

Я бы подумал, что задача сохранения даты последнего действия для каждого пользователя будет сложнее, чем назначение часового пояса пользователям или типам действий.

Редактировать Я думаю, что стоит отметить различия между двумя методами

24-е правило

• Я получу постоянный поток событий с ограничением скорости менее 1 в сутки.
• Когда я закончу, некоторые пользователи получат меньше событий.
• Мне нужно хранить каждый пользователь последнее событие
• Когда переход на летнее время приводит к длинному или короткому дню, у меня не будет 1 мероприятия в день
• Люди не смогут наносить точные удары ровно 24 часа, поэтому я, естественно, получу в среднем меньше 1 в день

1 за правило календарного дня

• Я получаю события с интервалом в 50 часов (? UTC + 14 до -12?), Назначенных календарному дню
• реально мне все еще нужно хранить каждое событие последнего пользователя как «дни» на коленях
• У меня есть определенный конец дня, когда я могу сказать, что все события после этого не в этот день.
• Мне нужно знать местоположение пользователя, чтобы знать, к какому дню относится его событие
• Некоторые люди просыпаются гораздо раньше в «день», чем другие

1 за календарный день в правиле UTC

• Я получаю хорошую униформу 24 часа в сутки
• Я могу вести свои события
• Я знаю, когда начало и конец дня
• Летнее время сбивает людей с толку.
• Люди могут иметь 1 событие в день
• У людей, не живущих рядом с Гринвичем, будут смешные времена начала и конца
• Может быть, я могу сделать умную оптимизацию и просто сохранить список пользователей, которые вошли? (вероятно, я буду хранить каждое событие и время каждого пользователя)

* Информирование о событиях будет очень полезным для различных целей отчетности. например. скажем, у меня есть 10 призов, которые нужно выигрывать каждый 24-часовой период, и они меняются со временем. Сколько студентов вошло в день 10? так далее

С верхней части моей головы:

• Может быть проще реализовать версию «24 часа с момента последнего действия»
• Если пользователь не выполняет действие ровно через 24 часа после последнего времени, то в конечном итоге он может пропустить целый 24-часовой период, поскольку сброс должен произойти, когда он спит или работает. Возможно, они делают это в 7 часов утра, прежде чем уйти на работу, и уходят на работу в 8 часов вечера. На следующий день они делают это в 7:15, затем в 7:30, затем в 7:45 и в последний день остаются до 8:00, чтобы выполнить действие непосредственно перед отъездом. На следующий день они не желают оставаться до 8:15, поэтому просто пропустите это утро и сделайте это после возвращения домой с работы в 6 часов вечера, разрыв в 34 часа. Если результат акции дорог для компании, экономия может быть важнее, чем неудобство.

Как уже упоминалось в других ответах, 24-часовой метод более удобен для нескольких часовых поясов, и его так же легко кодировать, поскольку вы просто сохраняете последнюю успешную метку времени для каждого пользователя.

Он также имеет дополнительное «преимущество», заключающееся в том, что пользователь фактически должен взаимодействовать с приложением каждый день, чтобы выполнять все ежедневные действия. Если произойдет сброс в полночь, то пользователь может выполнить действие в 23:59, а затем снова в 12:00. Они могли бы делать это через день и при этом получать все действия. Для некоторых приложений цель ежедневных действий состоит в том, чтобы пользователь ежедневно взаимодействовал с приложением, так что это не идеально.

Есть третья альтернатива, которая избегает ловушек UI обоих, но немного сложнее для кодирования.

3) Нет полос более чем n действий в (n-0,75) * 24 часа

Для его хранения требуется две переменные, но он позволяет тем, кто не пытается злоупотреблять системой, использовать одно действие в любое время дня, не беспокоясь о временных поясах и сбросах.

Он также не позволяет никому использовать более 1 «дополнительного» действия.

Так что на самом деле реализуйте алгоритм, который вам понадобится для хранения времени начала серии, времени последней игры и количества действий в вашей серии.

Отслеживание времени последнего действия позволяет отклонить два действия, которые находятся слишком близко друг к другу. Вы можете установить этот предел менее чем на 24 часа, потому что полоса предотвращает ползание в начале дня.

Полоса продолжается до тех пор, пока вы будете действовать каждый день. Если выполнение действия будет означать, что в вашей серии будет больше действий, чем дней, тогда оно будет отклонено. Это предотвращает медленное продвижение вперед, упаковывая «дополнительные» действия, потому что время начала вашей серии не меняется.

некоторый псевдокод для реализации проверки и отслеживания времени:

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

В качестве дополнительного бонуса вы получаете счетчик полос, если хотите.

Что касается вашей проблемы с 24-часовой продолжительностью между действиями, некоторые компании вместо этого используют 22-часовую продолжительность, таким образом, пользователи получают некоторую свободу действий в точный момент дня, когда требуется действие, и все же получают стимул для пользователей фактически выполнять действие один раз в день - нет 23:59 - 00:00 лазейка.

Не ответ, но у меня недостаточно очков, чтобы комментировать.

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

В дополнение к вышеприведенным ответам сброс в полночь стимулирует всплеск трафика. Если действие становится доступным для всех участников в определенное время, у многих людей будет стимул предпринять это действие одновременно. По этой же причине в большинстве штатов срок действия ваших водительских прав истекает в день вашего рождения, а не в фиксированную дату (США): DMV не сможет идти в ногу, если у всех истек срок действия водительских прав 1 января.

Небольшое отступление : если компьютерной системе необходимо предпринимать действия один раз в день для большого числа пользователей, вы можете задать один и тот же вопрос, и я обычно задаю его как комбинацию обоих. Вы можете представить две задачи cron:

1. Беги в полночь, найди все записи, прими меры
2. Запускайте каждую минуту (или с определенной частотой), найдите все записи, которые не предпринимали действий с 00:00 вчера, выполните действие, запишите, что действие было выполнено

На практике я обнаружил, что первое хрупкое. Если задача cron прерывается во время работы, то для некоторого числа может не быть примененного действия, и может потребоваться дополнительная работа, чтобы система запомнила, где она была, и выбрала, где она остановилась. Это также может вызвать проблемы, если вы получаете достаточно записей, что ваша задача cron не может обработать их все в течение разумного периода времени, и она закрывается перед завершением.

Последний берет на себя обе эти проблемы. Он не нацелен на то, чтобы обрабатывать все с точностью до 24 часов, но если ваша задача cron может легко выполнять все действия каждый день, они будут довольно близки, и вы гарантируете, что все будут запускаться в каждый фактический день (т.е. у вас не будет медленного расставания вещей более чем на 24 часа). Но самое главное, что он легко поймет, где остановился, если что-то сломается по какой-то причине.

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

Ежедневные билеты на автобус / поезд в TfL (Транспорт для Лондона) действительны с 4:30 до 4:30. Переключайтесь, когда люди спят. Многие люди захотят воспользоваться услугой, скажем, с 8:30 до часа после полуночи

Сброс в полночь имеет определенное условие, которое может быть желательным или вредным, в зависимости от того, какую проблему вы пытаетесь решить, а именно: я могу выполнить действие один день в 11:59:58 и снова в 00:00:01. Если проблемным пространством является какой-либо вид конкуренции, это может дать несправедливое преимущество людям, которые хотят выполнять свои действия ближе к полуночи. 24-часовое правило сброса - это единственный способ обеспечить справедливое распределение доступных действий независимо от того, какое время суток кто-то имеет для них в распоряжении.

Последствия 24-часового сброса становятся более поздними и могут быть смягчены путем обеспечения допуска, например, принятия запроса действия в течение 15 минут после сброса, если действие фактически не записано (или не требует эффект), пока не произойдет сброс. Это вносит немного большую сложность в решение, но я не могу представить себе какую-либо стратегию смягчения, которая позволяла бы выполнять два ежедневных действия с интервалом в несколько секунд, как в случае сброса в полночь.

Я не видел, чтобы кто-нибудь упоминал тот факт, что правило 24 часов поощряет регулярные регулярные посещения. Многие игры имеют вознаграждение за вход / победу раз в день, которое сбрасывается через 24 часа, потому что они предпочитают, чтобы вы регистрировались на короткое время каждые 24 часа, а не в два раза дольше каждые 48 часов. Я полагаю, что это аналогично для сайтов, предоставляющих билеты.