А/Б тестирование в Google Optimize. Уровень «Полубог».

За последние пару месяцев я неплохо продвинулась в А/Б тестировании маркетплейса с помощью Google Optimize, выпытала секреты у гуру из продуктовой команды соседнего стартапа и нашла несколько лайфхаков, чем с удовольствием поделюсь с вами.

Кому интересно начать с более базовых вещей – прочитайте первую статью о том, как я подсела на А/Б тесты

Попапы и др.

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

Чтобы открыть календарик, нужно нажать на неприметную иконку Interactive mode в правом верхнем углу. После этого в интерактивном режиме кликаешь на поле – календарик открывается, затем выходишь из интерактивного режима кнопкой Exit. Календарик остается на странице и на нем теперь можно ставить эксперименты.

Карточки товаров

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

Итак, допустим я хочу увеличить и перекрасить заголовки в карточках товаров. Если выделить заголовок одной карточки и поменять его стиль – он поменяется только в этой карточке. Но на странице карточек может быть 10, 100, 10000… и меняться они будут в зависимости от действий пользователя.

Что делать?

Зажимаем Shift, выделяем парочку заголовком и видим в верхнем левом углу кнопку SELECT SIMILAR: 20

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

Скрывать нельзя показывать

Google Optimize неистово рекомендует установить Anti-flicker snippet чтобы страница скрывалась от пользователя до тех пор, пока не применятся изменения эксперимента.

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

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

Поэтому мы делаем так – новая фича выходит в продакшен в скрытом виде, а потом я ее показываю с помощью Google Optimize в одном из вариантов эксперимента.

Пример

Решили добавить в карточки товаров лейблы типа «Новая яхта», «Минимальный расход топлива» и др. Фронтендер добавляет в карточки div с лейблой в скрытом виде:

Моя задача – найти скрытый div в Google Optimize и показать его.

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

Иду в Optimize. Тыкаю в какой-нибудь из соседних с моим div-ом элементов и, двигаясь назад по строке, в которой отображается путь к текущему элементу, нахожу родительский div – благо он подсвечивается при наведении точно так же, как в браузере в Inspect mode.

Вижу посте него ссылку MORE, жму на нее и получаю список дочерних элементов. Выбираю второй (потому, что помню, что в коде мой div стоял на втором месте).

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

Дальше жмем на иконку Select element в левом верхнем углу. В открывшейся панельке нажимаем Add change и выбираем Style.

Вы еще со мной? Отлично, идем дальше.

За отображение элемента отвечает атрибут display. Если элемент скрыт – display имеет значение none, если элемент отображается – то block, inline и др. Поэтому, во всплывающем окне пишем display и Optimize подставляет текущее значение атрибута - none. Bingo! Значит мы нашли правильный div, который в настоящий момент скрыт.

Меняем значение none на block, жмем APPLY и видим красивенькую лейблу в карточке товара. Ура!

Теперь надо всего лишь повторить процедуру для еще одной карточки, потом выбрать обе лейблы, нажать SELECT SIMILAR и применить display: block ко всем выбранным элементам, как описано выше, чтобы отображать лейблы во всех карточках на странице, а не только в первой.

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

Почему? Как минимум три причины:

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

В какой-то момент мне начало казаться, что тесты вообще не дают осмысленного результата. Конверсии пляшут, ни один вариант не выигрывает, разные домены показывают разную вероятность выигрыша одного и того же варианта. Доверие к Гуглу зашаталось. И тогда я решила запустить A/A/B-test, чтобы проверить сам Google Optimize.

Создала довольно простой A/A/B test с единственным изменением – сделала жирными названия полей в фильтре. Запустила на 2-х крупных доменах - в Испании и Германии.

Хотя результаты пока еще статистически не значимые, на обоих доменах новый вариант работает лучше оригинального, что радует. Разброс вероятностей одинаковых вариантов на первом домене 38-44% и это вполне приемлемо, на втором пока 29-53%, что слегка волнительно и говорит о том, что нельзя 100% доверять Гугл Оптимайзу. Подожду еще несколько дней, чтобы получить более статистически значимые цифры.

Я уже об этом писала, но напишу еще раз. Не надо лениться проверять все варианты на всех разрешениях, устройствах и браузерах. Чтобы протестировать вариант, например, на телефоне – открываете главную страницу эксперимента, жмете на ссылку PREVIEW и выбираете пункт Share preview. Optimize выдает вам ссылку, которую можно вставить в любой браузер и посмотреть, как выглядит интерфейс.

Особенно рекомендую проверять тесты в Safari – браузер капризный, особенно мобильный.

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

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

Дымится ли мозг? Еще как! Но если каждый результат, отличный от 100%-но положительного воспринимать не как поражение, а как новую информацию к размышлению – тесты становятся инструментом познания и открывают огромные возможности для исследований.