В новом эпизоде подкаста Ленни Рачицкого признанный мировой эксперт по A/B-тестированию Ронни Кохави делится тактическими инсайтами из своего опыта руководства командами экспериментов в Microsoft, Amazon и Airbnb. Эксперименты часто приносят неожиданные результаты, опровергая интуицию продуктовых менеджеров и демонстрируя высокую долю неудач даже самых перспективных идей. В материале подробно разбираются механики построения надежной культуры тестирования, природа метрик и типичные ловушки интерпретации данных.
💰 Сдвиг двух строк на 100 миллионов долларов: уроки Bing 5:01
В практике проведения контролируемых экспериментов самые невзрачные идеи порой приносят колоссальные финансовые результаты. Ронни Кохави приводит в пример классический кейс из истории поисковой системы Bing. Один из сотрудников предложил изменить логику отображения рекламных объявлений: переместить вторую строку описания в первую, сделав заголовок визуально крупнее.
Эта идея месяцами находилась в бэклоге как низкоприоритетная, поскольку никто из аналитиков не ожидал от нее значимого эффекта. Однако ее реализация была тривиальной и заняла у инженера всего пару дней.
После запуска эксперимента автоматическая система мониторинга Microsoft зафиксировала критическую аномалию: графики выручки резко ушли вверх. Первой реакцией команды был поиск программной ошибки или дублирования логов, поскольку зафиксированный рост выручки составил беспрецедентные 12%.
Тщательная проверка и серия повторных запусков подтвердили: багов в коде нет. Данное микроизменение принесло компании около 100 миллионов долларов дополнительного годового дохода на тот момент, став самой успешной идей по увеличению выручки в истории Bing.
При этом защитные пользовательские метрики (guardrail metrics) не продемонстрировали статистически значимого ухудшения. Как отмечает эксперт, тривиальный сдвиг строк открыл целое направление для последующих успешных экспериментов с цветами и шрифтами ссылок.
🔄 Проблема институциональной памяти и кейс Airbnb 8:58
Ленни Рачицкий вспомнил аналогичный пример из своей работы в Airbnb, когда команда поиска решила протестировать автоматическое открытие объявлений в новой вкладке браузера при клике пользователя, вместо перехода в текущем окне. Данное решение стало одной из крупнейших побед в истории поисковой оптимизации сервиса.
Ронни Кохави раскрыл предысторию этого паттерна: аналогичный эксперимент он успешно провел в Microsoft еще в 2008 году — сначала для сервиса Hotmail в Великобритании, а затем для портала MSN. Результаты тех тестов были официально опубликованы, однако внутри индустрии данные знания со временем амортизируются.
По словам гостя, когда он пришел в Airbnb, эта механика уже применялась для страниц объявлений, но полностью игнорировалась в новых интерфейсных блоках. Кохави пришлось заново внедрять эту логику через совместную работу с аналитиками, что вновь обеспечило рост показателей.
Этот пример иллюстрирует критическую проблему утери «институциональной памяти» в технологических компаниях. Ронни Кохави рекомендует регулярно проводить квартальные встречи для разбора наиболее удивительных экспериментов и поддерживать сквозную базу знаний с возможностью поиска по ключевым словам, чтобы организация не тратила ресурсы на повторное изобретение колеса.
📊 Суровая статистика: почему 92% идей проваливаются 11:50
Вопреки распространенному ожиданию «золотых жил», реальный прогресс продукта в Big Tech складывается из сотен микроскопических улучшений. По мнению Кохави, бизнес растет «дюйм за дюймом». К примеру, в Bing сотни специалистов по релевантности работают ради того, чтобы суммарно улучшить годовую оценку поисковой выдачи всего на 2%. Этот показатель складывается из мелких побед уровня +0,1% или +0,15% в отдельных тестах.
Статистика распределения успешных и неудачных гипотез выглядит отрезвляюще для любого продуктового лидера. За время работы Ронни Кохави в Airbnb его команда провела порядка 250 экспериментов в области поисковой релевантности, обеспечив совокупный прирост выручки на 6%. При этом:
- 92% протестированных идей полностью провалились, не сумев сдвинуть целевые показатели в положительную сторону.
- Лишь 8% гипотез увенчались успешным релизом.
Подобная картина характерна для всей индустрии. На основе своего карьерного опыта Кохави приводит следующие исторические данные по доле неудачных продуктовых идей:
- В Microsoft в среднем отклоняется около 66% (две трети) всех выдвигаемых гипотез.
- В поисковой системе Bing, как в высокооптимизированной зрелой среде, доля неудач достигает 85%.
- В таких компаниях, как Booking и Google Ads, по опубликованным ими данным, отсекается от 80% до 90% идей.
Дополнительно около 10% всех создаваемых экспериментов закрываются в первый же день запуска. Как уточняет эксперт, это происходит не из-за ошибочности продуктовой логики, а по причине грубых багов реализации или проблем с логированием данных.
Чтобы снизить издержки на генерацию заведомо проигрышных интерфейсных решений, Кохави советует сверяться со специализированными агрегаторами успешных тестов, такими как ресурс goodui.org Якоба Линовского, содержащий более 140 верифицированных UX-паттернов.
Иногда эксперименты приносят крайне негативные сюрпризы из областей, которые продуктовая команда вообще не держала в фокусе. В качестве примера приводится тест новой версии индексатора Windows. В автономных оффлайн-тестах алгоритм показывал превосходную точность выдачи. Однако запуск полноценного A/B-теста показал катастрофический результат: код потреблял избыточные ресурсы CPU и мгновенно разряжал батареи ноутбуков пользователей, из-за чего проект был экстренно свернут. К 2019 году масштаб инфраструктуры Microsoft позволял запускать от 20 до 25 тысяч экспериментов ежегодно, что эквивалентно старту 100 новых вариантов интерфейса или кода каждый рабочий день.
🛑 Опасности слепого оптимизма: когда нужно закрывать проекты 22:48
Кохави категорически не согласен с практикой внедрения фич без тестирования. Он убежден, что проверять нужно абсолютно любое изменение кода. При этом продуктовый портфель должен быть сбалансирован: наряду с предсказуемыми эволюционными тестами необходимо выделять ресурсы на высокорискованные ставки с потенциально огромной отдачей. Главное — изначально смириться с тем, что крупные радикальные концепции будут проваливаться в 80% случаев.
В качестве примера масштабного провала «большой ставки» гость приводит проект интеграции поисковика Bing с социальными сетями. Компания выкупила доступ к потокам данных (firehose) Twitter и Facebook, инвестировав в разработку свыше 100 человеко-лет.
Сотни проведенных A/B-тестов на протяжении полутора лет показывали либо плоские, либо строго отрицательные результаты. Пользователи не хотели видеть социальный контент в поисковой выдаче. Несмотря на сопротивление топ-менеджера Ци Лу, верившего в стратегическую важность концепта, Кохави на цифрах доказал необходимость закрытия направления. Похожие провальные попытки построить социальные функции внутри сугубо транзакционных сервисов в свое время пережили Netflix и Airbnb.
Controlled-эксперимент выступает беспристрастным оракулом. Если данные долгосрочно указывают на отсутствие ценности для пользователя, проект обязан умереть, невзирая на авторитет его создателей и объем потраченных средств.
🎯 Разработка OEC: как не превратить оптимизацию в спам 28:12
Одной из главных ошибок начинающих команд Кохави называет неправильный выбор целевой метрики. Оптимизация системы исключительно под краткосрочную выручку неизбежно губит бизнес. Самый простой способ поднять доход любого сайта — завалить его агрессивной рекламой, но это спровоцирует отток аудитории (churn) в долгосрочной перспективе.
Решением выступает внедрение комплексного критерия OEC (Overall Evaluation Criterion — единый критерий общей оценки). Его можно сформулировать как задачу условной оптимизации: максимизировать доход при жестком ограничении на ухудшение пользовательского опыта. В Bing для этого ввели строгий «пиксельный бюджет» — лимит на вертикальное пространство выдачи, которое может занимать реклама.
Ярким примером вреда прямолинейной оптимизации служит кейс из работы Кохави в Amazon, где под его управлением находилась команда email-рекомендаций. Изначально успешность работы команды оценивалась по модели прямого атрибутирования: если пользователь кликал на рекомендацию в письме и совершал покупку, команде засчитывался доход.
Не имея сдерживающих факторов, инженеры начали лавинообразно увеличивать количество отправляемых писем, рапортуя о росте продаж, что фактически превратило сервис в инструмент спама.
Кохави кардинально изменил Fitness-функцию команды, поручив дата-сайентистам рассчитать финансовый ущерб от одной отписки пользователя от рассылки Amazon. Оказалось, что потеря возможности коммуницировать с клиентом обходится долгосрочной ценности (LTV) компании в несколько долларов.
Когда стоимость отписок внесли в формулу OEC как вычитаемое, выяснилось, что более половины запущенных email-кампаний на самом деле были глубоко убыточными для бизнеса. Это открытие заставило Amazon перестроить систему и внедрить точечную отписку от конкретных типов писем вместо полной блокировки рассылок.
В сфере бронирования жилья и отелей (включая Airbnb) грамотный OEC должен базироваться на Lifetime Value клиента. Нельзя оценивать успех интерфейса только по факту совершения транзакции. Необходимо строить прогнозные модели, предсказывающие, останется ли пользователь доволен поездкой через 3 месяца, когда физически заселится в объект, и какую оценку он выставит в отзыве.
📐 Масштаб для стартапов и ловушка редизайнов 24:57
Метод A/B-тестирования подходит далеко не всем. Существуют жесткие инфраструктурные ограничения:
- Инструмент неприменим для единичных событий, таких как сделки слияния и поглощения (M&A).
- Для проведения тестов критически важно иметь достаточный объем выборки.
Кохави выводит эмпирическое правило для молодых компаний: если у вашего сервиса нет хотя бы десятков тысяч пользователей, математическая статистика просто не позволит зафиксировать изменения стандартных продуктовых метрик.
Для классического интернет-магазина, желающего надежно улавливать улучшения конверсии на уровне 5%, требуется стабильная посещаемость не менее 200 000 уникальных пользователей. Стартапам на ранних стадиях не стоит тратить ресурсы на поиск однопроцентных сдвигов; им нужно целиться в крупные изменения и параллельно закладывать техническую базу под будущую платформу тестов.
Отдельно эксперт предостерегает от проведения масштабных комплексных редизайнов интерфейса. Исторически такие проекты практически всегда демонстрируют резко негативные результаты в тестах.
Когда команда тратит полгода на полную переработку дизайна, включающую десятки изменений, и видит падение метрик, она часто попадает в ловушку невозвратных затрат (sunk cost fallacy) и все равно выпускает продукт, нанося вред бизнесу.
Кохави настаивает на методологии O-FAT (One Factor At A Time — один фактор за раз). Масштабное видение нужно декомпозировать на мелкие элементы и тестировать их последовательно. Только так можно вычленить те 4 удачные идеи из 17, которые действительно принесут пользу.
Внедрение этой логики в консервативную корпоративную среду всегда наталкивается на сопротивление. Вспоминая свой переход из Amazon в Microsoft, Кохави столкнулся с открытым высокомерием со стороны местных продуктовых менеджеров. На его предложение построить платформу тестирования, поскольку половина идей в Amazon отсеивается, менеджеры заявили: «У нас в Microsoft PM-ы гораздо лучше, наши планы идеальны».
В то время цикл разработки пакета Office составлял 3 года, и гипотезы никто не проверял на реальном трафике. Переломить ситуацию и доказать полезность тестов удалось только благодаря жесткой административной поддержке со стороны Сатьи Наделлы и Ци Лу. Кохави подчеркивает: если тест показывает плоский, статистически незначимый результат, фичу нельзя выпускать, так как она усложняет кодовую базу и увеличивает стоимость поддержки ИТ-системы.
🧪 Кризис доверия к платформам: кейс Optimizely и ловушка p-value 51:54
Доверие к результатам тестов — фундамент экспериментов. Если платформа выдает недостоверные данные, организация быстро разочаровывается в методе. Книга Ронни Кохави «Trustworthy Online Controlled Experiments», разошедшаяся тиражом более 20 тысяч копий и переведенная на русский язык, детально разбирает этот аспект (при этом все доходы от продаж автор полностью направляет на благотворительность).
В качестве примера подрыва доверия Кохави приводит ранний этап развития популярного коммерческого инструмента Optimizely. В погоне за маркетинговой привлекательностью создатели сервиса заявляли о возможности отслеживать p-value экспериментов в реальном времени. С точки зрения математической статистики это грубейшая ошибка: регулярный заглядывание в промежуточные результаты (peeking) раздувает ошибку первого рода (false positive rate) с задекларированных 5% до внушительных 30%.
Бизнес видел в панели Optimizely зеленую галочку «успех», но по факту реальная выручка в банке не росла. Ситуация стала настолько скандальной, что в сети завирусилась статья инженера под заголовком «Как Optimizely чуть не уволил меня», где автор поймал платформу на выдаче значимых результатов при запуске А/А-теста (теста системы против самой себя, где разницы между группами нет). Позже компания привлекла профессора Стэнфорда Рамеша Джохари, который полностью переписал статистическое ядро сервиса, ликвидировав уязвимость.
Главным индикатором сломанного эксперимента Кохави называет нарушение пропорции распределения выборки (Sample Ratio Mismatch, или SRM). Если система настроена делить трафик строго 50 на 50, а на выходе аналитик видит соотношение 50,2% на 49,8% при выборке в миллион пользователей, это повод бить тревогу. Вероятность случайного возникновения такого перекоса ничтожно мала. Это явный маркер технического сбоя.
Даже в зрелой инфраструктуре Microsoft около 8% всех тестов регулярно страдали от SRM из-за некорректной фильтрации ботов или зависания пайплайнов данных. Менеджеры часто игнорировали предупреждающие текстовые баннеры, стремясь поскорее отчитаться об успехе, поэтому разработчикам платформы пришлось полностью блокировать отображение цифр на дашбордах и подсвечивать весь экран предупреждающим красным цветом, пока SRM не будет устранен.
Здесь вступает в силу Закон Тваймена (Twyman's Law): любой показатель, который выглядит слишком интересным или необычным, чаще всего является простой ошибкой в данных. В 90% случаев внезапный взрывной рост метрики на 10% свидетельствует о баге, а не о гениальности продуктового решения.
📉 Что на самом деле означает p-value и как ускорить тесты 1:02:17
Ронни Кохави указывает на повсеместное непонимание академического термина p-value в бизнес-среде. Большинство менеджеров ошибочно полагают, что если p-value равен 0.02, то существует 98%-ная вероятность того, что вариант B лучше варианта A.
На самом деле p-value — это условная вероятность получить такие или еще более экстремальные данные при условии, что изначально верна нулевая гипотеза (то есть изменений нет). Чтобы ответить на реальный вопрос бизнеса о вероятности успеха, необходимо использовать теорему Байеса и знать априорную (prior) вероятность удачности идеи.
Если применить эти расчеты к жестким реалиям поиска Airbnb, где историческая базовая вероятность успеха идей составляет всего 8%, то при получении стандартного p-value на уровне 0.05 реальный риск ложноположительного результата (False Positive Risk) составит колоссальные 26%. Четверть всех «успешных» фич при таком подходе будут фикцией. Из-за этого в Airbnb была введена практика: если p-value находится в пограничной зоне от 0.01 до 0.05, тест отправляется на обязательную повторную репликацию, а результаты затем объединяются статистическими методами Фишера или Стоуффера.
Для сокращения длительности экспериментов без потери точности эксперт выделяет три ключевых метода:
- Автоматизация аналитики: Сведение к нулю времени ожидания отчета. Скоркард должен рассчитываться платформой сразу по завершении теста без привлечения дефицитных дата-сайентистов.
- Ограничение выбросов (Capping): Искусственное усечение аномальных всплесков данных, искажающих средние значения. В Airbnb метрику забронированных ночей жестко ограничивают сверху (например, не более 30 ночей на аккаунт в месяц), чтобы отсечь оптовые бронирования со стороны туристических агентств, которые вносят огромную дисперсию в статистику.
- Применение метода CUPED: Использование исторических данных о поведении пользователей до начала эксперимента для корректировки текущих результатов, что позволяет резко снизить дисперсию и проводить тесты на меньшем объеме трафика.
⚡ Блиц-раунд: от Чернобыля до борьбы со скунсами 1:14:23
В финальной части подкаста Ронни Кохави ответил на серию личных и технических вопросов Ленни Рачицкого. В качестве главных книжных рекомендаций для развития критического мышления гость выделил три работы:
- «Calling Bullshit» (Карл Бергстром, Джевин Вест) — манифест против манипуляций с данными;
- «Hard Facts, Dangerous Half-Truths and Total Nonsense» (Джеффри Пфеффер, Роберт Саттон) — разбор устоявшихся бизнес-заблуждений;
- «Mistakes Were Made (But Not by Me)» (Кэрол Тэврис, Эллиот Аронсон) — исследование механизмов человеческого самооправдания.
Среди недавних впечатлений Кохави отметил мини-сериал «Чернобыль» от HBO, похвалив его за демонстрацию роли ученых, хотя образ ключевой героини и был собирательным отражением работы 30 реальных советских физиков.
Ведущий Ленни Рачицкий поделился личным фактом: он родился в украинской Одессе, и в день аварии его отец был мобилизован на работы по очистке городских деревьев от радиоактивной золы, прилетевшей со стороны взрыва.
При проведении технических интервью с инженерами на позиции C++ разработчиков любимым вопросом Кохави остается просьба объяснить работу спецификатора static для переменных и функций. По его наблюдениям, более половины кандидатов дают на этот вопрос совершенно неверный ответ.
Из потребительских гаджетов эксперт выделил беспроводные камеры Blink, работающие по полгода от двух батареек АА. С их помощью Кохави удалось решить бытовую проблему: вычислить скрытую лазейку внизу забора, через которую на его участок пробирался скунс. Камеры также зафиксировали забавный инцидент с ложным срабатыванием сигнализации, когда в дом с обнаженным оружием ворвался наряд полиции.
В качестве самого эффективного управленческого решения Кохави назвал заимствованный им из Amazon полный запрет на использование презентаций PowerPoint на совещаниях. Все обсуждения продуктовых фич должны начинаться в тишине с чтения структурированного 6-страничного текстового нарратива, в котором четко прописаны ответы на ключевые вопросы к проекту.
В повседневной жизни гость призывает всех руководствоваться концепцией «иерархии доказательств» (hierarchy of evidence). Любые анекдотичные свидетельства и простые наблюдательные исследования из новостей заслуживают минимального доверия, уступая место контролируемым научным экспериментам.
