Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

А/В-тесты — не только статистика? Чек-лист для продакт-менеджера

Привет! Меня зовут Андрей, я Product Manager в appflame. В этой статье я не буду рассматривать базовые статистические принципы, а расскажу про практические аспекты проведения А/В-тестов в формате чек-листа для продакт-менеджера, который мы применяем в работе. Он составлен на основе той информации, которую считаю наиболее полезной в актуальной книге по теме — Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing, а также на основе личного опыта проведения нескольких сотен А/В-тестов в качестве аналитика и продакт-менеджера на проектах с большим количеством взаимодействий между миллионами пользователей.

Информация может быть интересна как опытным продакт-менеджерам и аналитикам, так и новичкам без опыта проведения А/В-тестирования. Рассмотрим, когда возможно и нужно А/В-тестирование, что не является А/В-тестированием, проблемы взаимного влияния групп, временные эффекты, полезные практики на каждом этапе в аналитике и продакт-менеджменте и многое другое.

Для многих продуктовых компаний А/В-тестирование — не просто один из полезных аналитических инструментов, это отправная точка для развития продукта, без которой редко обходится какое-либо изменение. В Google и Microsoft каждый год проводят тысячи А/В-тестов. Про статистические принципы и техническую реализацию А/В-тестирования можно найти немало информации. В большинстве обзоров А/В-тестов есть поинты про подсчёт выборки, подсматривание за данными, трактовку p-value — но это лишь часть важных моментов, с которыми большинство столкнется на практике. Про практический продакт-менеджмент А/В-тестов информации немного.

Кто такой продакт-менеджер

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

Зачем нужны чек-листы

Чек-листы повсеместно применяются, когда необходимо минимизировать вероятность ошибки. К примеру, в медицине и авиации. По данным крупного эксперимента, описанного в статье A Surgical Safety Checklist to Reduce Morbidity and Mortality in a Global Population, в госпиталях, где начали использовать стандартизированный чек-лист во время проведения хирургических операций, смертность снизилась с 1,5% до 0,8%.

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

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

  1. Что мы ожидаем от изменения? Какие наши текущие цели и как это изменение поможет их достичь?
  2. Возможно ли тестировать данное изменение с помощью А/В-теста?
  3. Стоит ли применить альтернативный дизайн?
  4. Первая прикидка, нужен ли А/В-тест.
  5. Определяем метрики.
  6. Какие юниты будет разделять логика А/В-тестирования?
  7. Определяем путь разбивки на группы.
  8. Определяем взаимодействие с другими А/B-тестами.
  9. Определяем последовательность запуска А/В-теста.
  10. Ожидается ли взаимное влияние групп, и если да — какие основные сценарии такого влияния?
  11. Определяем точку чувствительности оценки теста — место в продукте, на котором происходит разделение логики, то есть изменение.
  12. Определяем необходимый размер выборки.
  13. Принимаем окончательное решение, нужен ли А/В-тест.
  14. Описываем, какой трекинг необходим для оценки теста.
  15. Старт технической реализации функционала.
  16. Назначаем разбивку на группы и проверяем историческую динамику интересующих нас метрик в рамках каждой из групп.
  17. Запуск теста.
  18. Первая проверка после запуска.
  19. Следим за метриками по сегментам и по общей динамике.
  20. Выявляем характерные временные эффекты в рамках изменения.
  21. После накопления достаточной выборки принимаем решение.
  22. Закрываем тест и убеждаемся, что он закрыт корректно.
  23. B/В’ (А/А’) тест — продолжаем следить за группами и смотрим на разницу между ними, особенно на старых пользователях.
  24. Решаем, полезным ли был для нас тест.
  25. Записываем характеристики и результаты теста в историю проведения А/В-тестов.

Предлагаю рассмотреть каждый пункт более детально.

Что мы ожидаем от изменения? Какие наши текущие цели и как это изменение поможет их нам достичь?

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

Возможно ли тестировать данное изменение с помощью А/В-теста?

На практике основные критерии следующие:

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

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

Стоит ли применить альтернативный дизайн?

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

К примеру, один покупатель может посещать сразу несколько магазинов из разных групп, и опыт покупок в одних магазинах может повлиять на результаты других — это взаимное влияние групп друг на друга. Один из методов ухода от взаимного влияния групп — назначение групп по географическому признаку. К примеру, сеть магазинов может применить другую расстановку товара для всех магазинов определённых городов. Это, в свою очередь, будет отходом от другого важного критерия — рандомного назначения групп. В IT-продуктах такие проблемы также встречаются повсеместно, особенно когда речь идёт про проекты, в которых пользователи могут взаимодействовать между собой.

