Назад в блог

Блог

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

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

Пропуск 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 и проверьте саму «Расширенную статистику», а не опции под ней.

Шестнадцать событий, которые может отправить только ваш сайт

События, которые приносят деньги, — продажа, заявка, регистрация — единственные на этой странице, которые ничто не отправляет автоматически. GA4 задаёт их имена и форму; ваш сайт должен отправить каждое из них в dataLayer точно под этим именем в тот момент, когда оно происходит.

В каждом контейнере SignalHost для шестнадцати из них уже ждут триггер и тег события GA4:

  • Девять для воронки магазина: view_item_list, view_item, add_to_cart, remove_from_cart, view_cart, begin_checkout, add_shipping_info, add_payment_info и purchase, каждое с приложенным объектом ecommerce.
  • Пять для заявок: generate_lead, contact, schedule, submit_application и subscribe.
  • Два для регистраций: sign_up и start_trial.

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

Кнопка «Поддерживаемые события» на карточке «События» вашего контейнера перечисляет их все: что означает каждое и что отправлять. Если ваш контейнер уже отправляет одно из них в GA4 собственным тегом, SignalHost оставляет это событие вашему тегу, а не считает его дважды.

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

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

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

Две вещи никогда не дадут двум спискам совпасть точно. Посетитель, не ответивший на ваш баннер, всё равно отправляет каждое событие — как пинг без cookie, — и контейнер его считает, а Analytics отбрасывает; страница показывает оба числа, чтобы было видно, какое из них какое. А session_start и first_visit на странице контейнера не появляются вообще: браузер не отправляет их как события, он ставит два флага на первом page_view, и Analytics создаёт события на своей стороне.

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

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

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

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

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

Начинаете с нуля? Как настроить серверный Google Tag Manager: пошаговое руководство.

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

Начните бесплатно. Запустите первый контейнер за несколько минут.