0/5

Кейс Inventive Retail Group: Как отказаться от Google Tag Manager и не пожалеть об этом

Кейс Inventive Retail Group: Как отказаться от Google Tag Manager и не пожалеть об этом
время публикации: 10:00  17 июля 2018 года
Сегодня любой омниканальный магазин развивается только благодаря правильной работе с данными. В том числе – благодаря трекингу данных с сайта, который строится на основе Google Tag Manager. Сергей Иванов, руководитель отдела веб-аналитики Inventive Retail Group, рассказывает, почему компания решила отказаться от Google Tag Manager и выбрала другой путь.
Кейс Inventive Retail Group: Как отказаться от Google Tag Manager и не пожалеть об этом

На фото: Сергей Иванов, руководитель отдела веб-аналитики Inventive Retail Group

Сегодня Inventive Retail Group – это магазины сетей re:Store, Samsung, STREET BEAT, STREET BEAT SPORT, STREET BEAT KIDS, Nike, LEGO, Sony Center, UNOde50. У каждого из них своя аудитория, продукт и стратегия продвижения. У семи проектов компании есть сайты. Задача отдела аналитики – заниматься не только техническими вопросами интеграций, сбором данных из всех источников, но и давать маркетологам необходимые для работы инсайты.


Как всё работало вчера?

Изначально мы работали с небольшим числом маркетинговых инструментов и рекламных каналов. 

Данные с сайта собирались и отправлялись в сторонние системы через теги – специально созданные для этого фрагменты JavaScript-кода. Например, пиксели социальных сетей, коды ретаргетинга. 

Чтобы быстро активировать, редактировать и отключать теги, мы использовали бесплатный контейнер тегов Google Tag Manager (GTM). Некоторые рекламные сервисы и вовсе интегрировались прямо в код сайта. Для создания тегов и работы с контейнером приходилось обращаться к отделу разработки и увеличивать нагрузку на агентство «Риалвеб», с которым мы на тот момент работали. 

Так мы собирали данные, следили за выполнением основных KPI, видели, как показатели менялись в зависимости от нашей активности, и строили отчеты. Этого хватало для принятия решений и управления маркетингом. 

Вскоре наша эффективность начала снижаться. Основная причина – быстрый рост онлайн-маркетинга. Число необходимых для работы сервисов на всех проектах группы достигло нескольких десятков. Кроме того, стало больше «экспериментальных интеграций»: подключений сервисов для выбора наиболее эффективного или проверки гипотез. 

Это значит, что:

  • все они с достаточно высокой периодичностью требовали обновлений;
  • стало больше задач по настройке и интеграциям в целом.

Наш GTM превратился в большое полотно тегов, и работать с ним становилось всё сложнее. JS-ошибки стали появляться чаще, а разбираться с ними приходилось самостоятельно – GTM не предоставляет поддержку. Снова нагрузка на агентство, которое могло получить от Google хоть какую-то обратную связь. 

Бывали периоды, когда около 90% рабочего времени мы тратили на настройку событий для сервиса, его обновления, поиск ошибок и аномалий. На собственно аналитическую работу оставалось мало времени.

Когда проблема стала критической, мы решили найти инструмент, который позволил бы по-другому организовать работу с данными. 


Что мы хотели? 
  1. По-прежнему пользоваться функционалом, который предлагает GTM, но минимизировать в работе использование кода.
  2. Быстро подключать и отключать сервисы, не привлекая разработчиков.
  3. Быть уверенными в корректной работе сервисов и видеть источники ошибок.
  4. Очистить код сайта и впредь сохранить его неизменным.
  5. Получать быструю и внятную обратную связь от поддержки в случае необходимости. 
Сначала мы изучили европейский рынок и обнаружили, что решение, о котором мы говорим, относится к типу Customer Data Platform. 








Что они могут?

  • Они подключаются к сайту через единый API, и все необходимые сервисы уже интегрированы в платформу;
  • Они не требуют от специалиста знаний JavaScript;
  • Они позволяют работать с сырыми данными. 