Это не означает, что проводить такие тесты нет смысла — при корректном подходе лучше провести их, чем просто оценивать изменение в динамике. Но стоит помнить следующее:

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

Первая прикидка, нужен ли А/В-тест. Доводы за:

1. Тест дает наиболее объективную оценку изменения. Основная альтернатива — смотреть на динамику во времени, то есть сравнивать периоды до/после изменения. Такой подход в определённых ситуациях жизнеспособен, но становится проблематичным в нескольких кейсах:

  • На метрики одновременно влияет много факторов. Чем больше факторов влияют на метрики вашего продукта — тем актуальнее оценивать изменение с помощью А/В-теста. Факторами могут быть как постоянное изменение структуры ваших пользователей по ключевым параметрам (полу/возрасту/источнику трафика и так далее), так и одновременное проведение других тестов внутри продукта. Даже скрупулезно наблюдая динамику в разрезе всех сегментов, можно не получить свидетельства того, что именно интересующее вас изменение повлияло на метрику, а не другой фактор. Вы никогда не будете обладать полной информацией о всех факторах, влияющих на продукт в конкретный момент. Рандомизированное назначение групп в А/В-тестах позволяет уйти от влияния всех факторов, в том числе невидимых для вас.
  • От изменения ожидается лишь незначительное влияние на метрики, которое в динамике можно не заметить за обычной волатильностью метрики. Большинство тестов на продуктах, особенно не на начальных стадиях развития, именно такие. Проведя десяток таких тестов, можно загнать общую динамику как в плюс, так и минус, не поняв при этом, что конкретно к этому привело и как двигаться дальше. На графике ниже гипотетический пример с выручкой продукта, на котором было 5 изменений без А/В-теста в разное время, но из-за общей волатильности нет возможности понять, какие именно из них приводили к уменьшению выручки:

Если бы изменения оценивались А/В-тестированием, на таком же графике с добавленной разбивкой по группам можно было бы заметить, что негативную динамику дали только два изменения, от которых стоило отказаться (синие линии — контрольные группы, оранжевые — группы с изменениями):

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

3. Тест требует меньше работы от аналитика при оценке изменения. При условии, что налажен процесс работы с А/В-тестированием, для аналитика гораздо проще оценить очередной А/В-тест, чем возиться с динамикой десятков факторов.

4. В условиях А/В-теста на порядок проще находить баги и несоответствия задуманной изначально логике изменения.

5. Без теста высока вероятность, что мы не узнаем:

  • было ли изменение эффективным;
  • степень влияния этого изменения;
  • реальных причин падения/роста общей динамики;
  • корректно ли работает задуманная логика;
  • стоит ли дальше работать в этом направлении.

Доводы против:

  • Тест сложнее для разработки.
  • Если изменение незначительное, тратится лишний ресурс (но не всегда очевидно, что изменение незначительное — изменение на любых местах продукта с большим посещением стоит считать значительным).
  • Если выборка заведомо малая/недостаточно релевантная, А/В-тест не даст достоверного/долгосрочно актуального результата. Либо потребуется слишком много времени на тестирование с утратой возможностей альтернативного развития на этот период.
  • Долгосрочная концепция продукта строится на рассматриваемом изменении и не подразумевает альтернатив в зависимости от результатов изменения.

