Внести изменение на уровне шаблона страницы с товаром в вашей CMS. Обычно на страницу выводится оба тестируемых элемента со свойством display:none, а затем на клиенте в зависимости от сегмента пользователя стиль одного из элементов меняется на display:block
По Закону Больших Чисел если обеспечить случайность распределения, то на бесконечности оно будет абсолютно равномерным.
Специально для Вас сделал еще пару скриншотов из того же теста, из которого делался скриншот в предыдущем комментарии, но за другой интервал: take.ms/t3pAb и take.ms/2igdy
Такая картина _должна_ быть. Пример с планшетами в статье показывает, как найти проблему в тесте и том конкретном случае на планшетах в тестовой версии ехала верстка, что искажало результаты теста.
Да, правильно. Тестирование изменения на небольшой выборке применяется довольно часто. Несколько лет назад, кажется, в блоге Яндекса на Хабре я читал, что они проводят тестирования нового алгоритма ранжирования примерно на 4% аудитории – на их трафике и это не долго.
Очень много вопросов, из ответов можно составить новую статью такого же объема. Постараюсь очень кратко выразить свои мысли по всем вопросам сразу.
Google Analytics – самый популярный инструмент в мире для веб-аналитики и вероятность его правильный работы в общем случае максимальна (большое количество пользователей, репортящих проблемы, наибольшее среди аналогов количество экспертов по настройке, максимальное количество обучающих материалов – есть даже шутка такая в профессиональной тусовке про Яндекс.Метрику и Google Analytics).
По этой же причине мы используем этот иструмент для тестирования эффективности нашей системы для наших клиентов – всем привычно. Для внутренней аналитики платформы Retail Rocket GA не используется, объемы не те – бесплатная версия имеет ограничение в 10 миллионов хитов в месяц, мы преодолеем его менее чем за полчаса :) Но в нашем личном кабинете и на промо-сайте Google Analytics, конечно же, установлена.
Распределить пользователей одинаково возможно. Нам не удалось добиться хорошего распределения и исключения других описанных в статье проблем «модными» инструментами вроде Visual Website Optimizer и Optimizely как раз по причинам, которые вы описываете, поэтому мы создали и поддерживаем open source библиотеку для проведения А/Б тестов. Результаты распределения трафика очень достойные, пример:
Такое распределение наблюдается по всем срезам. Достигается оно, в основном, за счет двух вещей:
Очень простой код, который только делит трафик и больше ничего. Никаких WYSIWYG-редакторов с манипуляциями DOM и прочих крутых фич.
Библиотека скачивается с GitHub, хостится сайтом и подключается синхронно в head
По последнему вопросу – все примеры из статьи касаются тестирования сайтов наших клиентов (интернет-магазинов) в состояниях «с Retail Rocket» и «без Retail Rocket» для оценки эффекта платформы на продажи магазина. Факторы же ранжирования товаров в конкретных алгоритмах могут быть самыми разными и зависеть от сегмента пользователя, его действий, свойств сущностей, с которыми он взаимодействовал, и даже погодных условий в его регионе. Какие-то вещи о наших подходах будем постепенно раскрывать, для этого мы и завели инженерный блог :)
А/Б тесты проводят на всей совокупности, так как стоимость тестирования от размера выборки не меняется. Другое дело, что тестирования альтернативной версии возможно на любой доли трафика, то есть новую версию сайта можно запустить на 10% трафика, тест по прежнему будет актуален, только статистической достоверности превосходства одной из вариаций придется ждать дольше.
В статье же упоминается проверка на размер выборки как таковой, очень важно убедиться, что она именно такая, как вы ожидаете. Одна из самых частых проблем – ожидаем, что тестируется 100% аудитории, а на самом деле – гораздо меньше.
И это намеренно – если мы не можем измерить эффект в тесте на всю аудиторию сайта – мы не сможем понять как тестируемое изменение влияет на бизнес в целом.
У каждого А/Б теста есть так называемый opportunity cost – запуская один тест, мы жертвуем возможностью запустить другой. Всегда нужно стремиться выявлять результат в эскпериментах для бизнеса, иначе cost рискует превысить profit.
Спасибо за комментарий! Вы говорите правильно, однако, с «искусственным» изменением не соглашусь. Весь посыл статьи в том, что с помощью А/Б тестов можно и нужно принимать решения на основе данных, а не на основе «мнения HIPPO» (highest paid person's opinion). Проблема в том, что на пути принятия таких решений можно допустить массу ошибок и в этой статье мы собрали наиболее частые.
Что касается конкретного примера про исполняемость заказов из статьи, тут дело вот в чем. При нормальном проведении А/Б теста исполняемость заказов между сегментами отличаться не должна. Мы вносим изменение в интерфейс сайта, которое делает его удобнее и помогает большему количеству людей покупать. Если же в одном из сегментов значительно падает исполняемость – на мой взгляд практически на лицо манипуляция тестом, то есть кто-то осознанно, находясь в одном из сегментов теста, оформляет заказы, чтобы исказить результаты эксперимента.
Говоря о промо-акциях, рассылках и т.д. – по Закону Больших Чисел на бесконечности мы должны получить абсолютно равномерное распределение аудитории по акциям, рассылкам и любым другим срезам между сегментами теста. В статье приводится несколько доводов о важности проверки такого распределения, а так же о получении статистической достоверности превосходства одного варианта над другим.
P.S.: про 10-20 тестов – имелось ввиду, что 10-20 магазинов независимо друг от друга проводят тестирование нашей системы.
У каждого бизнеса свои цели – у кого-то повысить рыночную стоимость компании, которая опирается на «размещенную выручку» (это устойчивый в ecommerce термин для стоимости товаров в оформленных заказах без учета исполняемости), а у кого-то – поднять операционную прибыль.
В Google Analytics можно создать сегмент, который включает только посетителей специфичной страницы или типа страницы, например, с помощью url-паттерна.
Такой режим был в GWO. Его использование опасно. Во-первых, в начале эксперимента, когда до статистической достоверности еще далеко, вариации обгоняют друг друга по эффективности по несколько раз в день. Во-вторых, его применение не учитывает возможного влияния внешних факторов, которые могут временно исказить картину эксперимента (удачная рекламная кампания, ссылка на вариацию на популярном сайте, СМИ и т.д.).
В профессиональной литературе обычно пишут «Посадочная страница». В русском интерфейсе Google Analytics, на сколько я помню, называют «Страницы входа».
«Расширила» — не совсем верный термин. На прошлой неделе по JS был только один project, без lessons, а на этой — так и вовсе без JS, только HTML. Надеюсь, они действительно «расширят» курс и не забросят JS, ведь только-только закончились основы…
Специально для Вас сделал еще пару скриншотов из того же теста, из которого делался скриншот в предыдущем комментарии, но за другой интервал: take.ms/t3pAb и take.ms/2igdy
Такая картина _должна_ быть. Пример с планшетами в статье показывает, как найти проблему в тесте и том конкретном случае на планшетах в тестовой версии ехала верстка, что искажало результаты теста.
Google Analytics – самый популярный инструмент в мире для веб-аналитики и вероятность его правильный работы в общем случае максимальна (большое количество пользователей, репортящих проблемы, наибольшее среди аналогов количество экспертов по настройке, максимальное количество обучающих материалов – есть даже шутка такая в профессиональной тусовке про Яндекс.Метрику и Google Analytics).
По этой же причине мы используем этот иструмент для тестирования эффективности нашей системы для наших клиентов – всем привычно. Для внутренней аналитики платформы Retail Rocket GA не используется, объемы не те – бесплатная версия имеет ограничение в 10 миллионов хитов в месяц, мы преодолеем его менее чем за полчаса :) Но в нашем личном кабинете и на промо-сайте Google Analytics, конечно же, установлена.
Распределить пользователей одинаково возможно. Нам не удалось добиться хорошего распределения и исключения других описанных в статье проблем «модными» инструментами вроде Visual Website Optimizer и Optimizely как раз по причинам, которые вы описываете, поэтому мы создали и поддерживаем open source библиотеку для проведения А/Б тестов. Результаты распределения трафика очень достойные, пример:
Такое распределение наблюдается по всем срезам. Достигается оно, в основном, за счет двух вещей:
По последнему вопросу – все примеры из статьи касаются тестирования сайтов наших клиентов (интернет-магазинов) в состояниях «с Retail Rocket» и «без Retail Rocket» для оценки эффекта платформы на продажи магазина. Факторы же ранжирования товаров в конкретных алгоритмах могут быть самыми разными и зависеть от сегмента пользователя, его действий, свойств сущностей, с которыми он взаимодействовал, и даже погодных условий в его регионе. Какие-то вещи о наших подходах будем постепенно раскрывать, для этого мы и завели инженерный блог :)
В статье же упоминается проверка на размер выборки как таковой, очень важно убедиться, что она именно такая, как вы ожидаете. Одна из самых частых проблем – ожидаем, что тестируется 100% аудитории, а на самом деле – гораздо меньше.
У каждого А/Б теста есть так называемый opportunity cost – запуская один тест, мы жертвуем возможностью запустить другой. Всегда нужно стремиться выявлять результат в эскпериментах для бизнеса, иначе cost рискует превысить profit.
Что касается конкретного примера про исполняемость заказов из статьи, тут дело вот в чем. При нормальном проведении А/Б теста исполняемость заказов между сегментами отличаться не должна. Мы вносим изменение в интерфейс сайта, которое делает его удобнее и помогает большему количеству людей покупать. Если же в одном из сегментов значительно падает исполняемость – на мой взгляд практически на лицо манипуляция тестом, то есть кто-то осознанно, находясь в одном из сегментов теста, оформляет заказы, чтобы исказить результаты эксперимента.
Говоря о промо-акциях, рассылках и т.д. – по Закону Больших Чисел на бесконечности мы должны получить абсолютно равномерное распределение аудитории по акциям, рассылкам и любым другим срезам между сегментами теста. В статье приводится несколько доводов о важности проверки такого распределения, а так же о получении статистической достоверности превосходства одного варианта над другим.
P.S.: про 10-20 тестов – имелось ввиду, что 10-20 магазинов независимо друг от друга проводят тестирование нашей системы.
www.startupvitamins.com/products/startup-canvas-experiment-fail-learn-repeat
Обратите внимание, что возможно использование и других команд, например -с или -d