Как автоматизировать тестирование метрик на сайте — история OZON.ru

32
2706
Материалы для скачивания

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

Клиенты периодически обращаются к нам с подробными проблемами, поэтому мы разработали решение для автоматического тестирования метрик на сайте. А компания OZON.ru стала первой, кто его попробовал.

О компании

OZON.ru — один из самых крупных российских интернет-магазинов, основанный в 1998 году. На его сайте продаются товары 23 категорий: книги, программное обеспечение, товары для дома и сада, одежда и обувь, электроника и бытовая техника, спортинвентарь, косметика, авто- и зоотовары, продукты питания и другие.

Клиенты OZON.ru могут заказывать товары на сайте и в мобильном приложении, а забирать — в пунктах выдачи (более 4 тыс. в 137 городах) либо заказывать доставку курьером. У компании 3 млн покупателей в год и ежедневный трафик — более 1 млн человек.

Задача

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

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

Ручная проверка внедренных метрик была очень трудозатратной. Компания тратила ресурсы на обработку, поддержку и сбор данных в аналитические системы. После каждого релиза разработчики, тестировщики и аналитики проверяли, ничего ли не сломалось при передаче данных в dataLayer, не отвалилось ли событие, отвечающее за транзакцию или добавление в корзину с товарной полки. В зависимости от релиза на проверку всех возможных кейсов уходило от 0,15 часа до 2 часов.

Команда OZON.ru решила сократить затраты и время на проверку аналитики и уменьшить риски, связанные с внедрением на сайт нового функционала, с помощью автоматического тестирования метрик. Аналитики компании обратились с этой задачей в OWOX BI.

Решение

У аналитиков OWOX BI уже был опыт в автоматизации тестирования, так как они регулярно внедряют системы метрик на сайты крупных Ecommerce проектов. Этот опыт помог им в решении задачи OZON.ru.

Сам процесс автоматизации можно разделить на три основных этапа:

  1. Сбор информации для настройки тестирования.
  2. Настройка тестирования и обработка данных по итогам запуска теста.
  3. Построение отчетов и применение данных.

Рассмотрим детальнее каждый этап.

1. Сбор информации для настройки тестирования

Функционал сайта ozon.ru растет день ото дня и, как следствие, увеличивается список тестируемых метрик. Поэтому аналитики интернет-магазина собрали в одной таблице самые важные метрики и параметры, которые необходимо регулярно проверять. Почему в Google Sheets? Чтобы в любой момент список можно было отредактировать и все сотрудники могли увидеть, что и где отслеживается.

В первую очередь в список включили параметры, которые передаются в Google Analytics и используются в отчетах об эффективности продаж и микроконверсиях на сайте. Почему именно эти параметры? Потому что на них строятся ключевые бизнес-метрики и обмен данными с рекламными сервисами, от них зависят решения, которые принимают руководители отделов маркетинга и аналитики.

В итоге получили три набора данных для тестирования:

  • Данные по страницам.
  • Данные по событиям.
  • Данные по сценариям поведения пользователей.

1. Набор данных по страницам содержит следующую информацию:

  • Definition — название параметра в объекте dataLayer, например: clientID, pageType, categoryName, prodName и т.д.
  • Type — тип параметра: числовой или строковый.
  • False pattern — формат, который принимает параметр на тех страницах, где он не заполняется.
  • True pattern — формат, который принимает параметр на тех страницах, где он заполняется.
  • Правила для проверки — тип страницы и тип пользователя (авторизованный или неавторизованный), для которых значения должны передаваться и для которых не должны. Например, параметр TotalOrderCount передается только для авторизованных пользователей. Если пользователь не авторизован, значения быть не должно.

Пример:

Список метрик для по страницам

2. Набор данных по событиям:

  • Event name — название события: показ товара, клик по товару, добавление в корзину.
  • Parameter — параметры для проверки, например: action, list, id, position, name, price и т.д.
  • Description — описание допустимых значений для параметров, например, любое значение больше 0.
  • Type — тип параметра: числовой или строковый.
  • Comment — обязательный или необязательный параметр.
  • Page Type — тип страниц, на которых необходимо проверять наличие параметров.

Пример:

Список метрик для по событиям

3. Набор данных о сценариях поведения пользователя:

  • Название сценария, например: новый пользователь — онлайн оплата, новый пользователь — офлайн оплата.
  • Event — последовательность событий в сценарии.
  • Параметры для проверки, например: ecommerce.purchase.actionField.action (id, revenue, affiliation), ecommerce.purchase.products.id, ecommerce.purchase.products.name, ecommerce.purchase.products.price и т.д.

Пример:

Набор данных о сценариях поведения пользователя

Список параметров и метрик во всех наборах данных в любой момент можно изменить или дополнить.

2. Настройка тестирования и обработка данных по итогам запуска теста

После того, как аналитики интернет-магазина предоставили список необходимых метрик, команда OWOX BI настроила и запустила скрипт, который проверяет соответствие переменных в dataLayer на страницах сайта тем, что указаны в списке. Запуск тестирования можно настроить с любой периодичностью — у OZON.ru оно проходит раз в день.

Если кратко, то скрипт работает по такому принципу:

  1. Имитирует действия пользователей на сайте: заходы на страницу, клик по товару, добавление товаров в корзину и т.д.
  2. Сверяет полученные параметры в dataLayer с теми, которые должны передаваться в Google Analytics после выполнения этих действий.
  3. Выгружает результаты тестирования в Google BigQuery для построение отчетов об ошибках.

