Этот блог является четвертой частью серии блогов, состоящей из четырех частей, посвященной передовым практикам внедрения GCP Retail Search. Очень рекомендую начать с Части 1
В части 4 мы рассмотрим лучшие практики проведения экспериментов и A/B-тестирования.
(Основы A/B-тестирования и мониторинга не рассматриваются в этом блоге).
Рекомендации по сопоставлению идентификаторов эксперимента.
Идентификаторы эксперимента в основном необходимы для A/B-тестирования, то есть при сравнении Retail Search с существующим поисковым решением. Их также можно использовать для проведения экспериментов с полностью адаптированным сайтом Retail Search, где необходимо протестировать новую конфигурацию обслуживания/управление обслуживанием/ускорение и т. д. на контрольной группе.
Поле идентификатора эксперимента в пользовательских событиях представляет собой текстовый массив, позволяющий проводить более детальные измерения. Рассмотрим следующий вариант использования.
- Эффективность розничного поиска необходимо сравнить с контрольной группой.
- Необходимо измерить общую производительность
- Также необходимо измерить производительность только на мобильных устройствах.
- Также необходимо измерить производительность только на стороне настольного компьютера.
- Эффективность поиска и рекомендаций также необходимо измерять отдельно.
Чтобы добиться таких детальных и срезных измерений, нам может потребоваться в общей сложности 10 идентификаторов экспериментов, из которых 4 идентификатора эксперимента необходимо отправить в массиве идентификаторов экспериментов событий для каждого события.
Если мы хотим измерить общую эффективность, мы сравниваем показатели KPI, полученные на основе событий, с идентификаторами экспериментов для Control и Google.
Если мы хотим измерить эффективность мобильного поиска, мы сравниваем показатели, полученные на основе событий, с идентификаторами экспериментов Control_mobile. + Control_search против Google_mobile + Google_search
Соотношение иерархии категорий между контролем и тестированием.
Следует позаботиться о том, чтобы одни и те же продукты имели одинаковую иерархию категорий между контрольной и испытательной площадкой. Скажем, на контрольном сайте продукт футболки имеет иерархию категорий как [одежда › мужские › топы › футболки], и тот же продукт находится в другой иерархии категорий на тестовой стороне, например [мужские › популярные › топы]. Это будет приводят к разным результатам поиска и различным аспектам категорий между контрольным и тестовым сайтами. Эта проблема больше повлияет на возможности просмотра, поскольку категория страницы является входными данными для вызова просмотра (наряду с фильтрами).
Ux-паритет между тестовым и контрольным сайтом перед A/B-тестированием.
При подготовке сайта к A/B-тестированию, прежде чем реальный пользовательский трафик API поиска/рекомендаций будет подан в Retail Search (с правильным сопоставлением идентификаторов эксперимента), важно отметить соответствие UI/UX между сайтом с управляющим/устаревшим поисковым сервером и сайт с серверной частью Retail Search.
Рекомендуется провести тест на четность UX (обычно называемый тестом темного режима), который фокусируется только на аспектах, не связанных с релевантностью и рейтингом продукта. Некоторые вещи, которые необходимо проверить для данного поискового запроса, между страницами результатов поиска, созданными с помощью управляющей серверной части поиска, и страницами результатов поиска, созданными с помощью серверной части Retail Search.
- Отображается ли одинаковое количество граней? Если нет, то необходимо просмотреть фасетные характеристики, настройки атрибутов в Поиске розничной торговли. Это важно, поскольку фасеты помогают пользователям фильтровать и переходить к нужному продукту из первоначальных результатов поиска. Таким образом, более качественные и значимые аспекты будут означать, что пользователям потребуется меньше времени, чтобы найти нужный продукт. В противном случае это приведет к большему количеству кликов, увеличению прокрутки и т. д., что может затруднить поиск и в конечном итоге повлиять на конверсию и рейтинг кликов. Это также может привести к прекращению поиска. Таким образом, наличие схожих аспектов на контрольном и тестовом сайтах будет означать, что у пользователей нет несправедливого преимущества при поиске продуктов между ними.
- Размещение продуктов спонсоров в результатах поиска часто является общей чертой многих сайтов электронной коммерции, и в большинстве случаев продукты спонсоров не являются частью обычных результатов поиска. Следует позаботиться о том, чтобы размещение и продукты, показанные на странице результатов поиска между контрольным сайтом и испытательным сайтом, были почти одинаковыми, если не идентичными. В противном случае к измерению показателей эффективности дохода будет добавлен шум, и в зависимости от уникальности спонсируемых продуктов между контрольной и испытательной площадками шум может быть более высоким.
Другие аспекты пользовательского интерфейса, которые следует учитывать
- Одинакова ли информация о цене и скидках на контрольном и испытательном полигонах?
- Предлагает ли автозаполнение одинаковые варианты завершения поискового запроса?
- Значения фасетов имеют одинаковый порядок?
- Представлен ли список продуктов в одном стиле (список или сетка) и т. д.?
В заключение, важно иметь правильный UX-паритет перед проведением тестов. Это создаст равные условия при проведении A/B-тестов, а эффективность поиска можно будет измерить с минимальным шумом.
