Блог
Каждое событие 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: неверный идентификатор потока, фильтр данных, ресурс в другом аккаунте, а не в том, куда вы смотрите, или просто задержка отчётов — в реальном времени оно появится за секунды, стандартные отчёты могут занять сутки.
