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

24

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

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

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

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

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


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

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

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


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

RUL
источник
5
Может быть причина ограничить фактическое время между действиями, поэтому они предпочли бы 24-часовую блокировку. Например, с опцией 2 вы можете выполнить действие в 23:59 и снова в 00:00.
Иво Куманс
21
Ответ будет полностью специфичным для проблемы, и нетрудно придумать проблемы, которые также подходят. Программное обеспечение разработано для реализации бизнес-правил, а не наоборот.
Blrfl
4
Обратите внимание, что полночь - произвольное время. Это может быть так же легко в любое время.
Дэвид Старки
2
Вид sidenote, полночь может быть проблематичной для ночных сов. Чтобы обойти это, WoW, например, сбрасывает «ежедневные» вещи в 3 или 4 часа утра.
Кевин
6
Примечание. Существует множество игр, в которых разрешено действие только каждые 21 час. Теоретически можно злоупотреблять этим, чтобы получить> 1 в день, но это означает пробуждение в середине сна, что достаточно редко, чтобы обычно не быть таким уж большим для серверов. Затем он позволяет пользователям входить в систему «каждое утро» без тайм-аута, медленно продвигающегося в течение дня.
Mooing Duck

Ответы:

21

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

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

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

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

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

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

24-е правило

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

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

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

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

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

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

Ewan
источник
Ты явно касаешься моего хода мыслей, поскольку я в равной степени удивлен. Я думаю, что было бы довольно лениво пойти на 24-часовой сброс, но, как говорится в ответе @Richard Ward, может быть труднее соблюдать все часовые пояса и даже может вызвать проблемы со связью с момента начала и окончания события.
ПРАВИЛО
хм, я думаю, вы запутались в своих ответах. Но, подумав, я думаю, что это, скорее всего, проблема коммуникации между бизнесом и разработчиком. Я могу только представить встречу для планирования ... Продажи: «Таким образом, пользователям следует разрешать принимать предложение только один раз в день». Дев: «Что если они летят и пересекают международную линию дат? Могут ли они разместить два заказа? " Продажи: «..... нет ... скажем, 1 раз в сутки» Dev: «Хорошо, хм, нужно больше таблиц для хранения всех этих данных!» Продажи: "whateves"
Ewan
Понятно, вы думаете, что 24-часовой подход менее сложен? Потому что я не думаю, что кроме дополнительной таблицы гораздо проще просто сказать 24 часа, чем проверять и рассчитывать в разных часовых поясах. Но у вас есть хорошее замечание: с выходом из часового пояса вы можете получить более одного вращения.
ПРАВИЛО
4
Я думаю, что это менее сложно объяснить
Ewan
10
Это. Материал, зависящий от часового пояса, открывает целую банку червей, которую вы можете просто оставить закрытым, используя правило 24-часового ожидания. И точно не сложнее хранить, когда действие произошло, чем хранить, что оно произошло в определенный день.
Начальник
14

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

  • Может быть проще реализовать версию «24 часа с момента последнего действия»
  • Если пользователь не выполняет действие ровно через 24 часа после последнего времени, то в конечном итоге он может пропустить целый 24-часовой период, поскольку сброс должен произойти, когда он спит или работает. Возможно, они делают это в 7 часов утра, прежде чем уйти на работу, и уходят на работу в 8 часов вечера. На следующий день они делают это в 7:15, затем в 7:30, затем в 7:45 и в последний день остаются до 8:00, чтобы выполнить действие непосредственно перед отъездом. На следующий день они не желают оставаться до 8:15, поэтому просто пропустите это утро и сделайте это после возвращения домой с работы в 6 часов вечера, разрыв в 34 часа. Если результат акции дорог для компании, экономия может быть важнее, чем неудобство.
Ричард Уорд
источник
3
Хорошая мысль о хитрой маркетинговой причине, чтобы пользователи пропустили один день.
ПРАВИЛО
1
@RUL Или, возможно, что еще важнее, пользователь с большей вероятностью купит "оплаченный дополнительный спин" (или что-то еще), если он пропустит бесплатный. Стоимость предоставления спинов может быть тривиальной, но случайные дополнительные продажи могут стоить того.
TripeHound
Я играл в игру, основанную на времени зулу, когда я был в США. Это не было тривиально, чтобы держать прямо, когда я мог или не мог сделать деятельность.
Cort Ammon - Восстановить Монику
2
Пункт 2 - это то, почему Blizzard (и т. Д.) Избегают 24-часового таймера сброса в WoW и других MMORPG и вместо этого делают ежедневный сброс.
Adonalsium
8
Возможно, стоит отметить, что некоторые компании просто используют менее строгий «ежедневный» - League of Legends использует 21-часовой локаут для «первой победы дня». Достаточно держать бонусы примерно ежедневно, при этом удобно для игроков. Это может быть частично из-за идеи, что вы не всегда выиграете свою первую игру, а игры занимают ~ 30-50 минут, поэтому строгие часы будут действительно раздражать (так как вы, вероятно, отодвинете время на 30 минут или около того) день, в этот момент это не заманчиво, потому что у вас есть только игровое время, чтобы получить первый выигрыш каждые 3 дня при напряженном графике).
Делиот
8

