Читайте в Telegram
|
Команда продукта запускает A/B-тест и получает результат: время просмотра на главной VK Видео выросло на несколько процентов.
Для аналитика это только начало исследования: изменение могло перераспределить активность пользователей с подписок или другого раздела, улучшив один показатель за счёт другого.
В VK проходит тысяча A/B-тестов в месяц. При таком масштабе оценка чистого эффекта каждого изменения становится ключевой сложностью. Для этого необходимо проверять десятки метрик по разным срезам — главная, подписки, рекомендации. Задача получает дополнительную звёздочку, когда эксперимент затрагивает несколько команд: например, одна меняет интерфейс, а другая тестирует новую модель рекомендаций. В таком случае согласовывать результаты и проверять корректность сплитования аудитории ещё сложнее.
Сейчас большая часть необходимых аналитикам расчётов выполняется автоматически — благодаря единой платформе для A/B-тестов OneAB. О том, как изменилось проектирование и интерпретация экспериментов, рассказывает старший продуктовый аналитик VK Видео Семён Булатчик. А руководитель отдела разработки OneAB Ахмед Зарманбетов и продакт платформы OneAB Дарья Владимирова объясняют техническую сторону решения.
Как это работало раньше
У каждого продукта VK была своя платформа для проведения A/B-тестов. Пока эксперименты проходили внутри одного сервиса, это было удобно: команда сама сплитовала аудиторию, считала метрики и подводила итоги.
Но для аналитика это означало трудоёмкую поэтапную работу с данными.
«При ручном расчёте приходится заранее ограничивать набор метрик двумя-тремя наиболее важными группами. Если результат оказывается неожиданным, аналитик возвращается к данным и проводит дополнительные расчёты — иногда несколько раз. Это увеличивает время от завершения эксперимента до продуктового решения», — комментирует Семён.
Аналитик тратил время на последовательный сбор пазла. Он получал лишь фрагмент картины: понимал, что произошло на конкретной поверхности, но сразу оценить контекст соседних разделов, разных типов контента и общих показателей всего продукта было сложно.
А когда одно изменение начинало затрагивать сразу несколько команд, аналитику приходилось следить за синхронизацией процессов. Команды отдельно настраивали один и тот же тест, из-за чего распределения пользователей могли не совпадать, а наборы метрик различались. Требовалась дополнительная проверка: не получилось ли так, что одни пользователи видят новый интерфейс с прежней моделью рекомендаций, а другие — обновлённую модель и старый интерфейс.
Единая платформа: что изменилось для аналитика
Чтобы решить эти вопросы, VK объединила разные системы экспериментов на одной платформе — OneAB. Этот шаг был продиктован стратегией развития всей компании. Объясняет Дарья Владимирова, продакт OneAB:
«Вопрос разобщённых A/B-систем — это в первую очередь проблема масштабирования. Новые продукты могли на старте проверить пару гипотез вручную, но при развитии всё равно нуждались в системном решении. В то же время команды общих сервисов, вроде поиска или рекомендаций, должны были тестировать изменения во многих продуктах сразу. Всё это создавало большую нагрузку на аналитиков и разработчиков и могло тормозить масштабирование. Поэтому мы проектировали OneAB не как локальный инструмент для аналитиков, а как платформу, встроенную в общий процесс продуктовой разработки. Она снижает порог входа для запуска экспериментов и позволяет командам сосредоточиться на гипотезах и решениях, снимает с них техническую рутину».
В OneAB общими стали панель управления для заведения тестов, сервис сплитования аудитории и блок подсчёта результатов.
«Самое сложное — привести разные команды к одному процессу проведения эксперимента. Поэтому миграция включала работу с методологией: единой платформе требовались общие принципы, иначе внутри неё быстро появились бы локальные исключения», — говорит Дарья.
Для аналитика изменения при работе с OneAB начинаются ещё на этапе проектирования теста. Раньше специалистам приходилось выбирать конкретные наборы метрик, предполагая, что они помогут проверить гипотезу, а уточняющие запросы к логам писать с нуля уже после эксперимента. Теперь команда может свободнее проектировать тесты: в OneAB сформирован ранжированный набор ключевых продуктовых метрик. Например, для VK Видео это показатели от времени просмотра до retention и глубины просмотра — десятки метрик, по которым принимаются решения. Если нужного показателя ещё там нет, его можно добавить до запуска.
После завершения теста около 90% необходимых метрик рассчитываются автоматически. Аналитик открывает карточку эксперимента в OneAB и сразу видит результаты: система подсвечивает статистически значимые изменения ключевых показателей. Это сокращает время на рутинные расчёты — специалист скорее приступает к интерпретации.
«Когда мы видим рост ключевой метрики, сначала проверяем, не произошёл ли он за счёт других частей продукта. При ручном расчёте такая проверка могла занимать несколько часов. В OneAB я вижу полную картину и быстрее перехожу к локализации источника эффекта», — говорит Семён Булатчик.
Платформа позволяет смотреть не только на метрики отдельных поверхностей — главной страницы, подписок, рекомендаций — но и на другие срезы. С помощью фильтров аналитик может проверить показатели по всему сервису: например, как изменилось смотрение коротких и длинных форматов или тематических направлений контента.
«Это помогает увидеть дополнительные эффекты эксперимента: например, не снизилось ли общее время просмотра определённого тематического контента. Мы отслеживаем не только перераспределение активности между разделами продукта, но и изменения в потреблении разных типов контента. Такая комплексная картина помогает быстрее определить направление дальнейшего анализа», — объясняет Семён.
Как OneAB проводит перекрёстные эксперименты
Единая система особенно важна для перекрёстных A/B-тестов — когда изменение затрагивает несколько команд или частей продукта одновременно. Например, продуктовая команда меняет интерфейс, а команда рекомендаций в тот же момент тестирует новую модель подбора контента. Пользователи из тестовой группы должны увидеть оба связанных изменения вместе, иначе результат нельзя будет корректно оценить.
«При проектировании OneAB мы рассматривали три варианта: встроить сплитование аудитории в локальные A/B-системы как библиотеку, вынести его в отдельный контейнер рядом с каждым продуктом или поднять единый сервис, в который нужно ходить по сети. Выбрали центральный сервис — сплиттер: он одинаково распределяет пользователей для разных продуктов и команд и отвечает за единые правила тестов. Чтобы сервис быстро отвечал и выдерживал общую нагрузку, мы написали его на Go. Данные об активных экспериментах разместили в оперативной памяти, а для обмена данными с продуктами используем gRPC и HTTP», — рассказывает Ахмед.
Для аналитика главное следствие этой архитектуры — единый принцип сплитования аудитории. Пользователь стабильно остаётся в одной группе, а разные команды, участвующие в эксперименте, работают с одним и тем же распределением. Единое распределение снижает риск, что выборки разойдутся из-за разных настроек локальных систем — так что командам больше не нужно вручную синхронизировать эти настройки.
Система рассчитывает группу пользователя по его идентификатору и параметрам эксперимента. Одинаковые данные дают одинаковый результат, поэтому пользователь при повторном заходе попадает в ту же группу. При этом разные тесты получают независимые распределения.
Как с OneAB запускать тесты параллельно
Ещё одна задача аналитика — следить, чтобы одновременно идущие эксперименты не искажали результаты друг друга. В OneAB для этого используются два уровня разделения аудитории: партиции — фиксированные доли аудитории, и слои — наборы таких долей. Семён называет управление пересечениями одним из главных повседневных преимуществ платформы.
«Эксперименты в продукте разделены по логическим направлениям: рекомендации, платформы, интерфейс, маркетинг. Изменения в разных направлениях часто не влияют друг на друга, поэтому такие тесты можно запускать параллельно в ортогональных слоях. Это позволяет эффективнее использовать аудиторию и получать необходимый объём выборки без взаимного влияния экспериментов», — объясняет Семён.
Если два эксперимента всё-таки затрагивают одну поверхность (например, рекомендации на главной странице VK Видео), система автоматически выделяет им непересекающиеся группы пользователей. В результате аудитории разводятся, а их результаты не смешиваются.
В обоих случаях аналитик понимает, какие тесты могут влиять друг на друга, и учитывает эти пересечения при распределении аудитории и анализе результатов.
Та же механика используется для долгосрочной контрольной группы: часть аудитории можно не включать в продуктовые изменения в течение выбранного периода. Это помогает отслеживать накопленный эффект нескольких A/B-тестов.
Как аналитик разбирает результат эксперимента
Вот типичный сценарий анализа: допустим, команда запускает эксперимент на главной странице видеосервиса. Гипотеза: изменение интерфейса этой страницы может увеличить общее время просмотра в сервисе.
После завершения теста аналитик открывает карточку эксперимента в OneAB и видит: время просмотра на главной действительно выросло.
Следующий шаг — посмотреть, как изменились метрики всего продукта. Аналитик проверяет общее время просмотра по видеосервису — оно не изменилось. Значит, новая функция могла просто перераспределить активность пользователей между разными частями продукта.
«У нас есть готовый набор срезов: добавив несколько фильтров, мы быстро видим полную картину. Наша задача — понять, действительно ли изменение принесло пользу или мы просто переместили метрику из одной части продукта в другую», — объясняет Семён.
Тогда аналитик проверяет соседние поверхности и типы контента. Выясняется, что на соседней поверхности (например, в разделе подписок) время просмотра упало, а показатели по типам контента — детскому, спортивному и другим — остались без изменений.
Картина прояснилась: рост произошёл из-за того, что пользователи стали проводить больше времени на главной и меньше — в соседнем разделе. Метрика просто перетекла из одной поверхности в другую, но в целом время просмотра всего сервиса не увеличилось. Первоначальная гипотеза не подтвердилась.
Раньше на сбор такого пазла ушло бы много часов — с учётом написания запросов и ручного досчёта недостающих метрик. В OneAB этот процесс занимает минимум времени. Аналитик быстрее формулирует объяснение результата, при необходимости делает точечные выгрузки и решает, что делать с исходной гипотезой дальше.
«Как правило, ручные расчёты теперь нужны не для первичной проверки базовых метрик, а для более глубокой проработки выводов по результатам эксперимента. На их основе мы определяем, что делать с гипотезой дальше: развивать изменение, дорабатывать его или останавливать», — резюмирует Семён.
Единая платформа для A/B-тестов даёт команде продукта возможность проводить больше экспериментов и оценивать их по единым правилам. А аналитикам открывает более короткий путь от результата теста к его интерпретации.
Важно, что OneAB не принимает продуктовые решения за человека. Платформа помогает собрать полную картину эксперимента и быстрее проверить возможные причины изменений. А уже аналитик определяет, что означает результат, какую гипотезу проверить дальше и стоит ли развивать изменение.
