Краткий ответ

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

Исторический контекст

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

Фиксированный часовой пояс, например UTC, упрощает хранение и воспроизводимость отчётов. Однако он может плохо соответствовать пользовательскому восприятию дня: вечерняя активность одной страны и утренняя активность другой страны окажутся в разных или неожиданных календарных датах.

Постановка проблемы

В запросе событие пользователя с идентификатором 1 в 21:30 UTC попадает в 1 июля, а событие того же пользователя в 00:20 UTC — уже в 2 июля. Если отчёт начали строить по часовому поясу UTC+3, оба события будут относиться ко 2 июля.

Из-за этого изменятся не только даты событий, но иногда и множество уникальных пользователей в каждом дневном бакете. Неверный вывод может выглядеть так, будто DAU вырос или упал после релиза, хотя изменилась только граница суток.

Подробное решение

Сначала нужно зафиксировать смысл метрики: что именно считается днём активности. Возможны три основные схемы:

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

Для анализа поведения отдельного пользователя обычно логичнее использовать его часовой пояс, если он надёжно известен и не меняется неконтролируемо. Для финансового или операционного отчёта часто удобнее единый часовой пояс бизнеса. Главное — не менять правило внутри временного ряда без пересчёта исторических данных.

Пример пересчёта в фиксированный часовой пояс показывает, что меняется именно принадлежность события к дню:

WITH events(user_id, utc_ts) AS (
  VALUES
    (1, TIMESTAMP '2025-07-01 21:30:00'),
    (2, TIMESTAMP '2025-07-01 22:10:00'),
    (1, TIMESTAMP '2025-07-02 00:20:00')
), localized AS (
  SELECT user_id,
         CAST(utc_ts + INTERVAL '3 hours' AS DATE) AS local_day
  FROM events
)
SELECT local_day, COUNT(DISTINCT user_id) AS dau
FROM localized
GROUP BY local_day
ORDER BY local_day;

В исходной агрегации пользователь 1 учитывается в двух UTC-днях, а в локальной агрегации оба его события могут оказаться в одном дне. Это не означает, что локальный DAU обязательно правильнее: выбор зависит от определения метрики и качества данных о часовом поясе.

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

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

Ситуация из практики

Команда международного приложения заметила рост DAU в день запуска новой версии. Одновременно аналитики перенесли отчёт с UTC на часовой пояс штаб-квартиры. Вариант с сохранением UTC был воспроизводимым, но хуже отражал локальные сутки пользователей; вариант с часовым поясом каждого пользователя лучше соответствовал поведенческому анализу, но требовал надёжно хранить зону и усложнял агрегацию; вариант с зоной бизнеса был простым, но не подходил для оценки ежедневной вовлечённости пользователей из разных стран.

Команда выбрала пользовательский часовой пояс для продуктового DAU и отдельную бизнес-зону для операционной отчётности. Исторические данные пересчитали по тем же правилам, а в мониторинге временно показывали старую и новую версии метрики. После этого скачок исчез из анализа запуска: он был вызван сменой границ суток, а не доказанным эффектом релиза.

Что кандидаты часто упускают

Дополнительный вопрос: Можно ли сравнивать DAU в UTC с DAU в часовом поясе пользователя, если обе метрики рассчитаны за один и тот же календарный день?

Ответ: Нет, без специальной оговорки такое сравнение некорректно. У метрик различаются временные бакеты, поэтому в них могут попасть разные события и пользователи. Сравнение допустимо только после пересчёта обоих рядов по единому определению дня.

Дополнительный вопрос: Почему переход на пользовательский часовой пояс не решает проблему автоматически?

Ответ: Для этого нужен корректный часовой пояс на момент события, а не только текущая страна или регион пользователя. Пользователь может путешествовать, менять настройки устройства или передавать неполные данные. Кроме того, переходы на летнее время делают простое прибавление фиксированного числа часов ошибочным.

Дополнительный вопрос: Как отличить эффект смены часового пояса от реального изменения активности?

Ответ: Нужно пересчитать периоды до и после изменения по единому правилу и сравнить результат с исходным отчётом. Если скачок исчезает после унификации временной зоны, основная причина была методологической. Дополнительно проверяют распределение событий около границы суток и используют метрики с менее чувствительным к календарным границам окном, например активность за последние 24 часа.