Определяем метрики:

  • На каких метриках мы ожидаем увидеть влияние как в лучшую, так и в худшую сторону? Стараемся перечислить все метрики, на которые изменение может повлиять, даже не самые важные. Они могут помочь в будущем убедиться, что функционал работает корректно.
  • На основании каких метрик будет приниматься решение и какими метриками мы можем пренебречь, даже если на них будет влияние? Чем больше метрик принятия решения, тем выше вероятность получить ошибочный результат в хотя бы одной из них. Поэтому оптимально ориентироваться в решении лишь на несколько ключевых метрик.
  • Смотреть в рамках теста можно на сотни и тысячи метрик, некоторые из них могут впоследствии стать метриками решения при неожиданном на них влиянии. Полезно выделить все важные для вашего продукта метрики и в каждом тесте проверять их, даже если вы не ожидаете увидеть на большинство из них влияния. При этом в сотне метрик при p-value, к примеру, в 0,05 с большой вероятностью хотя бы несколько из них покажут значимый результат там, где его на самом деле нет. Поэтому для метрик, на которые вы не ожидаете влияния, можно ставить более высокий порог для принятия решения по p-value, к примеру 0,01. Такой подход удобен, если на каждую из сотен метрик вы не планируете смотреть глазами, а автоматизируете отчёты с последующим просмотром только тех метрик, которые прошли выставленные пороги.
  • Каково текущее значение потенциальных метрик решения и какова их динамика? Какие факторы на них влияют?
  • Какие метрики помогут нам убедиться в том, что логика теста работает корректно? Учитываем не только те метрики, на которые обычно смотрим, но и те, которые можно будет рассчитать после добавления соответствующего трекинга. Очевидный пример — частота использования функционала, который появится, если будет решено осуществлять рассматриваемое изменение.
  • Какие метрики для нас максимально критичны, чтобы их не задеть? Такие предохранительные метрики важны, чтобы не загнать в минус стратегически важные аспекты продукта, например скорость работы приложения, жалобы пользователей и другие.

Какие юниты будет разделять логика А/В-тестирования

В большинстве случаев оптимальный юнит — это пользователь. Альтернативные варианты — связка пользователь/день, единица контента (к примеру, уникальный идентификатор имейла/уведомления), отдельный просмотр страницы, сессия пользователя и другие. Именно пользователь является отправной точкой в юнит-экономике в большинстве продуктов. Разбивка по идентификатору уведомления подразумевает, к примеру, что один человек может много раз получать как уведомления группы с изменением, так и контрольной группы, на которую, в свою очередь, влияет опыт взаимодействия пользователя с измененными уведомлениями. Альтернативные юниты могут быть уместны, если:

  • выборка пользователей как юнитов небольшая. Как в случае первоначальной стадии развития продукта, так и в случае состоявшихся продуктов, характер которых подразумевает относительно небольшое количество активных долгосрочных юзеров (например, в B2B-сегменте);
  • не критична консистентность опыта взаимодействия юзера с данным функционалом;
  • взаимодействие пользователя с функционалом в отдельно взятом сеансе слабо влияет на его последующие взаимодействия с этим функционалом. Более достижимо для постоянных пользователей, когда сотая покупка незначительно влияет на сто первую. Первое же взаимодействие с функционалом практически гарантированно повлияет на второе;
  • в плане метрик в рамках теста нас интересует в первую очередь перфоманс отдельно взятого функционала, а не всей юнит-экономики продукта с этим функционалом. Если функционалом стали пользоваться лучше, мы готовы рискнуть и предположить, что на юнит-экономику негативного влияния тоже нет — желательно на основе опыта предыдущих тестов, юнитом которых выступал юзер.

Определяем путь разбивки на группы

Здесь возможны разные варианты, рассмотрим основные.

  • Разбивка на две равные группы, 50% юнитов с изменением и 50% контрольная группа без изменений. Эта разбивка наиболее быстрая с точки зрения получения результатов, но рискованная, если изменение существенное и если запуск теста включает в себя пользователей, которые уже использовали ранее продукт.
  • Разбивка на более чем две равные группы, к примеру на 5 групп по 20% юнитов, одна из которых — контрольная. Уместна, если мы хотим провести тест со множеством однотипных изменений, из которых хотим выбрать одно оптимальное, например текстовки на одном и том же экране.
  • Разбивка на неравные группы. Например, группа на 5% юнитов с изменением и контрольная группа из 95% юнитов. Применяется зачастую тогда, когда количество юнитов в распоряжении очень большое, либо когда под риск изменения мы хотим подставить лишь небольшую их часть. Также многие тесты есть смысл проводить не менее одной недели вне зависимости от выборки, чтобы уловить особенности изменения в рамках вариативности по дням недели, которая характерна для большинства продуктов. 5% выборки в течение недели в условиях продуктов с огромными миллионными аудиториями обычно даст достаточную выборку. Долгосрочной оценки (2–3 недели и более) требуют тесты, в которых функционал проявляет своё влияние на более поздних этапах жизни юзера (например, работа со снижением уровня отмен платных подписок). В таких условиях бывает рискованно надолго подставлять под изменение значительную часть аудитории, и даже на проектах с более скромной аудиторией бывает уместнее выделить 5–10% для группы с изменением.

