Несоответствие соотношения выборок (SRM): полное руководство с решениями для клиентских случаев

Что может быть хуже проваленного теста?

Проблемы с качеством тестовых данных, которые делают результаты тестов ненадежными.

Но как избежать плохих данных?

Проверка несоответствия отношения выборки (SRM) — это простой способ выявить потенциальные проблемы на ранней стадии. Если что-то не так, то чем раньше вы об этом узнаете, тем лучше.

Читайте дальше, чтобы узнать больше о несоответствии отношения выборки, о том, как его обнаружить, как оно влияет на ваши тесты и какие платформы A/B-тестирования поставляются со встроенными проверками SRM (так что вам не нужно держать электронную таблицу рядом). .

Что такое несоответствие отношения выборки (SRM)?

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

Проиллюстрируем это примером.

Скажем, веб-сайт посещает около 15 000 посетителей в неделю. У нас есть 3 варианта: оригинал (это неизмененная страница) и 2 варианта. Какой объем трафика, по вашему мнению, получит каждый из них, если трафик распределяется поровну? В идеальном мире ответом было бы то, что каждый вариант должен получить 15 000 / 3 = 5 000 посетителей.

Теперь очень маловероятно, что каждый вариант на самом деле получит 5000 посетителей, но число очень близкое к этому, например, 4982 или 5021. Это небольшое отклонение является нормальным и связано с простой случайностью! Но если один из вариантов должен был принять 3500 посетителей, а другие около 5000, то с этим может быть что-то не так!

Вместо того, чтобы полагаться на собственную интуицию в обнаружении этих проблем, мы можем вместо этого пройти тест SRM. Он использует критерий согласия Хи-квадрат, чтобы сказать нам, например, являются ли 4850 или 4750 посетителей «нормальными» или нет, по сравнению с другим числом полученных посетителей!

С точки зрения статистики, критерий согласия Хи-квадрат сравнивает наблюдаемое количество выборок с ожидаемым. А если есть реальная разница, то p-значение будет ниже установленного уровня значимости 0,01, что соответствует достоверности 99%.

Есть ли в вашем A/B тесте SRM? Как рассчитать несоответствие отношения выборки?

В A/B-тестировании SRM может стать настоящей страшилкой, приводя к неточным результатам и ошибочным выводам. Хорошая новость заключается в том, что существуют инструменты, которые помогут вам избежать головной боли.

Использование электронных таблиц

Электронные таблицы — самый простой метод расчета SRM из-за широкой доступности продуктов Microsoft Excel и/или Google.

Давайте покажем вам другой пример.

Мы рассчитаем SRM для теста A/B с разделением трафика 50/50 и наблюдаемым количеством посетителей 214 598 и 241 156 для исходного и варианта соответственно.

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

Вам нужно будет использовать функцию CHISQ.TEST в вашей электронной таблице, чтобы вычислить p-значение, как показано в электронной таблице ниже.

В нашем примере p-значение равно 0. При p-значении ниже 0,05 у вас есть SRM и достаточно доказательств, чтобы в большинстве случаев отклонить результаты теста.

Использование онлайн-калькуляторов несоответствия отношения выборки

1. Калькулятор Convert может помочь в диагностике несоответствия соотношения выборки, а также подскажет, сколько времени вам нужно ждать завершения эксперимента!
   

   

2. Еще один онлайн-калькулятор для SRM разработан Лукасом Вермеером. Этот метод рассчитывает SRM так же, как и предыдущий метод, поэтому, если вы следовали и поняли процесс, вы сможете использовать этот онлайн-калькулятор SRM. Просто введите числа для ваших образцов, и результат будет выглядеть так:
   

   

Как SRM влияет на A/B-тесты?

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

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

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

Соответствует ли фактическое разделение между двумя вариантами (исходным и вариантом 1) ожидаемым значениям? Если это не так, вам следует отклонить данные и перезапустить тест, когда вы решите проблему.

Влияет ли SRM как на частотную, так и на байесовскую модели статистики?

Да.

Причины SRM одинаково влияют на достоверность результатов эксперимента независимо от того, анализируются ли данные с помощью байесовского (Google Optimize, Optimizely, VWO, A/B Tasty) или частотного (Convert Experiences, Dynamic Yield) подходов.

