Как я уже неоднократно говорил, я не очень люблю ui-аналитику. Тем нагляднее кейс, который некоторое время назад случился на одном из проектов, с которыми я работаю (пример основан на реальных событиях, но не полностью).

В одном из релизов отломали всплывающее окно с предложением докупить софты. Оно появлялось, когда у пользователя не хватает софты, а он хочет что-то купить/проапгрейдить и т. д. Мест, где такое окошко всплывает, было несколько, сломалось одно из них.

Про баг qa знали, приоритет был низкий, но в какой-то момент все же поправили. А пользователи стали тратить на 20% больше софты.

Казалось бы, все отлично. Но на самом деле это весьма проблемная история. Потому что в этот момент мы планировали тест новых балансов в экономике и такое изменение ошибочно можно было приписать нашему эксперименту. Во-вторых, багофиксы обычно проходят мимо аналитиков, разработчики вообще могли в рабочем режиме молча поправить баг, а мы бы потом долго разбирались, что же произошло. И в-третьих, такие вещи очень маятно отслеживать и контролировать на лету — к релизообразующим фичам всплывающее окошко не отнесешь, да и в ченджлоге такие изменения редко расписываются подробно. Логами и дашбордами события показа ui-окон обкладывать долго и дорого, всегда есть более важные задачи.

А самое противное — не особо понятно, что можно/нужно изменить, чтобы в следующий раз верно и с минимальными затратами исключать роль ui в изменениях метрик.