Определяем взаимодействие с другими А/B-тестами

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

Есть два основных подхода к их разграничению.

1. Благодаря корректной рандомизации юнитов при назначении групп нового теста в каждую из них попадает равномерное количество юнитов из групп остальных тестов. На примере двух тестов с группами А и B, и разбивкой 50/50 — должно получиться 4 примерно равномерные группы юнитов. Пример такой разбивки с указанием количества юнитов в каждой группе представлен на схеме ниже:

Так, в левом синем квадрате — все 8010 юнитов, которые попали в контрольную группу А как в первом тесте, так и во втором. В левом оранжевом — все 7988 юнитов, которые попали в группу B c изменением в первом тесте и в контрольную А во втором. Каждый юнит относится к какой-либо из групп каждого из тестов. В группе с изменением первого теста примерно 50% юнитов этой группы (и 25% от всех пользователей) будут подпадать под изменение второго теста, а другие 50% — не будут, и аналогично — в группе без изменения.

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

Также даже при корректной рандомизации лучше избегать большого количества одновременных тестов на одну и ту же область продукта (особенно если логики новые и сложные). Это может приводить к техническим издержкам, ухудшению опыта пользователей и неправильной интерпретации результатов тестов.

2. Все доступные для тестирования юниты изначально разбиваются на множество групп, на каждой из которых одновременно тестируется лишь одно изменение. Такую стратегию есть смысл рассматривать только при наличии большого количества юнитов. Основной плюс — нет пересечения разных изменений, а значит меньше волатильности и шума при сравнении контрольной группы и группы с изменением.

Определяем последовательность запуска А/В-теста

На практике с нашими приложениями мы применяем следующие стратегии.

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

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

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

Возможны следующие подходы:

1. Не пытаться обойти взаимное влияние, но делить аудиторию на группы в рамках одной из ролей. Например, изменив дизайн кнопки лайка поста для половины аудитории, мы влияем в первую очередь на роль сендера лайков. В другом тесте, изменив текст нотификации у половины получателей лайков, мы влияем в первую очередь на роль ресивера лайков — и в аналитике разбираем метрики, которые относятся к соответствующей роли (сендер — конверсия в отправку хотя бы одного лайка, ресивер — конверсия в переход хотя бы по одной нотификации).

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

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

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

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

К примеру, в рамках теста на своих продуктах части юзеров мы предлагали функционал «открытости к разговору» (то есть стать ресивером нового функционала) и только для них же показывали рекомендацию написать таким юзерам сообщение (то есть стать сендером нового функционала). А могли показать рекомендацию стать сендером для всей аудитории, тогда таким юзерам писали бы намного чаще — такой тест приблизил бы опыт ресивера к конечному его опыту в случае позитивного решения по тесту, но тогда мы не смогли бы оценить влияние на сендеров, так как сендерами стали бы все.

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

3. Вместо рандомизированного назначения групп можно применить разбивку на группы на основе географических признаков — в случае, если это обеспечит высокий уровень изоляции для вашего продукта. Кластеризация с последующей изоляцией пользователей возможна и по множеству других признаков. На таких соцсетях, как Reddit и Discord, люди собираются в кластеры в большей мере на основе интересов, чем географии. Определяя и сравнивая между собой группы А/В-теста, назначения юнитов которого было определено не случайным образом, важно учитывать разницу в динамике метрик групп до запуска теста, она может оказаться достаточно значительной. По возможности в назначенных группах разница в динамике до теста должна быть минимальной.

Определяем точку чувствительности оценки теста

Это место в продукте, на котором происходит разделение логики, то есть изменение.

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

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

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

Определяем необходимый размер выборки с учетом:

  • Точки чувствительности, в том числе в рамках жизненного цикла юзера — если изменение ожидается начиная с определенного дня жизни юзера на проекте, выборку стоит рассчитывать с учетом доли юзеров, которая будет активной к моменту столкновения с изменением.
  • Важных сегментов, в рамках которых мы хотим проверить влияние — каждый сегмент расцениваем как отдельный тест со своей выборкой, своими ошибками первого и второго рода и так далее.
  • Минимального эффекта влияния на метрику, который удастся обнаружить тестом (minimum detectable effect). Чем большего влияния мы ожидаем, тем меньше выборка потребуется. Если вы не ожидаете конкретного влияния, а лишь бы стало лучше от изменения — можно определить другие приемлемые для вас параметры, включая количество юнитов, на сбор которых готовы потратить время, и узнать ту минимальную степень влияния, которую сможете уловить, проведя тест.
  • Количества дней недели, которые нужно охватить тестом для получения данных по метрикам, показывающим волатильность в зависимости от дня недели. Иногда продукт может собрать внушительную выборку за полдня, но для получения объективной картины по дням недели его всё равно лучше проводить не менее 7 дней.