Таким образом, приведенные выше калькуляторы SRM также можно использовать для проверки SRM на платформах, использующих байесовскую статистику.

Когда следует принимать во внимание SRM?

Обнаружение несоответствия отношения выборки в ваших тестах не обязательно означает, что вам нужно отбросить результаты.

Так когда действительно необходимо серьезно относиться к расчету SRM?

Давайте узнаем это на нескольких примерах.

Пример №1

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

Результаты возвращаются как

• Контроль: 21 588 пользователей
• Лечение: 15 482 пользователя

Давайте проверим их через SRM Checker:

Это повод для беспокойства?

Значение p для приведенного выше отношения выборки <0,0001, поэтому вероятность увидеть это соотношение или более экстремальное при планировании, требующем равных пропорций, составляет <0,0001!

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

Пример #2

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

Насколько далеко могут быть показатели? Вы действительно должны отказаться от результатов?

Используя экспериментальную платформу, такую ​​как Convert Experiences, вы можете применить некоторую сегментацию результатов после тестирования и обнаружить, что если вы исключите пользователей Internet Explorer, SRM исчезнет.

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

Без сегмента оставшийся процент пользователей правильно сбалансирован, и показатели выглядят нормально.

Если бы SRM не был обнаружен, весь эксперимент можно было бы считать крупной неудачей.

Но как только SRM был обнаружен, можно было удалить небольшой сегмент и использовать эксперимент для надлежащего анализа.

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

Пример №3

Вы проводите эксперимент и обнаруживаете, что в вашем тесте есть тег SRM.

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

В этом случае вы можете смело игнорировать SRM и продолжать доверять своим данным .

Где вы должны проверить, существует ли SRM?

Есть несколько областей, где может возникнуть SRM. Давайте посмотрим на таксономию причин Лукаса Вермеера:

1. Назначение эксперимента — может быть случай неправильной группировки (пользователи помещаются в неправильные кластеры), неисправной функции рандомизации или поврежденных идентификаторов пользователей.
2. Выполнение эксперимента — вариации могут начаться в разное время (вызывая расхождения) или могут быть задержки выполнения фильтра (определяющие, какие группы подвергаются эксперименту).
3. Обработка логов эксперимента — Автоматическое удаление ботами реальных пользователей, задержка поступления информации в логи.
4. Анализ эксперимента – Неправильный запуск варианта или неправильный его запуск.
5. Вмешательство в эксперимент. Эксперимент может подвергаться атакам и взлому, или другие текущие эксперименты могут мешать текущему эксперименту.

Если у вас есть SRM и вы не знаете, где искать ответ, вышеприведенная таксономия — ценное место для начала.

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

Назначение эксперимента

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

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

Для получения достоверных результатов эксперимента процедура рандомизации имеет решающее значение.

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

Выполнение эксперимента

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

1. Скрипт некорректно установлен на одном из вариантов.

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

Наша служба поддержки недавно разобралась со случаем, когда скрипт Convert не был добавлен в один из вариантов, что вызвало ошибку SRM в тесте.

Убедитесь, что вы добавили сценарий на все страницы, на которых вы хотите запустить интерфейс, как показано ниже:

2. Неправильно настроен таргетинг страницы

В этом случае несоответствие SRM связано с неправильной настройкой таргетинга теста.

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

Чтобы избежать этого, перенастройте выражения URL вариантов эксперимента и перезапустите тест.

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

