Сегодня любой омниканальный магазин развивается только благодаря правильной работе с данными. В том числе – благодаря трекингу данных с сайта, который строится на основе 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% рабочего времени мы тратили на настройку событий для сервиса, его обновления, поиск ошибок и аномалий. На собственно аналитическую работу оставалось мало времени.
Когда проблема стала критической, мы решили найти инструмент, который позволил бы по-другому организовать работу с данными.
Что мы хотели?
По-прежнему пользоваться функционалом, который предлагает GTM, но минимизировать в работе использование кода.
Быстро подключать и отключать сервисы, не привлекая разработчиков.
Быть уверенными в корректной работе сервисов и видеть источники ошибок.
Очистить код сайта и впредь сохранить его неизменным.
Получать быструю и внятную обратную связь от поддержки в случае необходимости.
Сначала мы изучили европейский рынок и обнаружили, что решение, о котором мы говорим, относится к типу Customer Data Platform.
Они подключаются к сайту через единый API, и все необходимые сервисы уже интегрированы в платформу;
Они не требуют от специалиста знаний JavaScript;
Они позволяют работать с сырыми данными.
Однако большинство таких платформ показались дорогими и избыточно сложными для наших задач и объемов. Появились опасения, что подключив такое решение, мы, во-первых, будем переплачивать, а во-вторых, не сможем поддерживать его в рабочем состоянии без саппорта на русском языке.
В России интерес к таким платформам лишь просыпается, и на рынке пока есть одно подобное решение – DigitalDataManager (DDM).
Мы захотели попробовать его и поставили на самый крупный проект – re:Store. Внедрение и отладка платформы заняли полтора месяца, что оказалось дольше предполагаемых нами сроков. Причина была в большом техническом задании: мы должны были максимально заполнить слой данных DigitalData, чтобы потом практически не возвращаться к этому вопросу.
Что изменилось?
Полгода мы не решались снести GTM полностью, он был своеобразной страховкой: если что-то пойдет не так, сможем вернуться на старые рельсы. Тем временем переносили интеграции и решали накопившиеся проблемы.
Чем отличается работа с данными через платформу?
1. Единый формат собираемых данных. Нет необходимости настраивать события для каждого сервиса в отдельности. На старте мы заполнили слой данных DigitalData, и теперь они автоматически отправляются в нужные системы в требуемом формате. Если мы что-то меняем на сайте, то так же быстро можем добавить нужные параметры в слой.
2. Работа с удобным интерфейсом и никакого кода, тегов, скриптов, пикселей. Все сервисы, с которыми мы работаем, есть в каталоге платформы. Мы научились подключать и отключать их самостоятельно через личный кабинет. Например, если маркетолог приходит с задачей «срочно подключить Soloway», её решение занимает ровно пять минут. Для сложных и кастомных интеграций мы обращаемся к поддержке, и тогда задача решается в среднем в течение суток.
3. Чистый код сайта. Даже прекращая работу с площадкой, мы не всегда могли с уверенностью сказать, что начисто снесли её скрипт. Это большие риски, от которых нам удалось избавиться. Снизилось число JS-ошибок, скорость загрузки сайта выросла на 3-4 секунды. Есть куда стремиться, но это уже вопрос высокого качества контента.
4. Стоимость. У DDM платная поддержка, но по нашим подсчетам, выходит дешевле, чем с бесплатным GTM и постоянным привлечением разработчиков. Платформу разрабатывают в Москве, есть постоянная связь с нами и агентством. Можем обращаться с вопросами к живым людям, не скриптам и формам обратной связи.
5. Дополнительные фичи, которые... мы до сих пор не до конца исследовали.
Кроме того, снизилось число ошибок в работе сервисов. Например, остро стояла проблема с CPA-сетями. Изначально их скрипты часто стояли в коде сайта, и на крупных проектах их насчитывалось до пяти штук. Кроме ошибок как таковых мы видели проблемы с трекингом. В итоге мы переподключили сети через AdSpire в DDM, настроили передачу необходимых параметров и снизили число ошибок в десятки раз.
Когда в апреле этого года начались блокировки IP-адресов Google, мы обнаружили разницу в показаниях счетчиков Google Analytics и Яндекс.Метрики до 8-10%. Мы быстро включили встроенный в DDM прокси-сервер и восстановили работу с данными в полном объеме. Причем через этот сервер идет только тот трафик, который блокирован. Ситуация по-прежнему кажется нестабильной, потому мы до сих пор используем проксирование в работе.
Что будем делать завтра?
Мы многое сделали для того, чтобы работа с онлайн-данными стала быстрой, простой и безопасной. На сегодняшний день платформа стоит почти на всех наших проектах, а где-то мы на этапе внедрения. В ближайшем будущем планируем также через DDM подключить стриминг «сырых» данных, чтобы собирать их в облачном хранилище BigQuery сразу в формате DigitalData и затем использовать в маркетинговой коммуникации.
Сергей Иванов, руководитель отдела веб-аналитики Inventive Retail Group