Принимаем окончательное решение, нужен ли А/В-тест

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

Описываем, какой трекинг необходим для оценки теста

Какие новые данные необходимо записывать по событиям продукта:

  • Чем больше событий вокруг функционала трекаются, тем легче заметить проблемы с функционалом и выловить потенциальные баги.
  • Лучше избыточный трекинг, чем недостаточный — в случае, если это не вызывает технических проблем и не влияет на опыт использования продукта (это необходимо проверять).
  • С помощью трекинга должна быть возможность как минимум ответить на базовые вопросы по использованию функционала: какой процент юзеров хоть раз попробовал начать использовать функционал, какой процент юзеров успешно воспользовался функционалом, на каких шагах юзера проводили больше времени и отваливались и так далее.
  • Может помочь для оптимального обозначения точки чувствительности — например, с помощью трекинга событий на контрольной группе в том же месте и в тех же условиях, в которых к ним могла бы применяться логика группы с изменением (но не применяется). При этом трекинг в контрольной группе может влиять на производительность и таким образом на всю активность в группе. В условиях такого риска можно проводить А/А’/В тест, в котором А’ - контрольная группа без трекинга.

Старт технической реализации функционала

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

Запуск теста. Первая проверка после запуска

Её стоит делать сразу же в течении первых дней после запуска, как только появляются первые данные. Проверяем:

1. Наличие и корректность запланированного трекинга.

2. Соответствуют ли назначенным группам варианты логики.

3. Выборка равномерно распределена по вариантам, как запланировано (50/50 к примеру). При наборе достаточной выборки не должно быть статистически значимого отличия между группами в фактическом распределении количества юзеров от запланированного (sample ratio mismatch) — как для всей выборки, так и в рамках точки чувствительности.

4. Графики перехода A/A-теста в A/B-тест по основным метрикам. Они часто позволяют заметить очевидные проблемы, к примеру когда в условиях сплита контрольная группа А также меняет свое поведение. Такое может возникнуть вследствие непредвиденного влияния группы с изменением на контрольную, технически неправильного запуска, а также из-за использования общей инфраструктуры, на работу которой влияет группа с изменением. Пример такой ситуации изображен на графике ниже. До момента запуска 17 июня группы показывали очень схожую динамику по выручке, после запуска группа В выросла по выручке, но группа А тоже явно вышла на более высокий уровень. Такое могло произойти из-за увеличения в группе В не только выручки, но и активности в продукте. Это позитивно отобразилась на активности и выручке группы А.

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

Следим за метриками по сегментам и по общей динамике

Смотрим не только на обобщённые метрики, но и на конкретные кейсы использования функционала, распределения значений метрик и на аутлаеров. Досрочное закрытие теста (до момента набора достаточной выборки) уместно в следующих случаях:

  • Тест работает некорректно.
  • Тест работает корректно, но показывает очевидно плохой результат. Грань того, что считать очевидно плохим, решаете вы сами отдельно для каждого кейса. Естественно разница в худшую сторону должна быть определённой на выборке адекватного размера и сопоставленной с историческим значением метрики и её обычной волатильности. Если есть сомнения — ждите предопределенного заранее размера выборки и тогда принимаете решение. Здесь речь в основном про кейсы, когда изначально рискованный тест показывает очевидно плохой результат именно там, где его логично было ожидать, а на позитивное влияние нет и намека. И в которых вы готовы не получать полноценный отчёт по всем плюсам и минусам изменения, а просто отказаться от изменений.

Рядовые изменения и добавления новых вспомогательных функционалов редко дают сильно хороший/плохой результат — как только замечаем такие результаты в динамике теста, стоит смотреть на них как на потенциальную ошибку и стараться найти проблему. Если проблему найти не удаётся, но результаты вызывают подозрения — можно провести новый тест на другой разбивке групп, но важно найти логичные обоснования неожиданно сильному влиянию.

