Experiment Insights UI — визуализация репортов

8.1 Цель

Контроль качества данных нужен для того, чтобы экспериментам доверяли. Без него любой отчёт превращается в “верю/не верю”. Команде нужно быстро понять, что происходит с экспериментом: есть ли эффект, нет ли деградации, достаточно ли данных, когда и почему всё изменилось.

UI/дашборды должны:

• ускорять принятие решений (rollout / rollback / продолжать);
• помогать в расследованиях (почему метрика “поехала”);
• снижать риск неправильных выводов за счёт контекста и “здоровья данных”.

8.2 Качество данных эксперимента

В истории: если продукт вдруг перестал слать события факта показа или события приходят с дырками, продакт должен увидеть это сразу, иначе он сделает неправильный вывод. Чтобы не принимать решение по “битым” данным, UI должен отображать:

• долю отклонённых событий и причины (топ причин);
• долю дубликатов;
• долю событий конверсии/ошибок/задержки, которые временно не дождались экспозиции (или наоборот — степень полноты атрибуции);
• задержку доставки событий — если собирается;
• перекос трафика: фактическое распределение показов по вариантам против ожидаемого по весам (как предупреждение).

8.3 Сегментация и разрезы

В истории: общий эффект может быть ноль, но на “новичках” плюс, а на “старичках” минус. Разрезы — способ не пропустить такие штуки. В отчёте должна быть возможность быстро переключать разрезы:

• по стране, версии приложения, платформе, экрану (из атрибутов события) и другим важным признакам.

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

8.4 Экспорт и шаринг

В истории: продакт идёт на демо/встречу и кидает ссылку на отчёт — чтобы не пересылать скрины и не спорить “у меня другое число”.

• Экспорт графиков/таблицы (CSV / изображение / ссылка на диапазон времени).
• Постоянная ссылка на эксперимент с выбранным окном и метрикой (для обсуждения в чатах/тикетах).