{
  "index": 88,
  "slug": "editorial-2025-07-field-product-metrics",
  "title": "Когда рост conversion не означает улучшение продукта",
  "excerpt": "Conversion имеет смысл только вместе с определением событий, cohort, периодом, denominator и guardrail. Разбираем механизм ошибки, отрицательные пути и проверяемый критерий готовности.",
  "contentHtml": "<p>На дашборде растёт conversion, а число ошибок рендера растёт вместе с ним. Пользователь открывает форму повторно, но повторное открытие уже не попадает в denominator. Команда видит красивую дробь и оставляет новый вариант. Через день выясняется, что сравнивались разные множества событий. Цена ошибки — неверное решение, повторный сбор данных и часы спора о том, что именно измерила система.</p>\n<p>Тезис простой: метрика становится основанием для решения только вместе с условиями её получения. Нужно связать изменение, событие, cohort, period, numerator, denominator и guardrail. Если связь не доказана, расчёт должен остановиться с понятной причиной. Неполный результат лучше честного на вид числа, которое отвечает на другой вопрос.</p>\n<h2>Механизм ошибки</h2>\n<p>Conversion — это отношение numerator к denominator. Например, numerator может считать уникальных субъектов с событием <code>checkout_confirmed</code>, а denominator — уникальных субъектов с событием <code>checkout_opened</code>. Дробь отвечает на вопрос «какая доля открывших подтвердила действие» только при одинаковых правилах отбора.</p>\n<p>Cohort задаёт сравниваемую группу: control или treatment. Period задаёт единое окно времени. Attribution связывает подтверждение с конкретным открытием и вариантом. Guardrail показывает ущерб, который не должен расти ради локального улучшения. Если один элемент выпадает, значение conversion меняет смысл.</p>\n<p>Предзагрузка формы может сократить ожидание. Она не доказывает, что пользователь чаще завершает действие. Для такого вывода нужны как минимум открытие, подтверждение и правило их связи. Отдельно нужно считать сбой рендера, отмену или другой риск, который может скрыться за ростом локальной метрики.</p>\n<h2>Контракт события</h2>\n<p>Событие должно иметь стабильное имя и отдельные атрибуты. Динамические значения нельзя зашивать в имя: запрос не сможет надёжно сгруппировать такие записи. OpenTelemetry формулирует то же правило для semantic conventions: имя события должно однозначно описывать структуру, а переменные значения должны жить в attributes.</p>\n<pre><code>event: product.checkout_opened; subject: subject-a; cohort: treatment; period: 2025-07-14; requestId: request-2;</code></pre>\n<p>Вызов подтверждения должен содержать совместимые поля: <code>event</code>, <code>subject</code>, <code>cohort</code>, <code>period</code> и <code>requestId</code>. Тогда запрос может проверить, что открытие и подтверждение относятся к одному субъекту, одной попытке и одному окну. Если <code>requestId</code> отсутствует, запрос не должен угадывать связь.</p>\n<p>Значения в примере фиксированы и нужны только для объяснения механизма. Они не задают политику идентификации. В реальной системе отдельно определяют допустимый идентификатор, срок хранения, доступ к данным и правила обработки задержанных событий. Нельзя переносить строку <code>subject-a</code> в действующий сбор без такой проверки.</p>\n<h2>Конкретный расчёт</h2>\n<p>Возьмём малый набор событий. В control два открытия и одно подтверждение. В treatment два открытия и одно подтверждение. В control один экран завершился событием <code>product.render_failed</code>. Расчёт считает уникальных субъектов внутри cohort и period.</p>\n<pre><code>const events = [\n  { event: 'product.checkout_opened', subject: 'a', cohort: 'control', period: '2025-07-14', requestId: 'r-1' },\\n  { event: 'product.checkout_confirmed', subject: 'a', cohort: 'control', period: '2025-07-14', requestId: 'r-1' },\\n  { event: 'product.checkout_opened', subject: 'b', cohort: 'treatment', period: '2025-07-14', requestId: 'r-2' },\\n  { event: 'product.checkout_confirmed', subject: 'b', cohort: 'treatment', period: '2025-07-14', requestId: 'r-2' },\\n  { event: 'product.checkout_opened', subject: 'c', cohort: 'treatment', period: '2025-07-14', requestId: 'r-3' },\\n  { event: 'product.checkout_opened', subject: 'd', cohort: 'control', period: '2025-07-14', requestId: 'r-4' },\\n  { event: 'product.render_failed', subject: 'd', cohort: 'control', period: '2025-07-14', requestId: 'r-4' }\n];</code></pre>\n<p>В treatment conversion равна 1/2. В control conversion тоже равна 1/2. Для control guardrail равен 1/2. Эти значения показывают только работу дроби на фиксированных данных. Они не оценивают эффект, статистическую значимость или поведение пользователей.</p>\n<p>Смысл примера раскрывается на ошибочном пути. Если подтверждение приходит без <code>requestId</code>, его нельзя приписать открытию. Если одно событие имеет следующий period, его нельзя молча объединить с предыдущим. Если denominator заменили на <code>all-events</code>, старое имя conversion больше не описывает новый расчёт.</p>\n<h2>Симптом → причина → проверка → действие</h2>\n<div class=\"table-scroll\"><table><caption>Проверки перед интерпретацией метрики</caption><thead><tr><th scope=\"col\">Симптом</th><th scope=\"col\">Причина</th><th scope=\"col\">Проверка</th><th scope=\"col\">Действие</th></tr></thead><tbody><tr><td>Conversion выросла после изменения запроса</td><td>Изменился denominator или deduplication</td><td>Вывести numerator и denominator по cohort</td><td>Остановить сравнение и исправить правило inclusion</td></tr><tr><td>Подтверждение есть, вариант не определён</td><td>Нет attribution или requestId</td><td>Проверить subject, requestId и cohort</td><td>Вернуть ошибку владельцу событий</td></tr><tr><td>Группы имеют разные даты</td><td>Смешан period или пришли задержанные события</td><td>Проверить period каждой записи до агрегации</td><td>Разделить окна или собрать данные заново</td></tr><tr><td>Local metric растёт вместе с ошибками</td><td>Guardrail считает другую population</td><td>Посчитать failure на том же срезе</td><td>Не считать локальный рост улучшением</td></tr><tr><td>Расчёт нельзя повторить</td><td>Definition хранится только в сообщениях</td><td>Восстановить запрос по полям метрики</td><td>Зафиксировать definition, owner и limitation</td></tr></tbody></table></div>\n<p>Таблица задаёт маршрут диагностики. Она не заменяет проверку данных. Каждый ответ должен вести к действию: пересчитать дробь, исправить событие, разделить period, пересмотреть guardrail или остановить решение.</p>\n<h2>Иллюстрация цепочки доказательств</h2>\n<figure><img src=\"/assets/editorial/2025/product-metrics-2025-decision-evidence-loop.svg\" alt=\"Цепочка проверки метрики: изменение и гипотеза, контракт событий, cohort и denominator, guardrail, затем решение или остановка с причиной\" loading=\"lazy\" /><figcaption>Схема показывает, какие условия нужно проверить до решения. Финальная остановка сохраняет причину, которую можно исправить.</figcaption></figure>\n<p>Человек находится в конце цепочки не случайно. Код может проверить обязательные поля, период, denominator и известные отрицательные пути. Он не может по одной дроби выбрать допустимый продуктовый риск. Локальный рост может сопровождаться отказами, отменами или недоступностью. Guardrail делает такую цену видимой, но не выбирает порог вместо владельца.</p>\n<h2>Отрицательный путь в коде</h2>\n<p>Проверяющая функция должна отклонять неполный контракт. Ниже приведён ограниченный пример с фиксированными данными в памяти. Он не читает сеть или файл и не отправляет события.</p>\n<pre><code>const report = inspectProductMetric(\\n  createProductMetricInput('mixed-period-example'),\\n);\\n\\nconst decision = prepareProductDecision(report);\\n\\nconsole.log(decision);\\n// {\\n//   status: 'stop-before-decision',\\n//   reasons: ['mixed-cohort-or-period']\\n// }</code></pre>\n<p>Смешанный period не превращается в <code>null</code> и не замазывается средним. Проверка возвращает короткую причину. Она направляет действие: владелец событий проверяет instrumentation, владелец запроса проверяет population, владелец варианта проверяет cohort и окно.</p>\n<p>То же правило действует для неверного denominator и отсутствующего attribution. Ветка <code>wrong-denominator</code> не чинит запрос автоматически и не разрешает сохранить старое имя метрики. Ветка <code>missing-attribution-rule</code> не угадывает связь между открытием и подтверждением. Такая строгость защищает от убедительного числа, собранного из несвязанных фактов.</p>\n<h2>Порядок действий</h2>\n<ol><li><strong>Назвать решение.</strong> Записать, что можно оставить, остановить или повторить. Не начинать с самого удобного графика.</li><li><strong>Описать цепочку.</strong> Связать изменение с событием, действием, outcome и возможным ущербом. Отделить гипотезу от наблюдаемого факта.</li><li><strong>Зафиксировать event contract.</strong> Записать имена событий, обязательные поля, deduplication, attribution, cohort и period.</li><li><strong>Разложить ratio.</strong> Показать numerator и denominator отдельно для каждой группы. Проверить одно правило inclusion.</li><li><strong>Положить рядом guardrail.</strong> Использовать тот же срез или явно назвать отличие. Указать владельца порога и error path.</li><li><strong>Проверить отрицательные входы.</strong> Подать missing attribution, mixed period и wrong denominator. Каждый случай должен вернуть остановку с причиной.</li><li><strong>Сохранить доказательства.</strong> Оставить definition, запрос, источник данных, limitation, owner и дату следующей проверки. Если другой инженер не восстановит расчёт, вернуться к шагу 3.</li></ol>\n<h2>Ограничения</h2>\n<p>Контракт событий не доказывает причинность. Он не заменяет randomization, расчёт мощности, проверку задержки доставки, privacy, retention и качества identity. Guardrail не делает эксперимент безопасным автоматически. Он заранее называет ущерб, который нельзя скрыть локальным ростом.</p>\n<p>Малый набор не говорит о размере эффекта. В нём нет реальных пользователей, денег, сети, clock, действующего запроса или инцидента. Его можно использовать для детерминированной проверки веток и отсутствия побочных действий. Нельзя выдавать его значения за наблюдение действующего продукта.</p>\n<p>Корректный контракт тоже может устареть после изменения клиента, схемы или pipeline. Проверяйте смысл события рядом с кодом отправки и запросом. Если событие меняет смысл, меняйте definition и отмечайте несовместимость. Молчаливое сохранение старого названия опаснее явной остановки.</p>\n<h2>Проверяемый критерий готовности</h2>\n<p>Измерение готово к продуктовому решению, если другой инженер по одной карточке восстанавливает population, numerator, denominator, attribution, period и guardrail. Он видит входящие события, условие остановки и владельца каждой ошибки. Если нужен устный контекст, контракт измерения ещё не готов.</p>\n<p>Минимальный проверяемый результат таков: корректный фиксированный пример получает статус <code>needs-human-decision</code>; missing attribution, mixed period и wrong denominator получают <code>stop-before-decision</code> с разными причинами; ни один вызов не отправляет данные и не меняет состояние системы. Для действующего проекта добавьте отдельные проверки схемы, задержки, прав доступа и повторяемости запроса.</p>\n<h2>Проверяемые источники</h2><ul><li><a href=\"https://opentelemetry.io/docs/specs/semconv/general/events/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenTelemetry: Semantic conventions for events</a> — официальное описание имён событий, timestamp и attributes. Документ не определяет product metric и не доказывает причинность.</li><li><a href=\"https://developers.google.com/analytics/devguides/collection/protocol/ga4/reference\" target=\"_blank\" rel=\"noopener noreferrer\">Google Analytics: Measurement Protocol reference</a> — официальная спецификация параметров событий и ограничений протокола. Она не заменяет проверку собственной схемы данных.</li><li><a href=\"https://www.microsoft.com/en-us/research/uploads/prod/2020/06/Safe-Velocity-ICSE-SEI.pdf\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Research: Safe Velocity with Controlled Rollouts</a> — первичная работа о local, success и guardrail metrics при контролируемых изменениях. Её пороги и выводы нельзя автоматически переносить на другой продукт.</li></ul>"
}