Когда команда упирается в один показатель и гонит его вверх любой ценой, я почти всегда знаю, чем это кончится: цифра вырастет, а продукт станет хуже. Это и есть закон Гудхарта — «когда метрика становится целью, она перестаёт быть хорошей метрикой». Защита от него не про героизм и не про интуицию, а про конкретную инженерию метрик: контр-метрики (guardrail), пары «скорость плюс качество» и одна North Star вместо десятка прокси. Разберу, как это устроено и почему именно аналитик обязан ловить манипуляции первым.
Что такое закон Гудхарта простыми словами?
Формулировку приписывают британскому экономисту Чарльзу Гудхарту — он говорил про денежно-кредитную политику: как только центробанк начинает таргетировать конкретный монетарный агрегат, тот перестаёт вести себя предсказуемо. Позже антрополог Мэрилин Стратерн переформулировала мысль так, как её сегодня цитируют в продуктовых командах: любая мера, превращённая в цель, теряет свойства хорошей меры.
В продукте это выглядит буднично. Мы не умеем напрямую измерить «пользователь получил ценность». Поэтому берём наблюдаемую цифру — заходы, клики, длину сессии — и договариваемся считать её сигналом ценности. Пока цифра просто наблюдается, она честно коррелирует с тем, что нам важно. Как только за неё начинают премировать, увольнять и защищать квартальные планы, люди оптимизируют именно её. И оптимизируют изобретательно: находят самый дешёвый способ подвинуть число, не трогая ту самую ценность, ради которой метрику вводили.
Почему хорошая метрика ломается, когда становится целью?
Потому что почти любая метрика — это прокси. Она стоит вместо настоящей цели, которую тяжело или дорого измерить. Между прокси и целью всегда есть зазор, и в спокойном режиме он маленький. Давление на метрику растягивает этот зазор: люди двигают прокси, а цель остаётся на месте или проседает.
Классический пример — DAU. Дневная активность — приличный прокси вовлечённости, пока вы её просто смотрите. Поставьте DAU целью команды роста — и появятся пуши в 22:00, счётчики непрочитанного, «войдите, чтобы забрать награду». DAU поедет вверх, а удержание на длинном горизонте и NPS поедут вниз, потому что вы обучили продукт дёргать людей, а не давать им пользу.
Механика всегда одна: у сотрудника есть выбор между дорогим честным способом двинуть метрику (сделать продукт лучше) и дешёвым способом (накрутить прокси). Если система награждает за цифру, а не за результат, рациональный человек выбирает дешёвый путь. Это не про плохих людей — это про плохо спроектированные стимулы.
Как выглядит геймификация метрик на реальных примерах?
Самые узнаваемые случаи — там, где метрику привязали к KPI и бонусу.
Колл-центр, где оператору платят за количество обработанных звонков. Среднее время разговора падает, «обработано в час» растёт, отчёт зелёный. А на деле операторы сбрасывают сложные обращения, лишь бы взять следующий простой звонок. Проблема клиента не решена — он перезванивает, и один и тот же человек засчитывается как три успешных контакта.
Реклама и контент, где цель — CTR. Заголовки мутируют в кликбейт, ставятся кричащие превью. Клики растут, а конверсия в покупку и время на странице падают, потому что пришли люди, которых обманули ожиданием.
Поддержка, где метрика — доля закрытых тикетов. Тикеты закрывают через минуту с формальной отпиской, клиент открывает новый — счётчик закрытий счастлив, а очередь и повторные обращения растут.
Такой разрыв легко увидеть в данных, если вообще додуматься посмотреть на пару метрик сразу:
-- Операторы: «производительность» против реальной решённости
SELECT
o.operator_id,
COUNT(*) AS calls_handled,
ROUND(AVG(o.duration_sec), 1) AS avg_duration,
-- контр-метрика: доля клиентов, перезвонивших в течение 24 часов
ROUND(AVG(CASE WHEN c.recontacted_24h THEN 1 ELSE 0 END), 3) AS recontact_rate
FROM calls o
JOIN call_outcomes c ON c.call_id = o.call_id
WHERE o.created_at >= DATE('now', '-30 day')
GROUP BY o.operator_id
ORDER BY calls_handled DESC;Оператор с рекордным calls_handled и подозрительно низким avg_duration часто идёт в паре с высоким recontact_rate. Это и есть подпись Гудхарта: локальный чемпион по прокси-метрике проваливает настоящую цель. Похожие расследования удобно тренировать на разборах в кейсах — там как раз даётся сырой набор данных и задача докопаться до того, что цифра скрывает.
Что такое контр-метрики и guardrail-метрики?
Контр-метрика (её же называют guardrail, «ограждение») — это показатель, который специально двигается в противоположную сторону, если основную метрику начинают накручивать нечестно. Вы не оптимизируете guardrail, вы за ним следите: он должен оставаться в допустимом коридоре, пока вы гоните основную метрику.
Пары «метрика — контр-метрика», которые я держу в голове:
- Скорость выкатки фич — количество инцидентов и доля откатов релизов.
- Конверсия в оформление заказа — доля возвратов и отмен.
- Рост числа заказов — средний чек и маржинальность (иначе рост может быть выкуплен скидками в убыток).
- Отправленные пуши — отписки и доля отключивших уведомления.
- CTR письма — жалобы на спам и отписки.
В экспериментах guardrail-метрики — обязательная часть дизайна. Вы катите A/B-тест на новую механику, у которой цель — поднять активацию. Заранее фиксируете, что при этом не должны просесть удержание 30-го дня, доля жалоб и время загрузки. Если основная метрика выросла, а guardrail пробил порог — это не победа, это перекладывание проблемы в другой карман. Такие ловушки любят на собеседованиях: посмотрите разбор в вопросах по продуктовой аналитике, там регулярно спрашивают, какие guardrail вы бы поставили к предложенной метрике.
Зачем держать метрики парами: скорость и качество?
Одиночная метрика всегда однобока, потому что у любого действия есть две стороны — сколько и насколько хорошо. Скорость без качества деградирует в халтуру, качество без скорости — в паралич. Поэтому здоровая система метрик почти всегда парная.
«Быстрее отвечаем в поддержке» превращается в «быстрее отписываемся», если рядом нет метрики решённости с первого контакта. «Больше заказов» превращается в «раздали промокоды в минус», если рядом нет маржи. Пара работает как система сдержек: команда физически не может выиграть по одной цифре, обвалив вторую, потому что смотрят на обе.
Посчитать пару на Python — минута работы. Считаю доставку заказов: скорость (медиана времени) и качество (доля без возврата) в одной таблице:
import pandas as pd
# orders: order_id, courier_id, delivery_minutes, is_returned, delivered_at
df = pd.read_parquet("orders.parquet")
recent = df[df["delivered_at"] >= "2026-06-01"]
report = (
recent.groupby("courier_id")
.agg(
orders=("order_id", "count"),
speed_median_min=("delivery_minutes", "median"), # скорость
return_rate=("is_returned", "mean"), # качество (контр-метрика)
)
.reset_index()
)
# «Подозреваемые»: быстрые, но с высокой долей возвратов
suspects = report[
(report["speed_median_min"] < report["speed_median_min"].median())
& (report["return_rate"] > report["return_rate"].quantile(0.75))
]
print(suspects.sort_values("return_rate", ascending=False))Тот, кто «возит быстрее всех», но собрал верхний квартиль по возвратам, скорее всего гонит скорость за счёт брошенных у двери или перепутанных заказов. Потренировать такие срезы можно в Python-тренажёре, а логику агрегатов на SQL — в SQL-тренажёре с настоящим PostgreSQL в браузере.
Чем North Star лучше набора прокси-метрик?
North Star — это одна метрика, которая максимально близко описывает переданную пользователю ценность, а не побочный сигнал. Смысл её не в том, чтобы отменить остальные, а в том, чтобы задать иерархию: есть верхняя цель, а под ней дерево прокси, которые ей служат.
Разница принципиальная. Прокси-метрику легко накрутить, потому что она узкая: клики, заходы, отправленные сообщения. North Star подобрана так, что накрутить её дёшево уже нельзя — придётся и правда дать ценность. Для маркетплейса это не «визиты», а что-то вроде «выкупленных заказов на активного покупателя»; для медиасервиса — не «клики по плейлисту», а «часы реально прослушанного контента»; для B2B-инструмента — не «заведённые аккаунты», а «команды, которые дошли до регулярного использования».
Когда North Star определена, прокси перестают быть самоцелью и становятся рычагами. Мы по-прежнему смотрим на клики и заходы, но задаём другой вопрос: двигают ли они верхнюю метрику или отрываются от неё. Если DAU растёт, а North Star стоит — значит, активность накручена и ценности в ней нет. Дерево метрик под North Star помогает не потерять эту связь; собрать его аккуратно на SQL можно, пройдя базовые агрегаты в курсе по SQL, а синтаксис под рукой держать в SQL-справочнике.
Как аналитику ловить манипуляции с метриками?
Это прямая часть моей работы, и держится она на нескольких привычках.
Смотреть на распределение, а не на среднее. Среднее время ответа улучшилось — а что с 90-м перцентилем? Часто среднее двигают, отрезав хвост дешёвых случаев, а тяжёлые обращения при этом стали хуже. Медиана и перцентили врут заметно реже.
Резать по сегментам. Метрика в целом выросла — а по когортам, каналам, командам? Гудхартовская накрутка обычно локальна: один менеджер, один канал, один город тянут агрегат, оставаясь аномалией на фоне остальных.
Держать при каждой целевой метрике её контр-метрику и требовать смотреть на обе. Если в дашборде «конверсия» есть, а «возвратов» нет — дашборд врёт по построению.
Проверять определение метрики глазами того, кого по ней оценивают. Полезное упражнение: «представь, что твоя премия зависит от этой цифры — как ты накрутишь её, ничего не улучшив?». Найденные дешёвые лазейки сразу превращаются в guardrail. Такой стресс-тест метрик стоит прогонять и на тренировочных задачах, где нужно самому предложить и защитить набор показателей.
И самое неудобное политически — говорить вслух, когда цифра зелёная, а продукт нет. Аналитик, который молчит про разъезжающийся зазор между прокси и целью ради красивого отчёта, сам становится частью механизма Гудхарта.
Как собрать систему метрик, устойчивую к закону Гудхарта?
Свести всё вместе можно коротким чек-листом, который я держу под рукой перед запуском любой метрики или эксперимента.
- Отделить цель от прокси. Явно записать, что мы на самом деле хотим (ценность, удержание, деньги) и какой наблюдаемой цифрой это подменяем. Помнить, что подмена временная и дырявая.
- К каждой целевой метрике завести guardrail. Ни одной метрики роста без контр-метрики качества рядом.
- Ставить метрики парами. Скорость и качество, объём и маржа, охват и жалобы — на один дашборд.
- Держать одну North Star над деревом прокси. Прокси разрешено двигать только если верхняя метрика тоже растёт.
- Не привязывать бонус жёстко к одиночной цифре. Как только за прокси начинают платить, начинается его накрутка.
- Смотреть распределения и сегменты, а не только агрегат. Гудхарт прячется в хвостах и в отдельных группах.
Ни один из этих пунктов не спасает сам по себе — работает только система целиком. Метрика без guardrail будет накручена, guardrail без North Star позволит выигрывать по мелочам ценой главного, а North Star без сегментного контроля вы просто не заметите, как перестала расти.
Если хотите довести это до автоматизма — считать пары «метрика — контр-метрика», строить дерево под North Star и отлавливать накрутку в распределениях, — на тренажёре подготовки аналитиков это отрабатывается на живых данных: SQL и Python в браузере, продуктовые кейсы и разбор метрик с формулами. Pro открывает все 425 SQL- и 402 Python-задачи, кейсы и метрики без ограничений — удобно, когда хочется натренировать этот навык до состояния, в котором вы ловите Гудхарта на цифрах ещё до того, как он попадёт в квартальный отчёт.