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

Между «мы изменили X» и «бизнес получил Y» обычно есть причинная цепочка. После внедрения инициативы должно измениться поведение пользователя или какой-то процесс. Затем этот эффект должен распространиться дальше и в итоге повлиять на то, ради чего изменение вообще затевалось: выручку, retention, затраты и т. д.

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

В этой цепочке есть как минимум три места, где можно ошибиться.

Иногда за конечный результат принимают output отдельного этапа: например, обработанное обращение вместо решённой проблемы клиента. Команда действительно может улучшить производительность своего участка, просто этот показатель не совпадает с результатом, ради которого участок вообще существует.

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

Хороший пример — эксперимент Microsoft с намеренным ухудшением релевантности поиска. В первые дни выросло число поисковых сессий на пользователя. Авторы связывали это не с ростом ценности продукта, а с тем, что людям приходилось чаще переформулировать запросы, чтобы решить ту же задачу. Позже engagement начал снижаться.

А иногда проблема находится за пределами участка, который мы вообще решили анализировать. Можно хорошо оптимизировать каждый touchpoint и всё равно получить плохой end-to-end journey. У McKinsey был похожий кейс. Трёхмесячный онбординг клиента состоял из множества взаимодействий, каждое из которых имел показатель успешности выше 90%: клиенту отвечали, вопрос решали, проблему исправляли.

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

Из этого не следует, что каждую задачу нужно раскручивать до уровня всего customer journey или продукта. Я бы проверяла только то, что может повлиять на само решение, его scope, требования или способ оценки результата.

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

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