Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Зачастую каждый эксперимент требовал дизайна и печати нового тиража, рассылки тысяч предложений, ждать ответов приходилось неделями. Каждая попытка обычно обходилась в десятки тысяч долларов и занимала несколько недель или месяцев. Однако, несмотря на все расходы, такое повторяющееся тестирование вполне окупалось, если оно значительно увеличивало показатель конверсии (например, если процент заказавших продукт покупателей увеличивался с 3 до 12 %).

Хорошо задокументированные примеры A/B-тестирования включают в себя сбор средств, интернет-маркетинг и методологию бережливого стартапа. Интересно, что эта методика также использовалась британским правительством для определения того, с помощью каких писем эффективнее всего было собирать просроченные налоги с задерживающих платежи граждан[134].

Интегрирование A/B-тестирования в тестирование компонентов функциональности

Самая распространенная методика A/B-тестирования в современной практике взаимодействия с пользователем — сайт. На нем посетителям показывается одна из двух страниц, контрольная («А») и альтернативная («B»), выбранная случайным образом. На основе статистического анализа делаются выводы о значимости различий в поведении двух групп пользователей. После этого мы можем установить причинно-следственную связь между внесенным изменением (например, в функциональных возможностях, элементах дизайна, цветах фона) и последствиями (например, коэффициентом конверсии, средним размером заказа).

К примеру, можно провести такой эксперимент: проверить, увеличивает ли доход изменение цвета кнопки «купить». Или замерить, уменьшает ли выручку рост времени ответа сайта (с помощью искусственного замедления его работы). Такой тип A/B-тестирования позволит нам оценить улучшение работоспособности сайта в денежном выражении.

A/B-тесты также известны под такими названиями, как «онлайн-эксперименты в контролируемых условиях» или «сплит-тесты». Эксперименты можно проводить и с несколькими переменными. Благодаря этому мы сможем наблюдать их взаимодействие. Такая методика называется многомерным тестированием.

Результаты A/B-тестирования часто просто поразительны. Ронни Кохави, выдающийся инженер и директор отдела анализа и проведения экспериментов компании Microsoft, заметил: после «оценки тщательно продуманных и поставленных экспериментов, проведенных с целью улучшить какой-либо ключевой показатель, выяснилось, что только одна треть действительно помогла улучшить этот показатель!». Другими словами, воздействие двух третей новых компонентов функциональности было либо незначительным, либо вовсе отрицательным. Кохави отмечает, что все эти новшества казались хорошими и обоснованными идеями, что еще раз подчеркивает преимущество пользовательского тестирования перед интуицией и экспертными оценками.

Выводы из данных Кохави ошеломляют. Если мы не исследуем поведение пользователей, вероятность того, что разрабатываемая нами функциональность бесполезна или наносит вред компании, равна двум третям. И это не считая того, что сам код усложняется, увеличиваются затраты на его поддержку, а вносить изменения становится все труднее. Кроме того, усилия, затраченные на создание таких элементов функциональности, могли бы быть потрачены на что-то действительно полезное (то есть это альтернативные издержки). Джез Хамбл в связи с этим пошутил: «Если довести эту мысль до крайности, то компании и заказчикам было бы выгоднее отправить всю команду в отпуск, чтобы она не занималась разработкой бесполезных компонентов».

Лекарство от этого — интеграция A/B-тестирования в проектирование, разработку, тестирование и развертывание элементов функциональности. Осмысленное исследование поведения пользователя и постановка экспериментов помогут нам достичь намеченных целей и занять прочные позиции на рынке ПО.

Интегрируйте A/B-тестирование в релизы

Быстрое и многократное A/B-тестирование возможно в том случае, если мы можем быстро и без усилий развертывать наш код, используя переключатели функциональности для отключения ненужных компонентов и отправляя в эксплуатацию несколько версий кода одновременно для разных сегментов заказчиков. Для этого нужна полезная телеметрия на всех уровнях стека приложения.

С помощью переключателей мы можем контролировать процент пользователей, участвующих в эксперименте. Например, пусть одна половина будет контрольной группой, а другая будет видеть следующее предложение: «Заменить в вашей корзине товары, в данный момент отсутствующие, на похожие». Мы будем сравнивать поведение экспериментальной группы (видящей предложение) и контрольной (не видящей), измеряя, например, количество покупок за одну сессию.