Как уже упоминалось в других ответах, 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;
}

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

стог
источник
Я думаю, что это, вероятно, лучший ответ, так как он «просто работает» для пользователя. Единственным недостатком является то, что это может быть трудно понять, но это должно повлиять только на людей, пытающихся играть в систему. 18 graceHours можно объяснить в тексте, так как я думаю, что важно сделать эту работу (хотя я думаю, что она должна быть ниже)
rtpax
Интересный подход, не могли бы вы подробнее рассказать словами, как этот работает?
ПРАВИЛО
@RUL Основная идея заключается в том, что время сброса для пользователя фиксируется, как только он предпринимает свое первое действие. Он не заблокирован в точное время, когда они предпринимают свои действия, но немного раньше (в этом случае 18 часов назад), чтобы обеспечить лучшее взаимодействие с пользователем. Это позволяет пользователю немного продвинуться вперед (они могут выполнить свои первые два действия всего за 6 часов), но кумулятивной ошибки нет, так как запуск все еще заблокирован - если он исчерпал льготный период, ему придется ждать в минимум 24 часа для следующего действия.
Джейкоб Райле
5

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

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

TheNaturalTanuki
источник
Я думаю, что этот сайт делает это с расходными вещами, такими как голоса. Они сбрасываются не каждые 24 часа, а каждые 16 или около того (не уверен в точном числе). Я думаю, это имеет смысл - допустим, вы начинаете свой день в 8 часов утра и начинаете голосовать «вверх / вниз» - у вас заканчиваются голоса через 6 часов в 2 часа дня. При строгом сбросе в течение 24 часов, если вы выберете время сброса при последнем голосовании, вам придется подождать до 14:00, чтобы начать голосование вместо вашего обычного времени, и тогда у вас может не быть времени. Если вы выберете первое голосование, у вас возникнет проблема, если однажды вы начнете голосовать в 10:00, а в 8:00 - в следующий.
ВЛАЗ
Хотя теперь, когда я думаю об этом - я не уверен, что это действительно 16 часов, время сброса отключено действиями. Это может быть 24 часа, и я случайно поймал его через 8 часов после ежедневного сброса. Но я думаю, что логика верна - если у вас есть 24 отдельных таймера, то это может быть не удобно для пользователя.
ВЛАЗ
Это имеет противоположную проблему с 34-часовым сбросом, когда пользователи могут выполнять дополнительные действия, если они всегда действуют так быстро, как только могут (конечно, это потребует ужасного графика сна ...)
Rick
3
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

Конор Манконе
источник
0

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

gnasher729
источник
4
Это хорошо для строго локального использования, но если вы ожидаете взаимодействия из Интернета, то вы не можете выбрать время сброса, которое подходит всем. Даже у местных жителей разное время сна - сменные рабочие и т. Д. Незначительные возражения, недостаточно для -1.
Кори
@Corey Steam связывает большинство своих таймеров с 10 утра по тихоокеанскому времени. Более конкретно, это меняется в зависимости от любых рекламных акций - ежедневно (10:00 каждый день), в середине недели (10:00 во вторник - 10:00 в пятницу) или в выходные дни (10:00 в пятницу - 10:00 в понедельник). Это международный магазин, который применяется ко всем - это будет 19:00 по центральноевропейскому времени или 13:00 в Нью-Йорке. Возможно, это не удобно для каждого часового пояса, но это соответствует. И, честно говоря, даже если бы я использовал ПТ, то 10 часов утра было бы не очень удобно - я в Европе, поэтому вечер для меня лучше.
ВЛАЗ
0

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

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

Джефф Ламберт
источник
0

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

деревенщина
источник
1
Оба метода приводят к 24-часовому пересмотру, за исключением нескольких человек, которые ждут 48 часов и выполняют действие в 23:59:59 и 00:00:01, но я думаю, что это довольно неактуально.
ПРАВИЛО
@RUL Я использую метод регистрации дважды подряд для многих игр, в которых для меня установлено время в удобном для меня часовом поясе. Так что я не думаю, что это так важно, как вы думаете. Обычно я не буду входить в систему каждые 48 часов, но я всегда получаю 2 действия при каждом входе в систему.
Рик