Как A/B тест убил человека. Границы Data-Driven.

Индустрия часто делает A/B-тесты и относится к ним как к рутине: «катнём через АБ, посмотрим на метрики» 📊. Но за этими метриками стоят живые люди 👥. В этой статье я наглядно покажу, как A/B‑тесты обернулись трагедией. Чтобы в следующий раз, обсуждая новый тест, мы принимали осознанное решение: он действительно нужен и понимаем зачем.

Первая история про крупный агрегатор краткосрочной аренды жилья. Это не стерильный мир: сервис используют не только туристы, но и люди с гораздо менее мирными планами. Квартиры снимают, в том числе, под грабежи, нападения и другие преступления.

Поэтому одна из базовых задач такой платформы — заранее отсекать потенциально опасных хозяев и гостей. Чтобы защитить пользователей, партнёров и саму компанию🛡.

Платформа работает в нескольких странах 🌍, в том числе там, где уровень преступности высокий. И одна из продуктовых команд сделала понятное улучшение: обновила скоринг профилей. Не «магическая» нейросеть, а аккуратный набор признаков из внешних баз, которые помогают ловить связи и паттерны, характерные для рискованных профилей.

На уровне здравого смысла всё очевидно: старый скоринг пропускает часть опасных хозяев, новый — их отсеивает. Улучшение кажется безусловным.

И тут продакт оказывается в знакомой многим в индустрии ситуации. В конце года нужно приходить на ревью с цифрами: рост, влияние, метрики. Для смены грейда тоже нужны формальные продуктовые результаты. Плюс всегда есть риск, что бизнес придёт с вопросом:

«А вы точно не уронили GMV/конверсию этим обновлением? Докажите».

На стол ложится самый «безопасный» с точки зрения защиты решения вариант: катить через A/B, чтобы потом показать доказательную базу.

Выбирают несколько похожих городов: где-то оставляют старый скоринг (контроль), где-то включают новый (тест). Эксперимент живёт в фоне, все заняты следующими задачами.

Через пару месяцев в поддержку прилетает запрос: у клиента пропал родственник, перестал выходить на связь. Последнее, что о нём известно: он заехал в жильё, забронированное через приложение.

Дальше всё разворачивается по процедуре: запрос от органов, выгрузка данных бронирования, совместная работа с полицией. Через несколько дней приходит новость: человека нашли убитым.

На разборе всплывает ключевая деталь, которая всех цепляет: хозяин квартиры, к которому заехал погибший, проходил по старому скорингу. Новый скоринг, который уже был готов, заблокировал бы его на этапе регистрации. Город, где произошла трагедия, оказался в контрольной группе.

Формально никто не нарушал процесс. Но именно решение «давайте катнём через АБ, чтобы было что показать на ревью» стало частью цепочки, которая закончилась смертью реального человека.

Вторая история из нефтянки. Если вы когда-нибудь видели, как работает бригада на буровой, картина такая: люди стоят прямо у скважины, руками направляют подвешенные на кран трубы. Всё держится на дисциплине и на нескольких, казалось бы, простых, но критичных деталях, например на крюке, который берёт на себя сотни килограммов ⚙.

Индустрия консервативная: есть пара эталонных производителей из США, десятилетия эксплуатации, сертификация, расчёты, усталостные испытания. Все знают, почему покупают именно у них, потому что это надёжность, проверенная тысячами смен.

Но в одной стране решили принудительно попытаться перейти на отечественный товар. Нашёлся локальный производитель, выпустил партию крюков. Их поставили на несколько скважин «пилотом», отработали год, нормально. На этом месте у любого человека возникает ложное чувство безопасности: «ну раз год всё нормально, значит, можно масштабировать». Компания закупила огромную партию на все объекты и масштабировали.

А дальше началась цепочка поломок на объектах, где проводили пилот: микротрещины в сварке, усталость металла, конструктивные слабости, всё то, что нельзя увидеть невооружённым глазом, но что накапливается. На одной из смен крюк просто не выдержал. Когда падает труба весом под тонну, у людей под ней нет шансов. Произошло несколько трагедий на разных объектах. Партию отозвали в экстренном порядке, посчитали убытки, выплатили компенсации семьям погибших. И молча вернулись к эталонным поставщикам.

Это был не правильный тест. Это была эксплуатация критического оборудования без полного инженерного цикла валидации: расчёты, ускоренные циклы, независимая сертификация. На таких системах нельзя учиться только «в проде».

Я вижу перекос: компания за компанией объявляет себя Data-Driven, добавляет это в презентации, ценности и вакансии. Data-Driven пытаются впихнуть во все процессы подряд, от кнопки в онбординге до решений про безопасность людей.

При этом забывают простую вещь: A/B-тест это не цель и не идеология. Это всего лишь один из инструментов.

Да, A/B-тесты отлично работают. Но когда на кону безопасность, здоровье и жизнь людей, правильный порядок действий другой:

Сначала смысл и границы допустимого. Что мы вообще хотим проверить? Какие варианты лучше всего подходят для этого?

Потом уже метод. И далеко не всегда это A/B-тест. Иногда это оффлайновый расчёт, причинно-следственный анализ, экспертные ревью или мониторинг клиентских обращений после релиза.

Есть решения, которые являются гигиеническим минимумом. Они не тестируются «на части базы ради чистой выборки». Они просто делаются для всех. А считать эффект уже приходится другими, менее удобными, но более адекватными способами.

А как вы считаете, где, на ваш взгляд, граница: когда нужно катить изменение на всю базу сразу, а когда действительно стоит идти через A/B?

Если этот текст был полезен — поставьте огонёк 🔥, подпишитесь и загляните в другую мою статью: о том, как команда из 20 человек за полгода заработала миллиард рублей. Не теряйтесь, скоро выпущу новые интересные публикации!