«Горячая» и часто обсуждаемая сегодня тема оптимизации конверсии привела к безусловной популяризации А/Б-тестирования, как единственного объективного способа узнать правду о работоспособности тех или иных технологий/решений, связанных с увеличением экономической эффективности для онлайн-бизнеса.
За этой популярностью скрывается практически полное отсутствие культуры в организации, проведении и анализе результатов экспериментов. В Retail Rocket мы накопили большую экспертизу в оценке экономической эффективности от систем персонализации в электронной коммерции. За два года был отстроен идеальный процесс проведения A/Б-тестов, которым мы и хотим поделиться в рамках этой статьи.
Два слова о принципах A/Б-тестирования
В теории все невероятно просто:
- Выдвигаем гипотезу о том, что какое-то изменение (например, персонализация главной страницы) увеличит конверсию интернет-магазина.
- Создаем альтернативную версию сайта «Б» — копию исходной версии «А» с изменениями, от которых мы ждем роста эффективности сайта.
- Всех посетителей сайта случайным образом делим на две равные группы: одной группе показываем исходный вариант, второй — альтернативный.
- Одновременно измеряем конверсию для обеих версий сайта.
- Определяем статистически достоверно победивший вариант.
Прелесть этого подхода в том, что любую гипотезу можно проверить с помощью цифр. Нет необходимости спорить или опираться на мнение псевдоэкспертов. Запустили тест, замерили результат, перешли к следующему тесту.
Пример в цифрах
Для примера представим, что мы внесли на сайт какое-то изменение, запустили А/Б-тест и получили следующие данные:
Конверсия — не статичная величина, в зависимости от количества “испытаний” и “успехов” (в случае интернет-магазина — посещений сайта и оформленных заказов соответственно) конверсия распределяется в определенном интервале с расчетной вероятностью.
Для таблицы выше это означает, что если мы приведем еще 1000 пользователей на версию сайта “А” при неизменных внешних условиях, то с вероятностью 99% эти пользователи сделают от 45 до 75 заказов (то есть сконвертируются в покупателей с коэффициентом от 4.53% до 7.47%).
Сама по себе эта информация не слишком ценная, однако, при проведении А/Б-теста мы можем получить 2 интервала распределения конверсии. Сравнение пересечения так называемых “доверительных интервалов” конверсий, получаемых от двух сегментов пользователей, взаимодействующих с разными версиями сайта, позволяет принять решение и утверждать, что один из тестируемых вариантов сайта статистически достоверно превосходит другой. Графически это можно представить так:
Почему 99% ваших А/Б-тестов проводятся неверно?
Итак, с вышеописанной концепцией проведения экспериментов знакомо уже большинство, про неё рассказывают на отраслевых мероприятиях и пишут статьи. В Retail Rocket одновременно проходит 10-20 А/Б-тестов, за последние 3 года мы столкнулись с огромным количеством нюансов, которые часто остаются без внимания.
В этом есть огромный риск: если А/Б-тест проводится с ошибкой, то бизнес гарантированно принимает неверное решение и получает скрытые убытки. Более того, если вы ранее проводили A/Б-тесты, то скорее всего они были проведены некорректно.
Почему? Разберем самые частые ошибки, с которыми мы сталкивались в процессе проведения множества пост-тест анализов результатов проведенных экспериментов при внедрении Retail Rocket в интернет-магазины наших клиентов.
Доля аудитории в тесте
Пожалуй самая распространенная ошибка — при запуске тестирования не проверяется, что вся аудитория сайта участвует в нем. Довольно частый пример из жизни (скриншот из Google Analytics):
На скриншоте видно, что суммарно в тесте приняло участие чуть менее 6% аудитории. Крайне важно, чтобы вся аудитория сайта относилась к одному из сегментов теста, в противном случае невозможно оценить влияние изменения на бизнес в целом.
Равномерность распределения аудитории между тестируемыми вариациями
Недостаточно распределить всю аудиторию сайта по сегментам теста. Также важно проделать это равномерно по всем срезам. Рассмотрим на примере одного из наших клиентов:
Перед нами ситуация, при которой аудитория сайта делится неравномерно между сегментами теста. В данном случае в настройках инструмента для тестирования было выставлено деление трафика 50/50. Такая картина — явный признак того, что инструмент для распределения трафика работает не так, как ожидалось.
Кроме того, обратите внимание на последний столбец: видно, что во второй сегмент попадает больше повторной, а значит и более лояльной аудитории. Такие люди будут совершать больше заказов и исказят результаты тестирования. И это ещё один признак некорректной работы инструмента тестирования.
Чтобы исключить подобные ошибки через несколько дней после запуска тестирования всегда проверяйте равномерность деления трафика по всем доступным срезам (как минимум по городу, браузеру и платформе).
Фильтрация сотрудников интернет-магазина
Следующая распространенная проблема связана с сотрудниками интернет-магазинов, которые, попав в один из сегментов теста, оформляют заказы, поступившие по телефону. Тем самым сотрудники формируют дополнительные продажи в одном сегменте теста, в то время как звонящие находятся во всех. Безусловно, подобное аномальное поведение в конечном счете исказит итоговые результаты.
Операторов call-центра можно выявить с помощью отчета по сетям в Google Analytics:
На скриншоте пример из нашего опыта: посетитель 14 раз заходил на сайт из сети под названием «Торговый центр электроники на Пресне» и 35 раз оформил заказ — это явное поведение сотрудника магазина, который по какой-то причине оформлял заказы через корзину на сайте, а не через панель администратора магазина.В любом случае, всегда можно выгрузить заказы из Google Analytics и присвоить им свойство “оформлен оператором” или “оформлен не оператором”. После чего построить сводную таблицу как на скриншоте, отражающую другую ситуацию, с которой мы сталкиваемся довольно часто: если взять выручку сегмента RR и Not RR (“сайт с Retail Rocket” и “без” соответственно), то “сайт с Retail Rocket” приносит меньше денег, чем “без”. Но если выделить заказы, оформленные операторами call-центра, то окажется, что Retail Rocket дает прирост выручки на 10%.
На какие показатели стоит обращать внимание при финальной оценке результатов?
В прошлом году проводился А/Б-тест, результаты которого оказались следующими:
- +8% к конверсии в сегменте “сайт с Retail Rocket”.
- Средний чек практически не изменился (+0.4% — на уровне погрешности).
- Рост по выручке +9% в сегменте “Сайт с Retail Rocket”.
После составления отчетов результатов мы получили такое письмо от клиента:
Менеджер интернет-магазина настаивал на том, что если средний чек не изменился, то эффекта от сервиса нет. При этом полностью игнорируется факт общего прироста выручки благодаря системе рекомендаций.
Так на какой показатель стоит ориентироваться? Конечно, для бизнеса самое важное — это деньги. Если в рамках A/Б-теста трафик делился между сегментами посетителей равномерно, то нужный показатель для сравнения — выручка (revenue) по каждому сегменту.
В жизни ни один инструмент для случайного деления трафика не дает абсолютно равных сегментов, всегда существует отличие в доли процента, поэтому необходимо нормировать выручку по количеству сессий и использовать метрику “выручка на посещение” (revenue per visit).
Это признанный в мире KPI, на который рекомендуем ориентироваться при проведении A/Б-тестов.
Важно помнить, что выручка от оформленных на сайте заказов и “исполненная” выручка (выручка от фактически оплаченных заказов) — это абсолютно разные вещи.
Вот пример А/Б-теста, в котором система Retail Rocket сравнивалась с другой рекомендательной системой:
Сегмент «не Retail Rocket» побеждает по всем параметрам. Однако, в рамках следующего этапа пост-тест анализа были исключены заказы call-центра, а также аннулированные заказы. Результаты:
Пост-тест анализ результатов — обязательный пункт при проведении A/Б-тестирования!
Срезы данных
Работа с разными срезами данных — крайне важная составляющая при пост-тест анализе.
Вот еще один кейс тестирования Retail Rocket на одном из крупнейших интернет-магазинов в России:
На первый взгляд мы получили отличный результат — прирост выручки +16.7%. Но если добавить в отчет дополнительный срез данных «Тип устройства» можно увидеть следующую картину:
- По Desktop-трафику рост выручки практически 72%!
- На планшетах в сегменте Retail Rocket просадка.
Как выяснилось после тестирования, на планшетах некорректно отображались блоки рекомендаций Retail Rocket.
Очень важно в рамках пост-тест анализа строить отчеты как минимум в разрезе города, браузера и платформы пользователя, чтобы не упустить подобные проблемы и максимизировать результаты.
Статистическая достоверность
Следующая тема, которую необходимо затронуть, — статистическая достоверность. Принимать решение о внедрении изменения на сайт можно только после достижения статистической достоверности превосходства.
Для подсчета статистической достоверности конверсии существует множество online-инструментов, например, htraffic.ru/calc/:
Но конверсия — это не единственный показатель, определяющий экономическую эффективность сайта. Проблема большинства А/Б-тестов сегодня — проверяется только статистическая достоверность конверсии, что является недостаточным.
Средний чек
Выручка интернет-магазина строится из конверсии (доли людей, которые покупают) и из среднего чека (размера покупки). Статистическую достоверность изменения среднего чека посчитать сложнее, но без этого никак, иначе неизбежны неверные выводы.
На скриншоте продемонстрирован очередной пример A/Б-теста Retail Rocket, при котором в один из сегментов попал заказ на сумму более миллиона рублей:
Этот заказ составляет почти 10% от всей выручки за период проведения теста. В таком случае, при достижении статистической достоверности по конверсии можно ли считать достоверными результаты по выручке? Конечно, нет.
Такие огромные заказы значительно искажают результаты, у нас есть два подхода к пост-тест анализу с точки зрения среднего чека:
- Сложный. «Байесовская статистика», о которой мы расскажем в следующих статьях. В Retail Rocket мы используем ее для оценки достоверности среднего чека внутренних тестов по оптимизации алгоритмов рекомендаций.
- Простой. Отсечение нескольких процентилей заказов сверху и снизу (как правило, 3-5%) списка, отсортированного по убыванию суммы заказа.
Время проведения теста
И напоследок, всегда обращайте внимание на то, когда вы запускаете тест и как долго он длится. Старайтесь не запускать тест за несколько дней до крупных гендерных праздников и в праздничные/выходные дни. Сезонность также прослеживается на уровне получения зарплат: как правило, это стимулирует продажи дорогих товаров, в частности, электроники.
Кроме того, существует доказанная зависимость между средним чеком в магазине и временем принятия решения до покупки. Проще говоря, чем дороже товары — тем дольше их выбирают. На скриншоте пример магазина, в котором 7% пользователей до покупки размышляют от 1 до 2 недель:
Если на таком магазине проводить А/Б-тест меньше недели, то в него не попадет около 10% аудитории и влияние изменения на сайте на бизнес однозначно оценить невозможно.
Вместо вывода. Как провести идеальный А/Б-тест?
Итак, для исключения всех описанных выше проблем и проведения правильного A/Б-теста нужно выполнить 3 шага:
1. Разделить трафик 50 / 50
Сложно: с помощью балансировщика трафика.
Просто: воспользоваться open source библиотекой Retail Rocket Segmentator, которую поддерживает команда Retail Rocket. За несколько лет тестов нам не удалось решить описанные выше проблемы в инструментах вроде Optimizely или Visual Website Optimizer.
Цель на первом шаге:
- Получить равномерное распределение аудитории по всем доступным срезам (браузеры, города, источники трафика и т.д.).
- 100% аудитории должно попасть в тест.
2. Провести А/А-тест
Не меняя ничего на сайте, передавать в Google Analytics (или другую систему веб-аналитики, которая вам нравится) разные идентификаторы сегментов пользователей (в случае с Google Analytics — Custom var / Custom dimension).
Цель на втором шаге: не получить победителя, т.е. в двух сегментах с одинаковыми версиями сайта не должно быть разницы по ключевым показателям.
3. Провести пост-тест анализ
- Исключить сотрудников компании.
- Отсечь экстремальные значения.
- Проверить значимость ценности конверсии, использовать данные по исполняемости и аннуляции заказов, т.е. учесть все кейсы, упомянутые выше.
Цель на последнем шаге: принять правильное решение.
Делитесь своими кейсами проведения A/Б-тестов в комментариях!
Комментарии (23)
playgrey
03.07.2015 13:08А как быть, если нужно протестировать, например, конверсию какой-то специфической страницы категории, которую в принципе не посещает 100% аудитории сайта?
nikolaykhl
03.07.2015 13:49В Google Analytics можно создать сегмент, который включает только посетителей специфичной страницы или типа страницы, например, с помощью url-паттерна.
playgrey
03.07.2015 14:16Да-да, спасибо. Я просто к тому, что в статье говорится «вся аудитория сайта», а не вся аудитория тестируемой страницы.
nikolaykhl
03.07.2015 14:19И это намеренно – если мы не можем измерить эффект в тесте на всю аудиторию сайта – мы не сможем понять как тестируемое изменение влияет на бизнес в целом.
У каждого А/Б теста есть так называемый opportunity cost – запуская один тест, мы жертвуем возможностью запустить другой. Всегда нужно стремиться выявлять результат в эскпериментах для бизнеса, иначе cost рискует превысить profit.
RuslanZavackiy
03.07.2015 13:14Статья неплохая, но вот стало интересно:
«Однако, в рамках следующего этапа пост-тест анализа были исключены заказы call-центра, а также аннулированные заказы.»
Почему были исключены анулированные заказы? И к анулированным заказам, были ли отнесены возвраты? Т.к если были, то это очень страно.
Магазин выполняет свою задачу, когда продает товар. Если товар возвращается, то в большинстве случаев, это проблема товара, и бизнес процессов и людей, которые решили продавать не качественный товар.
Например, вы сделали акцию, на товар на складе, чтобы его распродать, товара много. Весь распродали, конверсия увеличилась, но товар оказался не качественный и его весь вернули. Это не значит, что это нужно не учитывать. Т.к возможно для этого были сделаны разные улучшения, чтобы продать (или продавать и дальше этот товар).
В общем основной вопрос — почему исключили анулированные и были ли это тоже возвраты?
А так за статью спасибо. Хоть и PR статья, коих огромное кол-во. Но изложено доступно.nikolaykhl
03.07.2015 13:52У каждого бизнеса свои цели – у кого-то повысить рыночную стоимость компании, которая опирается на «размещенную выручку» (это устойчивый в ecommerce термин для стоимости товаров в оформленных заказах без учета исполняемости), а у кого-то – поднять операционную прибыль.
RuslanZavackiy
03.07.2015 14:01Как-то это не выглядит как ответ, я намекал на то, что вы таким решением «искусствено» изменили конверсию, чтобы она вам подходила. В статье не написано, почему так было сделано, и получается, что люди, которые не понимают «зачем» тупо начнут так делать и получать не верные результаты.
Я это говорю не просто так, т.к у нас интернет магазин, который входит в ТОП-100 в штатах по выручке. И наши задачи работают в обоих направлениях, просто мы не делаем такого разграничения как «срежем ка мы возвраты, т.к тогда цифра красивей». Тест должен идти достаточно времени, чтобы убрать эти выбросы.
Также, каждый день идут промо-акции, рассылки, которые приводят на сайт разные группы людей, на разные группы товаров, что усложняет однозначно и быстро дать ответ, что стало лучше или хуже.
Еще выглядит странным, что вы говорите о 10-20 A/B тестов, но не говорите о Multivariate A/B тестах. Т.к если идет паралельно не один тест а несколько, нужно учитывать все вариации A/B тестов, чтобы видеть, какая связка в совокупности дает наилучший результат.nikolaykhl
03.07.2015 14:17Спасибо за комментарий! Вы говорите правильно, однако, с «искусственным» изменением не соглашусь. Весь посыл статьи в том, что с помощью А/Б тестов можно и нужно принимать решения на основе данных, а не на основе «мнения HIPPO» (highest paid person's opinion). Проблема в том, что на пути принятия таких решений можно допустить массу ошибок и в этой статье мы собрали наиболее частые.
Что касается конкретного примера про исполняемость заказов из статьи, тут дело вот в чем. При нормальном проведении А/Б теста исполняемость заказов между сегментами отличаться не должна. Мы вносим изменение в интерфейс сайта, которое делает его удобнее и помогает большему количеству людей покупать. Если же в одном из сегментов значительно падает исполняемость – на мой взгляд практически на лицо манипуляция тестом, то есть кто-то осознанно, находясь в одном из сегментов теста, оформляет заказы, чтобы исказить результаты эксперимента.
Говоря о промо-акциях, рассылках и т.д. – по Закону Больших Чисел на бесконечности мы должны получить абсолютно равномерное распределение аудитории по акциям, рассылкам и любым другим срезам между сегментами теста. В статье приводится несколько доводов о важности проверки такого распределения, а так же о получении статистической достоверности превосходства одного варианта над другим.
P.S.: про 10-20 тестов – имелось ввиду, что 10-20 магазинов независимо друг от друга проводят тестирование нашей системы.
saboteur_kiev
03.07.2015 13:23+1Зашел почитать, потому что очень красивая девочка на фото.
За статью — спасибо. Вроде как читаешь, и все понятно, то есть прописные истины, но с приведенными примерами, понимаешь, что если бы делал тесты А/Б до того, как прочел уже оформленное в слова и пункты, точно где-нибудь налажал бы.
Теперь при случае буду дольше думать и не совершу совершу меньше ошибок.nikolaykhl
03.07.2015 13:48Эта девушка из магазина плакатов Startup Vitamins, такие плакаты висят в офисе Retail Rocket :)
www.startupvitamins.com/products/startup-canvas-experiment-fail-learn-repeat
Delfino
03.07.2015 19:34Крайне важно, чтобы вся аудитория сайта относилась к одному из сегментов теста, в противном случае невозможно оценить влияние изменения на бизнес в целом.
Почему оценка становится невозможной? А как же работают статистические опросы? По этой логике необходимо в каждом опросе опросить каждого гражданина России. Что неверно. В реальности опросы работают довольно хорошо.nikolaykhl
05.07.2015 21:09А/Б тесты проводят на всей совокупности, так как стоимость тестирования от размера выборки не меняется. Другое дело, что тестирования альтернативной версии возможно на любой доли трафика, то есть новую версию сайта можно запустить на 10% трафика, тест по прежнему будет актуален, только статистической достоверности превосходства одной из вариаций придется ждать дольше.
В статье же упоминается проверка на размер выборки как таковой, очень важно убедиться, что она именно такая, как вы ожидаете. Одна из самых частых проблем – ожидаем, что тестируется 100% аудитории, а на самом деле – гораздо меньше.Delfino
07.07.2015 14:35Выходит, что «оценить влияние изменения на бизнес в целом» все же возможно и без участия в тесте «всей аудитории сайта». Просто дольше, но не невозможно
Я правильно Вас понял?nikolaykhl
07.07.2015 19:15Да, правильно. Тестирование изменения на небольшой выборке применяется довольно часто. Несколько лет назад, кажется, в блоге Яндекса на Хабре я читал, что они проводят тестирования нового алгоритма ранжирования примерно на 4% аудитории – на их трафике и это не долго.
Alekseo
07.07.2015 09:43спасибо за статью; есть несколько комментариев, сори, если выглядит как критика, хочется обсудить несколько моментов
1) Использование GA — видимо чтобы было удобнее клиентам показывать результаты. Для внутренней аналитики тоже его используете или просто нет возможности размещать свой счетчик по условиям сотрудничества?
2) Один из самых важных этапов в такого плана тестах — фильтрация данных, GA убивает возможность что-то фильтровать практически полностью, т.к. нет исходных данных (по которым всегда нужно пробегаться глазами и убирать всякий мусор)
3) Про сотруников магазинов и лояльных старых посетителях сайтах писали многие, это важный баг при тестировании. Но еще очень много багов чисто техническая ошибка (отрабатывает или нет ява скрипт и т.п.) Опять же GA практически убивает возможности это дополнительно проверять.
4) Один из вариантов контроля ява скрипта, например, это дополнительный свой счетчик на картинках или т.п., который работает очень примитивно, но очень надежно (или логи). Тогда можно сверять макропоказатели в АБ тестах.
— 5) Все говорят что распределить хорошо пользователей по группам сложно, но никто не обсуждает детали. Наверное, какие-то наработки которые не хочется выдавать даже на уровне идеи.
6) Распределить пользователей одинаково невозможно, по крайней мере на разумных выборках порядка 500 тыс. человек на эксперимент. Допустим берем: география (4-5 кластеров городов), пол и возраст (6-8 групп), социальный статус (3 вида), устройство (3 вида), время захода (3 времени), новый или постоянный ну и еще 3-4 показателя.
невозможно все сделать равными, будут достаточно сильные просадки по какому-то показателю;
(могу скинуть числовой пример, интересно какое решение даже вручную можно предложить для таких цифр)
7) я лично не верю в историю о идеальном балансировщике. решение для меня лежит в том чтобы одни группы распределить равномерно, а другие группы обработать на уровне фильтрации и поправочных коэффициентов
8) Вы правда смотрите условно только две цифры уровень достоверности (при принятии решения)? У вас же есть данные в динамике по дням (а лучше — группам по часам), из этого можно выжать больше для анализа. Разве нет?nikolaykhl
07.07.2015 19:07Очень много вопросов, из ответов можно составить новую статью такого же объема. Постараюсь очень кратко выразить свои мысли по всем вопросам сразу.
Google Analytics – самый популярный инструмент в мире для веб-аналитики и вероятность его правильный работы в общем случае максимальна (большое количество пользователей, репортящих проблемы, наибольшее среди аналогов количество экспертов по настройке, максимальное количество обучающих материалов – есть даже шутка такая в профессиональной тусовке про Яндекс.Метрику и Google Analytics).
По этой же причине мы используем этот иструмент для тестирования эффективности нашей системы для наших клиентов – всем привычно. Для внутренней аналитики платформы Retail Rocket GA не используется, объемы не те – бесплатная версия имеет ограничение в 10 миллионов хитов в месяц, мы преодолеем его менее чем за полчаса :) Но в нашем личном кабинете и на промо-сайте Google Analytics, конечно же, установлена.
Распределить пользователей одинаково возможно. Нам не удалось добиться хорошего распределения и исключения других описанных в статье проблем «модными» инструментами вроде Visual Website Optimizer и Optimizely как раз по причинам, которые вы описываете, поэтому мы создали и поддерживаем open source библиотеку для проведения А/Б тестов. Результаты распределения трафика очень достойные, пример:
Такое распределение наблюдается по всем срезам. Достигается оно, в основном, за счет двух вещей:
- Очень простой код, который только делит трафик и больше ничего. Никаких WYSIWYG-редакторов с манипуляциями DOM и прочих крутых фич.
- Библиотека скачивается с GitHub, хостится сайтом и подключается синхронно в head
По последнему вопросу – все примеры из статьи касаются тестирования сайтов наших клиентов (интернет-магазинов) в состояниях «с Retail Rocket» и «без Retail Rocket» для оценки эффекта платформы на продажи магазина. Факторы же ранжирования товаров в конкретных алгоритмах могут быть самыми разными и зависеть от сегмента пользователя, его действий, свойств сущностей, с которыми он взаимодействовал, и даже погодных условий в его регионе. Какие-то вещи о наших подходах будем постепенно раскрывать, для этого мы и завели инженерный блог :)Alekseo
07.07.2015 19:51спасибо большое за ответ; очень мало интересной информации по АБ тестам доступно; на «американцев» надежды мало, они всегда общими словами отделываются, поэтому хочется верить что российский сервис чуть больше деталей расскажет. Поэтому и столько вопросов :)
— уточню про идеальное распределение пользователей
0. почему это может быть важно: вот вы делаете два среза tablet RR_recs и tablet not_RR_recs. В вашем случае разница очень большая, поэтому все очевидно и без учета возможного шума. Но может оказаться и так, что разница будет 5-10%. И если, например, что в «tablet RR_recs» по какой то причине будет 60% женщин, а в tablet not_RR_recs будет 40% женщин. То качество срезов будет критично для анализа результатов.
1. Почему балансировщику сложно. Как я написал есть около 8 параметров и по каждому от 2 до 8-10 групп. Итого может быть, например, порядка 5*8*3*3*3*3*3*6*3=175 тыс. комбинаций этих параметров.
Да, они не равновероятны, но все таки мы выбираем группы так, чтобы какое-то сравнимое количество было людей в них.
Теперь берем 500 тыс. человек в эксперименте. Получается в среднем по 3 чел. на комбинацию параметров.
2. Вопрос: как в теории разделить на 2 группы так, чтобы по каждому параметру было примерно равномерно?
3. Понятно что А/А тесты можно пройти и при достаточно простом делении, достаточно, например, брать последнюю цифру айпи адреса и достаточно качественное будет распределение. Но если аккуратно оценивать равномерность — как быть?
4. Поясню в чем примерно возникает затык.
Шаг 1. Берем 500 тыс. человек. Делим на 2 группы по полу (мужчины и женщины). 250 тыс. в одной и 250 тыс. в другой. Половина из 250 тыс. пойдет в А. Другая половина пойдет в Б, осталось только понять какая именно.
Шаг 2. Берем 250 тыс мужчин и делим на 5 групп по географии. Получаем условно по 50 тыс. в каждой.
Шаг 3. 50 тыс. делим на группы на время захода на сайт, получаем условно по 17 тыс. в каждой группе
и т.д.
Шаг 9. Получаем условно 10 человек. Из них 7 заходили с дестопа 2 с планшета и 1 с мобильного. И вот тут не делится на две части поровну.
И как не крути в каком-то срезе как правило будет перекос. Это чисто комбинаторно невозможно, если я не ошибаюсь.
5. Я думаю что вы используете вероятностный подход. С какой то вероятностью кидаете человека в какую то кучку.
6. Но вероятностный подход будет давать до 10-15% различия на каком-то срезе. Или у вас лучше результаты? Или вы не очень много срезов используете?
это можно легко проверить, просто возьмите эксперимент и посчитайте процентовку в А и в Б по следующим срезам (проверить — я имею в виду если вам интересно это для себя сделать):
-пол
-возраст
-источник трафика (на уровне поисковый/прямой/...)
-время дня
-устройство
-город (кластер по географии)
-новый/постоянный
-социальный статус/интересы
-страница входа (например, рубрика/товар)
nikolaykhl
07.07.2015 21:12По Закону Больших Чисел если обеспечить случайность распределения, то на бесконечности оно будет абсолютно равномерным.
Специально для Вас сделал еще пару скриншотов из того же теста, из которого делался скриншот в предыдущем комментарии, но за другой интервал: take.ms/t3pAb и take.ms/2igdy
Такая картина _должна_ быть. Пример с планшетами в статье показывает, как найти проблему в тесте и том конкретном случае на планшетах в тестовой версии ехала верстка, что искажало результаты теста.
AmirL
07.07.2015 20:35Не подскажете, как с помощью GA протестировать не отдельную страницу с товаром, а страницы товаров в целом?
nikolaykhl
07.07.2015 21:14Внести изменение на уровне шаблона страницы с товаром в вашей CMS. Обычно на страницу выводится оба тестируемых элемента со свойством display:none, а затем на клиенте в зависимости от сегмента пользователя стиль одного из элементов меняется на display:block
AmirL
10.07.2015 21:29в CMS я знаю как сделать, а вот GA просит при создании эксперимента указать два варианты страницы… А как их указать если есть два набора Всех страниц?…
Jamon
Спасибо за статью! Видимо, накипело )