Дизайн метрик
Метрики north-star, деревья метрик, guardrail-метрики, контр-метрики, прокси и закон Гудхарта.
11 вопросов
JuniorДизайнОчень частоВаша команда владеет частью оформления заказа в e-commerce, и ей велено «растить выручку», но выручка слишком широка, чтобы на неё действовать. Постройте дерево метрик, раскладывающее выручку на входы, спускаясь вниз до рычагов, которыми команда может двигать напрямую. Покажите декомпозицию и назовите листовую метрику, которой команда реально будет владеть.
Ваша команда владеет частью оформления заказа в e-commerce, и ей велено «растить выручку», но выручка слишком широка, чтобы на неё действовать. Постройте дерево метрик, раскладывающее выручку на входы, спускаясь вниз до рычагов, которыми команда может двигать напрямую. Покажите декомпозицию и назовите листовую метрику, которой команда реально будет владеть.
Раскладывают мультипликативно: Выручка = посетители x конверсия x средний чек, а конверсия — на add-to-cart x старт оформления x успех оплаты. Трафик — не рычаг команды, поэтому она владеет долей успешных оплат, а не корневой выручкой.
Типичные ошибки
- ✗Раскладывать выручку сложением, когда естественная структура мультипликативна
- ✗Давать команде лист, которым она не двигает, вроде трафика, вместо успеха оплат
- ✗Останавливаться на самой выручке, не спускаясь к действенному листу-рычагу
Уточняющие вопросы
- →Куда в этом мультипликативном дереве встанет рычаг ставки скидки?
- →Как не дать соседним листам пересекаться или считаться дважды?
JuniorТеорияОчень частоЧто такое north-star метрика, и почему у компании должна быть ровно одна?
Что такое north-star метрика, и почему у компании должна быть ровно одна?
Единственная метрика, которая лучше всего отражает основную ценность для пользователя и опережает выручку в долгую. Одно общее число выравнивает команды на один результат и не даёт каждой оптимизировать локальную метрику в ущерб остальным.
Типичные ошибки
- ✗Приравнивать north-star к выручке или vanity-числу вместо прокси ценности
- ✗Считать, что несколько north-star, по одной на команду, лучше одной общей
- ✗Выбирать её ради заметности на дашборде, а не по связи с ценностью
Уточняющие вопросы
- →Как отличить настоящий прокси ценности от vanity-метрики?
- →Что ломается, когда две команды выбирают каждая свою north-star?
SeniorДизайнОчень частоВы запускаете новую фичу «сохранённые корзины» и должны определить её набор метрик до раскатки: одну основную, две вторичные и два guardrail, плюс правило решения о том, успешен ли запуск. Спроектируйте набор для этой фичи и сформулируйте точное правило, по которому вы раскатите её на всех, придержите или откатите.
Вы запускаете новую фичу «сохранённые корзины» и должны определить её набор метрик до раскатки: одну основную, две вторичные и два guardrail, плюс правило решения о том, успешен ли запуск. Спроектируйте набор для этой фичи и сформулируйте точное правило, по которому вы раскатите её на всех, придержите или откатите.
Основная: доля повторных покупок сохранивших vs контроль. Вторичные: конверсия в оформление и сохранения на активного пользователя. Guardrail: задержка оформления и выручка на пользователя против каннибализации. Правило: раскатывать лишь при значимом росте основной и всех guardrail в пределах порога; иначе откат.
Типичные ошибки
- ✗Брать в основные охват или всего сохранений вместо ценностной метрики ниже по потоку
- ✗Раскатывать на любом дёрганье вверх без проверки значимости основной
- ✗Опускать guardrail, из-за чего каннибализация или рост задержки остаются незамеченными
Уточняющие вопросы
- →Почему ценностная метрика, а не охват, — верная основная для новой фичи?
- →Сколько guardrail должны отработать, прежде чем сработает правило решения?
JuniorТеорияЧастоЧто такое guardrail-метрики, и почему их нельзя оптимизировать напрямую?
Что такое guardrail-метрики, и почему их нельзя оптимизировать напрямую?
Guardrail — те, за которыми следят, чтобы рост основной метрики не навредил чему-то ещё: задержке, ошибкам, возвратам, цене. Их держат в пределах порога, не максимизируют; это ограничения, а не цели — оптимизировать guardrail напрямую нельзя.
Типичные ошибки
- ✗Считать guardrail ещё одной целью для максимизации, а не порогом для удержания
- ✗Путать guardrail с пост-инцидентными алертами, на которые лишь реагируют потом
- ✗Верить, что guardrail можно улучшать без ущерба защищаемой им основной метрике
Уточняющие вопросы
- →Для основной метрики вовлечённости какие два guardrail вы бы задали и почему?
- →Как выбрать порог, при котором считается, что guardrail пробит?
JuniorДизайнЧастоВы первый аналитик в приложении доставки еды (клиенты заказывают у ресторанов, курьеры доставляют). Руководство хочет одну north-star метрику, чтобы выровнять продукт, рост и операции. На столе два кандидата — общее число загрузок приложения и gross merchandise value (GMV) за квартал. Предложите метрику, которую сделаете north-star, и объясните, почему она лучше обоих этих вариантов как ориентир для каждой команды.
Вы первый аналитик в приложении доставки еды (клиенты заказывают у ресторанов, курьеры доставляют). Руководство хочет одну north-star метрику, чтобы выровнять продукт, рост и операции. На столе два кандидата — общее число загрузок приложения и gross merchandise value (GMV) за квартал. Предложите метрику, которую сделаете north-star, и объясните, почему она лучше обоих этих вариантов как ориентир для каждой команды.
Берут метрику ценности и частоты — доставленные заказы на активного пользователя в месяц. Она отражает реализованную ценность и повторность использования, и каждая команда может на неё влиять. Загрузки — vanity-число вершины воронки без учёта удержания; GMV запаздывает и раздут скидками и разовыми заказами.
Типичные ошибки
- ✗Выбирать загрузки — vanity-число вершины воронки без учёта возвращаемости
- ✗Выбирать квартальный GMV — запаздывающую цифру, раздутую скидками и разовыми заказами
- ✗Отказаться выбрать одну и смешать три метрики в размытую общую цель
Уточняющие вопросы
- →Как развернуть заказы на активного пользователя в дерево метрик рычагов команд?
- →Какой guardrail вы бы добавили к ней, чтобы защитить юнит-экономику?
MiddleДизайнЧастоКоманду доставки мерят по «доле заказов, доставленных вовремя», и появляется игра — курьеры завышают ETA и помечают заказ доставленным до передачи, чтобы часы остановились раньше. Вы хотите сохранить цель по вовремя, но не дать добивать её нечестно. Какую контр-метрику вы добавите и где в скоркарте она стоит относительно основной метрики?
Команду доставки мерят по «доле заказов, доставленных вовремя», и появляется игра — курьеры завышают ETA и помечают заказ доставленным до передачи, чтобы часы остановились раньше. Вы хотите сохранить цель по вовремя, но не дать добивать её нечестно. Какую контр-метрику вы добавите и где в скоркарте она стоит относительно основной метрики?
Добавляют контр-метрику, которая ухудшается, когда вовремя геймится, — разрыв обещанного и фактического ETA или долю опозданий по жалобам. Ставят её как guardrail рядом с основной, чтобы вовремя засчитывалось лишь пока контр-метрика ровная.
Типичные ошибки
- ✗Просто поднимать планку вовремя — это меняет число, а не стимул к игре
- ✗Брать контр-метрику, которая не двигается, когда основную реально геймят
- ✗Прятать контр-метрику в другом дашборде вместо пары рядом с основной
Уточняющие вопросы
- →Как задать порог контр-метрики, не наказывая честные задержки?
- →Закроет ли подтверждение доставки от клиента лазейку с ранней передачей?
MiddleДизайнЧастоОтдел поддержки ставит одну цель — «закрытых тикетов в час» на агента — и привязывает к ней бонусы. Применяя идею о том, что метрика под давлением перестаёт мерить то, что хотели (закон Гудхарта), предскажите конкретные способы, которыми агенты будут добивать число, не помогая клиентам, и назовите реальный итог, который цель перестала отслеживать.
Отдел поддержки ставит одну цель — «закрытых тикетов в час» на агента — и привязывает к ней бонусы. Применяя идею о том, что метрика под давлением перестаёт мерить то, что хотели (закон Гудхарта), предскажите конкретные способы, которыми агенты будут добивать число, не помогая клиентам, и назовите реальный итог, который цель перестала отслеживать.
Агенты оптимизируют прокси, а не цель: выбирают лёгкие тикеты, дробят одну проблему на несколько, закрывают преждевременно, торопят завершить чат. Закрытых в час растёт, а итог — решённые проблемы и довольные клиенты — стоит на месте.
Типичные ошибки
- ✗Считать, что ясную числовую цель нельзя гейммить и она лишь двигает реальный труд
- ✗Предсказывать замедление, упуская, что игра, наоборот, раздувает счёт
- ✗Называть симптомы, но не потерянный итог — решённые проблемы и удовлетворённость
Уточняющие вопросы
- →Какой парный guardrail быстрее всего поймает дробление и переоткрытие?
- →Уберёт ли стимул переход на метрику решения с первого обращения?
MiddleДизайнЧастоВ прошлом квартале общая выручка выросла на 15%, но ARPU (средняя выручка на пользователя) упал на 8%, потому что дешёвый канал привлёк много малоплатящих пользователей. Руководство спрашивает, какое число ставить в OKR следующего квартала — абсолютную выручку или подушевой коэффициент — и почему. Дайте рекомендацию и обоснование, включая то, к чему каждый выбор подтолкнёт команду.
В прошлом квартале общая выручка выросла на 15%, но ARPU (средняя выручка на пользователя) упал на 8%, потому что дешёвый канал привлёк много малоплатящих пользователей. Руководство спрашивает, какое число ставить в OKR следующего квартала — абсолютную выручку или подушевой коэффициент — и почему. Дайте рекомендацию и обоснование, включая то, к чему каждый выбор подтолкнёт команду.
Используют оба в разных ролях — абсолютную выручку как цель роста, ARPU как guardrail. Одна абсолютная поощряет покупку убыточного объёма; один коэффициент «улучшают», отсекая малоценных пользователей. Пара держит рост здоровым без размытия подушевой ценности.
Типичные ошибки
- ✗Брать только коэффициент, который команда «улучшает», отсекая малоценных пользователей
- ✗Брать только абсолют, который поощряет покупку убыточного малоплатящего объёма
- ✗Считать это выбором одного из двух, а не парой цель-плюс-guardrail
Уточняющие вопросы
- →Какой порог ARPU сработает как guardrail и приостановит дешёвый канал?
- →Как сегментация ARPU по каналам меняет диагноз в этом случае?
SeniorТеорияИногдаХорошая метрика чувствительна, атрибутируема, устойчива к игре и связана с ценностью — оцените так «сессии на пользователя».
Хорошая метрика чувствительна, атрибутируема, устойчива к игре и связана с ценностью — оцените так «сессии на пользователя».
Смешанно. Чувствительна: да, быстро реагирует. Атрибутируема: неплохо, режется по когортам. Устойчива к игре: слабо — раздувается дроблением сессий или назойливыми пушами. Связь с ценностью: слабая, ведь больше сессий может значить путаницу. Сигнал полезен, но цель плохая.
Типичные ошибки
- ✗Называть её устойчивой к игре, упуская, что дробление сессий и пуши её раздувают
- ✗Считать, что больше сессий всегда ценнее, а не возможная путаница
- ✗Проходить или проваливать все четыре разом вместо оценки каждого критерия отдельно
Уточняющие вопросы
- →Какое одно изменение сильнее всего повысит её устойчивость к игре?
- →Какую связанную с ценностью метрику вы бы добавили в пару, чтобы закрыть слабость?
SeniorДизайнИногдаИстинная целевая метрика команды — 7-дневный retention, но на маленьком недельном масштабе команды она слишком шумная, чтобы уловить любое ваше изменение. Предложите более чувствительную прокси-метрику, которой можно управлять вместо неё, и опишите, как вы докажете, что прокси действительно валиден — что его сдвиг реально двигает 7-дневный retention, а не дрейфует сам по себе.
Истинная целевая метрика команды — 7-дневный retention, но на маленьком недельном масштабе команды она слишком шумная, чтобы уловить любое ваше изменение. Предложите более чувствительную прокси-метрику, которой можно управлять вместо неё, и опишите, как вы докажете, что прокси действительно валиден — что его сдвиг реально двигает 7-дневный retention, а не дрейфует сам по себе.
Берут раннюю опережающую метрику выше retention — активацию в день-1 или ключевые действия за первую неделю — с большим числом событий и меньшим шумом. Доказывают валидность: она исторически предсказывает retention и в прошлых экспериментах двигалась вместе с ним.
Типичные ошибки
- ✗Путать высокообъёмную метрику с валидным прокси, не проверив связь
- ✗Считать сегодняшнюю корреляцию полным доказательством причинной валидности
- ✗Сдаваться и дольше усреднять шумную цель вместо поиска опережающего прокси
Уточняющие вопросы
- →Как прошлые A/B-тесты послужат валидационной выборкой для прокси?
- →Что подскажет, что прокси со временем расцепился с retention?
SeniorДизайнРедкоСпроектируйте рейтинг продавца для маркетплейса. Наивное среднее сломано — продавец с тремя отзывами по 5 звёзд показывает 5.0 и обгоняет продавца с 500 отзывами и средним 4.8. Спроектируйте рейтинг, учитывающий объём и надёжность свидетельств, чтобы крошечная выборка не обгоняла крупного продавца с массой отзывов, и объясните механизм, который это чинит.
Спроектируйте рейтинг продавца для маркетплейса. Наивное среднее сломано — продавец с тремя отзывами по 5 звёзд показывает 5.0 и обгоняет продавца с 500 отзывами и средним 4.8. Спроектируйте рейтинг, учитывающий объём и надёжность свидетельств, чтобы крошечная выборка не обгоняла крупного продавца с массой отзывов, и объясните механизм, который это чинит.
Не ранжируют по сырому среднему; стягивают к глобальному по числу отзывов — сглаженное байесовское среднее или нижняя доверительная граница. Мало отзывов — у априори; много — у истинного среднего. Поэтому три отзыва по 5 звёзд ниже 4.8 из 500, ведь скудные свидетельства дисконтируются.
Типичные ошибки
- ✗Добавлять минимальный порог отзывов, но выше него всё равно ранжировать по сырому среднему
- ✗Ранжировать по одному объёму отзывов, игнорируя сами звёздные оценки
- ✗Навешивать аддитивный бонус за объём вместо стягивания к априори
Уточняющие вопросы
- →Как сила априори задаёт, насколько быстро оценка доверяет новым отзывам?
- →Почему нижняя доверительная граница естественно штрафует крошечную выборку?
