3 Ошибки, которые сделают результаты вашего сплит-теста невалидными

Posted on by riasevastopol

«Имеется три вида лжи: неправда, статистика и наглая ложь»,
Марк Твен (Mark Twain)

Пара недель назад одна из компаний перечня Fortune 500 попросила Клэр Вигнон Кезер (Claire Vignon Keser), аналитика данных и эксперта по машинному обучению, проанализировать их программу сплит-тестирования.

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

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

В то время, когда дело доходит до тестов, через чур многие компании волнуются о вопросе «что?» (к примеру, о дизайне тестовых предположений), но не хватает заняты вопросом «как?», либо самим процессом опыта.

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

Практически, то, как вы проводите сплит-тесты — наиболее значимая часть работы оптимизатора.

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

  • Если вы лишь знакомитесь с понятиями оптимизации конверсии (CRO) и не принимаете яркого участия в анализе и разработке тестов, не стесняйтесь пропускать технические разделы.
  • Если вы — специалист в области CRO либо участвуете в анализе и разработке тестов, вам нужно обратить внимание на технические подробности.

Просматривайте кроме этого: Как трудятся сплит-тесты: памятка для гуманитариев

Неточность №1: у вашего теста через чур много вариаций

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

К тому же, это может оказать влияние на целостность данных.

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

Но неприятность с проведением более долгих тестов содержится в файлах cookie. Чем продолжительнее проводится тест, тем выше риск взять «нечистые» результаты. В случае если опыт продолжается больше 3-4 недель, то за это время люди смогут удалить собственные файлы cookie и опять перейти на ваш ресурс, заметив в этом случае другую версию тестируемого элемента.

«За 14 дней число людей, каковые имели возможность удалить cookie и сейчас способны оказать влияние на уровень качества вашей выборки, вырастает до 10%», Тон Весселинг (Ton Wesseling), основатель Online Dialogue.

Второй риск при тестировании нескольких вариантов содержится в том, что уровень значимости уменьшается с возрастанием числа трансформаций. К примеру, если вы используете общепринятый уровень значимости в 0,05 и решили протестировать 20 сценариев, то один из них достигнет уровня значимости случайно (20 * 0,05). А если вы тестируете 100 сценариев, то это число вырастает до пяти (100 * 0,05).

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

Хороший пример — 41 оттенок светло синий. В 2009 году, в то время, когда Google не имел возможности решить, какие конкретно оттенки светло синий будут генерировать наибольшее число кликов на странице выдачи поисковых результатов, маркетологи корпорации решили протестировать 41 оттенок. При уровне достоверности 95%, возможность получения фальшивого хорошего результата составила 88%. Попытайся маркетологи Гугл 10 оттенков, возможность взять фальшивое подтверждение составила бы 40%.

Подобно, 9% с тремя оттенками и менее 5% с двумя оттенками.

Это именуется проблемой множественного сравнения (Multiple Comparison Problem).

Вы имеете возможность посчитать возможность получения фальшивого хорошего результата, применяя следующую формулу:

1-(1-a)^m,

где m — общее число проверенных вариантов, a — уровень значимости. При коэффициенте значимости 0,05, уравнение будет смотреться так:

1-(1-0.05)^m либо 1-0.95^m.

Обойти проблему множественного сравнения разрешает поправка Бонферрони (Bonferroni correction), которая вычисляет уровень достоверности для отдельного теста при проверке более одного варианта либо догадки.

Википедия иллюстрирует поправку Бонферрони следующим примером:

«В случае если экспериментатор контролирует догадки, и желаемый уровень значимости для всего семейства тестов равен a, то поправка Бонферрони будет контролировать каждую отдельную догадку на уровне значимости a/m»

К примеру, если вы тестируете m = 8 догадку с желаемым а = 0,05, то поправка Бонферрони проверит каждую отдельную догадку при а = 0,05/8 = 0,00625».

Иначе говоря вам пригодится уровень значимости 0,0625%, что сходится с уровнем достоверности 99,375% (100% – 0,625%) для личного теста. Поправка Бонферрони достаточно консервативна и основана на предположении, что все тесты не зависят друг от друга. Однако, она демонстрирует, как пара сравнений способны исказить ваши эти, если вы неверно измеряете уровень значимости.

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

Возможность ложноположительного результата при уровне значимости 0,05:

Левая колонка: номер догадки либо вариации.
Правая колонка: возможность фальшивого подтверждения.

достоверности и Уровни значимости, нужные для поддержания 5%-ной возможности фальшивого хорошего результата, представлены в таблице ниже:

