Три решения для Google Tag Manager (по результатам конкурса)

Предлагаю ознакомиться с работами призеров и победителя конкурса на лучший пользовательский тег и/или макрос для Google Tag Manager.

Ранее были подведены итоги конкурса, но от читателей блога и членов жюри поступили предложения опубликовать в открытом доступе работы конкурсантов. Сегодня эти работы предлагаются вашему вниманию.

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

Итак, начнем с третьего места.

Артем Кулбасов, представитель AdLabs. Макрос решающий следующую задачу “оценить влияние корреляции цен на услуги у конкурентов на реальные продажи своих услуг”.

Схема работы:

  1. Пользователь заходит на страницу услуги на нашем сайте. Срабатывает макрос {{ Our Price }}, который сопоставляет страницу с ценой услуги.
  2. Также срабатывает макрос {{parse_price}}, который забирает стоимость аналогичной услуги у конкурента.
  3. Срабатывает тег, который передает в пользовательских параметрах нашу стоимость и стоимость конкурента на услугу.
  4. Загрузка реальной стоимости проданных услуг через Measurement Protocol.
  5. Проведение анализа полученных результатов.
  6. Тест изменения стоимости услуг обозначенных на сайте.

Результаты работы:

скриншот 3 место

Конкурсная работа, третье место

Второе место, Филипп Сироткин, представитель Cubeline. Представлено решение “плагин EventDog, который облегчает написание скриптов”.

EventDog включает 5 методов: ajax, click, submit, dom, change.

Кейс: Есть форма заявки, правильность заполнения которой проверяется на сайте, а не на сервере и запрос на сервер отправляется с помощью Ajax. При подтверждении заявки появляется pop-up. Нам нужно отследить только правильно заполненные заявки.

Проблема: Средствами GTM можно отследить только подтверждение формы заявки, но невозможно отследить заявки, которые прошли валидацию и ушли на сервер.

Решение: Отслеживаем запросы, которые прошли валидацию и были отправлены на сервер.

Скрипт будет выглядеть следующим образом:

Комментарий к работе скрипта:

  1. <script src=”//eventdog.dev.cubeline.ru/eventdog.min.js”> — подключаем EventDog
  2. <script> </script> — тут “лежит” наш скрипт
  3. eventdog.ajax — выбираем метод (.ajax, .dom и т.д.)
  4. element: ‘#form_id’ — выбираем отслеживаемый элемент (вместо #id можно указать .class)
  5. substring: ‘success’ — значение, которое приходит с сервера и мы хотим получить. Нас интересуют правильные заявки.
  6. callback: function () {ga(‘send’,…)} — отправляем событие ga в Google Analytics или reachGoal, если хотим отправить в Яндекс Метрику.

Дополнительная информация по скрипту находится по адресу git.cubeline.ru/cubeline/eventdog/wikis/home

Победителем конкурса определен Владимир Ковтун, представитель К50. Ниже приведу оригинальный текст заявки Владимира, который описывает проблему, кейсы, а также алгоритм работы скрипта.

Проблема: Пользуюсь и GA, и новой метрикой. Обе системы хорошие, но в каждой чего-то не достает. Поэтому возникает необходимость сопоставлять данные этих систем и брать от них лучшее. Для этого я пробрасываю в ga и метрику сгенерированный id сессии и сопоставляю по нему сеансы в этих системах (как следствие, все параметры-измерения в рамках этого сеанса).

Примеры задач:

  1. Есть реклама с директа, необходимо оценить эффективность по регионам. В GA есть транзакции, в новой метрике их пока нет, но Google (GA) и Яндекс (директ и метрика) определяют регионы по-разному. Выход: брать транзакции из GA, регионы из метрики. Profit!
  2. В GA интересных измерений типа ip адреса, роботности, маловато всяких когортных штук (см. список измерений-метрик метрики). Выход: берем нужные данные в GA и эти крутые измерения из метрики. Profit!
  3. В метрике не реализованы по-нормальному события+нет кастомных метрик как в GA. Можем эти данные пробрасывать. Profit!
  4. Поисковые запросы. Метрика хранит поисковые запросы в отдельном измерении в отличие от GA (решается проблема, когда utm_term затирает эти данные).
  5. Метрика отдает user id. Можно этот user id сопоставлять с данными GA (и не забивать лишний слот под кастомные измерения).

Ну и так далее – подобных задач крайне много. И это только для этих 2 систем. А ведь можно задействовать и другие. Да и само измерение session_id интересно даже в рамках одной системы.

Как работает скрипт. Все просто – при загрузке проверяется наличие сессионной куки. Если её нет, то мы её создаем и пихаем туда сгенерированный нами session_id (чтобы отправляли данные с sid в GA/Метрику только 1 раз за сеанс). После создания куки пушим sid в GA и метрику. В GA – в кастомный dimension (в скрипте – первый по номеру), для метрики пользовательские параметры с помощью метода params (в коде указал пример без номер счетчика). Когда сессия заканчивается, кука сбрасывается. Все!

Данные по session id можно отправить куда угодно при небольшой кастомизации скрипта.

Содержание скрипта.

Надеюсь, что работы окажутся полезными и вы сможете использовать их в своих проектах.

П.С. Еще раз обращаю ваше внимание, что для получения разъяснений и информации об описанных решениях вам необходимо обратиться к их авторам.

Кейсы и инструкции по настройке в вашем ящике. Подпишитесь сейчас!

Комментарий к “Три решения для Google Tag Manager (по результатам конкурса)

  1. Дмитрий Захарченко 03.01.2016 в 17:37 - Ответить

    Анализ цен конкурентов через GA напоминает создание троллейбуса из буханки хлеба. Круто, но зачем?

Добавить комментарий

Current month ye@r day *