Веб-аналитика, часть 1. “Так как же правильно установить Google Analytics и зачем нам Tag Manager”

24 min readNov 18, 2020

Поговорим также про новую GA4 (она же Web+App), SPA, кросс- и субдомен, каналы привлечения и про тонкую настройку.

Привет дата-ниндзя👋! Надеюсь ты знаешь что такое веб-аналитика и зачем она тебе (если нет, обязательно прочти бесплатную часть объясняющей статьи от tilda 🤔).

Tagmanager

Начнем рассказ с Google Tag Manager (сокращенно GTM). Зачем он нужен:

Суть работы любой системы веб-аналитики (в дальнейшем СВА) заключается в установке на все страницы сайта фрагмента js-кода (тег, пиксель, счетчик), который при открытии страницы и совершении действий отправляет данные на сервер (допустим гугловский для GA). Одно такое сообщение называется хит/hit (кратко со всей терминологией можно ознакомиться тут).
Для изменения настроек или установки новой СВА нужно просить фронт-эндеров изменить/добавить фрагмент кода и ждать релиза.
GTM позволяет 1 раз внедрить блок кода (контейнер) на сайт и в дальнейшем все СВА подключать и настраивать (например, менять id счетчика, добавлять новые триггеры) уже в самом интерфейсе GTM без участия разработчиков и релиза сайта. При этом весь код для СВА, написанный в GTM, автоматом попадет на сайт через указанный ваше контейнер ⭐️. Для примера, GTM можно заставить при отправке формы писать что-то в Google Sheets и GA.

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

Итак, поехали. Перед внедрением GTM стоит проверить, не установлен ли уже он на интересующих страницах. Это можно сделать либо поиском по коду страницы, либо установив chrome-расширение Google Tag Assistant. Подробнее читай тут.

Скрин 1. Кнопка создания нового аккаунта

Для начала создаем новый аккаунт, если его еще нет (на одну почту можно создать много аккаунтов).

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

Если аккаунты уже же есть в организации (вместо данного экрана будет их список и плюсик для создания нового), подумай прежде чем использовать их. Администраторские права, часовой пояс и отправка статистики едины для всех контейнеров одного аккаунта (хотя права можно отдельно переопределить в контейнере). Рекомендую для каждого домена второго уровня в компании заводить отдельный аккаунт, а для поддоменов — отдельные контейнеры под единым аккаунтом (читай тут). Для тестовых контуров сайта (stage, shot) также стоит завести отдельный контейнер, чтобы не портить данные продового счетчика.

Все страницы сайта/сайтов, на которых будет установлен контейнер, получат одинаковые счетчики и их настройки. Конечно, можно сделать кастомные триггеры (ниже обсудим что это) с проверкой url-страниц и тд, но все же лучше для разных сайтов создавать отдельный контейнер. Добавить новый контейнер можно при создании аккаунта или во вкладке “”Администрирование” в каком-либо из уже существующие контейнеров внутри аккаунта.

При создании аккаунта необходимо указать следующие параметры:

Название аккаунта — я бы рекомендовал использовать название сайта без домена (очевидно) и с прописной буквы (чтобы не путать аккаунт с контейнером).
Часовой пояс — либо пояс столицы, если сайт для одной страны, скажем GMT+7 для Индонезии (хотя Бали GMT+8), либо пояс HQ на случай если сайт используется для нескольких стран с разными часовыми поясам.
Название контейнера —я бы рекомендовал использовать url сайта (без https:// и других протокольных штук) строчными буквами и доменом верхнего уровня. Сайт, апп iOs, апп Android — это все разные контейнеры.

После создания контейнера получаем код, который нужно отдать фронт-энду для установки на все страницы сайта.

Не волнуйся, если потерял код. Его можно найти во вкладке “Администрирование” → “Установить Google Менеджер тегов”. Если нет доступа к Администрированию, но известен id контейнера, то код можно взять тут https://developers.google.com/tag-manager/quickstart).

Если тебе стало интересно, что делает код сверху, то прочитай разбор тут. Хотя лучше сделай это после того, как прочтешь эту статью до конца, так будет понятнее.

После установки кода на сайт работа разработчиков заканчивается до момента, когда им потребуется кодом триггерить отправку сложных событий. Сложные, потому что такие триггеры как переход на конкретный url, скролл страницы, загрузка DOM, клик на какую-либо из ссылок, почти любые действия со встроенным видео Youtube, доступность html-элемента (через id или css-селектор) или отправка формы — tagmanager умеет тречить из коробки ⭐️.

GTM по дефолту версионирует настройки (еще один из аргументов в пользу его использования ⭐️) и умеет в дебаг-мод (поговорим об этом позже ⭐️). Также, оформив платную версию GTM 360 (часто идет вместе с Google’s Analytics 360 Suite) можно в интерфейсе с помощью Zones настроить несколько контейнеров на 1 страницу сайта (добавить второй контейнер можно и через Custom HTML, но это небезопасно и есть много подводных камней). Также через Zones можно более детально настраивать права.

Google Analytics

Переходим к матери всея веб-аналитики 🕸.

https://analytics.google.com/

Есть несколько важных моментов, которые требуется уточнить перед установкой Google Analytics (сокращено GA).

👮 Важно! Проверить стоит ли уже GA на интересующих страницах. Если GA настроена через tagmanager, то узнать это можно только в нем или через расширение Google Tag Assistant . Если установлена напрямую — поиском по коду страницы (ключевое слова ga) или поиском по запрошенным файлам во вкладке network в devtools (подробнее в оф-документации). Если GA уже установлена напрямую, устанавливать ее через GTM уже нельзя, иначе будет дублирование событий. Необходимо изначально убрать тег GA из кода сайта.
👮 Важно! Уточнить у разрабов, используется ли в коде js глобальная переменная ga. И если да, то переименовать ее.
👮 Важно! Альтернативный тег асинхронной загрузки использовать не нужно, если у пользователей могут быть старые браузеры.
👮 Важно! При использовании на SPA (Single Page Application, одностраничник) гугл-аналитика сама правильно не заведется. Нужно либо ставить autotrack (если используется historyAPI), либо просим разработчиков отправлять вручную смену экранов (если url вообще не меняется, как в он-лайн играх). Мы обсудим SPA ниже.

1. Создаем аккаунт и ресурс

Как и с tagmanager’ом, первоначально определись, создавать ли новый аккаунт/ресурс или воспользоваться уже существующими. Правила такие же, 1 сайт (домен второго уровня) — 1 аккаунт. Ресурс (аналогично контейнеру GTM) может быть свой на каждый домен верхнего уровня или один на всех, мы еще обсудим это ниже в блоке про кросс-домен.

Аналогично GTM:

Я бы рекомендовал для создания аккаунта и для администрирования использовать отдельную админскую почту, а для обычного анализа входить под личной почтой. Так будет меньше шансов сломать что-нибудь
Для тестовых контуров сайта (stage, shot) стоит завести отдельный ресурс (и указывать его в GTM), чтобы не портить данные продового счетчика.

Если решено создать новый аккаунт, то сделать это можно в левой выпадающей панели в блоке “admin” (там же можно создать новый ресурс для уже существующего аккаунта).

Параметры аналогичны GTM:

Название аккаунта — я бы рекомендовал название сайта со строчной буквы и без домена
Что необходимо проанализировать — стоит выбрать Веб-сайты (мобильные приложения обсудим в отдельном посте).
Из проставляемых галок наиболее интересной является продукты и сервисы Google (Google Signals) — включает новый функционал: отчеты о пользователях, получивших персонализацию рекламы ; кроссплатформенные отчеты при отсутствии UserId (поговорим об этом позже). Подробнее в оф.документации.

Далее, создаем новый ресурс.

Название ресурса — я бы рекомендовал url сайта (без https:// и других протокольных штук) строчными буквами с доменом. Сайт, апп iOs, апп Android — это все разные ресурсы.
Часовой пояс — либо пояс столицы, если сайт для одной страны, скажем GMT+3 для России, либо пояс HQ на случай если сайт для нескольких стран с разными часовыми поясам. Мы еще обсудим, на что это влияет.
В дополнительных параметрах можно переключить на создание старой версии (Universal Analytics), т.к. с 16 октября по умолчанию создается Google Analytics 4 (Web + Apps). Мы поговорим ниже про их отличия (но если не терпится, то можно найти в оф.документации), но пока GA4 сильно проигрывает в функционале и в ней отсутствуют довольно базовые вещи.

Далее в потоках данных выбираем нужный нам поток (Web, iOS, Android). В данном случае нас интересует веб (мобильную аналитику разберем в отдельном посте). Параметры для веба:

Урл сайта — обычный адрес сайта с протоколом и тд.
Название — url сайта (без https:// и других протокольных штук) с прописной буквы без домена. Сайт, апп iOs, апп Android — это все разные потоки.
Cтавим галку Улучшенной статистики.
Валюта (с конвертацией в отчете по курсу день оплаты).

После создания потока увидим такой скрин. Нас интересует MEASUREMENT ID (ИДЕНТИФИКАТОР ПОКАЗАТЕЛЯ в русской версии), на скрине он замазан. Нужно скопировать его.

У каждого ресурса в GA свой id счетчика, который нужно вставить в Tag Manager. При этом для каждого ресурса можно создать несколько view (кастомные фильтры вроде только авторизованной зоны, региона и тд), но для всех вью одного ресурса будет одинаковый id счетчика. Если у одного сайта есть тестовые версии (stage, шот) — для них создаем свой контейнер в GTM и свой ресурс (счетчик в GA).
В прошлой версии (на которой работает большинство наших сайтов) — счетчик назывался Universal Analytics и мел вид UA- XXXXXXXXX-X), сейчас в GA4 (бывший Web+Apps) id счетчика имеет вид G-XXXXXXXXXX, причем вместо X могут быть не только цифры, но и буквы.

Далее идем в Data Settings -> Data Retention (Настройка данных -> Хранение данных). Меняем значение на 14 мес. и выставляем галку сбрасывания пользовательских данных после нового действия. Жмем “Сохранить”.

Теперь давай разберемся что мы настроили. Если коротко, то число месяцев — это срок бездействия, после которого GA начнет считать вернувшегося пользователя как нового (сотрет его неагрегрированные данные). После этого срока в метрике Users появятся нули, хотя агрегированные данные будут валидными (это не касается Audience Overview, в нем данные по этой метрике всегда агрегированы).

Прошлые версии GA имели возможность настраивать гораздо более длительный срок для данных, но GA4 больше настроена на кросс-девайс, и очевидно что сейчас после более года бездействия есть большая вероятность что клиент сменил устройство/браузер, и старый cid (идентификатор клиента) уже перестанет быть актуальным. Собственно галка об сборе говорит лишь о том, что при каждом новом визите клиента срок отсчета (2мес/14мес для эвентов, данные для метрики Users всегда живут 14мес) начинался заново. Данные о том, что этот периода равен 2м годам, в GA4 уже неактуальны. Подробнее можно прочитать в оф.документации.

2. Каналы привлечения

Давай немного обсудим сеансы (сессии) и причем тут каналы привлечения. GA открывает новый сеанс если:

прошло 30 минут бездействия
в полночь (вот тут влияет от, какой часовой пояс в GA мы выберем)
сменился канал привлечения пользователя

Для определения канала привлечения GA (как и другие СВА) использует UTM-метки, а в случае их отсутствия — referrer (предыдущая страница). Как известно, GA использует модель атрибуции Последний непрямой клик (Last Non-Direct Click, можно изменить), значит что канал изменяется при переходе с другого сайта, с поиска или с рекламы, но не при директ-переходе или переходе со страницы своего же сайта.

Моделей атрибуций много, каждая компания используют ту, которую посчитают нужной (Facebook, Google Ads, Yandex). О том, какие они вообще бывают, можно прочитать тут (коротко), тут (более развернуто) или тут (совсем хорошо).

Проблема в том, что в случае междоменого сайта, необходимо добавить в исключения все домены своего сайта, иначе будут создаваться лишние сеансы. С Google Ads все немного сложнее. При использовании автоматической разметки, 2 клика дадут 2 разных сеанса, в ручной же разметке UTM-меток оба клика атрибутируются к одному сеансу.

Также проблема возникает в случае SPA, но мы обсудим это в последнем (самом интересном) разделе этого гайда.

3. Настройка исключений перехода

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

Стандартным способом для этого в UA (Universal Analytics, прошлая версия GA) был Referral exclusions, позволяющий создать список доменов, при переходе с которых не создается новый сеанс. К сожалению, в новой GA4 так функционал пока недоступен (привет кросс-домену).

4. Настройка фильтров и View

Следующим шагом в настройке GA обычно является исключения внутреннего трафика. Дело в том, что сотрудники компании часто используют собственный сайт, и их паттерн использования отличается от паттерна других клиентов. Поэтому для исключения внутреннего трафика обычно создают отдельный View (Представление). Как уже упомяналось, этот функционал позволяет просматривать все отчеты с заранее предустановленным фильтром. Тут описано, как создать представление без внутреннего трафика в UA. В новой GA4, к сожалению, нет функционала создания View (наверное, самая большая недоработка), но есть вариант для исключения внутреннего трафика на уровне всего потока. Создавать фильтры в GA4 пока нельзя.

5. Google Ads и Search Console

Возвращаемся к странице admin. В блоке Product Linking жмем на Google Ads Linking. Предварительно, нужно создать аккаунт для Google Ads (система, где можно запускать рекламные кампании в платной выдаче поиска и в сети партнеров Google AdSense). Далее жмем кнопку link.

Для чего это нужно: в отчете User Acquisition можно смотреть каналы пользователя, которые, как мы уже знаем, вычисляются по UTM-меткам или рефереру. В случае авторазметки компаний, их не будет, только gclickid в get-параметрах. Для того, чтобы можно было различать внутри конкретные кампании и запросы, нужно настроить связь между Google Ads и Google Analytics, в таком случае аналитика сможет смаппить gclickid на кампании. Также при наличие связи GA будет импортировать в Google Ads данные по конверсиям, что поможет последней системе оптимизировать рекламу, а в GA в отчетах по аквизишену появятся расходы.

Также можно создать аккаунт Search Console и подобным образом соединить с GA. Далее мы вернемся к вопросу подтверждения права собственности сайта в Search Console.

Возвращаемся в Tag Manager

Итак, мы закончили настройки GA, осталось подключить ее на сайт через GTM (он уже на сайте после того, как разработчики вставили описанный выше код на все страницы сайта). Переходим в менеджер тегов и жмем на “Добавить новый тег”. Задаем параметры:

Название тега (вверху)— “GA pageviews” или любое, главное понимать о чем этот тег.
конфигурация тега — выбираем конфигурация Google Analytics 4 (не событие!).
Идентификатор показателя — вставляем скопированный раннее id счетчика
Другие расширенные настройки не трогаем
триггер — All Pages

Жмем “Сохранить”. Изменения применяются не сразу, чтобы они вступили в силу нужно нажать “Отправить”. Это позволяет вносить изменения пачками (например, добавить тег и переменную одним коммитом), и видеть эту пачку в истории изменений.

Этим триггером мы добавим хиты pageviews в GA. О том, какие еще бывают хиты, читай в последнем блоке про SPA.

Owox рекомендует не прописывать идентификатор хардкодом, а использовать переменную GTM (мы еще поговорим о переменных позже), но я не вижу в этом плюсов и не фанат плодить лишние переменные.

Поговорим про междомен

Междоменный трекинг используется в случае, если нужен общий трекинг двух сайтов (общие клиенты, объединение сессий) между разными доменами. Как уже упоминалось, одной из проблем является автоматическое создание новой сессии с реферального источника при переходе между разными доменами одного сайта.

Итак, что важно знать — междоменного трекинга пока в GA4 нет в большинстве аккаунтов!

В отличии от GA4, настроить междоменный трекинг в UA не так уже и сложно. Во-первых, как уже упоминалось, нужно добавить свои домены в список источников перехода (док для разрабов тоже есть). Во-вторых, оба домена должны иметь общий client_id, поэтому разработчикам сайта стоит прочесть этот док. В нем рассказано, что при переходе на другой домен можно передавать cid в get-параметре (лучше добавить временную метку и валидировать ее, чтобы не путать клиентов при шаринге url). В нем же про передачу cid iframe’у с помощью postMessage (читай что это). Все это (двустороннее междоменное отслеживание) умеет делать стандартная библиотека linker.

Хорошие новости — гугл начал раскатывать функционал исключения переходов и междоменного трекинга в GA4, пока только на часть аккаунтов.

Передача Id пользователя (ClientId)

Итак, давайте разберемся с тем, как GA различает клиентов на новых и вернувшихся.

Первый идентификатор клиента (называется сlient_id) — кука, которой помечаются все клиенты и которая работает из коробоки. О том, что GA записывает идентификатор клиента в куку(cookies) переменную _ga и как он устроен уже много раз писали (например тут или тут). Вкратце, идентификатор имеет вид GA1.1.904941809.1556093647.

Скрин 12. Экран с куками в Google Chrome

Где:

первое число до точки означает уровень домена
второе — версию GA
третье (904941809) — это собственно случайно-сгенерированный id клиента,
последняя часть (1556093647) — unix таймстамп времени создания. Преобразовать timestamp к дате можно либо на различных он-лайн ресурсах (например), либо открыть консоль JS, которая в Chrome находится в devtools («F12» в windows или «Cmd+Opt+J» на маке)->«Console» и написать

new Date(1556093647*1000)

Кстати, если до этого ты не писал на javaScript, то выше — твоя первая строчка на этом языке.

Увидеть идентификатор в Chrome можно в devtools->«Application»->«Cookies». Важно понимать, что в случае междоменных и поддоменных сайтов, браузерных расширений, сторонних интеграций в сайт и тд возможно ситуация двух или больше переменных _ga (как на скрине). Они будут отличаться полем Domain, просто выбирай нужный тебе.

Для чего нужно знать свой client_id (сокращенно cid, как я называл его несколько раз в этой статье) — для отладки отправляемых событий и рекламных кликов. В Universal Analytics (UA) получить действия конкретного пользователя (cid’а) можно в отчете Audience->User Explorer, в GA4 к сожалению этот отчет еще не подвезли.

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

Скрин 13. Экран со списком пользовательских параметров

В чем смысл — каждый пользователь в GA имеет свои параметры, которые можно использовать в сегментах; например по умолчанию это возраст, пол, канал привлечения и тд. Также можно добавлять в GA своим параметры (скажем, наличие подписки) и отправлять их в хите. Параметры бывают уровня хита, сеанса и пользователя (в данном случае нас интересует последний вариант). В качестве широко используемого костыля дополнительным пользовательским параметром используется client_id. О том, как добавить параметр в UA, читай тут. В GA4 для этого есть отдельный блок в меня в левой части (cм. скрин).Что важно, если у тебя все же UA вместо GA4— запомнить индекс пользовательского параметра (от 1 до 20), поскольку в дальнейшем передача параметра будет проходить именно по индексу.

После того, как мы добавили пользовательский параметр, нужно настроить его передачу в хитах. Тут во всей красе проявляется основная цель GTM — настройку можно провести без разработки и релиза сайта. Итак, в GTM переходим во вкладку слева “Переменные”, далее жмем кнопку “Создать”. Вбиваем имя переменной (например Client ID), в конфигурации выбираем “Собственный код javaScript”.

Переменные в GTM — аналогичны переменным в языках программирования, т.е. являются некими именованными значениям, которые могут чем-то заполняться и дальше использоваться как параметр в триггерах и тегах. В этом примере переменная заполняется кодом JS, а можно просто значением глобальной переменной JS или с помощью dataLayer (увидим этот способ в следующем разделе). Также в GTM есть предопределенные переменные, такие как Page URL, Referrer и тд, заполняющиеся автоматически.

Итак, что же вписываем в код переменной JS:

Код №1. Получение cid из объекта счетчика UA

В прошлой версии GA (UA) получить client_id можно из глобальной переменной ga, как показано в gist’е слева. Блок try/catch нужен, чтобы при ошибке js и невозможности получить client_id не выпадала ошибка в консоль, а отсылался false.

Код №2. Получение cid из объекта счетчика GA4

В GA4 перестал использоваться analyticsjs, и теперь получать client_id нужно способом, показанным слева:

Код №3. Получение cid из кук

Также можно получить client_id через куку, как показано в gist’е (спасибо статье от prometriki). Но этот способ неуниверсален, т.к. можно настроить GA так, чтобы client_id хранился в localStorage или sessionStorage. О том, как реализовать это в GTM, хорошо рассказал Simo Ahava (один из лучших блогеров по GA, GTM и вообще веб-аналитике). Еще одна проблема с куками — для поддомена создается своя кука, и если стоит 1 счетчик на все субдомены, client_id

будет не тот.

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

Теперь, после создания переменной, хранящей client_id, мы должны отправить ее в GA. В UA для этого можно воспользоваться функционалом заданий (CustomTasks), позволяющим выполнить некоторое задание перед отправкой хита и изменить/дополнить сам хит (пример от burgerdata или еще один от owox). Это позволит разметить 100% трафика, не отправляя при этом лишних хитов.

Скрин 14. Эвент передачи client_id в GA4

Также это можно сделать, отсылая эвент с пользовательским параметром (передавать в теге pageviews нельзя, т.к. в этот момент объект счетчика еще не создан, в вместо cid будет передаваться indefined). Как указано в посте от burgerdata (статья для старой версии GA), данный метод позволяет разметить ~98% трафика. Потеря 2% скорее всего связана с тем, что часть пользователей уходит до полной загрузки DOM (случай, когда страница медленно загружается). В GA4 к сожалению нельзя сделать служебное событие, которого не будет в отчете, поэтому будем создавать обычное. Итак, создаем тег Google Аналитика: событие GA4, в нем в теге конфигурации выбираем тег Pageviews, созданный раннее для отправки просмотров страниц. Название — любое, главное потом отличать это событие от других. В качестве триггера создаем новый с типом “Окно загружено”. Не забываем опубликовать изменения.

Напоследок — если ты все же выберешь получение cid из кук, то можно настроить его получение с помощью тега Custom HTML и отсылать в тег просмотра страниц GA, однако потребуется дополнительная настройка порядка активации тега. Подробнее в этой статье.

Передача Id пользователя (UserId)

Итак, мы поняли как передавать id пользователя (на самом деле его куки) в отдельном параметре. Однако, иногда нам хочется иметь возможность настраивать сегменты/фильтры по нашему собственному id (например, id клиента в CRM), а также объединять все куки пользователя с разным устройств в один идентификатор. В таком случае, в качестве пользовательского параметра мы можем отсылать еще и user_id. Хорошая новость в том, что это зарезервированный параметр, GA имеет для него название по умолчанию и в случае с GA4 может показывать кросс-девайсные отчеты, если данный параметр будет присылаться. Очевидно, что первые просмотры или даже сеансы пользователя могут быть до авторизации, соответсвенно для них мы не можем указать user_id. Волноваться на этот счет не стоит, т.к. после того, как передадим в качества параметра user_id, все предыдущие хиты также автоматически разметятся с помощью функции объединения сеансов.

В UA данную функцию нужно включать отдельная в настройках ресурса. Также нужно отдельно включать функцию user_id и создавать для него отдельный view. Подробнее можно прочитать в статье thisisdata (надо отдать должное этому блогу, вместе с burgerdata и prometriki являются моими первыми пособиями по GA и лучшими блогами по веб-аналитике в рунете). В GA4 данный функционал работает из коробки.

Итак, тут наконец наступает момент, когда опять нужно просить разработчиков. На их плечи упадет необходимость заполнять dataLayer. Что это такое — объект, через который можно передавать контекст (какие-то данные) с сайта в веб-аналитику (GTM). Физически представляется собой js-массив, у которого ключи являются строго строками (на самом деле так только в первой версии), а значения — все что угодно, от числа/строки для объекта JS. В GTM мы имеем доступ к этому массиву, можем читать из него данные, а также создавать триггеры на пуш определенного ключа в dataLayer, чтобы затем передавать данные в другие системы (например GA). Не беспокойся, сейчас мы увидим пример. После того, как мы запушили что-либо в dataLayer, это значение можно прочитать, если создать переменную типа dataLayer.

Скрин 15. Создание переменной уровня данных user_id.

Итак, переходим в GTM в меню слева в Переменные, жмем создать, и в конфигурации переменной выбираем “Переменная уровня данных”. В названии вбиваем user_id (именно с таким ключом разработчики будут пушить данные в массив). Версию уровня данных можно оставить любой, если вы не знаете что это такое. Коротко — в первой версии если пушить один ключ несколько раз, всегда будет учитываться только последнее значение. Во второй — ключ может быть вложенным и быть merged (читай тут). Также можно установить значения по умолчанию и настроить автоматическое изменения формата переменной, но не думаю, что для id пользователя что-то из этого понадобится. Жмем “Сохранить”.

Затем настраиваем передачу user_id из переменной GTM в GA. Для этого открываем первый тег, который мы здесь создали (просмотры страниц в GA4). Раскрываем “Поля, которые необходимо задать”/“ Fields to Set”, в названии вбиваем user_id (зарезервированный параметр в GA), в значении — {{user_id}}. Фигурные скобки в GTM означают, что значение берется из переменной. Жмем “Сохранить”. Что прекрасно — в прошлой версии GA это настраивалось ровно также, поэтому Google вынес это отдельной статьей в документации GTM.

Код №4. Передача user_id в dataLayer

Дело за малым — тут как раз разработчики вступают в игру. Их задача — запушить в массив dataLayer ключ user_id и его значение. Пример кода можно увидеть слева (пример из статьи Simo Ahava). В целом, это можно сделать в коде уже после того, как объявлен контейнер (про объединение сессий я уже писал), но лучше вставить этот фрагмент до блока кода GTM, поскольку тогда абсолютно все хиты будут помечены user_id. Кстати, подключение Search Console через GTM надо проводить до того, как dataLayer начнет объявляться перед тегом <noscript> тег-менеджера. Читай про это ниже в блоке про подтверждение собственности.

К сожалению, при каждом обновлении или переходе на новую страницу объект dataLayer создается заново, поэтому все данные в него необходимо записать снова. Есть вариант, как этого избежать — использовать Single Page Application (SPA) или сделать persistent dataLayer при помощи браузерного хранилища localStorage (можно конечно и через куки, но некоторые пользователи их отключают).

Почему мы не использовали dataLayer для передачи client_id — потому что первые cid появляется уже после того, как инициализируются объекты GTM и GA.

Другие Custom Dimensions

Помимо client_id и user_id можно настроить и другие полезные dimensions, такие как session_id и hit_id. Читай обо всем тут.

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

Финальный аккорд про субдомены

Итак, мы уже знаем, что при наличии поддоменов каждый нужно будет прописать в Search Console и что у каждого своя кука. Советы на этот случай:

создать счетчик на общий домен
создать счетчик на каждый поддомен
все это активировать одни триггером в tagmanager.

И последний шаг — чтобы при переходе из одного в субдомена в другой не создавался новый сеанс с директа, нужно выставить параметр
cookieDomain. Сделать это можно через ga(‘create’, ‘UA-XXXXX-Y’’, ‘auto’) в случае установки GA напрямую (последний параметр и есть то что нам нужно, по умолчанию он равен document.location.hostname), или через GTM:

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

Подтверждение права собственности сайта

Возвращаемся к Search Console. В отличии от других систем, консоль поиска не требует установки блока кода на сайт (хотя можно и так), посколько вся информация собирается поисковыми ботами гугла во время индексации (боты гуляют по всему интернету и записывают данные о сайтах в специальную БД, называемую индексом, по которой гугл ищет информацию для ответа на запросы в своем поиске). Но для того, чтобы увидеть собранную информацию, нужно подтвердить что данный сайт — твой.

Есть множество способов сделать это (читай оф.документацию), таких как:

Вставить HTML-тег на любую страницу сайта. Тут много минусов, от лишнего кода для разработки до управления правами, поскольку каждый пользователь должен вставить свой тег. Вдобавок гугл иногда проверяет, актуальны ли права, и поэтому нужно поддерживать актуальность тегов на страницах.
HTML-файл на сервере. Из минусов можно назвать зависимость от разработки, поскольку файл должен висеть постоянно + данный способ подвержен ошибкам со стороны сайта.
Запись в DNS. Минус в том, что у аналитика скорее всего нет туда доступа, и придется каждый раз при изменении просить админов править файл.
Код отслеживания GA. В целом неплохой вариант, но нужно просить разработчиков править код на сайте. Зачем, если все можно сделать в GTM?
Через GTM. Это наш вариант и именно его мы сейчас обсудим.

Для начала добавляем ресурс в Search Console (слева в меню “Add property). Domain обязывает использовать DNS-верификацию, поэтому будем использовать URL prefix. Вбиваем туда свой сайт и жмем “Continue”. Есть вот такой нюанс (читай про него тут):

Если у сайта есть возможность использовать несколько протоколов (http/https) или существуют поддомены, то необходимо прописать каждый и подтвердить через GTM.

Скрин 17. Окно выбора способа подтверждения

Обязательным моментом здесь является то, что тег <noscript> GTM должен стоять сразу после открывающегося тега <body>, иначе не сработает. Поэтому эту процедуру стоит делать перед тем, как начать писать что-то в dataLayer в начале страницы, или просто перенести первый пуш на место после объявления GTM.

Выбираем Google Tag Manager и жмем “VERIFY”. Вуаля, на этом все.

Как и в случае с GTM/GA, в Search Console я бы советовал использовать общий админский аккаунт для подтверждения собственности, а для просмотра выдавал бы доступ делегированного владельца.

Отличие GA4 от Universal Analytics

Итак, поговорим про отличия. На представленной месяц назад GA4 основной упор делался на кросс-девайсные взаимодействия, поэтому функционал User Id работает по умолчанию во всех отчетах (не нужно создавать отдельный view). Также новая GA умеет считать LTV предсказывать churn.

Помимо уже обозначенных нюансов, таких как перенос page_view в события (как и все остальные типы хитов), отсутствие междоменного отслеживания, views и фильтрации трафика, также важно, что:

в событиях больше нет Category, Action и Label ❓
расчет времени сессий основывается на разнице во времени между последним событием в сессии и событием session_start (отправляется автоматически) ➕
в GA4 не всегда новая кампания обновляет сеанс ➖
отсутствие группировки контента ➖
отсутсвие Custom task (очень, очень много хаков делали крутые чуваки используя этот функционал)➖
отсутствие отслеживание тайминга➖
25 пользовательских параметров вместо 20 ➕

Хорошие новости — на некоторых аккаунтах недавно начали раскатывать междомен и фильтрацию трафика. Возможно, скоро GA4 ждет великое будущее.

Шаблоны GTM

Не так давно гугл внедрил новую фичу — шаблоны GTM. Теперь не нужно каждый раз настраивать GTM, можно сделать один раз, сохранить в шаблон и дальше доставать из шаблона. Также это один из способов для сервисов дистрибьютить свои теги. К сожалению, в этой статье уже не хватает места для подробного описания фичи, поэтому просто оставлю здесь ссылку на статью от Simo Ahava + оф.док. Также оставлю ссылки на уже появившиеся репозитории шаблонов (первый от того же Simo, второй от автора burgerdata с поиском по github). Скачивайте шаблон, потом заходите в GTM →Шаблоны —> Создать →3 точки справа →Импорт и выбираете скачанный .tpl файл.

Предварительный просмотр и дебаг

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

Скрин 19. Окно предварительного просмотра

На главном экране жмем “предварительный просмотр”. В новой вкладке откроется сайт https://tagassistant.google.com/?… с полем для ввода дреса. Забивай туда url сайта, на котором стоит контейнер, и жми “Continue”. В новой вкладке (еще одной) откроется твой сайт, при этом во вкладке с tag assistant будет выдаваться информация об отработавших триггерах, тегах и параметрах. Не волнуйся, хотя ты увидишь новые изменения в контейнере сайта, они работают только в твоем браузере, остальные пользователи пока видят старую версию контейнера.

Single Page Application (Advanced)

Настал черед поговорить про SPA, они же одностраничники. Давай поясню, что это такое.

В ранних версиях сайтов (тем более статичных) все работало так — ты вбивал адрес в браузер (или переходил по ссылке), браузер грузил html и все остальное (js, картинки, css и тд), полностью обновлял страницу и рендерил загруженное содержимое. Каждый раз при обновлении страницы создавался новый объект счетчика GA, который автоматом посылал pageviews, ибо передать объект js между страницам нельзя (можно разве что сохранять данные в куке, что и использует GA для хранения client_id).

Суть работы GA в этом и состоит — счетчик автоматом при создании отсылает pageviews + посылка эвентов кодом JS в ответ на какой-то триггер. В UA помимо просмотра страницы и эвента были еще несколько типов хитов. В GA4 абсолютно все хиты являются передачей эвентов (закос под мобилку), поэтому даже просмотр страницы — это эвент, который имеет зарезервированное имя события (page_view). Подробно о том, какие еще события собираются автоматически, читай в справке. Если тебе интересно, почему в первой ссылке абзаца — про gif, то сейчас объясню:

Раньше не все браузеры умели в JS, а также были более жесткие требования к кросс-доменным запросам для XHR-реквестов (поговорим про них ниже), а вот для запросов картинок не было таких жестких ограничений, плюс для них не нужен javaScript. Поэтому в старой версии GA (она же ga.js) отправка аналитики осуществлялась запросом GIF-картинки с передачей всей информации в get-параметрах запроса. Ответом служила минимально допустимая картинка размером 1х1, отсюда и название многих счетчиков СВА — пиксель. Поскольку в современном мире старые проблемы отпали, сейчас сбор данных осуществляется http-запросом POST по специальному протоколу, в теле которого передаются все данные (например, для версии GA analytics.js).
P.S.: Сейчас и analytics.js устаревает, на его место приходит глобальный таг (gtag.js), работающий с тегами многих систем ; а также в GA4 обновился и measurement protocol.

Так вот, в какой-то момент появились одностраничники (React и все такое), суть которых в том, что полная загрузка страницы и обновление в браузере происходит только 1 раз, далее клиент подгружает с сервера с помощью XHR код js, который дорисовывает новую страницу без перезагрузки (более того, такие блоки как хэдер и футер могут оставаться статичными и не перерисовываться). XHR — это подчасть AJAX, технология передачи HTTP запросов (как синхронных, так и асинхронных) на сервер без обновления страницы. При этом асинхронность означает то, что сайт до получения результата продолжает работать и может быть отзывчивым. Кстати, системы аналитики переходят с XHR на beacon (можно настроить в analytics.js и gtag.js), поскольку он позволяет не терять данные при unload’е документа (читай оф. документацию, но мы еще поговорим об этом в отдельной статье, посвященной достоверности данных веб-аналитики).

Итак, что же мы должны сделать, чтобы отловить перерисовку без перезагрузки новой страницы. Есть 2 варианта, как это работает:

JS с помощью history API изменяет url. GTM умеет это отслеживать с помощью триггера gtm.historyChange ⭐️, на который нужно навесить тег с отправкой эвента page_view (выше мы уже делали тег с эвентом, для передачи client_id, но пока я писал этот гайд появилась свежая статья).
Если у нас онлайн игра или что-то подобное, то скорее всего url не изменится никогда. В таком случае надо просить разработчиков пушить в dataLayer событие смены экрана, ловить его новым тегом и отсылать page_view. Думаю, ты справишься (если нет, пиши, в профиле указана телега).

Итак, мы научили GA работать с просмотрами страниц для SPA. Но есть еще одна проблема! Как упоминалось в блоке про каналы привлечения, при изменении utm-меток или referrer GA считает, что сменился канал привлечения, а значит создаст новый сеанс. Эта проблема хорошо описана в блоге burgerdata:

…
Говорят, что при этом возникают проблемы с источниками. Конечно! Но это связано с принципом работы встроенного тега GA, который каждый раз при срабатывании создает новый объект счетчика с заново определяющимися полями, в том числе location и referral. Пример: Юзер загремел на ваш реактивный сайт с adwords, пощелкал ссылки, url поменялся, из него пропали метки, однако перезагрузки страницы не произошло, и document.referrer в браузере по-прежнему указывает на google.com.
…
Любой сработающий далее тег аналитикса создаст новый сеанс с органики. По этому поводу я встречал у клиентов целые библиотеки на сотни строк, эмулирующие механизм GA по определению источника, и все равно приводящие к ошибкам. Подвох: Помимо location и referrer объект будет сохранять и другие поля, например, dimensionXX. Так что если в одном теге вы их указали, а в другом нет, злопамятный аналитикс передаст предыдущие. Это может быть критично для параметров уровня хита, но в моей практике проблем никогда не доставляло. ”

Для обычных сайтов такой проблемы не возникает, поскольку при обновлении страницы в новом счетчике GA в поле referrer будет адрес этого же сайта и новый сеанс не создастся (помнишь, мы обсуждали исключение источников перехода??).

Давай решим эту проблему!

Переходим в GTM в наш тег GA, жмем “расширенные настройки”, затем “Дополнительные метаданные тега”, ставим галку “Добавить название тега”. Далее вписываем название, которое нам нравится. Жмем Сохранить”.

Теперь наш JS объект трекера будет именован, в результате на новой странице не будет создан новый объект счетчика 😉.

Я бы рекомендовал прочитать также оф.док про SPA.

В тексте я ставил вот такие звездчоки ⭐️ в местах, где показывал плюсы GTM над прямым внедрением GA. Можешь еще раз пролистать статью и посчитать кол-во таких поинтов.

Бонус 🆒

Для тех, кто дочитал до конца, я подготовил несколько полезных ссылок :

интерактивный курс по GA4 от гугла — https://skillshop.exceedlms.com/student/path/66744-kak-ispolzovat-novye-vozmozhnosti-google-analitiki
мини-курс по GA4 от автора Analytics Tips — https://analytics-tips.com/pro-ga-4.html
Длинный метр по настройке эвентов в GA4 через GTM от автора Analytcs Mania — https://www.youtube.com/watch?v=ekp6dcCXXb8&feature=youtu.be
агрегатор чеклистов для GA — https://www.datadrivenu.com/google-analytics-checklist-library/
Гугл-док на русском с чеклистом проверки GA от IT-agency— https://docs.google.com/spreadsheets/d/1nCZkMwZrwtDomq_trlYUX5nGnKjnWGfXo7Y4foZizwE/edit#gid=0
Выгрузка всех тегов в таблицу — https://burgerdata.com/blog/vygruzka-tegov-iz-google-tag-manager-v-google-spreadsheets/

P.S.: Если тебе понравилась стать, в качестве благодарности можешь купить мне кофе на https://www.donationalerts.com/r/stats_data_ninja или https://buymeacoffee.com/koch.