Как мы запустили платформу для А/Б-тестирования на 20 000 офлайн-магазинов

Теперь мы знаем, как можно делать сложные расчёты и при этом экономить до двух недель на один А/B-тест. На примере разработанной нами Платформы А/Б-тестирования покажу, как достичь успеха при создании B2B-продукта, основанного на сложной математике.

X5 Group включает в себя 20 000+ офлайн-магазинов. Самые крупные сети – это “Пятёрочка” и “Перекрёсток”. Даже такой бизнес, как продуктовый ритейл, должен постоянно меняться, чтобы улучшать позиции на рынке. Идей того, что можно изменить в магазинах, очень много, и нужен надёжный способ проверки их эффективности. Стандартом в компании является А/Б-тест.

А/Б-тест – воплощение рандомизированного контролируемого исследования, самого надёжного способа интерпретировать причинно-следственные связи. Суть исследования заключается в том, что мы оказываем воздействие на одну группу объектов (Б) и не оказываем никакого воздействия на похожую группу объектов (А) в течение определённого времени. По прошествию которого сравниваем показатели групп А и Б и делаем вывод о том, как повлияло наше воздействие.

С помощью А/Б-тестов подтверждают свои гипотезы как фармакологические компании, проводя исследования новых препаратов, так и ИТ-гиганты, выпуская новые фичи в продуктах.

X5 Group проводит А/Б-тесты на магазинах для проверки своих гипотез. Например, таких:

• Как изменится розничный товарооборот категорий товаров, если в прикассовой зоне заменить шоколадные батончики на ореховые смеси?
• Как повлияет изменение графика работы сотрудников на списания?
• Как установка постаматов повлияет на трафик в магазинах?

Чтобы проверить гипотезу, необходимо провести эксперимент в три этапа:

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

Традиционно для работы над такими экспериментами подключалась команда ad-hoc аналитики. Ребята делали дизайн А/Б-теста и оценку его результатов вручную. Общались с представителями бизнеса, выгружали данные о магазинах, писали с нуля код на Python, выбирали лучший алгоритм для статистических расчётов и делали много дополнительной работы. Все участники команды ad-hoc аналитики – это серьёзные специалисты в области мат. статистики и анализа данных.

Подход требует большого количества человеческих ресурсов. Это влияет на скорость и стоимость. На ручную обработку одного эксперимента (дизайн + оценка) может уходить до 2,5 недель без учёта ожидания задачи в очереди. Поэтому было принято решение искать пути автоматизации.

Сначала написали библиотеку, которая ускоряла работу аналитиков. Потом перешли к идее self-service продукта, в котором пользователь может ввести критичные для расчётов данные самостоятельно, и получить результат. Под результатом мы понимаем готовый дизайн или отчёт с оценкой результатов.

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

На первый взгляд, кажется, что подводных камней тут много. Так и вышло. Чтобы получить MVP, дающий бизнес-результат, ушло больше года.

Чаще всего вы слышите об А/Б-тестировании в контексте web или mobile-продуктов. Так проверяют, влияют ли изменения, например, новые рекламные баннеры, на процент конверсии, CTR, время на странице и т. п.

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

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

Получается, при создании нашего продукта мы не могли опираться на большой опыт индустрии, поэтому многое приходилось изобретать самим.

1. Гибкие методологии

Естественно, мы использовали agile-практики. Мы работали и работаем по Scrum. Да, это дорого, но, когда ты на старте не знаешь, где должен оказаться в конце, выбор не очень большой. Приходится двигаться маленькими итерациями.

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

Аналитики ad-hoc и Платформа А/Б-тестирования работают немного по-разному и обрабатывают разные кейсы. А постоянная синхронизация методологии занимает много времени.

В итоге мы решили, что у двух библиотек слишком много общего, и продукт начал использовать ту же расчётную библиотеку, что и аналитики для ручного анализа. Сейчас такое решение кажется очевидным, но на первом этапе независимая работа выглядела вполне оправданной.

Также мы меняли подход к бизнес-процессу в разных MVP. Например, естественной кажется мысль, что раз один эксперимент состоит из дизайна, проведения и оценки, то и на Платформе это должна быть одна сущность, которая имеет три разных состояния. На практике всё работает несколько иначе.

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

Во-вторых, на этапе дизайна много идей могут быть откинуты, например, из-за стоимости оборудования эксперимента. Поэтому мы разделили сущности дизайна и оценки.

Я привела несколько больших примеров, но гибкие методологии позволяют управлять и более мелкими фичами.

2. Привлекаем пользователя, а не принуждаем

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

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

Поэтому одна из задач нашего продукта – привлекать пользователя, удерживать его и делать так, чтобы он сам хотел пользоваться продуктом, а не просто был вынужден это делать. Решали мы эту задачу так:

a) Просвещаем

Командой Платформы вместе с ad-hoc аналитиками мы регулярно проводим для сотрудников компании обучение на тему того, почему А/Б-тесты – это хорошо, и какую пользу они могут принести компании, каждому сотруднику и его проекту. Рассказываем основы статистики, а также о том, как правильно провести эксперимент, чтобы его можно было оценить и увидеть реальный эффект. А прямо на Платформе у нас есть своя база знаний и система подсказок на UI.

b) Делаем максимально понятный UI

Пользователю всегда – без дополнительных советов и инструкций – должно быть понятно, какой следующий шаг, что он сделал хорошо, а что плохо.

c) Активно собираем обратную связь от пользователей

Всегда фиксируем то, что пользователи говорят нам сами, плюс проводим глубокие интервью с активными пользователями.

d) Увеличиваем скорость работы

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

3. Не забываем про мотивацию команды

Мы долго шли к рабочей версии продукта (выше я рассказывала про несколько вариантов MVP). В ситуации, когда ты регулярно делаешь что-то, от чего потом отказываются, нетрудно потерять желание работать. Руководителям очень важно не забывать про мотивированность команды.

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

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

В 2022 году наша Платформа вышла в промышленную эксплуатацию, и реальные пользователи завели на ней уже более 150 расчётов. Мы провели глубокие интервью с пользователями и получили позитивную обратную связь. Самым главным для нас было то, что нашим пользователям удобно и просто работать с Платформой.

Благодаря Платформе на одном эксперименте мы можем сэкономить до 14 дней, а значит на 14 дней раньше реализовать изменения, которые повысят финансовые показатели 20 000 магазинов. И при этом сэкономить 10 рабочих дней дата-аналитика. В общем, 2022 год был долгожданным удачным годом для продукта, и я горжусь своей командой, которая этого добилась.

Хочется, чтобы 2023 год был не менее удачным, поэтому сейчас мы сконцентрировались на том, чтобы расширить применимость Платформы и автоматизировать ещё больше расчётов. Помимо этого, мы работаем над повышением чувствительности, чтобы отлавливать на А/Б-тестах ещё меньшие эффекты.