Привет! Я, Ева, руководитель продуктовой аналитики в М2, отвечаю за внедрение экспериментов и A/B-тестирования в компании. М2 — это онлайн-платформа для решения вопросов с недвижимостью. Сервисами М2 пользуются как частные лица, так и профессиональные участники рынка — риелторы, застройщики, банки. Мы помогаем тысячам людей экономить время, нервы и деньги.

Недавно мы завершили этап внедрения A/B‑платформы. Этот материал для тех, кто думает, как запустить эксперименты с ограниченными ресурсами, сохраняя здравый смысл.

В М2 достаточно компактная команда аналитики: 3 продуктовых и 4 digital-аналитика на 8 продуктовых команд.  Эта статья про то, как небольшая компания может внедрить A/B-тесты и получить пользу даже с ограниченными ресурсами.  Расскажем, как мы выбрали open source платформу GrowthBook, запустили MVP, обучили команду и выстроили процессы.

Когда A/B-тестирование становится необходимым

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

A/B-тестирование полезно при выполнении трёх условий:

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

• Культура экспериментов: Тесты часто дают нулевые или негативные результаты, и это нормально. Мы выстроили среду, где гипотезы проверяются без страха ошибок.

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

Зачем бизнесу эксперименты — на примере М2

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

Мы конкурируем не только с другими компаниями, но и с альтернативой «ничего не делать»: клиент может провести сделку сам, потратив десятки часов. Чтобы он выбрал М2, нужно дать запоминающийся, удобный опыт — и быстро проверять, что действительно работает.

Кроме того, рынок недвижимости в 2024 году был нестабильным: ставки, льготные программы, условия застройщиков менялись почти каждую неделю. Это нарушало сезонность и делало сложными квазиэксперименты по историческим данным. Онлайн-A/B‑тесты стали способом изолировать эффект и принимать решения с уверенностью.

Ключевую роль сыграла поддержка со стороны бизнеса. В М2 был запрос от C-level и продуктовых команд: им нужны были доказательства, что изменения работают. Без этого ни одна платформа бы не прижилась.

Если компания понимает, что готова экспериментировать и имеет для этого базу, возникает вопрос, как это сделать. Внедрение A/B-платформы — не единственный путь, хотя для М2 на этом этапе он оказался оптимальным. Есть и другие варианты, о которых расскажу дальше.

A/B-тестирование: от ручного подхода до своей платформы

Когда компания решает внедрять A/B-тестирование, у неё есть несколько путей. 

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

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

Третий путь — проводить тесты без какой-либо инфраструктуры. Разделить аудиторию подручными средствами, а для оценки результатов нагуглить онлайн-калькулятор. Это не редкость, и в отдельных случаях может работать — если понимаешь, какие данные обрабатываешь и применимы ли выбранные методы. Но без экспертизы такой подход часто приводит к кризису воспроизводимости - компании получают «наукообразные» цифры, которые не подтверждаются при раскатке тестового функционала. В итоге АБ тестирование становится пустой тратой времени — проще вообще ничего не делать и не надеяться на недостоверные результаты.

Четвертый вариант — разработать собственную систему A/B-тестирования. Для компаний с достаточными ресурсами аналитики и разработки это может быть оправдано, но для небольших, как М2, это рискованный шаг. Мы пробовали создать простую систему: думали, что достаточно взять трафик сайта, использовать идентификаторы клиентов и рандомно разделить их на группы. На практике всё оказалось сложнее: без настроенного процесса тестирования каждый тест занимал много времени, было сложно отследить, как составлен каждый эксперимент. Кроме того, аудит показал, что часть назначенных вариантов теста не доходила до аналитической системы. Трудозатраты на исправление проблемы были сравнимы с внедрением нового решения.

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

Внедрение платформы

Когда я начала работать над внедрением A/B-тестирования в М2, казалось, что всё будет просто: выбрать готовое решение, интегрировать и запускать тесты. Реальность оказалась сложнее. Внедрение потребовало координации нескольких команд, а процесс сопровождался неожиданными трудностями.

A/B-тестирование — задача не одной команды аналитики. Успех зависит от вовлечения разных специалистов и единой точки ответственности В М2 мы закрепили эту точку в аналитике, потому что именно у аналитиков есть понимание, где тесты применимы, какие у них ограничения и как избежать ошибок.

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

Минимальный состав команды включал три роли:

• Первая — эксперт по A/B-тестам, понимающий ограничения инструмента и умеющий проектировать эксперименты. 

• Вторая — специалист по системе, где проводятся тесты. У нас это сайт, поэтому нужен был фронтендер, знающий его архитектуру, чтобы интеграция прошла без сбоев. 

• Третья — эксперт по данным, обеспечивающий их сбор и хранение в нашей аналитической системе.
  
  Эти три роли распределились по участникам проекта.

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

Выбор подходящего решения

