Март принес с собой проблему: у некоторых клиентов начали подвисать страницы, на которых монолитный js был разделен на чанки. На таких страницах в основном бандле содержится минимум для отрисовки первого экрана, а остальные чанки мы загружаем отложено. Однако из-за неправильной приоритизации скриптов пользователи лишились некоторых функций нашего сайта. Поток жалоб множился, саппорт разрывался, маркетинг страдал больше обычного.

А сейчас немного остановимся и познакомимся: меня зовут Даша, я инженер по тестированию на платформе web в Иви. И я расскажу вам, как мы внедряли тестирование GTM в пайплайн разработки команды.

При разборе проблемы было выявлено, что один из скриптов GTM перестал отвечать. Браузер старался достучаться до GTM, другие скрипты не прогружались дальше, так как у чанка с GTM был высокий приоритет, а у всех остальных скриптов — средний. Поэтому пропустить чанк с GTM браузер не мог, несмотря на все последующие скрипты с модалками (например, чат авторизации), которые мы в Иви подгружаем динамически с помощью webpack.

После случившегося мы обратили внимание, что тестировщики и разработчики никак не учитывали GTM в своих процессах, так как этим инструментом пользовались коллеги из маркетинга. Мы осознали, что область влияния чужого инструмента плотно подошла к стабильности нашей работы, и решили, что пора бы с ним разобраться. Это и было нашей точкой А, зафиксируем её под названием "Безразличие".

Точка А - "Безразличие"

Что мы имели в этой точке:

Я потратила несколько часов на анализ ситуации, поиск информации и общение с аналитиками и разработчиками. Однако, несмотря на обилие информации о GTM и dataLayer, не нашлось готовых вариантов в стиле "Бери и делай" о том, как построить процесс работы с GTM для разработчиков и тестировщиков.

Тогда я решила написать данную статью, чтобы рассказать о нашем опыте организации процесса работы с GTM. Но не будем долго задерживаться на точке А, а сразу перейдем к точке В.

Точка В - "Принятие"

В этой точке мы приняли данную ситуацию и начали действовать. Мы задались вопросом: "Как сделать так, чтобы процесс интеграции разработчика/тестировщика в мир аналитики прошел как по маслу?". Ответ прост: создать алгоритм действий для команды, которая будет заниматься задачами, связанными с GTM и dataLayer. 

На этом этапе была создана и утверждена у аналитика дорожная карта. Карта имеет ряд плюсов:

• Экономия времени и ресурсов:
  

  • Компания экономит ресурсы, так как разработчики и тестировщики не тратят время на поиск корректной информации по GTM и dataLayer, что более эффективно с точки зрения бюджета.

  • Все, что нужно, уже собрано в едином месте.

  • Дорожная карта даст ответ аналитикам, что команда разработки знает или не знает о GTM на данный момент.

• Удобство использования:
  

  • Карта простая.

  • Компактная. 

• Универсальность вне зависимости от уровня знаний:
  

  • Подойдет для человека, который не знает базовых вещей об инструменте.

  • Подойдет для человека, который уже умеет работать с dataLayer и CSS-селекторами.

• Дорожная карта опробована в реальной работе, и она доказала свою эффективность: 
  

  • Часть сотрудников Иви уже ознакомлена с дорожной картой. 

  • После прохождения дорожной карты наши сотрудники не испытывают трудностей при тестировании или внедрении событий/переменных в GTM/dataLayer.

Мы понимаем, что ситуации у всех разные, и наша карта может вам вовсе не подойти, но надеемся, что она подтолкнет вас к изучению такого важного инструмента аналитики, как GTM.

Дорожная карта по GTM и dataLayer

1. Информация
    

   1. Список необходимой литературы для базовых знаний 
      

      • Просмотреть видео тут

      • Прочитать статью, чтобы лучше понимать, что делают аналитики в GTM "Как пользоваться Google Tag Manager"

      • Прочитать статью "Руководство по протоколу измерения GA4"

      • Эта статья более актуальна для разработчиков Краткое руководство по началу работы

   2. Внутренние документы о деталях реализации GTM на вашем сайте (проверить, что доступ к информации есть у всех заинтересованных сотрудников, так как часть информации может внезапно понадобиться соседним командам)
      

      • Список актуальных (и не очень) переменных и событий на вашем сайте

      • Аудиты от аналитиков со списком, статусом и описанием используемых тегов и событий

      • Руководства по протоколам и интеграциям в зависимости от ваших инструментов

2. Инструкция "Где и как смотреть dataLayer, и что в нем есть"
   

   1. Как открыть структуру datalayer с данными, которые хранятся в паре "ключ-значение"  

   2. Как посмотреть запросы к GTM

   3. Пробное задание с пошаговым процессом выполнения

