Сообщить об ошибкеКороткий ответ
Диагностику стоит начать с проверки технических причин (сбой трекинга, деплой, изменение атрибуции) и сезонности, затем декомпозировать падение по сегментам (платформа, страна, канал, new vs returning), чтобы понять, концентрируется ли проблема в одном срезе или это равномерное падение по всей базе.
Как это работает подробнее
строим чек-лист диагностики: 1) не изменилась ли логика трекинга события активности (релиз SDK, смена ID пользователя); 2) нет ли технического сбоя (ошибки, недоступность сервиса); 3) есть ли сезонный/календарный эффект (праздник, выходной, день недели); 4) если ничего из вышеперечисленного — разбиваем по сегментам и ищем, где именно произошло падение.
Пример кода
dau_diagnostics.sql
-- PostgreSQL: разбивка DAU по платформе за две недели для сравнения
SELECT platform, event_date,
COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_date BETWEEN CURRENT_DATE - 14 AND CURRENT_DATE
GROUP BY platform, event_date
ORDER BY platform, event_date;Что использовать на практике
- Практика. равномерное падение во всех сегментах чаще указывает на трекинг/техническую проблему или общий рыночный/сезонный фактор; падение, сконцентрированное в одном канале или платформе, чаще указывает на продуктовую проблему (баг, регрессия) или маркетинговую (остановка кампании, блокировка рекламного аккаунта).
Подводные камни
- Частые ошибки. сразу выдвигают продуктовые гипотезы ("пользователям не понравилось последнее обновление"), не исключив сначала технические причины, которые встречаются значительно чаще; смотрят только на агрегированный DAU и не проверяют, не изменилось ли само определение "активности" из-за изменений в трекинге.