Однако большинство таких платформ показались дорогими и избыточно сложными для наших задач и объемов. Появились опасения, что подключив такое решение, мы, во-первых, будем переплачивать, а во-вторых, не сможем поддерживать его в рабочем состоянии без саппорта на русском языке.

В России интерес к таким платформам лишь просыпается, и на рынке пока есть одно подобное решение – DigitalDataManager (DDM). 

Мы захотели попробовать его и поставили на самый крупный проект – re:Store. Внедрение и отладка платформы заняли полтора месяца, что оказалось дольше предполагаемых нами сроков. Причина была в большом техническом задании: мы должны были максимально заполнить слой данных DigitalData, чтобы потом практически не возвращаться к этому вопросу.


Что изменилось? 

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


Чем отличается работа с данными через платформу?

1. Единый формат собираемых данных. Нет необходимости настраивать события для каждого сервиса в отдельности. На старте мы заполнили слой данных DigitalData, и теперь они автоматически отправляются в нужные системы в требуемом формате. Если мы что-то меняем на сайте, то так же быстро можем добавить нужные параметры в слой.

2. Работа с удобным интерфейсом и никакого кода, тегов, скриптов, пикселей. Все сервисы, с которыми мы работаем, есть в каталоге платформы. Мы научились подключать и отключать их самостоятельно через личный кабинет. Например, если маркетолог приходит с задачей «срочно подключить Soloway», её решение занимает ровно пять минут. Для сложных и кастомных интеграций мы обращаемся к поддержке, и тогда задача решается в среднем в течение суток. 

Кейс Inventive Retail Group: Как отказаться от Google Tag Manager и не пожалеть об этом 

3. Чистый код сайта. Даже прекращая работу с площадкой, мы не всегда могли с уверенностью сказать, что начисто снесли её скрипт. Это большие риски, от которых нам удалось избавиться. Снизилось число JS-ошибок, скорость загрузки сайта выросла на 3-4 секунды. Есть куда стремиться, но это уже вопрос высокого качества контента.
 
Кейс Inventive Retail Group: Как отказаться от Google Tag Manager и не пожалеть об этом

4. Стоимость. У DDM платная поддержка, но по нашим подсчетам, выходит дешевле, чем с бесплатным GTM и постоянным привлечением разработчиков. Платформу разрабатывают в Москве, есть постоянная связь с нами и агентством. Можем обращаться с вопросами к живым людям, не скриптам и формам обратной связи.

5. Дополнительные фичи, которые... мы до сих пор не до конца исследовали.

Кроме того, снизилось число ошибок в работе сервисов. Например, остро стояла проблема с CPA-сетями. Изначально их скрипты часто стояли в коде сайта, и на крупных проектах их насчитывалось до пяти штук. Кроме ошибок как таковых мы видели проблемы с трекингом. В итоге мы переподключили сети через AdSpire в DDM, настроили передачу необходимых параметров и снизили число ошибок в десятки раз. 

Когда в апреле этого года начались блокировки IP-адресов Google, мы обнаружили разницу в показаниях счетчиков Google Analytics и Яндекс.Метрики до 8-10%. Мы быстро включили встроенный в DDM прокси-сервер и восстановили работу с данными в полном объеме. Причем через этот сервер идет только тот трафик, который блокирован. Ситуация по-прежнему кажется нестабильной, потому мы до сих пор используем проксирование в работе. 

Кейс Inventive Retail Group: Как отказаться от Google Tag Manager и не пожалеть об этом
 

Что будем делать завтра?

Мы многое сделали для того, чтобы работа с онлайн-данными стала быстрой, простой и безопасной. На сегодняшний день платформа стоит почти на всех наших проектах, а где-то мы на этапе внедрения. В ближайшем будущем планируем также через DDM подключить стриминг «сырых» данных, чтобы собирать их в облачном хранилище BigQuery сразу в формате DigitalData и затем использовать в маркетинговой коммуникации. 

Сергей Иванов, руководитель отдела веб-аналитики Inventive Retail Group

0
Реклама на New Retail. Медиакит