Почему для сбора данных выбрали облачное хранилище Google BigQuery? В первую очередь из-за безопасности — другие сервисы для тестирования метрик часто хранят данные клиентов у себя, т.е. непонятно, кто и что с ними делает. В нашем же случае данные сохраняются в GBQ проекте OZON.ru, клиент сам их контролирует и управляет правами доступа. К тому же Google BigQuery имеет коннекторы для сервисов визуализации и из него легко выгружать данные в Google Sheets.

Результаты тестирования сохраняются в таблицу Google BigQuery с такой структурой:

  • Time — время проверки.
  • Page — страница, на которой выполнена проверка.
  • PageType — тип страницы, на которой выполнялась проверка.
  • Status — Ok или Error.
  • Type — какие данные проверялись: pageview, event или scenario.
  • EventName — название события.
  • ErrorDescription — описание ошибок.

Шаг 3. Построение отчетов и применение данных

Чтобы результаты тестирования приносили реальную пользу и с ними можно было легко работать, аналитики выгружают данные из Google BigQuery в Data Studio. Команда OWOX BI подготовила для OZON.ru дашборд, на котором в любой момент можно посмотреть:

  • Tested Pages — количество протестированных страниц.
  • Tested Events — количество протестированных событий.
  • Tested Scenarios — количество протестированных сценариев.
  • Share of Pages/Events/Scenarios with Error — долю выполненных тестов с ошибками по страницам, событиям и сценариям.
  • Детализацию по ошибкам:
    • Internal — ошибки скрипта.
    • Redirect — ошибки в карте сайта (sitemap).
    • Implementation — ошибки в dataLayer.

Ниже скриншот дашборда с результатами тестирования. Работать с отчетом можно через фильтры. Например, чтобы проверить, какие ошибки во внедрении были сделаны на странице каталога, нужно использовать такую комбинацию фильтров: Page Type = catalog list, Test type = pageview, Error Type = Implementation.

Дашборд по тестированию метрик на сайте

На графике по динамике запусков тестов мы видим, что с 16-ого января доля тестов с ошибками существенно выросла, это связано с редизайном карточки товара (DetailProductView). Ранее установленный баннер «Name1» в новой версии сайта был удален, а в системе метрик это не учли. В результате при проверке клика по баннеру на карточке товара получаем ошибку «ValueError — no elements to click».

На скриншоте выше мы видим, что в событии productView перестали передаваться параметры position и list. Это произошло из-за того, что position пропал из dataLayer, а параметры list и name перепутались. Названия списка товаров начали передавать в name, в то время как туда должны передаваться названия товаров.

Теперь аналитики OZON.ru в любой момент могут проверить, корректно ли отслеживаются важные для бизнеса KPI, вовремя найти сбой и оперативно его пофиксить. А на случай, если у них не будет времени смотреть на дашборд, мы настроили email-уведомления. Каждый день ответственным сотрудникам OZON.ru приходит письмо с краткой сводкой за предыдущий день: количество найденных ошибок в разрезе типа страниц и событий.

Вот пример такого письма:

При необходимости аналитики передают эту информацию в отдел разработки для исправления ошибок на сайте.

Результат

Разработчики и аналитики OZON.ru получили инструмент для автоматической проверки метрик после обновлений на сайте. Благодаря решению от OWOX BI компания:

  • Увеличила скорость тестирования и точность результатов, исключив человеческий фактор.
  • Снизила себестоимость тестов и увеличила частоту их проведения. Теперь тесты запускаются каждый день и компания экономит 1,5 чел/час на каждом релизе.
  • Выявила и исправила около 2 700 неточностей на 37 типах страниц, которые не замечала ранее. В некоторых блоках рекомендаций не передавалась цена товара или был некорректный тип передаваемого значения. В каталоге на первых позициях отображались товары, которых нет в наличии. Редиректы отправляли пользователей на нерабочие страницы.
‘‘

«Автотестирование метрик от OWOX BI позволило нам отказаться от ручного регрессионного тестирования всех параметров и событий на сайте, которые напрямую не были затронуты в релизе. Благодаря этому мы экономим 1,5 чел/час после каждого релиза. При описании сценария для тестирования мы указываем ряд параметров, значения которых должны передаваться в GA, но не передаются, так как IT-специалисты еще не внедрили их. Мониторинг помогает нашим разработчикам не упускать эту задачу из виду.

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

Ян Чарный,
Project Manager в Ozon.ru
Ян Чарный, Project Manager в Ozon.ru

Теперь команда OZON.ru уверена в корректности собираемых данных. А как тестируете метрики вы? Наши аналитики подготовили шаблон дашборда, описанного в этом кейсе. Вы можете использовать его, чтобы проверять качество данных, собираемых на своем сайте. Заполните форму, и мы пришлем вам ссылку на дашборд.

Вы легко настроите отчет под себя, скопировав его и подключив в качестве источника данных таблицу в Google BigQuery со следующей структурой:

Если вам нужна помощь со сбором данных об ошибках, пишите нам на mail@owox.com — с радостью поможем, а если вы хотите узнать больше про автоматическое тестирование и другие способы проверки, посмотрите наш вебинар «Доверяй, но проверяй: как следить за качеством данных».

Вас также могут заинтересовать