{
  "index": 88,
  "slug": "editorial-2025-07-field-product-metrics",
  "title": "Когда рост conversion не означает улучшение продукта",
  "excerpt": "Полевой разбор ситуации, в которой conversion выросла, а обращения в поддержку удвоились: как сверить cohort, качество результата и guardrail до решения о раскатке.",
  "contentHtml": "<p>На дашборде новая форма показывает conversion 75% против 50% у прежнего варианта. Команда готовит раскатку, но через сутки поддержка сообщает: обращений стало вдвое больше. Пользователи подтверждают действие, а затем спрашивают, прошло ли оно, повторяют попытку или присылают скриншот ошибки. Рост первой цифры не отвечает на вопрос, стал ли продукт полезнее.</p>\n<p>Цена ошибки здесь практическая. Раскатка может увеличить число повторных операций, ручных разборов и недоверия к результату. Если откатить интерфейс сразу, можно потерять уже собранный сигнал; если оставить как есть, можно расширить ущерб. Разбор начинается не с поиска «плохой» команды, а с восстановления цепочки: кто увидел вариант, какое действие совершил, какой результат получил и почему после результата обратился за помощью.</p>\n<p>Ниже — учебный полевой сценарий, а не отчёт о production-эксперименте. Его задача — дать инженеру воспроизводимый порядок проверки. Главный вывод ограничен: conversion можно считать локальным успехом только вместе с качеством результата и guardrail, который показывает побочную цену. Эти показатели не заменяют интервью, анализ причин обращений и проверку статистической надёжности.</p>\n<h2>Симптом: красивая дробь и плохой следующий шаг</h2>\n<p>Сначала зафиксируйте наблюдаемые факты в одном окне времени. Для варианта <code>treatment</code> запишите число открывших форму, число подтверждений, число ошибок и число обращений в поддержку. Не смешивайте событие «кнопка нажата» с подтверждённым результатом. У обращения тоже должно быть определение: например, созданный тикет с категорией «результат неизвестен», а не любое сообщение в чате.</p>\n<p>Проблема может находиться в разных слоях. Пользователь мог не увидеть итоговый статус. Клиент мог отправить повторный запрос после timeout. Событие conversion могло отправиться до ответа сервера. Поддержка могла изменить тег обращения, и тогда выросла не проблема, а полнота классификации. Одна и та же картина на графике допускает несколько причин, поэтому первым действием должен быть разрез по варианту, устройству, версии клиента, времени и типу результата.</p>\n<figure><img src=\"/assets/editorial/2025/product-metrics-2025-causal-funnel.svg\" alt=\"Воронка product metric: изменение формы, уникальное открытие, подтверждение той же операции, ручная проверка и отдельный guardrail render_failed среди открывших\" loading=\"lazy\" /><figcaption>Asset показывает цепочку от изменения до human review и отдельно считает render_failed среди opened. Обращения в поддержку остаются дополнительным сигналом, который нужно связать с этой цепочкой.</figcaption></figure>\n<h2>Механизм: локальная метрика не равна результату</h2>\n<p>Удобно разделить измерение на три роли. <strong>Success metric</strong> отвечает на вопрос, улучшилось ли целевое действие. <strong>Diagnostic metric</strong> помогает понять, за счёт какого шага изменилось значение: например, выросло число открытий или завершений. <strong>Guardrail</strong> — защитный показатель: его не обязуются улучшать, но нельзя существенно ухудшить ради success metric.</p>\n<p>В нашем сценарии conversion — это доля субъектов, которые после открытия формы получили подтверждённый результат. Guardrail — доля открывших, создавших обращение в поддержку в течение согласованного окна. Это не универсальное определение: для финансовой операции полезнее дополнительно считать дубли, отмены, возвраты и фактически завершённые операции на стороне сервера. Владелец продукта должен заранее определить, какой ущерб запрещает раскатку.</p>\n<p>Техническая граница важна. Событие <code>checkout_confirmed</code> говорит, что клиент отправил телеметрию с таким именем. Оно не доказывает, что сервер принял операцию, пользователь понял результат или деньги действительно списались. Для сильного вывода свяжите клиентское событие с идентификатором операции и серверным состоянием, не раскрывая в аналитике платёжные секреты.</p>\n<h2>Контракт данных до чтения графика</h2>\n<p>Перед сравнением зафиксируйте единицу анализа. Это может быть пользователь, сессия, заявка или операция; менять единицу между вариантами нельзя. Затем запишите <code>cohort</code>, время экспозиции, версию клиента, вариант, идентификатор попытки и outcome. Если один пользователь нажал кнопку пять раз, число событий и число пользователей отвечают на разные вопросы.</p>\n<p>Имена событий должны быть стабильными, а изменяющиеся сведения — параметрами. Это согласуется с документацией Google Analytics: параметры добавляют контекст к событию, но пользовательский интерфейс аналитики сможет показывать произвольные параметры в отчётах только после их регистрации как custom dimensions или metrics. Поэтому «параметр отправляется» и «параметр пригоден для отчёта» — разные проверки.</p>\n<pre><code>const event = {\n  name: 'checkout_result',\n  params: {\n    variant: 'treatment',\n    operation_id: 'demo-op-17',\n    outcome: 'confirmed',\n    result_visible: true,\n    support_reason: null,\n  },\n};\n\n// Учебный контракт: один объект описывает одну попытку.\n// Реальная схема должна отдельно определить privacy, retention и owner.</code></pre>\n<p>Поле <code>result_visible</code> не следует считать доказательством само по себе: это сигнал клиента. Его полезность появляется только после проверки на реальном интерфейсе и сопоставления с серверным outcome. <code>support_reason</code> заполняется только для обращения и не должен принимать произвольный текст, если он попадёт в агрегаты. Для свободного текста нужны отдельные правила доступа и удаления чувствительных данных.</p>\n<h2>Воспроизводимый расчёт на фиксированных данных</h2>\n<p>Ниже приведён маленький набор для проверки логики. В control четыре открытия и два подтверждённых результата; в treatment — четыре открытия и три подтверждённых результата. Одновременно два человека из treatment создали обращение, а в control — одно. Числа специально простые: они показывают расхождение сигналов, а не размер эффекта и не качество настоящего продукта.</p>\n<pre><code>const rows = [\n  { variant: 'control', result: 'confirmed', support: false },\n  { variant: 'control', result: 'confirmed', support: false },\n  { variant: 'control', result: 'failed', support: true },\n  { variant: 'control', result: 'failed', support: false },\n  { variant: 'treatment', result: 'confirmed', support: false },\n  { variant: 'treatment', result: 'confirmed', support: true },\n  { variant: 'treatment', result: 'confirmed', support: true },\n  { variant: 'treatment', result: 'failed', support: false },\n];\n\nfunction summarize(variant) {\n  const sample = rows.filter((row) =&gt; row.variant === variant);\n  const confirmed = sample.filter((row) =&gt; row.result === 'confirmed').length;\n  const contacts = sample.filter((row) =&gt; row.support).length;\n  return {\n    variant,\n    conversion: confirmed / sample.length,\n    supportRate: contacts / sample.length,\n    confirmed,\n    contacts,\n    exposed: sample.length,\n  };\n}\n\nconsole.table([summarize('control'), summarize('treatment')]);</code></pre>\n<p>Ожидаемый результат: control имеет conversion <code>0.5</code> и supportRate <code>0.25</code>; treatment — <code>0.75</code> и <code>0.5</code>. В учебном наборе локальная метрика выросла, а guardrail ухудшился вдвое. Это основание остановить решение и исследовать причины, но не доказательство того, что именно новый интерфейс вызвал обращения: выборка мала, рандомизация и длительность не описаны, а связь с серверным outcome отсутствует.</p>\n<p>Запустите пример так: сохраните блок в файл <code>metric-demo.mjs</code>, затем выполните <code>node metric-demo.mjs</code>. Такой запуск проверяет арифметику и не обращается к сети. В рабочем проекте сначала воспроизведите тот же расчёт на выгрузке с известной схемой, затем сравните период, единицу анализа, задержку доставки и правила дедупликации.</p>\n<h2>Разбор расхождения по диагностическим срезам</h2>\n<p>После такого отрицательного сигнала не меняйте сразу код и не объявляйте виноватым канал поддержки. Разделите путь по этапам: показ варианта, успешный запрос, подтверждённый сервером outcome, видимость статуса и обращение. На каждом переходе оставьте числитель, знаменатель и число записей с неизвестным состоянием. Запись «неизвестно» лучше, чем молчаливое исключение: иначе conversion может расти за счёт пропавших ошибок.</p>\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 выросла, supportRate выросла</td><td>Сверить operation_id, outcome и категорию тикета</td><td>Пользователь видит успех клиента, но не видит подтверждённый итог</td><td>Остановить раскатку; проверить статус и серверный ответ</td></tr><tr><td>Подтверждений больше, операций меньше</td><td>Сопоставить клиентские события с серверным журналом</td><td>Событие отправляется до завершения операции или дублируется</td><td>Разделить client outcome и server outcome; исправить контракт</td></tr><tr><td>Обращения выросли только на одной версии</td><td>Срезать вариант по версии, устройству и времени</td><td>Регрессия рендера, timeout или несовместимый ответ</td><td>Ограничить scope, собрать trace и повторить проверку</td></tr><tr><td>SupportRate выросла после новой классификации</td><td>Сравнить правила тегирования до и после изменения</td><td>Изменилась полнота учёта, а не поведение пользователей</td><td>Разделить process metric и product metric</td></tr><tr><td>Неизвестный outcome исключён из расчёта</td><td>Посчитать unknown отдельно и проверить долю потерь</td><td>Пайплайн скрывает задержанные или невалидные события</td><td>Не принимать решение, пока data quality не восстановлена</td></tr></tbody></table></div>\n<p>Срез не должен превращаться в бесконечный перебор. Сначала проверьте ветки с наибольшей ценой ошибки: неизвестный результат, повторную операцию и один конкретный релиз. Зафиксируйте каждую гипотезу рядом с запросом и ожидаемым наблюдением. Если один запрос не различает две причины, добавьте минимальное поле или ручную проверку, а не делайте более сложную агрегацию.</p>\n<h2>Что сделать после остановки раскатки</h2>\n<p>Остановка — это изменение решения, а не диагноз. Сохраните snapshot метрик до отката, текущие значения и область воздействия. Затем выберите самый узкий обратимый шаг: уменьшить долю treatment, выключить флаг или вернуть прежний экран. Не удаляйте события и не перезаписывайте старые определения, иначе после исправления будет невозможно сравнить до и после.</p>\n<ol><li><strong>Зафиксировать симптом.</strong> Записать период, варианты, единицу анализа, conversion, supportRate, unknown и версию клиента.</li><li><strong>Проверить связность.</strong> Убедиться, что события относятся к одной экспозиции, операции и cohort; неизвестные связи не приписывать вручную.</li><li><strong>Поставить guardrail.</strong> Назвать показатель ущерба, порог остановки, окно наблюдения и владельца решения.</li><li><strong>Разделить уровни результата.</strong> Сопоставить событие клиента с серверным состоянием, а обращение — с устойчивой категорией причины.</li><li><strong>Выполнить узкое изменение.</strong> Ограничить вариант или вернуть флаг, затем проверить теми же запросами до и после.</li><li><strong>Повторить на малом scope.</strong> Возобновлять rollout можно только после проверки причины, отрицательного пути и качества данных.</li></ol>\n<p>После исправления полезно оставить автоматическую проверку схемы: обязательные поля, допустимые значения, долю unknown и отсутствие события без идентификатора операции. Она не подтверждает продуктовую пользу, но не даст незаметно сломать входные данные. Для технических метрик OpenTelemetry рекомендует единообразные имена и атрибуты, а также осмысленность агрегации по атрибутам; это хороший ориентир для собственного контракта, но не готовая схема conversion.</p>\n<h2>Ограничения применимости</h2>\n<p>Этот метод не превращает наблюдательный сигнал в причинный вывод. Для утверждения «вариант вызвал изменение» нужны корректная рандомизация или другой дизайн, заранее определённое окно, достаточный объём и статистический анализ. Даже A/B-тест может быть испорчен потерей данных, sample ratio mismatch, повторным попаданием субъекта в разные группы или изменением продукта во время теста.</p>\n<p>SupportRate тоже не универсальный guardrail. Обращение зависит от доступности поддержки, формулировки интерфейса, сезонности и правил классификации. Иногда рост обращений означает, что пользователи стали лучше находить канал помощи; иногда одна авария создаёт много тикетов от одного пользователя. Поэтому определите единицу счёта, deduplication, допустимое окно и причины исключения до сравнения.</p>\n<p>Пример с восемью строками нельзя использовать для оценки реального эффекта, принятия финансового решения или настройки порога. Он не содержит персональных данных, сети, авторизации, задержки телеметрии и настоящего server outcome. Порог «удвоение» в сценарии — условие учебного кейса, а не рекомендация для всех продуктов. В рабочей системе согласуйте пороги с риском операции, владельцем продукта, аналитиком и поддержкой.</p>\n<h2>Критерий готовности решения</h2>\n<p>Решение готово к следующему кольцу раскатки, если другой инженер без устного объяснения может восстановить: кто входит в population, что считается exposure, как вычисляются numerator и denominator, какой outcome подтверждает успех, что такое support contact, где находятся неизвестные записи и при каком сигнале нужно остановиться.</p>\n<p>Минимальная проверка даёт два результата. На фиксированных данных расчёт возвращает control 0.5/0.25 и treatment 0.75/0.5. На данных с отсутствующим <code>operation_id</code>, неизвестным outcome или смешанным вариантом расчёт не делает вид, что всё корректно: он возвращает ошибку качества или отдельную категорию <code>unknown</code>. Только после этого команда обсуждает причинность, стоимость поддержки и дальнейшую раскатку.</p>\n<h2>Проверяемые источники</h2>\n<ul><li><a href=\"https://developers.google.com/analytics/devguides/collection/ga4/event-parameters\" target=\"_blank\" rel=\"noopener noreferrer\">Google Analytics for Developers: Set up event parameters</a> — официальная документация о параметрах событий, регистрации custom dimensions и проверке через Realtime и DebugView. Она не определяет, что именно считать conversion в вашем продукте.</li><li><a href=\"https://developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events\" target=\"_blank\" rel=\"noopener noreferrer\">Google Analytics for Developers: Events reference</a> — официальные правила для имён и параметров событий Measurement Protocol, включая ограничения имён. Эти правила не гарантируют полноту вашей телеметрии.</li><li><a href=\"https://opentelemetry.io/docs/specs/semconv/general/metrics/\" target=\"_blank\" rel=\"noopener noreferrer\">OpenTelemetry: Metrics semantic conventions</a> — спецификация о единицах, типах инструментов, именовании и согласованных атрибутах метрик. Она задаёт технические ориентиры, но не заменяет продуктовую definition.</li><li><a href=\"https://www.microsoft.com/en-us/research/articles/a-b-testing-infrastructure-changes-at-microsoft-exp/\" target=\"_blank\" rel=\"noopener noreferrer\">Microsoft Research: A/B Testing Infrastructure Changes at Microsoft ExP</a> — первичный материал о guardrail-метриках и проверке телеметрии при controlled rollout. Практики Microsoft нельзя переносить без адаптации к трафику, риску и данным конкретного продукта.</li></ul>\n<p>Зафиксированная дробь помогает увидеть сигнал. Решение принимает команда, которая проверила цепочку до результата и назвала цену ошибки.</p>"
}