Аналитика и метрики

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

Боль

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

Как помогает ИИ

предлагает черновик метрик фичи: от цели к плану измерения;
пишет SQL по описанию на естественном языке;
помогает формулировать и приоритизировать гипотезы для A/B-тестов;
разбирает результаты экспериментов и указывает на статистические ловушки;
переводит таблицы в выводы и объясняет, что стоит за цифрой.

Формулировки для всех задач — в библиотеке промптов, раздел про аналитику.

Метрики фичи: от цели к плану измерения

Пустые дашборды появляются там, где метрики выбирали под фичу, а не под вопрос «что изменится у пользователей». Модель хорошо работает как оппонент: даёте цель фичи и гипотезу ценности — получаете набор метрик-кандидатов, привязанных к пользовательскому поведению, с типом (north star, input, guardrail) и планом измерения. Отвергать лишнее и связывать с целями продукта — ваша работа.

Готовый промпт — черновик метрик:

«Ты — продуктовый аналитик. Для фичи [описание] предложи черновик метрик: главная метрика успеха и 3–5 входных метрик, по одной guardrail-метрике, которой фича не должна вредить. Для каждой: формула и способ измерения; если целевого значения нет во входных данных — не придумывай, пиши «цель не задана». Отметь, чего метрика может не заметить. Гипотеза ценности фичи: [вставьте]».

Пример черновика для фичи «повторные напоминания о брошенной корзине»:

Метрика	Тип	Формула	Что покажет
Доля возвратов к корзине	Главная	Возвраты с напоминанием / напоминания	Работает ли сам механизм
Конверсия в оплату после возврата	Входная	Оплаты / возвраты к корзине	Качество возврата
Отписки от уведомлений	Guardrail	Отписки / получатели	Не раздражает ли фича

SQL по описанию на естественном языке

Модели уверенно пишут SQL — вопрос в том, пишут ли они его по вашей схеме. У модели нет доступа к вашей базе: имена таблиц, правила дедупликации, обработку тестовых заказов и часовых поясов нужно описать в промпте. После этого она превращает «посчитай конверсию из регистрации в первую оплату за март по новым пользователям» в готовый запрос.

Готовый промпт — SQL к данным:

«Напиши SQL-запрос для PostgreSQL: посчитай конверсию из регистрации в первую оплату по когортам за [период], отдельно для новых и вернувшихся пользователей. Схема: [перечислите таблицы и ключевые поля, включая флаги тестовых данных]. Используй дедупликацию по [поле], таймзона [укажите]. Добавь комментарии к каждому шагу запроса».

Запрос проверяется до запуска. Читайте SQL как код: фильтры, дедупликация, границы дат, соединения, которые могут размножить строки. Прогоняйте сначала на копии данных или read-only реплике, ограничив период выборки, и сравнивайте одну цифру с известным значением из панели. Помните: LIMIT ограничивает выдачу, а не объём работы запроса — соединения и агрегации он не удешевляет. Модель пишет синтаксически чистый запрос — семантическая ошибка в нём невидима и стоит дороже опечатки.

Гипотезы и разбор A/B

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

Готовый промпт — гипотезы A/B:

«Ты — продуктовый аналитик. Сформулируй 5 гипотез для A/B-тестов на основе проблемы [описание] и данных [вставьте]. Формат: изменение, ожидаемый эффект с метрикой, обоснование, оценка приоритета по ожидаемому эффекту и стоимости проверки. Отдельно укажи, каких данных не хватает для оценки».

Готовый промпт — разбор A/B:

«Разбери результаты A/B-теста ниже. Проверь: совпадает ли вывод с данными, нет ли признаков подглядывания и значимого результата только в подгруппе. Для размера выборки: если во входных данных нет ожидаемого эффекта, уровней значимости и мощности или единицы рандомизации — прямо скажи, что корректность размера оценить нельзя, и перечисли, чего не хватает. Дай интерпретацию и список рисков решения. Описание теста и данные: [вставьте]».

Типичные ошибки, которые стоит проверять в каждом эксперименте:

Ошибка	Как проявляется	Что делать
Подглядывание	Тест «останавливается», как только p-value опустился ниже 0,05	Фиксировать объём выборки заранее; ложные срабатывания растут кратно
Малая выборка	«Эффект виден» на сотне пользователей	Считать мощность заранее, не читать результат до набора объёма
Эффект в подгруппе	Победа «среди пользователей iOS 40–45 лет»	Считать подгруппы гипотезами заранее, а не постфактум
Много метрик	Хоть одна «значимо выросла» из двадцати	Определять главную метрику теста до запуска

Литература по онлайн-экспериментам (Kohavi, Tang, Xu) прямо относит подглядывание и отсутствие A/A-проверок к главным источникам ложных побед — и модели, если их не просить, эту дисциплину не поддерживают.

Цифры может считать модель — выводы подписываете вы. ИИ не видит вашей схемы, не знает историю продукта и не несёт ответственности за решение, принятое на основе его разбора. Результат эксперимента — это решение о продукте, и оно остаётся на продакте.

Чек проверки

SQL прочитан глазами и проверен на копии данных до боевого запуска;
главная метрика теста определена до его старта;
объём выборки зафиксирован заранее, тест не останавливается «по ощущению»;
guardrail-метрики смотрят вместе с метрикой успеха;
вывод не обобщает подгруппы, для которых мощности не было.

Результаты экспериментов и решения — материал для коммуникации с командой и стейкхолдерами; как оформить её без шума — в главе «Работа с командой и стейкхолдерами».

Источники

Evan Miller: How Not To Run an A/B Test — классический разбор подглядывания: повторная проверка значимости делает «значимость» на дашборде бессмысленной.
Kohavi, Tang, Xu: Trustworthy Online Controlled Experiments — глава об A/A-тестах: как подглядывание и ранние остановки приводят к ложным победам.
Amplitude: Every Product Needs a North Star Metric — фреймворк North Star: как выбирать метрику ценности и её входы.