После формирования проектной команды мы перешли к выбору платформы. Без команды, понимающей задачу, начинать бессмысленно — специалисты формируют требования, по которым оцениваются решения. В М2 аналитики и фронтендеры составили список критериев, учитывающих бизнес-задачи и технические ограничения, такие как совместимость с нашим сайтом и минимизация трудозатрат:

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

Мы протестировали два решения для A/B-тестирования. Sigma — коммерческий сервис с расширенными аналитическими функциями, что мне, как аналитику, очень импонировало. Но после консультаций с разработчиками стало ясно, что его интеграция сложнее и требует больше их участия для запуска тестов. GrowthBook оказался проще и быстрее в настройке, минимизируя трудозатраты, что стало решающим для М2.

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

Запуск MVP и обучение команды

После выбора GrowthBook мы перешли к запуску MVP. Полная интеграция платформы в микросервисную архитектуру нашего фронтенда заняла бы слишком много времени, так как требовалось подключение к каждому сервису. Мы опросили бизнес-заказчиков и выяснили, что 80% тестов они хотят проводить на лендингах — первом этапе воронки, где клиенты чаще всего «отваливаются». Это отражает особенность нашего продукта: сделки с недвижимостью начинаются с лендинга, и если он не привлекает, клиент уходит. На внутренних этапах воронки доходимость уже высокая, поэтому оптимизация лендингов стала приоритетом. Мы описали требования для интеграции с лендингами и запустили MVP, следуя стандартным принципам проектного управления.

Внедрение платформы — это только начало. Инструмент не принесёт пользы, если не встроен в рабочие процессы и не используется на практике. Если в компании до этого не было экспертизы в A/B‑тестировании, важно подумать, кто будет её носителем: нанять специалиста или обучить текущую команду. Мы выбрали второй путь. При этом внешний курс — не всегда достаточное решение. Новички, даже зная теорию, часто воспринимают A/B как что-то сложное и боятся допустить ошибку. Чтобы команда не теряла уверенность, важно обеспечить поддержку на старте — например, возможность обсудить свои гипотезы и тесты с более опытным коллегой.

В М2 мы написали внутренний гайд и провели серию встреч, где разбирали нюансы, отвечали на вопросы и вместе тренировались на первых экспериментах. Это помогло команде быстрее почувствовать уверенность и начать использовать платформу в продуктах.

Стандартизация процессов и работа с ожиданиями

Ключевое — научить бизнес-команды правильно формулировать задачи для A/B-тестов, осознать что нельзя просто внедрить изменение и потом пытаться его оценить -- нужен предварительный анализ. Мы объясняли, что нужно заранее определить, измерима ли гипотеза, какие метрики использовать и сколько времени займёт тест. Это требовало времени, чтобы все команды приняли такой подход.

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

Бизнес-команды часто переоценивают простоту A/B-тестов, но реальность быстро приземляет: это «занудный» инструмент, требующий строгих правил. Завышенные ожидания приводят к разочарованию, и не стоит это сглаживать. Понимание ограничений — ключ к правильному использованию. На встречах с командами я объясняю, что тесты решают узкие задачи, имеют кучу сложностей и не дают мгновенных чудес. Это помогает встроить A/B-тестирование в процессы и сделать его частью культуры компании.

Оценка затрат и эффективности

После внедрения A/B-тестирования в М2 мы начали оценивать его пользу. Для небольшой компании, как наша, нереально тестировать каждое изменение, как делают крупные корпорации. Запуск 2–3 тестов в квартал — уже достижение. Это означает, что окупаемость платформы наступает медленнее, так как эффект от тестов накапливается постепенно.

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

• Фиксированные расходы на внедрение: В М2 мы выбрали open source платформу GrowthBook, потратив только человеко-часы. У других компаний могут быть затраты на покупку платформы или серверы.

• Ежемесячные расходы на поддержку: Это абонентская плата за платформу или работа инженеров, если требуется сложное обслуживание.

• Переменные затраты на тесты: Для дискавери-команды тесты — часть работы, но если разработчики вручную запускают тесты, их человеко-часы учитываются, отвлекая от задач, приносящих выручку.

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

Итоги внедрения

В ходе внедрения мы убедились, что A/B-тестирование требует зрелых продуктов, культуры экспериментов и достаточной аудитории. При выборе платформы тестирования ключевым фактором была её совместимость с системами компании и удобство интеграции — мы выбрали GrowhtBook. Чтобы тесты давали надёжные результаты, мы стандартизировали метрики и вели строгую документацию, а ретроспективы помогли устранять ошибки в процессах, предотвращая хаос. MVP-подход позволил начать с малого, а слаженная работа аналитиков, разработчиков и бизнеса обеспечила успех. A/B-тестирование помогает М2 улучшать клиентский опыт и расти, даже если окупаемость приходит постепенно.