SQL в продуктовой аналитике: когда готовых отчётов недостаточно

Готовые отчёты ускоряют повседневные вопросы: построить воронку, удержание, путь или сегмент. SQL нужен, когда требуется проверить определение, соединить несколько источников или выполнить исследование, которого ещё нет в интерфейсе.

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

Когда использовать готовый отчёт

Интерфейс удобнее, если:

• задача повторяется;
• определение стандартно для команды;
• отчёт нужен нескольким ролям;
• важна быстрая смена фильтров;
• пользователям не нужно знать структуру таблиц;
• результат должен быть доступен без поддержки аналитика.

Повторяемое исследование после проверки через SQL полезно превратить в сохранённый отчёт с понятным названием.

Когда нужен SQL

Проверка агрегата

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

Нестандартная единица

Готовый отчёт может работать по пользователям, а вопрос относится к аккаунтам, заказам или проектам.

Соединение источников

Для связи поведения с оплатой нужны события продукта и достоверный статус из биллинга. Источники должны соединяться по устойчивому ключу.

Сложное окно

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

Контроль качества

SQL помогает найти события без идентификатора, неизвестные значения, смену типа, неожиданные повторы и задержки.

Начните с раздела «Контракт данных»

До запроса разберитесь:

• что означает строка;
• какие идентификаторы доступны;
• чем event_time отличается от received_at;
• как устроены свойства;
• есть ли версия схемы;
• как обрабатываются повторы;
• какие тестовые данные нужно исключить.

Запрос с правильным синтаксисом может отвечать не на тот вопрос.

Проверка объёма событий

Первый диагностический набор:

• количество событий по дням;
• уникальные пользователи и аккаунты;
• доля строк без обязательных идентификаторов;
• распределение по источникам и версиям;
• число неизвестных имён;
• задержка между временем действия и приёма.

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

Воронка через SQL

Перед расчётом определите:

• первый или любой вход в шаг;
• строгий или свободный порядок;
• окно;
• пользователь или аккаунт;
• допустимые повторы;
• фильтр когорты;
• момент сегмента.

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

Смысл параметров подробно разобран в статье анализ воронки.

Retention через SQL

Когортный запрос состоит из трёх частей:

1. определить старт каждого участника;
2. вычислить возраст события относительно старта;
3. посчитать уникальных вернувшихся в каждом периоде.

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

Дополнительные правила есть в материале когортный анализ.

Свойства и типы

Свойства часто приходят как полуструктурированные данные. Перед группировкой:

• проверьте наличие ключа;
• приведите тип безопасно;
• выделите неизвестные значения;
• не заменяйте ошибку нулём без причины;
• различайте отсутствующее, пустое и явное false;
• учитывайте версию схемы.

Если запрос молча отбрасывает строки с новым типом, отчёт может выглядеть стабильным при потере данных.

Воспроизводимость

Сохраните рядом с результатом:

• текст запроса;
• дату;
• версию;
• владельца;
• описание метрики;
• период данных;
• известные исключения;
• ссылку на решение или эксперимент.

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

Производительность

Продуктовые события быстро растут. Безопасный запрос:

• ограничивает период;
• использует партиционирование;
• выбирает только нужные столбцы;
• фильтрует до тяжёлого соединения;
• избегает неограниченного разворачивания свойств;
• проверяется на небольшом диапазоне;
• имеет лимит для детального вывода.

Скорость не должна достигаться удалением важных правил определения.

Доступ и приватность

SQL может открыть больше данных, чем готовый отчёт. Ограничьте:

• доступ по ролям;
• видимые проекты;
• персональные поля;
• экспорт;
• время выполнения;
• аудит запросов;
• срок хранения результатов.

Для большинства продуктовых исследований достаточно псевдонимных идентификаторов. Не выводите содержимое форм и секретные значения.

Типичные ошибки

• считать строки вместо уникальных участников;
• использовать received_at как время действия;
• соединять текущие свойства с прошлым;
• смешивать пользователя и аккаунт;
• скрывать незавершённые когорты;
• не версионировать запрос;
• превращать разовый сложный запрос в единственный источник регулярной метрики;
• делать вывод о причине только по корреляции.

Как использовать SQL в ActionPulse

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

Основные возможности платформы собраны на странице продуктовой аналитики.

Итог

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