Сообщить об ошибкеКороткий ответ
Праздники и сезонные периоды систематически меняют паттерны использования продукта (падение активности в праздники для B2B-продуктов, рост для развлекательных/travel-продуктов), поэтому сравнение метрик week-over-week или month-over-month вокруг таких дат может ошибочно интерпретироваться как продуктовый эффект; корректнее сравнивать год-к-году (YoY) или использовать период без аномалий как базу.
Как это работает подробнее
для B2B-инструментов активность обычно падает в выходные и праздники (пользователи не работают), для потребительских/travel/retail-продуктов, наоборот, может расти (больше свободного времени, сезонные покупки); если не учитывать это при сравнении, любое совпадение запуска фичи с праздниками исказит вывод о её эффекте.
Пример кода
seasonality.sql
-- PostgreSQL: сравнение DAU год к году для той же календарной недели
SELECT
date_trunc('week', event_date) AS week,
COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_date IN (
SELECT generate_series(DATE '2023-12-25', DATE '2023-12-31', '1 day')
UNION ALL
SELECT generate_series(DATE '2024-12-25', DATE '2024-12-31', '1 day')
)
GROUP BY 1
ORDER BY 1;Что использовать на практике
- Практика. стоит сравнивать метрику с аналогичным периодом год назад (если данных достаточно), либо исключать аномальные даты из анализа тренда, либо использовать методы декомпозиции временного ряда (выделение тренда, сезонности и случайной компоненты), чтобы не путать сезонный эффект с реальным изменением.
Подводные камни
- Частые ошибки. сравнивают DAU в праздничную неделю с DAU в обычную неделю и делают вывод о "падении продукта"; запускают A/B-тесты или оценивают эффект изменений в периоды с нетипичным поведением пользователей (новогодние каникулы, крупные внешние события) без поправки на это в интерпретации.