Сообщить об ошибкеКороткий ответ
Единственно верного алгоритма действий нет: нужно сначала оценить, можно ли восстановить корректную оценку эффекта из доступных данных (например, пересчитать на основе менее затронутых метрик или логов), затем прозрачно сообщить стейкхолдерам о масштабе неопределённости, и параллельно решить бизнес-вопрос — стоит ли откатывать уже раскатанное изменение или проводить новый, корректный тест постфактум, взвешивая стоимость каждого варианта.
Как это работает подробнее
Как это работает: задвоение событий конверсии в одной из групп искусственно увеличивает наблюдаемую конверсию именно в затронутой группе, что могло задать ложно позитивный или завышенный эффект, на основании которого было принято решение о раскатке — важно понять, затронуло ли задвоение только логирование (метрика искажена, но продукт работал нормально) или и реальное поведение (например, баг действительно отправлял пользователю двойное действие).
План действий: 1) зафиксировать период и масштаб бага (SQL-сравнение event_count по дням до/после фикса трекинга); 2) сверить искажённую метрику с независимым источником (например, фактические платежи в биллинговой системе) за тот же период; 3) если независимая проверка недоступна — запустить короткий контрольный тест 'фича vs без фичи' на 10% трафика на 2 недели с исправленным трекингом; 4) задокументировать инцидент в журнале качества данных с итоговым пересмотренным выводом.
Что использовать на практике
- На практике: первый шаг — технический аудит: с какого момента начался баг, какую долю событий затронул, есть ли независимый источник данных (например, биллинговая система или серверные логи) для перепроверки реальной конверсии без искажения; если независимая перепроверка показывает, что эффект сохраняется и без задвоения, решение о раскатке, вероятно, оставалось бы верным, просто цифра эффекта была неточной.
Подводные камни
- Частые ошибки: попытка 'тихо' исправить задвоение в будущих отчётах без документирования инцидента и без пересмотра прошлого решения — это оставляет риск, что ошибочное решение так и не будет скорректировано, даже если новые корректные данные покажут отсутствие реального эффекта.
- Компромисс: полный откат уже раскатанной фичи дорогой организационно и может быть неоправданным, если независимая перепроверка покажет реальный положительный эффект; оставление решения без пересмотра рискует закрепить ошибочный выбор, если эффекта на самом деле не было. Практичный средний путь — провести короткий follow-up тест на части трафика (A/B фичи против её отсутствия) с исправленным трекингом, чтобы получить чистую оценку эффекта постфактум, и документировать весь инцидент для будущего аудита качества данных; выбор конкретного пути зависит от стоимости поддержки фичи и критичности метрики, на которую влияло решение.