Рассмотрите расчёт DAU: событие app_open отправляется и при ручном запуске приложения, и при его фоновом восстановлении. Какой главный вывод о качестве метрики следует сделать из этого запроса?
WITH events(event_date, user_id, event_name, source) AS (
VALUES
(DATE '2025-04-01', 1, 'app_open', 'foreground'),
(DATE '2025-04-01', 2, 'app_open', 'background'),
(DATE '2025-04-01', 3, 'app_open', 'foreground'),
(DATE '2025-04-02', 1, 'app_open', 'background'),
(DATE '2025-04-02', 3, 'app_open', 'foreground')
)
SELECT event_date, COUNT(DISTINCT user_id) AS dau
FROM events
WHERE event_name = 'app_open'
GROUP BY event_date;
Этот запрос считает не обязательно активных пользователей, а пользователей, для которых сработало техническое событие app_open. Фоновые открытия создают ложную активность: DAU может расти без реального взаимодействия с продуктом.
Метрику нужно определять через событие или набор событий, отражающих значимое действие пользователя, либо исключать фоновые срабатывания из расчёта. В приведённых данных сырая DAU равна двум пользователям 1 апреля и двум 2 апреля, хотя осмысленное использование было только у пользователей с источником foreground.
Событийная аналитика появилась как способ измерять не только технические факты вроде установки или запуска приложения, но и последовательность действий пользователя: просмотр, поиск, создание объекта, оплату. На этой основе строят DAU, воронки, когорты и продуктовые эксперименты.
Однако событие само по себе не является бизнес-смыслом. Оно лишь сигнал от приложения. Поэтому вместе с развитием событийной аналитики возникла необходимость в чётких контрактах событий: что именно считается действием пользователя, когда событие отправляется и какие технические сценарии нужно исключить.
Если фоновое восстановление сессии отправляет тот же app_open, что и ручной запуск, запрос не различает намеренное использование и работу платформы. Пользователь может ни разу не увидеть экран, но попасть в DAU.
Такая ошибка искажает сравнение релизов, каналов привлечения и когорт. Например, изменение фоновой синхронизации способно увеличить DAU, хотя ценность продукта и частота полезных действий не изменились.
Особенно опасно использовать такую DAU как целевую метрику эксперимента. Команда может выбрать вариант, который чаще инициирует технические события, но не улучшает пользовательский результат.
Сначала нужно формально определить активного пользователя. Это может быть пользователь, который открыл интерфейс, просмотрел содержательный экран или выполнил доменное действие. Выбор зависит от продукта, но критерий должен быть связан с проверяемой ценностью, а не просто с наличием сетевого события.
Минимальное исправление для данного примера — фильтровать источник события:
В реальной системе надёжнее определить активность через набор валидированных событий, например content_view или task_completed, и отдельно контролировать их качество. Одного признака foreground тоже может быть недостаточно: приложение может открыться автоматически, а пользователь сразу закрыть его.
Нужно согласовать окно активности, дедупликацию и уровень агрегации. Обычно пользователь считается один раз за день, поэтому используется COUNT(DISTINCT user_id), но это не решает проблему неправильного определения самого события.
Есть компромисс между стабильностью и чувствительностью метрики. Узкое определение, например завершённая задача, лучше отражает ценность, но может быть слишком редким для ежедневного мониторинга. Широкое определение даёт больше наблюдений, однако сильнее зависит от технических деталей и легче поддаётся искусственному увеличению.
Практически полезно разделять несколько метрик: технический охват, активных пользователей и пользователей, достигших ценностного действия. Тогда изменение инфраструктурного события не маскируется под рост продукта.
После релиза фоновой синхронизации DAU выросла. Команда рассмотрела три варианта: оставить app_open без изменений, полностью исключить все открытия приложения или перейти на событие просмотра основного экрана.
Первый вариант прост и сохраняет сопоставимость со старым отчётом, но оставляет системное искажение. Второй убирает ложные открытия, однако может потерять пользователей, которые действительно запускают приложение через нестандартный сценарий. Третий лучше связан с видимым взаимодействием, но требует проверки полноты и корректности инструментирования.
Выбранным решением стало использовать валидированный просмотр основного экрана для продуктовой DAU, а исходный app_open оставить отдельной технической метрикой. Это разделило влияние фоновых процессов и реальную активность: в примере 1 апреля продуктовая DAU равна двум пользователям, а 2 апреля — одному.
После этого команда могла отдельно анализировать сбои доставки событий и пользовательскую активность. Решение не утверждает, что любой просмотр экрана равен ценности, но делает смысл метрики явным и пригодным для принятия продуктовых решений.
foreground, чтобы получить корректную DAU?Нет. Это устраняет один известный источник ложной активности, но не доказывает, что пользователь действительно взаимодействовал с продуктом. Событие может отправляться до отображения интерфейса, повторяться из-за ретраев или генерироваться при автоматическом восстановлении процесса.
Нужно проверить семантику события, задержки доставки, дубликаты и соответствие между событием и наблюдаемым действием. Фильтр по источнику — техническая коррекция, а не универсальное определение активности.
Число сессий измеряет запуски или интервалы активности, а не уникальных пользователей. Один пользователь с большим количеством сессий может непропорционально влиять на метрику, а автоматические сессии снова создадут шум.
Кроме того, сессия зависит от правила её формирования: тайм-аута, фоновых переходов и особенностей платформы. Сессии полезны для анализа частоты и глубины использования, но не заменяют явно определённую пользовательскую метрику.
Нельзя безоговорочно сравнивать старую метрику с новой: изменение определения создаёт разрыв временного ряда, даже если код расчёта стал корректнее. Нужно пометить дату смены методологии и по возможности пересчитать историю из исходных событий.
Если пересчёт невозможен, следует вести обе серии на переходном периоде, оценить их взаимосвязь и использовать новую метрику для будущих решений. В отчётах и экспериментах необходимо явно указывать, какая версия метрики применялась, иначе изменение измерительного инструмента можно ошибочно принять за изменение продукта.