Левая колонка: число догадок либо вариаций;
Средняя колонка: нужный уровень значимости;
Правая колонка: нужный уровень достоверности.

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

Исходя из этого стоит принимать оба варианта в качестве победивших.

Просматривайте кроме этого: Методика проведения сплит-тестирования

Неточность №2: вы меняете настройки опыта в середине теста

Запустив опыт, доведите его до конца. Не изменяйте характеристики опыта, его цели либо дизайн вариаций в середине теста. И не поменяйте распределение трафика на варианты.

Изменение распределения трафика между вариациями на протяжении опыта повлияет на целостность ваших результатов. Это случится из-за неприятности, известной как «парадокс Симпсона» (Simpson s Paradox). Данный статистический парадокс появляется, в то время, когда мы замечаем тенденцию в различных группах данных — но при объединении групп тенденция исчезает.

Ронни Кохави (Ronny Kohavi) из Микрософт делится примером сайта, что приобретает миллион визитёров каждый день, включая субботу и пятницу. В пятницу 1% трафика направляется на тестовую версию, а в субботу данный процент возрастает до 50%.

Не обращая внимания на то что тестовый вариант показывает более высокую конверсию, чем контрольный, как в пятницу (2,30% против 2,02%) так и в субботу (1,2% против 1,00%), при объединении данных за два дня, результаты, по-видимому, ухудшаются (1,20% против 1,68%). Это связано с тем, что мы имеем дело со средними значениями. Эти субботы (сутки с нехорошей конверсией) оказали влияние на тестовую версию больше, чем эти пятницы.

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

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

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

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

Итак, скажем, вы запускаете тест, выделив 80% трафика на контрольную и 20% на тестовую версию. После этого, через пара дней, вы измените это распределение на 50/50. С этого момента все главные пользователи будут распределены соответственно.

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

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

Это не повлияет на целостность ваших результатов.

Как упоминалось ранее, «правило середины опыта» распространяется на цели теста и дизайн вариаций. Отслеживая пара целей в ходе теста, вы имеете возможность захотеть поменять главную цель в середине опыта. Не делайте этого.

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

Отслеживайте и придерживайтесь их.

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

Просматривайте кроме этого: 10 неточностей сплит-тестирования, каковые дорого вам обойдутся

Неточность №3: неверная сегментация по окончании тестирования

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

Не так скоро! Вы остановили тест, когда он достиг статистической значимости? Сохраняем надежду, что нет.

Статистическая значимость не должна диктовать вам, в то время, когда останавливать тест. Она только информирует, имеется ли отличие между контрольным и тестовым вариантами. Вот из-за чего вам не нужно ожидать, в то время, когда тест достигнет значимости (по причине того, что этого может не произойти) либо заканчивать опыт сразу после достижения значимости. Вместо этого, дождитесь, в то время, когда будет достигнут вычисленный размер выборки.

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

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

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

Но существует две главных неприятности с сегментацией по окончании теста. Они воздействуют на статистическую достоверность ваших сегментов:

  1. Величина выборки сегментов через чур мелка. Вы остановили тест, достигнув расчетного размера выборки, но на уровне сегмента размер выборки, возможно, через чур мелок, а лифтинг между сегментами не имеет статистической достоверности.
  2. Неприятность множественного сравнения. Чем больше сегментов вы сравниваете, тем выше возможность того, что вы получите от них фальшивый хороший итог. При уровне достоверности 95% вы, возможно, получите фальшивое подтверждение на каждые 20 рассмотренных сегментов по окончании теста.

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

Мы не выступаем против пост-тестовой сегментации — совсем напротив. На деле, изучение через чур громадного количества совокупных разрешённых может ввести в заблуждение (парадокс Симпсона причиняет ответный удар).

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

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

Заглавия колонок слева направо: визита страницы А; визита страницы В; конверсии страницы А; конверсии страницы В; коэффициент конверсии страницы А; коэффициент конверсии страницы В.

Парадокс Симпсона довольно часто появляется при неравномерной выборке — в то время, когда размер выборки ваших сегментов разен. Имеется пара способов борьбы с этим эффектом.

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

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

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

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

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

Просматривайте кроме этого: 5 обстоятельств проводить отдельные сплит-тесты для различных типов устройств

Вместо заключения

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

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

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

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

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

Высоких вам конверсий!

По данным: widerfunnel.com Источник изображения: Internet Archive Book Images

Случайные статьи:

Как провести сплит тестирование


Подборка похожих статей:

riasevastopol

More Posts