что такое minimum detectable effect
Minimum Detectable Effect (MDE)
1. What is Minimum Detectable Effect (MDE)?
It’s a minimum improvement over the conversion rate of the existing asset (baseline conversion rate) that you want the experiment to detect.
By setting MDE, you define the conversion rate increase sufficient for the system to declare the new asset winner. The lower MDE you set, the slighter conversion changes will be detected by the system. Basically, MDE measures the experiment sensitivity.
Highly sensitive settings, or low MDE, come along with a big sample size. The lower MDE, the more traffic you need to detect minor changes, hence the more money you have to spend on driving that traffic.
So, by configuring MDE you are flexible about connecting the experiment design with the costs you are ready to incur.
2. What’s the optimal MDE?
There’s no such thing as an ideal MDE, so SplitMetrics can’t recommend you the optimal value. This is a key custom parameter affecting your sample size and, by implication, the costs associated with the traffic. In other words, we suggest you defining MDE by yourself, taking into consideration your individual risks – money and time.
3. How does MDE affect my sample size?
MDE has a dramatic effect on the amount of traffic required to reach statistical significance. To know your maximum sample size, use the Evan Miller calculator for sequential A/B sampling. Make sure that your insert relative value for MDE rather than absolute.
For example, to reach the significance level of 5%, you’ll require 2,922 total conversions with MDE = 10%. with MDE = 5% the sample size grows up to 11,141 total conversions.
Remember, however, that the sample size you see is only the maximum threshold required for a statistically significant result. Due to the nature of sequential A/B testing, the system will constantly check the difference between conversion rates of variations under testing. Once the difference is found, the test is finished and there’s no need to score the entire sample size.
4. How to calculate my MDE?
Although our system can count MDE for you, we strongly recommend setting it by yourself. This parameter depends on your own risks – money you’re ready to allocate for the traffic acquisition and time you can wait for the experiment to run.
To get MDE that works for you, you have to understand:
The best possible MDE implies that the potential revenue exceeds or compensates for the traffic acquisition costs.
MDE calculation workflow
Step 1. Estimate the desired conversion rate lift
Let’s say the conversion rate of your product page with the existing icon is 20% (baseline conversion rate). You assume that the new icon should have at least a 22% conversion rate for you to use it instead of the existing icon.
So, you have to configure an experiment in such a way that it declares the winner when the conversion rate difference is at least 22% – 20% = 2%. To set that up, you have to count your estimated MDE.
MDE is calculated as a percent of the baseline conversion rate:
MDE = desired conversion rate lift / baseline conversion rate x 100%
In this example, 2% of the 20% baseline conversion rate is 10% – this is your estimated MDE for the experiment.
Step 2. Calculate your sample size
Next step is to get your sample size, using the Evan Miller’s calculator for sequential A/B testing.
You will see the following:
Control wins if: 2,922 total conversions – this is the maximum sample size per two variations (A+B) needed to finish the experiment.
Treatment wins: 106 conversions ahead – means that the system will sequentially check the difference in conversions between variation A (control) and B, and may finish the experiment once the difference of 106 is found, even before reaching the maximum sample size.
Why? Each pair of variations has its individual significance level. As the number of variations under testing grows, so does the overall significance level because those individual values accumulate. The Sidak correction balances out individual significance levels so that the overall significance level equals 5%.
To apply the Sidak correction, use the following significant level values:
The total conversions will appear after you insert all the above in the calculator.
For example, you want to run an experiment with 3 variations – A+B+C. Things you’ll insert in the calculator will be:
Total conversions required: 3,472
In the above example with 3 variations, you’ll get:
total conversions / 2 = 3,472 / 2 = 1,736
Back to the example, as you run an A+B+C experiment, 3 will be your multiplier:
total conversions / 2 * 3 = 5,208
5,208 is the rough estimation of the maximum sample size for an experiment with 3 variations (A+B+C).
Step 3. Calculate your traffic acquisition costs
In step 2, we’ve calculated the maximum required conversions for an experiment with two variations (A+B) – 2,922. Now that you know the maximum required sample size, you can calculate the possible traffic acquisition costs. Use this formula:
traffic acquisition costs = total conversions / baseline conversion rate * Сost per Сlick
Note: By dividing the total conversions by your baseline conversion rate you gauge your sample size in visitors (those who click on your ad banner).
When you have SplitMetrics integrated with Facebook Pixel, you may configure “Complete Registration” as a conversion event. In such a case, the traffic acquisition costs will be calculated considering users who click on the “Get” button rather than those who click on an ad banner.
The formula for cost calculations in such cases will include Cost per Install (not Сost per Сlick):
traffic acquisition costs = total conversions x CPI
Note: As you can see, you don’t have to recalculate sample size in visitors. Just multiply CPI by the total conversions obtained in the Evan Miller calculator.
At this point, you have to make sure that these costs line up with the budget allocated for the traffic acquisition:
Step 4. Calculate the potential revenue
You may use different ways to calculate the potential revenue from the conversion rate lift, for example, based on the LTV of ASO-acquired app subscribers. In the above described example with two variations (A+B), you have to calculate how much money you will generate from a 2% conversion rate lift.
Once you have your Potential revenue ($Y) calculated, compare it with the Traffic acquisition costs ($X):
5. At what experiment stage should I set MDE?
MDE is configured after the experiment is created but before you start driving traffic. If you change your MDE after the traffic starts driving to the experiment, you will lose all the statistics.
6. Can I change my MDE during the experiment?
Don’t modify MDE after you start driving traffic to your experiment. Otherwise, all the statistics – visitors, conversions, improvement, etc. – will be reset.
7. How does SplitMetrics calculate my MDE?
To arrive at your best possible MDE, our algorithm will rely on your baseline conversion. Your ideal MDE will be the value which produces a sufficiently large sample size, yet comparable to that in classic A/B testing.
If SplitMetrics calculates MDE for you, be aware that the result won’t appear straight away. The algorithm will gauge and display your MDE in the interface after your variations gain enough conversions.
Part 1: A better way to think about “Minimum Detectable Effect
The Minimum Detectable Effect or MDE has always baffled me, and not because it’s a difficult concept to understand but rather because most people working in the field of experimentation have been using it counter-intuitively for so long.
For the record, I don’t think any of what I’m about to write is groundbreaking, but having worked in this field for many years, I’ve not seen anyone talk about it so I thought I would. Who knows, maybe you’ll disagree with me.
How are people currently using MDE?
The MDE is one of several inputs used to calculate the sample size required for an experiment along with:
– α: the selected level of significance
– β: the selected power
– σ: the standard deviation
– μ1 or p1: the baseline mean or proportion
– μ2 or p2: the proposed/expected new mean or proportion (this is where our MDE currently sits)
– r: ratio of groups (usually 1 assuming equal sample size)
– ni: sample size per variant
To calculate μ2 or p2, experiment owners are expected to estimate some percentage uplift they think a test or feature will drive — usually with very little reasoning. All of these values are then entered into one of the two formulas below:
Sample size for means (AOV, ARPU, Order Frequency)
Sample size for proportions (Conversion rate, sign up rate)
Whether you do this “by hand” or using an online calculator, you enter the inputs and hey presto, you have your sample size.
This is where I’ve found the use of MDE to be counter-intuitive. Most people can make a fairly accurate estimate of how many visitors they’re likely to get in a 1,2,3…n week period, but what they don’t usually know is the effect size they can measure with the visitors available to them. This results in:
a) people playing a game of trial and error with MDE until the value they’ve entered spits out a sample size that matches their available traffic over a time period they deem to be acceptable.
Or
b) they realise that their estimated effect size is too high (returning a very small sample size) or too low (returning a sample size that’s too large) at which point they jig things around anyway.
So, if there is a minimum period of time (e.g. 1 week) and some maximum period of time (e.g 4 weeks) that you’d want to run a test for, why do the MDE dance? Why not just treat MDE as a function of sample size and calculate what it would be for 1,2,3,4…n weeks? i.e. Move MDE from an input variable to an output variable. Once you know that, you can make a better decision on how long you want to run the test. Or, if you’re an analyst and you’re doing these calculations, you can provide a range to the experiment owner and show them what’s achievable with the traffic available to them. It will also give them a steer on how ambitious their tests can afford to be. Let’s face it, most of us don’t have Facebook’s level of traffic so knowing what minimum effect size we can detect is critical for test planning.
So why do the formulas above require us to input an MDE?
I don’t know but based on the countless clinical trial papers I’ve read, I would say it’s because most of the Mathematical formulas we use were born out of a necessity to understand the impact of medical intervention on patients. Therefore, having a robust and ethical way to ensure that the right number of patients were part of the medical study with meaningful effects based on countless research and past trials probably had something to do with it.
Luckily for us, we carry none of that burden, we don’t have to worry much about ethics and we can “enrol patients” by the thousands with a flick of a switch. What we don’t have is meaningful lab research or past trials to make a reliable estimate of the effect size but knowing our traffic volumes means we can simply rearrange the formula and make MDE the subject and make an educated guess on whether or not the output is achievable with our “intervention”.
In Part 2 I’ll be sharing what our newly arranged formula will look like and if that’s going to give you a headache (which it probably will) then a little trick in excel to do the rearranging for you.
You can follow me on Twitter or with minimal effort you can follow me and CRAP Talks on Medium.
Увеличиваем чувствительность экспериментов при помощи ранговой трансформации
Это перевод статьи booking.ai про увеличение чувствительности метрик в экспериментах с маленькими эффектами.
Описанная ниже методика трансформации позволяет увеличить скорость проведения эксперимента. В предыдущей статье в нашем блоге, мы рассказывали про метод CUPED, который в том числе позволяет ускорять A/B. Крайне желательно сначала изучить как работает CUPED перед прочтением этой статьи.
Записывайтесь на следующий поток интенсивного курса по математической статистике и A/B-тестированиям, который пройдет в октябре 2020 г.
A/B тесты и математическая статистика
Как проходит проверка домашних заданий? После каждой лекции даются задачи для работы в интерактивном калькуляторе…
Для Booking.com контролируемые онлайн эксперименты (A/B тестирование) — это ключевой способ измерения и оценки изменений на сайте, а также основной источник информации для принятия решений (Kaufman, Pitchforth, & Vermeer, 2017). Учитывая размеры и масштаб Booking.com, повышение метрики даже на долю процента приносит существенные для бизнеса результаты. (Jackson, 2018). Мы давно прорабатываем тему повышения чувствительности экспериментов. Это позволяет нам выявлять менее масштабные эффекты или же работать с меньшей выборкой (или в более короткие сроки) и таким образом ускорять разработку. В частности, для повышения чувствительности экспериментов мы часто используем метод CUPED (контролируемый эксперимент с использованием данных “до эксперимента”).
Однако классические методы A/B тестирования (такие как двухвыборочный независимый t-тест) могут быть недостаточно чувствительными, когда распределение данных далеко от нормального — даже с учетом использования методов уменьшения дисперсии вроде CUPED. В основе t-теста лежит предположение о нормальном распределении данных. Эмпирически, это предположение не всегда соответствует реальности.
К примеру, на рис. 1. изображено распределение реальной метрики, которое мы зафиксировали на Booking.com. Метрика сильно искажена целым рядом отклонений.
Исследования показывают, что t-тест достаточно устойчив к отклонениям от нормального распределения при условии что объем выборки достаточно большой. Однако, нельзя сказать наверняка, насколько именно “большой” должна быть выборка и достаточно ли она велика для решения отдельно взятой проблемы. Если мы не знаем природы и степени отклонения от взятого за основу предположения о нормальном распределении, то мы и не можем предугадать величину ошибок, которые появятся в результате этого предположения. (Colquhoun, 1971).
В этой статье мы предлагаем проводить t-тест не на изначальных данных, а на рангах, присвоенных этим данным — как способ повышения чувствительности экспериментов в ситуациях вроде той, что описана выше. Мы также хотим подчеркнуть, как важно понимать базовые интересы бизнеса, уделять внимание распределению данных и проводить моделирование чувствительности при выборе статистических методов.
Во-первых, мы покажем, что из себя представляет ранговая трансформация и продемонстрируем, что проведение t-теста на рангах дает примерно такие же результаты, как при применении непараметрического U-критерия Манна-Уитни.
Далее мы разберем реальные примеры с Booking.com, которые показывают, как увеличилась чувствительность экспериментов в результате применения t-теста к рангам данных. В конце статьи мы приводим конкретные рекомендации: когда использовать ранговую трансформацию в коммерческом A/B тестировании, а когда не стоит.
Ранговая трансформация
Метод
Ранговая трансформация — это просто преобразование данных путем присвоения им рангов. Таким образом, параметрический тест (например, t-тест) проводится не на самих данных, а на рангах. Данные из контрольной и тестовой выборок ранжируются вместе от меньшего к большему, а при наличии связей присваивается средний ранг.
В нашем примере в исходных данных есть большой выброс (нижний ряд). Исходное значение метрики — 100, и это сильно исказило бы статистику, если бы мы работали с самими данными,. Однако величина выброса не влияет на ранг. Самому большому значению будет присвоен ранг 6 — и не важно, 100 это или 3.
Как вариант, при распределении трафика в эксперименте 50/50, трансформацию можно определить как:
где N — это общий размер выборки. С точки зрения мощности эксперимента, трансформация сравнима по эффективности с простым ранжированием элементов выборки, но интерпретируемость трансформированной метрики лучше — и вот почему:
Взаимосвязь между t-тестом на рангах и U-критерием Манна-Уитни
Проведение t-теста на рангах данных дает примерно такие же результаты, как применение непараметрического U-критерия Манна-Уитни. Когда применение U-критерия Манна-Уитни к инфраструктуре, с которой вы работаете, не представляется возможным, практически эквивалентной альтернативой будет t-тест на рангах, который, к тому же, достаточно прост в проведении.
Поскольку U-тест Манна-Уитни — непараметрический, он не предполагает какого-то конкретного распределения данных. Нулевая гипотеза звучит так: случайно выбранное значение из одной выборки может быть равновероятно больше или меньше случайного значения из другой выборки. Или в виде формулы:
В то же время у t-теста другая нулевая гипотеза: что средние значения в двух выборках равны:
Таким образом, принимая решение о применении того или иного теста для решения наших задач, мы будем руководствоваться именно нулевой гипотезой.
Измерим при помощи вывода формул и моделирования, насколько “эквивалентными” являются t-тест на рангах и U-критерий Манна-Уитни. (Zimmerman, 2012).
Мы знаем, что по двухвыборочному t-тесту для независимых выборок у нас есть t-статистика:
где n — это объем выборки для выборки X, m — это объем выборки для выборки Y. N = n+m, а t-статистика сравнивается с квантилями из t-распределения с N-2 степенями свободы.
В непараметрическом U-тесте Манна-Уитни, мы заменяем значения данных на присвоенные им ранги Rᵢ от 1 до N и используем статистику (с поправкой на связи в рангах).
Рост продуктов через эксперименты — инструкция по Growth-процессу
Наблюдая за работой множества маркетинговых команд, заметил, что многие допускают одни и те же ошибки в процессе поиска, приоритизации и тестирование гипотез.
В этой статье я расскажу о Growth-процессе, постараюсь дать сложный материал максимально просто.
О чем поговорим в статье
1. Идея ≠ гипотеза.
2. Формируем бэклог гипотез.
3. Приоритизация гипотез и скоринг по ICEs и PXL-фреймворку.
4. Дизайн эксперимента.
5. Подготовка к тестированию.
6. Проведение эксперимента.
7. Анализ и статистическая значимость.
8. Внедрение.
Дисклеймер: в материале основные мысли и схема работы, но без углубления в тонкости, полагая, что читатель поймет куда копать, так как основной фреймворк уже будет дан.
При написании я ориентировался на маркетинговые и Growth-команды, учтите, что для других команд процесс может не подойти.
Идея ≠ гипотеза
Перед тем как приступить к основному процессу, нужно внедрить в команду мышление, основанное на гипотезах. Важно понимать, что идея, в первоначальном своем виде, еще не является гипотезой.
Основной плюс гипотез в том, что они измеримы. Вы точно понимаете, какие метрики вы улучшите, если начнете тестировать гипотезу.
Формула гипотезы
«Действие [X] позволит увеличить метрику [Y] на величину [Z], потому что [N]».
Давайте на примере разберем отличия.
Идея:
«Нужно сократить форму онлайн-заявки с 5 до 4 шагов, я думаю, что мы увеличим конверсию в регистрацию».
Гипотеза:
«Если мы сократим форму онлайн-заявки с 5 до 4 пунктов, то увеличим конверсию в регистрацию на 1 процентный пункт с 2% до 3%, потому что в системе аналитики мы видим, что часть пользователей уходит на шаге 4, так и не завершив регистрацию».
Если идею не получается привести в вид гипотезы, то от неё стоит отказаться. Правильно составленная гипотеза убивает бессмысленные действия, которые никак не влияют на метрики.
Формируем бэклог гипотез
Мы определились, что такое гипотеза, и чем она отличается от идеи.
Теперь пришло время наполнять бэклог гипотезами.
Бэклог гипотез — единая база, где находятся наши гипотезы в упорядоченном виде.
Помните, что тест гипотез стоит денег (время разработчика, аналитика, маркетолога, дизайнера и т.д.), и если вы понимаете, что гипотеза никак не влияет на метрики, не добавляйте её.
Все гипотезы, если мы говорим про IT-продукты, можно вписать в воронку AAARRR (на иллюстрации выше я её схематически изобразил).
Анализируя каждый шаг воронки, мы сможем найти большее количество точек роста по каждому из шагов.
К примеру, берем шаг acqusition и анализируем все каналы привлечения в разрезе по каналам/кампаниям/группам/креативам и т.д., в ходе анализа записываем гипотезы, которые значимо могут улучшить привлечение новых пользователей.
Какие еще инструменты нам помогут в поиске точек роста:
Рекомендация по формированию бэклога:
Приоритизация гипотез и скоринг по ICEs и PXL
Мы наполнили бэклог и распределили гипотезы по шагам воронки AAARRR, теперь важно понять, какие гипотезы мы тестируем в первую очередь.
Итак, мы плавно приходим к приоритизации и скорингу.
Представьте, что гипотезы в бэклог добавляют все сотрудники отдела и каждый хочет, чтобы его гипотеза была первой в очереди на тестирование. Чтобы избежать недопонимания и конфликтов, процесс приоритизации и скоринга гипотез должен быть максимально прозрачным. В этом поможет фрейморк ICE Score.
Impact (Влияние) — демонстрирует, насколько идея положительно повлияет на ключевой показатель, который вы пытаетесь улучшить.
Confidence (Уверенность) — демонстрирует, насколько вы уверены в оценках влияния и легкости реализации.
Ease (Легкость реализации) — это оценка того, сколько усилий и ресурсов требуется для реализации этой идеи.
ICE Score = Impact х Confidence х Ease
Команда собирается вместе, и каждый её участник оценивает Impact, Confidence и Ease по шкале от 1 до 10. Далее оценки каждого сотрудника умножаются между собой и складываются со значениями других сотрудников, так мы получаем ICE Score по каждой гипотезе.
Ниже приведена таблица для примера.
Подробнее разберем, как распределяются оценки по шкале от 1 до 10.
Тут все просто, чем больше влияние на ключевые метрики — тем выше оценка в таблице.
Есть только один способ рассчитать confidence — это поиск подтверждающих доказательств. Для этого вы можете создать собственную карту по распределению оценок по шкале от 1 до 10, это поможет команде выставлять оценки более прозрачно и исключить разброс оценок, когда один сотрудник ставит 1, а другой сотрудник — 10.
В карте перечислены общие типы тестов и доказательств, которые могут быть у вас, и уровень уверенности, который они предоставляют: результаты тестов, дата лонча, собственная уверенность, данные рынка, мнение других людей и др.
Легкость реализации вы оцениваете в соответствии со скоростью работы вашей команды.
Учтите, что время и оценки для каждой команды указываются индивидуально, если у вас реализация гипотезы рассчитывается в днях, а не в часах — указывайте дни.
Пример расчета Ease:
Как опробуете ICEs и захотите сделать скоринг более точным, то можете перейти к PXL-фреймворку. Подробнее про PXL-фреймворк можете почитать по ссылке.
Видов скоринга и приоритизаций много, вы можете подстроить уже имеющийся или сделать свой фреймворк, который подойдет именно вашей команде. Главное тут, чтобы скоринг помог вам в работе, использовать фреймворк ради самого фреймворка не нужно.
Дизайн эксперимента
Мы приоритизировали гипотезы, и теперь нужно составить дизайн эксперимента.
Дизайн эксперимента — подробное техническое задание по тестированию нашей гипотезы, и нужен он для того, чтобы понимать, что мы тестируем, на какой выборке и какие метрики считаем.
Дизайн эксперимента строится по такому шаблону:
Берем гипотезу из бэклога.
В нашем случае она выглядит так:
Если мы сократим форму онлайн-заявки с 5 до 4 пунктов, то увеличим конверсию в регистрацию на 1 процентный пункт с 2% до 3%, потому что в системе аналитики мы видим, что часть пользователей уходит на шаге 4, так и не завершив регистрацию.
Контрольная версия: оставляем все, как есть.
Тестовая версия: сокращаем форму онлайн-заявки с 5 до 4 пунктов.
На каких пользователях тестируем:
Только на новых пользователях.
Конверсия в регистрацию.
Если наш эксперимент будет положительным, и мы увидим улучшение в метриках (CR в регистрацию будет > 3%) — масштабируем на всех пользователей.
Если метрики падают, то откатываем.
Если метрики не меняются, то оставляем, как есть.
Перед запуском эксперимента обязательно обговорите и согласуйте план дальнейших действий, что собираетесь предпринять по факту получения результатов. Так вы избавитесь от ситуаций, когда тест прошел, а Product Owner в итоге не собирается внедрять эксперимент.
Подготовка к тестированию
Прежде чем запустить эксперимент, нужно сделать несколько подготовительных шагов.
1. Определитесь с видом тестирования
Выберите, какой вариант тестирования подойдет вам.
Вот несколько возможных вариантов:
2. Рассчитайте размер выборки, доверительный интервал и мощность
Перед запуском определите, сколько пользователей нужно привлечь на каждый из вариантов А/B-теста, чтобы данные в итоге получились статистически значимыми.
Воспользуемся калькулятором Эвана Миллера для расчёта выборки (смотрите скриншот ниже).
В «Baseline conversion rate» указываем конверсию контрольной версии, в нашем случае 2%.
В «Minimum Detectable Effect» указываем на сколько процентов увеличится конверсия контрольной версии, в нашем случае на +1%.
Significance level α (уровень доверия) — это уровень риска, который вы принимаете при ошибках первого рода (отклонение контрольной версии теста, если она верна), обычно α = 0.05.
Это означает, что в 5% случаев вы будете обнаруживать разницу между A и B, которая на самом деле обусловлена случайностью.
Чем ниже выбранный вами уровень значимости, тем ниже риск того, что вы обнаружите разницу, вызванную случайностью.
Statistical power 1−β (статистическая мощность) — это ошибки второго рода, вероятность того, что мы на выборке примем тестовую версию, если на самом деле она верна (шанс обнаружить эффект, если он на самом деле есть). При планировании эксперимента нужно помнить, что мощность должна быть разумно высокой, чтобы обнаружить отклонения от контрольной версии. Если вы не знаете, какой процент показателя стоит указать, оставьте значения по умолчанию (80%).
В итоге мы понимаем, что для корректного теста нам нужно по 3 292 пользователей на каждый из вариантов А/B-теста.
Далее можем рассчитать, сколько конверсий мы должны получить, и какая разница между ними должна быть, для получения статистически значимого результата.
Для корректного анализа мы должны получить 170 конверсий, и разница между версиями A/B-теста должна быть более 26 конверсий.
4. Рассчитайте длительность эксперимента
Возьмите размер выборки, полученный при расчете для тестирования каждой версии, и разделите его на ваш ежедневный трафик, так вы получите количество дней, необходимое для проведения теста.
Тест проводите как минимум одну полную неделю, т.к. данные в выходные могут отличаться от будней.
5. Подготовьте инструментарий для тестирования
Мы рассчитали, сколько нужно трафика и конверсий для статистически значимого эксперимента, теперь нужно выбрать сам инструментарий для тестирования.
Инструментарий состоит из двух основных блоков:
1. Источник трафика.
Подготовьте источник трафика, настройте рекламные кампании.
2. Системы распределения трафика между версиями A и B.
Тут можно пойти двумя путями: сделать собственный инструмент по распределению трафика между версиями, прибегнув к помощи разработчиков, или воспользоваться сторонними сервисами, такими как:
6. Убедитесь в чистоте эксперимента
Перед запуском теста убедитесь, что между двумя тестовыми версиями нет разницы.
Не должно быть технических различий в версиях или в трафике, так как любые различия влияют на чистоту эксперимента.
Для максимальной чистоты перед стартом проводят A/A-тестирование. В отличии от A/B-тестирования, в A/A мы тестируем две одинаковые страницы (элементы). Цель эксперимента — не увидеть различий в их показателях.
7. Настройте системы аналитики
Перепроверьте системы аналитики, убедитесь, что все нужные для эксперимента метрики работают корректно.
Частая ошибка — запуск теста без проверки систем аналитик и метрик, в итоге тратится время специалистов, бюджеты, и всё проводится зря.
8. Настройте сегменты для тестирования
Возвращаясь к дизайну эксперимента вспомним, на каких пользователях проводим эксперимент.
У нас было указано: «Только на новых пользователях».
В системе распределения трафика или рекламной системы мы должны отминусовать повторно вернувшихся пользователей.
И сделать абсолютно идентичные рекламные кампании (если вы проводите тест не на органике).
Проведение эксперимента
Перед стартом проверьте, действительно ли всё корректно работает. Перепроверьте всё еще раз и запускайте эксперимент.
По ходу эксперимента отслеживайте проблемы с трафиком и с системами тестирования, устраняйте их по мере появления.
Рекомендации по проведению эксперимента.
1. Не делайте преждевременных выводов.
Доводите эксперимент до конца, даже если вы в первый день видите статистически значимое улучшение в тестовой версии.
Проблема принятия преждевременных решений называется «Peeking problem» или «Проблема подглядывания».
Чем чаще вы смотрите на промежуточные результаты A/B-теста с готовностью принять на их основе решение, тем выше становится вероятность, что критерий покажет значимую разницу, когда ее нет.
Посмотрите картинку ниже, она отлично иллюстрирует всю суть «Peeking problem».
Если бы мы не знали о проблеме подглядывания, то завершили эксперимент на четвертый день, решив, что тестовая версия значительно лучше, и проводить эксперимент дальше нет смысла.
Но доведя эксперимент до конца мы поймем, что устойчивой измеримой разницы между группами нет.
Нужно понимать, что разница конверсий может периодически выходить за границы зоны неразличимости по мере накопления наблюдений, даже если мы тестируем идентичные версии.
Это совершенно нормально, так как границы сформированы таким образом, чтобы при тестировании одинаковых версий лишь в 95% случаев разница оказывалась в их пределах.
Для того чтобы не попасться на крючок «Peeking problem», перед стартом мы рассчитываем размер выборки и длительность проведения эксперимента. Следуйте намеченному плану.
2. Имейте систему экстренного отключения тестирования
Если проводите тестирование на самописном сервисе, то желательно иметь систему экстренного отключения тестирования и анализа аномалий, так как эксперимент может сломать продукт.
Анализ и статистическая значимость
Мы провели эксперимент и получили данные.
Теперь нам нужно понять, изменение, которое мы получили в метриках между версиями А и B, связано с нашей гипотезой или со случайностью.
Другими словами, является ли изменение статистически значимым или нет.
В нашем примере мы получили такие данные:
Выборка A: 3 292 сеансов, 67 конверсий.
Выборка B: 3 200 сеансов, 99 конверсий.
Воспользуемся калькулятором для расчёта статистической значимости.
P-value = 0.000691, то есть вероятность увидеть наблюдаемое различие при идентичных тестовых группах очень мала. Значит, можно с высокой степенью уверенности связать рост метрики с нашими изменениями.
A/B-тест подтвердил нашу гипотезу, тестовая версия статистически значимо лучше контрольной.
Получив статистически значимый результат, не спешите масштабировать его на всех пользователей. Не рискуйте и проверьте еще раз полученные данные.
Убедитесь, что не было пересечения выборок и аномалий.
Не должно быть такого, что один и тот же пользователь попал в две выборки, иначе вы рискуете достоверностью полученных данных.
Но что, если между версиями нет разницы, или тестовая версия значимо хуже?
Готовьтесь к тому, что наша версия эксперимента может проиграть, что вполне нормально при частом тестировании.
По окончании эксперимента проведите ретроспективу, проанализируйте, почему ваша гипотеза проиграла.
Углубитесь в данные, проведите исследование пользователей, постарайтесь понять, почему тестовая версия не работает так, как ожидалось. Ведите общую с командой базу знаний (Confluence), место, в котором вы расписываете изначальные ожидания от эксперимента и последующий результат. Все эти данные, в свою очередь, помогут вам в следующих экспериментах.
Все мы ошибаемся, и это нормально.
Людям вообще свойственно переоценивать свою способность к рациональным и правильным решениям.
Есть отличный афоризм по этому поводу: «Ошибки — налог на развитие.»
Внедрение эксперимента
После положительного эксперимента должно идти его внедрение (замена контрольной версии на тестовую).
Проведение эксперимента без последующих действий бессмысленно.
Часто бывает такое, что получив статистически значимый результат (наша гипотеза подтвердилась), мы не можем её внедрить, т.к. изначально не прошли все стадии согласования. Заранее обдумайте все возможные проблемы при внедрении.
Вместо заключения
Независимо от того, был ли ваш тест успешным или нет, относитесь к каждому эксперименту, как к возможности для обучения.
Используйте то, чему вы научились, в работе со следующими гипотезами.