Шаблон определения метрики (с примером): договоритесь, что считать, до того как писать SQL

«Сколько людей купили в августе?»

Вы считаете заказы и отправляете результат. «Нет, я имел в виду покупателей. И только завершённые покупки. Тестовые аккаунты учли?»

Вы меняете запрос. Число меняется. Теперь никто не уверен, какая версия попала в презентацию.

Пропущенный шаг был до SQL: договориться, что число должно означать. То же самое случается, когда запрос пишет AI. Точный расчёт всё равно может отвечать не на тот вопрос.

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

Спросите о решении раньше, чем о дашборде

Допустим, маркетинг спрашивает: «Те, кто пользовался промокодом, тратили больше?» Это может значить:

• Какой был средний чек в каждой группе? Это описательное сравнение.
• Заставил ли промокод людей тратить больше? Это вопрос о причине и следствии.
• Стоит ли давать промокод большему числу людей? Это решение, которое зависит ещё и от затрат и от того, кому код доступен.

Одно сравнение не отвечает автоматически на все три. Спросите: «Что вы сделаете по-другому в зависимости от результата?»

Затем сузьте запрос:

1. Что с чем сравниваем? Заказы с промокодом — с какими заказами, за какой период?
2. Что значит «тратить»? Стоимость товаров до скидки, сколько заплатил покупатель или маржа после затрат?
3. Кто мог попасть в каждую группу? Не отсекло ли правило минимальной корзины мелкие заказы из группы с промокодом?
4. Какие данные изменят решение? Хватит описательного разрыва или нужны доказательства, что сработал именно промокод?

«Сделать график?» может подождать. Это меняет подачу, а не то, что должен установить анализ.

Шаблон определения метрики, который можно скопировать

Даты и поля здесь для иллюстрации. Берите то событие, которое нужно для решения: создание, оплата и завершение заказа могут прийтись на разные месяцы. Запишите, как поздние отмены или возвраты влияют на метрику в отчёте.

Превратите таблицу в одно предложение:

Число уникальных нетестовых аккаунтов покупателей, у которых был хотя бы один завершённый заказ в августе, по времени завершения заказа в часовом поясе Europe/Amsterdam, на снимке от 2 сентября.

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

Знаменатель меняет историю

Небольшой выдуманный пример. Из 100 подходящих аккаунтов 40 зашли на страницу предложения, и 18 из них купили за то же окно наблюдения.

Оба расчёта верны. Но «конверсия — 45%» умалчивает об условии, без которого число теряет смысл. Если коллега ждёт конверсию по всем подходящим аккаунтам, вы ответили на другой вопрос.

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

Дайте определение AI, потом проверьте реализацию

Когда бриф согласован, попробуйте такую инструкцию:

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

Затем посмотрите на запрос и на несколько исходных записей. Объяснение ассистента может расходиться с его SQL. Полный бриф уменьшает неоднозначность, но не гарантирует правильный код, полные данные или обоснованный вывод о причинах. Прежде чем опираться на результат, пройдите семь проверок для чисел от AI.

Потренируйте этот разговор в Atterna

В «Корзины больше?», первом кейсе Atterna, маркетинг хочет вписать в декабрьский план фразу «промокод увеличивает корзину в 2,5 раза». Начните с готового запроса, разберите сравнение и решите, какую рекомендацию сможете защитить. По ходу уточните задачу и договоритесь, что значит «корзина».

Текущее начало кейса 1 на английском. Первый запрос уже написан; маркетплейс и коллеги вымышлены.

Именно этот навык тренирует Atterna: связывать бизнес-вопрос со смыслом данных, а потом проверять, что результат может подтвердить. Рабочая история даёт повод делать этот выбор, а сам навык пригодится и когда вы читаете дашборд или сомневаетесь в ответе AI.

Попробуйте «Корзины больше?» — около 17 минут, бесплатно, без аккаунта. Первый SQL-запрос уже написан. Разберите сравнение и решите, какой вывод можно включить в план. Хотите начать без SQL? В Wrong Number можно потренироваться выбирать, кого считать, на трёх просьбах.

Частые вопросы

Что должно быть в определении метрики?

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

Какой первый вопрос задать заказчику?

Спросите, какое решение будет опираться на это число. Вопрос «Что вы сделаете по-другому в зависимости от результата?» помогает отличить запрос на отчёт от вопроса о причинах или от решения о будущих тратах.

Это то же самое, что семантический слой?

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

Может ли AI определить метрику за меня?

Он может предложить черновик и показать неоднозначности. Но договориться о смысле всё равно должен человек, который отвечает за решение, и кто-то должен проверить, что расчёт этот смысл реализует. Уверенное объяснение — не доказательство того, что запрос или данные верны.