Сценарий 1. Настройте таргетинг только на домашнюю страницу (https://www.convert.com) с помощью разделенного URL-адреса и передайте все параметры запроса, которые могут быть у посетителей.

Здесь, в области сайта, URL-адрес страницы должен точно соответствовать https://www.convert.com. В разделе исключения строка запроса должна содержать v1=true , чтобы вы избегали каких-либо перенаправлений (поскольку условия эксперимента все равно будут совпадать, если вы окажетесь на https://www.convert.com ?v1=true , а трафик распределение может оказаться неравномерным).

Затем, когда вы определяете свои варианты, держите их так:

Сценарий 2. Настройте таргетинг на все страницы, а не только на домашнюю страницу (https://www.convert.com), с помощью разделенного URL-адреса и параметров запроса.

Здесь вам нужно определить область сайта с помощью «URL-адреса страницы», который содержит https://www.convert.com . В разделе исключения запрос должен содержать v1=true.

При определении вариантов используйте приведенный ниже рецепт регулярного выражения, чтобы поймать все страницы:

Обработка журнала эксперимента

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

Например, наша служба поддержки помогла клиенту, в тесте которого был SRM.

В их случае, когда мы отфильтровали отчет по Browser=Other , мы увидели неравномерное разделение и SRM. Но когда мы отфильтровали тот же отчет по Browser=Chrome+Safari , не было обнаружено ни SRM, ни неравномерного распределения.

Итак, мы проверили пару событий, в которых браузер был установлен на « Другое», и все они показали пользовательский агент «site24x7». Мы сразу поняли, что это какое-то программное обеспечение для мониторинга, которому повезло, поскольку оно рекламное и использует отдельный пользовательский агент. Если бы это было спрятано за обычным User Agent, найти его было бы невозможно.

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

Анализ эксперимента

Эта категория в основном влияет на опыт, установленный с ручным запуском.

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

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

 window._conv_q = _conv_q || [];
window._conv_q.push(["run","true"]);

Экспериментальные помехи

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

Сразу после этого и в зависимости от трафика вашего веб-сайта вы заметите SRM, рассчитанный для вашего теста.

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

Причины, не связанные с экспериментом

Если ни одна из вышеперечисленных категорий не раскрывает основную причину вашего SRM, мы предлагаем вам добавить программное обеспечение для отслеживания ошибок на свой веб-сайт (например, Sentry), чтобы выявить более серьезные проблемы с вашим сайтом.

Платформы A/B-тестирования, поддерживающие оповещения SRM

Вам может быть интересно, какие платформы A/B-тестирования поддерживают эту функциональность SRM и выдают вам предупреждения без необходимости вычислять ее самостоятельно.

Мы провели исследование и составили список инструментов.

Преобразование опыта

С декабря 2021 года мы внедрили собственный метод SRM.

Если вы являетесь пользователем, вы можете включить проверки SRM в разделе «Конфигурация проекта» > «Дополнительные настройки».

Тогда вы сможете увидеть теги SRM в отчетах:

Оптимизировано

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

Компания Optimizely превратила ssrm-test в готовую к работе серверную микрослужбу, которая может работать во всех запущенных экспериментах одновременно.

На странице результатов Optimizely вы можете настроить оповещения и получать результаты ssrm-test в реальном времени:

Майкл Линдон, специалист по статистике Optimizely Staff, говорит, что SRM — это типичная проблема, возникающая при некачественном проведении тестов.

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

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

Adobe Target через MiaProva

В апреле 2021 года Adobe Target заключила партнерское соглашение с MiaProva для отправки предупреждений SRM о действиях A/B.

Эти оповещения уведомляют клиентов MiaProva, использующих Adobe Target, при обнаружении несоответствия. Этот подход автоматически применяет тест хи-квадрат к каждому живому A/B-тесту.

Книга роста

GrowthBook — это платформа A/B-тестирования с открытым исходным кодом, оснащенная байесовским статистическим механизмом и автоматическими проверками SRM для каждого эксперимента.

Каждый эксперимент ищет SRM и предупреждает пользователей, если он обнаружен.

Когда вы предсказываете определенное распределение трафика (например, 50/50), но вместо этого видите что-то совершенно иное (например, 40/60), вы получаете предупреждение. Это отображается только в том случае, если p-значение меньше 0,001, что указывает на то, что совпадение крайне маловероятно.

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

Сплит.ио

Split — это платформа доставки функций, которая обеспечивает управление флагами функций, эксперименты с программным обеспечением и непрерывную доставку.

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

Разоблачение несоответствия соотношения размеров выборки

Вы можете спросить, как часто «нормально» видеть SRM?

Лукас Вермеер сказал это лучше всех. Даже крупные технологические фирмы наблюдают естественную частоту SRM от 6% до 10% в своих контролируемых онлайн-экспериментах.

Теперь, если SRM повторяется чаще, это требует более глубокого изучения дизайна эксперимента или веб-сайта.

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