Назад в блог

Блог

Каждое событие GA4, которое видит ваш серверный контейнер, и откуда берётся каждое из них

Опубликовано · 4 мин чтения

Пропуск GA4 через серверный контейнер не меняет набор существующих событий. Меняется то, что вы наконец видите, какие из них доходят: страница контейнера считает каждое имя события, которое она пересылает. Этот список удивляет в обе стороны: появляются события, которых никто не настраивал, и не хватает тех, которых ждали. У обоих случаев простые объяснения, как только знаешь, откуда берётся каждое событие.

Четыре события, которые тег Google отправляет в любом ресурсе

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

  • page_view — одно на загрузку страницы или на смену маршрута в одностраничном приложении, если в потоке включена опция «изменения страницы».
  • session_start — первое обращение новой сессии. Сессия заканчивается после тридцати минут бездействия, поэтому посетитель, вернувшийся через два часа, начинает новую.
  • first_visit — один раз на браузер, в самой первой сессии, которую GA4 от него видел. Очистка cookie порождает ещё одно.
  • user_engagement — отправляется, когда страница пробыла на переднем плане десять секунд, или когда посетитель уходит после взаимодействия. Отсюда берётся время взаимодействия в GA4.

Если вы видите page_view и больше ничего — тег работает. Это не поломка; это сайт, на котором ещё никто не доскроллил до самого низа.

Девять событий расширенной статистики — и переключатель, который решает, получите ли вы хоть одно

Расширенная статистика GA4 собирает в браузере ещё девять событий, без тега для любого из них. Настраиваются они в потоке данных, а не в Диспетчере тегов, и поэтому серверный контейнер пересылает их, не зная об их существовании.

У каждого условие строже, чем подсказывает название.

  • scroll — один раз на страницу и только когда было видно 90 % высоты страницы. Не при любой прокрутке — при достижении низа. Страница короче области просмотра не вызывает его никогда.
  • click — исходящий клик, на домен, отличный от текущего. Внутренние ссылки не считаются. Событие называется click, с параметром outbound; события outbound_click не существует.
  • view_search_results — загрузка страницы, в URL которой есть параметр поискового запроса (по умолчанию q, s, search, query или keyword).
  • file_download — клик по ссылке, оканчивающейся расширением документа, архива, аудио, видео или таблицы.
  • form_start и form_submit — первое взаимодействие с формой на странице и её отправка.
  • video_start, video_progress и video_complete — только для встроенных плееров YouTube и только если во встраивании включён JS API.

А вот часть, которая стоит людям недель. Каждое из этих девяти зависит от главного переключателя расширенной статистики в потоке, и поток, созданный через Analytics Admin API, а не в интерфейсе Analytics, имеет этот переключатель ВЫКЛЮЧЕННЫМ. Прочитайте настройки через API — каждая отдельная опция вернёт true; главный переключатель в ответе просто отсутствует, потому что он false, а API опускает ложные булевы значения. Настройка выглядит полностью включённой и отдаёт только page_view.

Мы обнаружили это на собственном ресурсе. SignalHost включает главный переключатель, когда создаёт ресурс для вас; если ваш был создан иначе и scroll так и не приходит, откройте поток данных в Analytics и проверьте саму «Расширенную статистику», а не опции под ней.

Семь событий электронной торговли — только если их отправляет ваш сайт

Коммерческие события — view_item_list, view_item, add_to_cart, remove_from_cart, begin_checkout, add_payment_info и purchase — это те, что действительно важны магазину, и единственные на этой странице, которые ничто не отправляет автоматически. GA4 задаёт имена и форму; ваш сайт должен отправить каждое из них в dataLayer точно под этим именем, с приложенным объектом ecommerce.

Стандартная тема Shopify этого не делает. Ядро WooCommerce этого не делает. Это делает приложение или плагин для dataLayer, а в Shopify событиям оформления заказа нужен Custom Pixel, потому что контейнер темы никогда не загружается на страницах оплаты. Когда вы выбираете платформу магазина в мастере SignalHost, мы устанавливаем триггер и тег события GA4 для каждого из семи, так что в момент, когда ваш сайт отправит purchase, событие будет переслано — но саму отправку организуете вы. Следующая статья описывает, что именно установить.

Что считает страница контейнера

Каждый запрос измерения, проходящий через ваш контейнер, считается по имени события, по дням, в течение 400 дней. Хранится только имя — не URL, не идентификатор клиента, ни один параметр — и именно это делает безопасным хранить его так долго. Список — это то, что дошло до вашего имени хоста, поэтому он отвечает на вопрос, на который сам Analytics ответить не может: отправил ли браузер это вообще?

Ожидайте неровных чисел. Каждая загрузка страницы — page_view; только загрузки, дошедшие до низа, — scroll; только сессии длиннее десяти секунд — user_engagement. Сайт с десятью просмотрами страниц и двумя scroll — нормальный сайт.

Когда события нет

Два случая, и страница контейнера их различает.

Если события нет в списке контейнера, ваш сайт его не отправлял. Контейнер не может переслать то, что не пришло. Для стандартного события проверьте переключатель расширенной статистики в потоке; для коммерческого — что отправка в dataLayer происходит, с правильным именем, на той странице, где должна.

Если событие есть в списке контейнера, но нет в Analytics, оно пришло и было переслано, а проблема на стороне Google: неверный идентификатор потока, фильтр данных, ресурс в другом аккаунте, а не в том, куда вы смотрите, или просто задержка отчётов — в реальном времени оно появится за секунды, стандартные отчёты могут занять сутки.

Перестаньте терять данные из-за блокировщиков

Десять тысяч запросов в месяц бесплатно, сколько угодно долго. Четыре минуты, чтобы понять, помогает ли это.