Продуктовые метрики и эксперименты
Версия: 0.2
1. Позиция
Измерение поддерживает профессиональное суждение, но не заменяет его. Метрика — представление результата в определённых условиях, а не сам результат.
HIF требует цепочку:
цель человека или организации
→ наблюдаемый сигнал
→ операциональная метрика
→ правило решения
→ изменение
→ оценка ожидаемых и неожиданных эффектов
Продукт MUST NOT оптимизировать proxy, скрывая ущерб успешности задачи, доступности, доверию, безопасности или человеческой агентности.
2. Goals, signals and metrics
До выбора данных определите цель в человеческих и продуктовых терминах. Для каждой цели зафиксируйте популяцию и контекст, желательные и недопустимые результаты, опережающие и запаздывающие сигналы, определение метрики и знаменатель, источник данных, исходный уровень, неопределённость, практически значимый эффект, владельца, решение, защитные ограничения и дату пересмотра.
Метрики без связанного решения SHOULD удаляться или помечаться exploratory.
3. Измерения HEART
- Happiness — удовлетворённость, воспринимаемая лёгкость и уверенность;
- Engagement — значимая глубина или частота использования;
- Adoption — принятие целевой популяцией;
- Retention — продолжающаяся ценность в значимом интервале;
- Task success — результативность, эффективность и ошибки.
Не каждому продукту нужны все измерения. Engagement MUST NOT считаться безусловным благом: рост использования может означать трение, зависимость или невозможность завершить задачу.
4. Метрики задач
Для определённого task corpus полезны успешное завершение, завершение с помощью, time on task с учётом типа задачи и опыта, ошибки и восстановление, успех с первой попытки, отклонение пути, повторная работа, понимание последствий, калибровка уверенности и барьеры доступности по способам ввода.
Средние MUST сопровождаться распределением, размером выборки и значимыми сегментами. Быстрее не означает лучше, если уменьшается понимание или растёт риск существенной ошибки.
5. Experience и trust
Self-report SHOULD использовать валидированные инструменты, когда construct и контекст совпадают. Одна оценка удовлетворённости MUST NOT заменять удобство использования, доступность или доверие.
Доверие SHOULD разделять воспринимаемую компетентность, предсказуемость, прозрачность, контроль, correctability, ожидания приватности и justified reliance. Цель — калиброванное доверие, соответствующее реальной способности и неопределённости.
6. Операционное качество
Следите за доступностью главных journeys, latency и responsiveness по процентили, ошибки клиента, неудачные отправки, потерю данных, повторные действия, регрессии доступности, различия браузеров, устройств, языковых стандартов и ввода, темы обращений и время исправления.
Техническое здоровье — диагностический сигнал, но не доказательство успешного человеческого результата.
7. Сегментация и равенство результата
Агрегат MAY скрывать вред. Анализируйте этично обоснованные сегменты: device capability, connection quality, locale, новый или опытный пользователь, режимы доступности.
Малые выборки MUST сообщаться с неопределённостью и MUST NOT использоваться для раскрытия личности или стереотипизации. Отсутствие demographic data не доказывает равный результат.
8. Дизайн эксперимента
До контролируемого эксперимента зафиксируйте гипотезу и механизм, основной результат, защитные ограничения, единицу назначения, риск взаимного влияния, популяцию и исключения, минимальный практически значимый эффект, обоснование размера выборки и длительности, план остановки и анализа, эффект новизны и переноса, проверку доступности, конфиденциальности и безопасности.
Нельзя намеренно выдавать вариант, нарушающий установленные требования безопасности, доступности, приватности или informed choice, только ради измерения вреда.
9. Интерпретация
Statistical significance не доказывает практическую ценность, переносимость или долгосрочный эффект. Сообщайте absolute и relative effect, uncertainty, missing data, exclusions, fidelity реализации, guardrails, альтернативные объяснения и границы обобщения.
Repeated peeking, смена метрик и выборочная сегментация MUST раскрываться.
10. Триангуляция
Telemetry показывает, что произошло внутри инструментированной системы. Она редко объясняет почему, что человек пытался сделать, но не смог, или кто вообще не дошёл до продукта.
Сочетайте операционные данные с исследованием задач, интервью, оценкой доступности, доказательствами поддержки и экспертной проверкой модели. Конфликт данных — результат исследования, требующий объяснения.
11. Исходный уровень аудита и ценность исправления
До исправления клиентский аудит SHOULD зафиксировать воспроизводимый исходный уровень. Для каждого принятого результата проверки определите задачу и популяцию, исходные доказательства, механизм улучшения, acceptance criterion, measure/window, regression guardrail и residual risk.
Коммерческая ценность MUST NOT выдумываться через универсальный conversion multiplier. Финансовая оценка SHOULD раскрывать допущения и диапазон и MUST оставаться отдельно от доказанных usability- и conformance-находок.
12. Этика данных
Измерение MUST соблюдать data minimisation, purpose limitation и обоснованное retention. Нельзя обманом вовлекать людей в существенное исследование. Session replay, захват sensitive fields и cross-context tracking требуют отдельной оценки риска и законного основания.
Команда MUST документировать доступ к сырым данным и защиту личности в отчётах, записях и issue trackers.