3. Удобные инструменты для работы
   

   1. Общедоступные
      

      1. "Adswerve - dataLayer Inspector+"  –  просто незаменимое расширение, спасающее тестировщиков и разработчиков от нервного срыва в попытке поймать ускользающий при обновлении страницы тег

   2. Внутренние
      

      1. Инструкции по разворачиванию тестовых сред для нужд тестирования GTM/dataLayer

      2. Инструкции по применению get параметров (если на вашем ресурсе предусмотрено использование включения дополнительного функционала через параметры)

4. Важно запомнить
   

   1. Для разработчика
      

      1. Где можно посмотреть код внедрения переменных в коде (или пример с объяснением)

      2. Где хранятся unit-тесты для GTM и dataLayer

   2. Для тестировщика
      

      1. Особенности тестирования GTM и dataLayer

      2. Где можно посмотреть кейсы по GTM и dataLayer

      3. При получении каких тикетов стоит проверить dataLayer

5. КОНТАКТЫ – куда нести свои слезы и непонимание при возникновении вопросов.

Процесс адаптации и внедрения дорожной карты

Если вы столкнулись со схожими проблемами и хотите адаптировать нашу дорожную карту под свои процессы, то вам необходимо:

1. Взять данную дорожную карту и пойти к своим коллегам: аналитикам, разработчикам и тестировщикам.

2. Актуализировать ее и подстроить под вашу компанию и команду.

3. Обсудить имеющиеся переменные и события.

4. По возможности провести аудит используемых тегов и событий в GTM, или запланировать этот аудит в ближайшем будущем.

5. Написать кейсы на важные для маркетинга события и переменные.
   

   1. Приоритизировать вместе с аналитиком: в зависимости от выбранного уровня приоритета решить, идут ли кейсы к автоматизаторам или остаются для мануалов.

   2. Утвержденные кейсы передаются автоматизатору и разработчику для написания автотестов и unit-тестов соответственно.

Важно учесть и обсудить в команде, при каких случаях необходимо проверить GTM и dataLayer на той или иной странице вашего сайта. Допустим, если вы работаете над сайтом розничного интернет-магазина, важнее всего для вас будут события в dataLayer, связанные с покупкой или оплатой чего-то пользователями на сайте. Значит при возникновении задачи, связанной с платежной системой (вне зависимости был ли там баг, новая фича или рефакторинг кода), важно проверить, чтобы ничего из тегов или событий не было сломано.

Пример применения дорожной карты командой тестирования

1. Получили тикет, связанный с GTM и dataLayer

2. Просмотрели дорожную карту по GTM
   

   1. Ознакомились с литературой из внешних ресурсов (если еще не были знакомы)

   2. Нашли информацию о нужной переменной/событии (внутренние документы о деталях реализации GTM на вашем сайте) и узнали, чего от нее ожидают аналитики и маркетологи
      

      1. Нашли кейсы по данной переменной/данному событию

      2. Если не нашли, то написали новые кейсы, которые покрывают задачу

3. Протестировали тикет с учетом полученных знаний

Результаты начала внедрения процесса 

После начала внедрения процесса тестирования GTM и данной дорожной карты мы получили следующие результаты:

• У нас есть инструкция по работе с GTM и dataLayer для разработчиков и тестировщиков.

• Мы увеличили количество кейсов по GTM и dataLayer, поддерживаем их в актуальном состоянии.
  

  • До работы над внедрением процесса было написано 3 кейса на проверку переменных и событий GTM и dataLayer.

  • После внедрения процесса тестовое покрытие увеличено до 49 кейсов.

• Автоматизаторы создают автотесты на переменные и события.
  

  • Ранее не было написано ни одного автотеста на переменные и события из dataLayer.

• Разработчики пишут unit-тесты на проверку тегов и событий из dataLayer.

Благодаря описанным выше действиям:

• Увеличилось количество находимых багов. Если сравнивать количество багов за 6 месяцев до внедрения процесса и после, получится:
  

  • до начала внедрения процесса был найден 1 баг (8 багов с 2019 года по август 2023 года) 

  • после внедрения процесса тестировщики нашли 4 бага (4 бага с августа 2023 года по декабрь 2023 года)

• Скорость работы с аналитикой возросла за счет тривиального, но четкого плана "как и что делать".

Заключение

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

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

Выстраивание процессов по тестированию GTM подтолкнуло нас к мысли о проведении эксперимента по ускорению веба посредством очистки GTM. Об этом эксперименте мы собираемся рассказать в следующей статье. До новых встреч на Хабре!