Все материалы
Продуктовая аналитикапрактикумсредний

COUNT DISTINCT с условием: несколько продуктовых метрик в одном SQL

Как считать DAU, платящих и активированных пользователей одним запросом через FILTER и CASE, сохраняя общий знаменатель.

КПКейсПрактика1 сентября 2026 г.9 мин

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

Когда пригодится подход

Как получить DAU, платящих и активированных пользователей так, чтобы показатели были сопоставимы?

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

Для daily active rate нужно считать активных пользователей и пользователей с core_action на одной дневной базе. Если core_action берётся только из платных каналов, ratio уже не описывает весь продукт.

Договорённости до расчёта

Базовый слой — событие или user × day, но финальный результат — одна строка на период. Не соединяй отдельные агрегаты по дате без проверки пропущенных периодов.

Сначала отфильтруй период и технический мусор, затем собери несколько условных числителей и общий COUNT DISTINCT. После запроса проверь, что каждый числитель является подмножеством знаменателя.

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

Проверяемый результат
вопрос → объект → период → расчёт → проверка → решение

Любой пропущенный шаг может изменить смысл итогового числа.

Пример с данными

Для daily active rate нужно считать активных пользователей и пользователей с core_action на одной дневной базе. Если core_action берётся только из платных каналов, ratio уже не описывает весь продукт.

Не копируй пример в рабочий отчёт вслепую. Сначала замени названия таблиц и полей, проверь кардинальность связей и запиши, какие строки должны попасть в результат. Хорошая адаптация сохраняет логику, но делает допущения видимыми.

Проверка знаменателя
МетрикаЧислительЗнаменательКонтроль
Activationcore_action usersall registeredсобытие в окне
Paid ratepaying usersactive usersодна timezone
Core ratecore usersactive userssame period
sqlСчитать несколько уникальных метрик из общей базы
SELECT COUNT(DISTINCT user_id) AS active_users, COUNT(DISTINCT user_id) FILTER (WHERE event_name = 'core_action') AS activated_users, COUNT(DISTINCT user_id) FILTER (WHERE event_name = 'purchase') AS paying_users\nFROM events\nWHERE event_at >= DATE '2026-07-01' AND event_at < DATE '2026-08-01';

Ограничения метода

Нельзя смешивать COUNT(*) и COUNT DISTINCT в одном сравнении, использовать разные события без подписи и считать долю после независимого удаления NULL.

Отдельно протестируй пустой результат, NULL, дубль, граничную дату и объект без связанной записи. Эти случаи не являются редкими исключениями: именно они чаще всего превращают рабочий показатель в красивую, но неверную цифру.

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

Сравнение на графике

График здесь нужен не для украшения статьи. Он помогает увидеть форму сигнала: тренд, разрыв между сегментами, хвост распределения или этап, на котором теряется объект. Сначала прочитай оси и единицы, затем сравни с таблицей и только после этого формулируй вывод.

На визуализации «Подмножества одной пользовательской базы» сравнивай не только максимальное значение. Проверь, одинаковы ли базы, не скрыта ли неполная дата и не меняется ли знаменатель от категории к категории.

Подмножества одной пользовательской базы

Условный пример: каждый следующий числитель не должен быть больше общего активного множества.

Пользователи

Самостоятельная проверка

Собери метрики для четырёх дней и проверь неравенства: activated <= active <= registered. Нарочно добавь дубль события и убедись, что уникальные пользователи не меняются.

После упражнения напиши вывод в двух версиях. Первая — техническая: какие строки и условия дали результат. Вторая — для команды: что изменилось, насколько это надёжно и какое действие стоит проверить. Если эти версии противоречат друг другу, вернись к определению показателя.

  • Собери контрольный пример из пяти-десяти строк.
  • Сверь итог с независимым способом расчёта.
  • Проверь хотя бы один крайний случай.
  • Зафиксируй дату, версию схемы и ограничение.

Следующий шаг

Один запрос полезен для согласованных метрик и общего фильтра. Если определения сильно отличаются, раздели их на именованные CTE, чтобы прозрачность не потерялась.

Сильный аналитический материал не обещает абсолютной уверенности. Он показывает, как получить число, где оно может ошибиться и какое решение можно принять уже сейчас. Такой формат хорошо переносится в дашборд, SQL-тренажёр, собеседование и рабочее обсуждение с командой.

Продолжить чтение
Вся библиотека