Функционал может показать себя хорошо, но в обход изначально запланированной логики — к примеру, ошибочные дубликаты уведомлений могут привести к краткосрочно положительному эффекту и крайне негативному долгосрочно. Или показать себя плохо не из-за своей сути, а к примеру из-за негативного влияния на скорость работы и других факторов, которые можно было исправить. Ложноотрицательный результат может скрыть для вас потенциально перспективные направления в развитии продукта.

Выявляем характерные временные эффекты в рамках изменения

1. Новизна (для старых пользователей) — юзеры видят новый функционал и пробуют его, в итоге в первые дни добавления функционала наблюдается высокий конверт в пользование, но со временем он снижается. На графике ниже изображена ситуация, когда на продукте 29 апреля был добавлен новый более заметный дизайн лайка поста. В первые дни стремительно повысился процент активных ежедневных юзеров (DAU) с хотя бы одним отправленным лайком поста, но дальше группа с изменением опустилась по уровню этой метрики ниже контрольной группы из-за негативного влияния на количество просмотренных постов, так как новый дизайн менее удобен для их просмотра.

2. Привычка (для старых пользователей) — юзеры привыкают к определенному функционалу и сразу после его изменения может наблюдаться временная негативная динамика.

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

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

После накопления достаточной выборки принимаем решение

Решение о закрытии нужно принимать одноразово в момент, когда соберется выборка необходимого размера, а не выжидать статистической значимости и тогда закрывать (почему так не стоит делать, можно почитать в большинстве обзоров на А/В-тесты, в частности здесь). Если между группами нет значимого отличия — принимаем решение на основании других факторов, например сложность поддержания функционала в будущем, возможности для его развития и так далее.

Закрываем тест и убеждаемся, что он закрыт корректно

B/В’ (А/А’) тест — продолжаем следить за группами и смотрим на разницу между ними, особенно на старых пользователях. Это может помочь более выраженно выявить и исследовать временные эффекты. Когда контрольная группа старых пользователей получит изменение, мы увидим ещё одну итерацию временных эффектов с момента старта изменения. Следим до тех пор, пока группы существенно отличаются.

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

Решаем, полезным ли был для нас тест

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

Записываем характеристики и результаты теста в историю проведения А/В-тестов, которая будет крайне полезна, если:

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

Пункты, которые обязательно стоит расписать в истории:

  • время запуска и закрытия теста;
  • какое решение по изменению было принято;
  • размер выборки, на которой было принято решение;
  • значение метрик решения до запуска теста, minimum detectable effect, significance level, statistical power;
  • на какие метрики было значимое влияние;
  • было ли взаимное влияние групп;
  • члены команды, которые работали над запуском и анализом теста;
  • примерное время, затраченное на разработку функционала (стори поинты).

Выводы

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

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

👍ПодобаєтьсяСподобалось8
До обраногоВ обраному8
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Спасибо за статью! Закрепил ее себе как образчик ведения а/б-тестов. Впервые узнал, что это прерогатива продукт-менеджеров и аналитиков, а не дизайнеров.

Статья очень понравилась. По описанию кейсов и выводам чуствуется что написана практиком! Спасибо Андрей за то что поделился своими наработками. Буду использовать в своей работе.

Упомянутые здесь улучшения в 1.5% для такой методики это колебания ниже статистической погрешности.Отсюда вывод — в теории все красиво, применение на практике возможно, но толку явно от метода мало

1.5% здесь присутствуют только в качестве отсылки на исследование в авторитетном медицинском журнале, как аргумент в пользу применения чек-листов. Связь с тем что в статье описано про А/В тесты — нулевая)

Какого-то нового «метода» здесь нет — просто описаны известные для всех кто в теме продуктовые проблемы А/В тестов и способы их решения, в практически применимой форме

Андрей, так как же определяете размер выборки? По какой формуле? Какие распределения используете? Как p-value влияет на размер выборки? Было бы интересно увидеть

Формула для расчёта выборки — такова, как в ответе здесь: stats.stackexchange.com/...​-size-calculation-by-hand

Если кто-то не хочет считать вручную — можно воспользоваться онлайн калькулятором здесь www.evanmiller.org/...​-testing/sample-size.html

Про p-value и другие базовые моменты статистики А/В тестов — лучше прочитать отдельные статьи, их много. Кратко — при прочих равных, если по факту изменения для нас важно получить более низкий p-value, то и выборка понадобится больше. Но даже большая выборка не даст низкий p-value, если между вариантами логик нет значимого отличия.

Підписатись на коментарі