Сообщить об ошибкеКороткий ответ
Нужно сначала перевести время события из UTC (как обычно хранится в событийных логах) в локальную таймзону пользователя, затем определить календарный день по локальному времени и сравнить его с днём регистрации + 7 — в ClickHouse это делается функциями toTimeZone/toDate с динамической таймзоной из поля пользователя.
Как это работает подробнее
если считать Day 7 retention по UTC-дате для пользователей из разных часовых поясов, для части из них "день 7" фактически может означать день 6 или 8 по их локальному времени — особенно критично для продуктов с ежедневной активностью (например, привычка "заходить утром").
Проверка: сравнить итог с расчётом по UTC без поправки на таймзону — для продукта с глобальной аудиторией расхождение должно быть заметным.
Что использовать на практике
- Практика. в ClickHouse таймзону можно задавать per-row через
toTimeZone(event_time, user_timezone), гдеuser_timezone— строковое поле вида 'Europe/Moscow'; для больших объёмов данных стоит заранее проверить, что поле таймзоны заполнено и валидно (невалидные названия таймзон ClickHouse может обработать с ошибкой или откатом к UTC в зависимости от версии).
Подводные камни
- Частая ошибка. используют единую фиксированную таймзону (например, таймзону штаб-квартиры компании) для всех пользователей глобального продукта, искажая retention для пользователей в других часовых поясах; не учитывают переход на летнее/зимнее время в некоторых регионах, что может на 1 день сместить расчёт для конкретных дат.