Привет, Хабр! На связи команда A/B-платформы Купера. Время поговорить о том, как можно улучшать аналитическую инфраструктуру в бигтехе. С какими вызовами мы столкнулись, когда работали с A/B-платформой как с калькулятором? Почему выбрали перейти на светлую сторону продуктового развития? Как заслужили доверие аналитиков из десятков команд? Раскрываем все карты в статье!
A/B-платформа Купера — это кроссфункциональный продукт, который состоит из админки, автоматического подсчета результатов экспериментов и разных аналитических инструментов: дашбордов, калькуляторов и библиотек.
Каждый день через платформу проходит примерно 70 экспериментов, у нас сотни метрик и более 30 команд исследователей. Мы поддерживаем разные типы экспериментов, от онлайн-A/B до сплитования и свитчбэков.
Зачем вообще нужна A/B-платформа
Функции платформы могут варьироваться от компании к компании, но есть три основных, на которых мы предлагаем сконцентрироваться.
Минимальное необходимое требование к платформе — калькулятор. Это значит, что платформа является инструментом для запуска и расчетов экспериментов. Мы ожидаем, что она будет единой точкой входа в весь процесс экспериментирования и корректно считать то, что мы просим.
Кроме того, платформа — это драйвер A/B-культуры. Она доносит ценность экспериментирования, выстраивает процессы и обучает аналитиков.
Также платформа обеспечивает контроль за качеством экспериментов. Она помогает сделать так, чтобы можно было доверять результатам тестов, которые прошли через платформу.
Что не так с калькулятором
Наша команда пришла к выводу, что калькулятор — это лишь этап развития A/B-платформы. Такая конфигурация ведет за собой серьезные вызовы, которые можно обобщить фразой «Garbage in — Garbage out».
Конечно, калькулятор считает правильно, но это не обязательно на самом деле решает наши задачи. Мы можем получить результат, который не будет отображать эффекты от тестируемого изменения. Это повышает риск принятия некорректного решения.
Пусть у нас будет три теста для примера:
Первый тест запускается на несколько дней без подсчета MDE. Тут два варианта развития событий: 1) мы не увидим эффектов, которые планировали; 2) тест просто будет underpowered и приведет к рандомным прокрасам и завышенным оценкам.
Второй тест запускается без учета сетевого эффекта. Такой подход может привести к результатам, которые будут противоположны реальным.
Третий тест запускается без контрметрик. Мы получим корректные результаты, но они не будут раскрывать весь спектр эффектов фичи. Какая-то метрика может увеличиться, но те метрики, которые снизятся после нововведения, нам не доступны.
Такой дизайн тестов не позволяет принимать обоснованные решения. Но если контроля за дизайном нет, как верифицировать результаты?
Автоматически уловить ошибки по параметрам, которые мы видим в заполненной карточке теста, крайне затруднительно. Поэтому приходится полагаться на человеческую интерпретацию (со свойственными человеческими ошибками).
В разных командах разный уровень знаний о том, как правильно проводить эксперименты. Есть те, кто хочет быть в авангарде и поэтому стремится соответствовать всем стандартам методологии. Есть и те, кто проводит тесты скорее для галочки, не сильно погружаясь в тему, что и зачем тестируется. А кто-то вообще не проводит эксперименты, потому что не понимает их ценности. В итоге мы имеем очень много кастомизированных тестов и много недоверия к ним, а значит — и к A/B-платформе.
«Не так» что-то не с самим калькулятором, а с тем, как с инструментами взаимодействуют люди.
Дело не в тебе, калькулятор, дело во мне
Этап калькулятора в Купере шел рука об руку с культурой ограниченного вмешательства со стороны консультантов, прикрепленных к A/B-платформе. У нас много инструментов, много методологий, и экспериментаторы могли обращаться к консультантам за прояснениями. Но как принимать решение по итогу консультации — не регламентировалось. Ответственность полностью лежала на экспериментаторе.
Почему же правил не было? Во-первых, нужно не просто установить правила, а контролировать их выполнение. Но A/B-тестирование — это не вещь в себе, это часть интегрального продуктового процесса. Влияя на правила A/B, можно увеличить Time to Market или даже спровоцировать нежелание экспериментировать вообще.
Во-вторых, A/B-платформа с точки зрения организационной структуры часто находится в аналитике, она сделана аналитиками для аналитиков и оторвана от продукта и разработки. Мы знали, какие правила нужны в теории, однако не понимали, как привязать их к реалиям продуктового процесса с сотнями участников.
Качественные эксперименты невозможны без включения разных сторон, но есть ловушка: когда все ответственны за эксперименты, никто за них не ответственен.
Кто виноват — понятно. А что делать?
Когда мы в A/B-платформе осознали все эти проблемы, то решили привлечь в эксперименты продуктовую культуру.
Суть развития платформы как продукта можно описать пятью пунктами:
Позиционирование. Кто мы? Где наши границы — где A/B-платформа начинается и где заканчивается? Что в зоне нашей ответственности, а что выходит за рамки?
Стратегия. Куда и как мы хотим прийти? Этот этап включает в себя не только внешнюю, но и внутреннюю стратегию — как двигаться в сторону успешных исследований рынка и мощной экспертизы.
Метрики и целевые показатели. Как мы узнаем, что движемся в правильном направлении?
Кастдевы — общение с пользователями. Важно не просто описывать их как фич-реквесты, но и искать и решать истинные проблемы.
Взаимодействие с бизнесом. Что беспокоит бизнес-заказчиков? Где экспериментов много, а где мало? В какие процессы должна встроиться A/B-платформа и как оптимизироваться?
Только подумав над всеми этими вопросами, можно заложить крепкий фундамент для деятельности A/B-платформы.
Первая инициатива, к которой мы пришли, когда начали внедрять новое позиционирование, — это ревью экспериментов.
Сейчас эксперименты в обязательном порядке проходят ревью перед запуском на платформе. Но дополнительный этап не портит Time to Market — и это не чудо, а следствие двух сознательных шагов:
Мы отобрали для ревью экспериментов десятки опытных аналитиков. Они знают, как минимизировать затраты по времени.
Мы определили основные блокеры процесса ревью, четко распределили роли и выровняли общее понимание, что такое валидный тест.
Когда мы только начали, тесты отправлялись на доработку в среднем трижды. Сейчас выходит по две итерации правок.
Ревизия метрик
Метрики — важнейшая часть дизайна эксперимента. Если мы не уверены, что метрика валидная, то не понимаем, чем вообще замеряем эффект, и не можем напрямую переводить результаты эксперимента в предполагаемый бизнес-импакт.
Метрика валидная, если она соответствует двум критериям:
У нее валидный расчет. То есть сама формула и источники данных корректны с точки зрения аналитики.
Метрика имеет смысл для бизнеса. Бизнес-заказчик заинтересован в том, чтобы мы поставляли ему именно такие замеры и никакие другие.
Помните, в начале сказано, что у нас сотни метрик? Они были заведены аналитиками в калькулятор в крайне неупорядоченном состоянии. О многих мы не знали практически ничего. Некоторые вообще измерялись по дефолту и не несли полезной информации.
Мы провели ревизию: часть метрик удалили, часть исправили и обогатили метаинформацией (то есть обозначили место в продукте, оунеров и ответственные команды). Также мы стали определять аномальные метрики на основе исторических данных.
Последним этапом ревизии стала автоматизация. У каждой метрики появился таймер валидности, по истечении которого оунер должен валидировать метрику. Если валидации не происходит, мы удаляем метрику сначала из поиска, а потом — вообще из платформы. Для аномальных метрик мы обнуляем таймер валидности, и санкции наступают чуть позже.
Пипл-менеджмент и образовательные инициативы
Раньше мы проводили много консультаций, но они не были обязательными (вспоминаем культуру ограниченного вмешательства). В рамках продуктового подхода мы внедрили в экспериментирование подобие онбординга, чтобы выровнять стартовые позиции аналитиков.
Бывает так, что команда вообще не встречалась с экспериментами или проводила их неправильно. Такие команды требуют не просто ревью, а глубокого погружения со стороны Experimentation Partners. Это опытные аналитики, которые с помощью ресурсов платформы, помогают командам в экспериментах.
Как мы определяем результативность команды?
Во-первых, смотрим на долю успешных тестов. Если она слишком большая, это может указывать либо на махинацию с числами, либо на малое количество экспериментов, либо на то, что команда много рискует.
Во-вторых, мы смотрим на долю валидных тестов. Маркеры валидности — Sample Rate Mismatch, соответствие длительности, соответствие критериям раскатки и т. д. Но это отдельная тема.
Количество запущенных экспериментов и все эти метрики помогают нам отслеживать состояние платформы и находить команды, которым нужна дополнительная поддержка. Детекция аномальности по этим показателям — часть базовых метрик A/B-платформы.
Дополнительно мы следим за покрытием продуктов A/B-тестами. Это помогает нам понять, что в каком-то домене или в команде есть проблема с проведением экспериментов. Мы исследуем, хватает ли методологии и инструментов для тестирования, есть ли блокеры — и что можно сделать, чтобы увеличить покрытие.
Конечно, мы обращаем внимание и на время, которое команды тратят на экспериментирование. A/B-тесты — часть большого продуктового процесса, и цель платформы — следить за адекватностью Time to Market. Поэтому мы помогаем аналитикам ускорять процесс через разные автоматизации и снижение доли ручных подсчетов.
Где мы сейчас?
Прежде всего, мы (вместе со всеми нашими стейкхолдерами) наконец-то понимаем, что такое A/B-платформа и куда она движется. У нас есть единые процессы, унифицированные инструменты и методология. А самое главное — доверие к платформе значительно выросло.
Несмотря на успех, перед нами остаются вызовы, потому что становление A/B-платформы — это путь. У нас он получается таким, а у вашей компании может быть совершенно другим.
Тем не менее мы уверены, что калькулятор — не единственное возможное состояние A/B-платформы и только один из этапов ее развития. Проблемы калькулятора — отсутствие доверия и унифицированности, а решить это помогает продуктовый подход.
Делитесь в комментариях своими мыслями о том, как сделать A/B-платформу более эффективной!
Tech-команда Купера (ex СберМаркет) ведет соцсети с новостями и анонсами. Если хочешь узнать, что под капотом высоконагруженного e-commerce, следи за нами в Telegram и на YouTube.
