Краткий ответ

Метрика выросла из-за оптимизации прокси-показателя, а не обязательно из-за улучшения продукта. Система стала засчитывать активацию пользователям, которые пропустили настройку, поэтому показатель больше не отражает целевое поведение и может быть улучшен без роста долгосрочной ценности.

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

Исторический контекст

В продуктовой аналитике часто используют прокси-метрики, потому что бизнес-результаты проявляются поздно. Например, удержание или повторные покупки могут быть видны через недели, поэтому команда наблюдает более раннюю активацию как потенциальный сигнал будущей ценности.

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

Постановка проблемы

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

Риск состоит не только в ошибке отчёта. Команда может решить, что онбординг стал лучше, масштабировать изменение и ухудшить retention, повторное использование или выручку. Кроме того, сравнение с историческими периодами станет некорректным, если раньше автоматическая активация не засчитывалась.

Подробное решение

Сначала нужно отделить измеряемое событие от бизнес-смысла активации. Если активация означает завершение настройки, в метрику следует включать только соответствующий источник:

WITH events(user_id, event_name, source) AS (
  VALUES
    (1, 'activation', 'completed_setup'),
    (2, 'activation', 'auto_skip'),
    (3, 'activation', 'completed_setup'),
    (4, 'activation', 'auto_skip')
)
SELECT COUNT(DISTINCT user_id) FILTER (
         WHERE event_name = 'activation'
           AND source = 'completed_setup'
       ) * 1.0 / COUNT(DISTINCT user_id) AS true_activation_rate
FROM events;

В примере исходная формула даёт 100%, а показатель завершения настройки — 50%. Это не просто техническое исправление: нужно явно зафиксировать определение метрики, допустимые источники событий и правило для пользователей, пропустивших шаг.

Одной активации недостаточно для решения о запуске. Её следует проверять вместе с заранее выбранными guardrail-метриками: удержанием, повторным использованием ключевой функции, конверсией в целевое действие и обращениями в поддержку. При этом нельзя добавлять метрики постфактум только потому, что они подтверждают удобный вывод.

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

Ситуация из практики

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

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

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

Что кандидаты часто упускают

1. Достаточно ли просто исключить auto_skip из запроса?

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

2. Можно ли оставить широкую активацию основной метрикой, если она сильно коррелирует с удержанием?

Корреляция не доказывает, что изменение активации вызовет рост удержания. Связь может объясняться составом пользователей, каналом привлечения или другими факторами. Широкую метрику можно использовать как диагностический сигнал, но решение лучше основывать на метрике, максимально близкой к целевому поведению, и на проверке downstream-результатов.

3. Как обнаружить, что команда начала оптимизировать метрику вместо продукта?

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