Сеанс перестал быть контейнером
Главное изменение спрятано глубже интерфейса. В прежней версии данные складывались в иерархию: пользователь содержал сеансы, сеанс содержал обращения — просмотры, события, транзакции. Каждый тип обращения обрабатывался по своим правилам, и добавить измерение можно было только там, где это предусмотрено типом.
В GA4 сущность одна — событие с параметрами. Просмотр страницы, клик по ссылке, оплата и запуск видео описываются одинаково: имя события плюс набор пар «параметр — значение». Сеанс из контейнера превратился в производную величину: система видит событие начала сеанса и группирует последующие события по времени и правилам таймаута.
Практическое следствие важнее теоретического. Раз структура плоская, любой вопрос к данным сводится к фильтрации потока событий по параметрам. Раз сеанс выводится, а не задаётся, его границы зависят от настроек — и потому расходятся с сеансами других систем. Почему цифры двух счётчиков на одном сайте не совпадают никогда, разобрано в сравнении Метрики и GA4.
Из чего собрано событие
| Категория событий | Кто их создаёт | Что с ними делать |
|---|---|---|
| Автоматические | Собираются сразу после установки кода | Ничего, они уже есть |
| Улучшенная статистика | Включается переключателем в потоке данных | Проверить, что не дублируют свою разметку |
| Рекомендуемые | Отправляет разработчик с предписанным именем | Использовать имена из документации, иначе отчёты не соберутся |
| Пользовательские | Придумывает и отправляет команда | Описать схему заранее, имена не менять |
| Ключевые | Любое событие, помеченное как важное | Помечать только то, что означает результат |
Разница между рекомендуемыми и пользовательскими событиями не косметическая. Рекомендуемые имена система понимает: под них уже собраны отчёты и предусмотрены параметры. Пользовательское событие с собственным именем система хранит, но интерпретировать не умеет — все выводы придётся строить руками.
Отсюда правило порядка работ: сначала список событий и параметров на бумаге, потом внедрение. Разметка «сначала поставим, потом разберёмся» даёт набор имён вроде click1, click_new, click_final, которые через полгода не читаются никем.
Куда делись привычные показатели
| Было в прежней версии | Стало в GA4 | В чём разница по существу |
|---|---|---|
| Показатель отказов | Вовлечённость и обратная к ней доля | Считается от порога времени и действий, а не от одного просмотра |
| Цели | Ключевые события | Метка на событии вместо отдельной сущности с условиями |
| Тип обращения | Имя события | Типов больше нет, отличается только имя |
| Категория, действие, ярлык | Произвольные параметры | Схема не навязана, но и не задана — её проектируют сами |
| Готовые отчёты по умолчанию | Конструктор и свободный анализ | Нужный отчёт чаще собирается, чем находится |
Замена отказов на вовлечённость — не переименование. Прежний показатель отказов считал сеанс с единственным обращением, независимо от того, сколько человек читал страницу. Вовлечённость учитывает длительность, число просмотров и факт ключевого события. Из-за этого страница с одним длинным материалом в GA4 выглядит совсем иначе, чем в старом отчёте, — и сравнение двух чисел между собой лишено смысла. Что именно означает каждое из них, разобрано в терминах показатель отказов и вовлечённость.
Переименование целей в ключевые события развело две величины, которые раньше назывались одним словом. Внутри аналитики считаются ключевые события, в рекламном кабинете — конверсии по своим правилам атрибуции. Расхождение между ними теперь хотя бы объяснимо; как оно возникает, показано в разборе моделей атрибуции. Практическая часть настройки — в материале про цели в аналитике.
Параметры, регистрация и лимиты
Параметр — это то, что отличает одно событие от другого: какой товар, какая форма, какой раздел. Отправить можно почти любой набор, но в отчётах он появится только после регистрации в качестве специального параметра.
Порядок здесь неочевидный и стоит нервов. Незарегистрированный параметр приходит и хранится, но в интерфейсе его нет. После регистрации он появляется — и только для данных, собранных начиная с этого момента. Прошлое не пересчитывается никогда.
Число регистрируемых параметров ограничено, и лимит расходуется быстрее ожидаемого: каждое поле формы, каждый признак товара просится в отдельное измерение. Актуальные значения лимитов стоит смотреть в документации, а планировать — исходя из того, что места мало. Практичный подход: регистрировать параметры, по которым будете принимать решения, а остальное оставлять в сыром потоке и доставать выгрузкой.
Вторая ловушка — количество разных значений. Параметр с сотнями уникальных значений — идентификатор заказа, полный адрес страницы с метками — в стандартных отчётах схлопывается в строку «прочее». Данные не пропали, просто интерфейс их не показывает. Отсюда правило: идентификаторы — в выгрузку, а в отчёты — категории. Разметку ссылок UTM-метками это касается напрямую, потому что бесконтрольные метки плодят уникальные значения.
Что ломается при переносе «как было»
Схема «категория — действие — ярлык», перенесённая дословно. Три параметра со старыми именами формально работают, но лишают смысла всю затею: событийная модель даёт свободу назвать параметры по предметной области, а не по слоту старого интерфейса.
Дубли из улучшенной статистики. Переключатель уже собирает прокрутку, исходящие клики, поиск по сайту и загрузки файлов. Своя разметка тех же действий даёт два события на одно действие, и цифры удваиваются незаметно.
Ключевые события, назначенные всем подряд. Если пометить важным просмотр контактов, прокрутку и клик по телефону, отчёт покажет конверсию, которая ничего не измеряет. Что считать результатом, а что промежуточным шагом, разбирается в материале про конверсию.
Перенос исторических данных. Внутрь GA4 старые данные не переносятся. Единственный доступный ход — сохранить выгрузки прежней версии отдельно и сравнивать вручную, помня о разнице определений.
Событие в отладке видно, в отчётах нет. Стандартные отчёты обновляются с задержкой, а новые измерения появляются только после регистрации параметра. Проверять в отладочном режиме и в свободном анализе, а выводы делать через сутки.
Конверсий в аналитике меньше, чем в рекламном кабинете. Разные правила атрибуции и разные окна учёта. Сравнивать динамику внутри одной системы, а не абсолютные числа между системами.
В отчёте строка «прочее» вместо значений. Слишком много уникальных значений параметра. Сгруппировать значения в категории при отправке, а детализацию доставать из выгрузки сырых данных.
Часть строк исчезла из отчёта. Система скрывает строки с малым числом пользователей, чтобы их нельзя было идентифицировать. Расширить период, укрупнить срезы или работать с выгрузкой.
Пользователей меньше, чем визитов в другой системе. Разные определения пользователя, разная фильтрация роботов и разное поведение при отказе от сбора. Порядок сверки описан в обзоре инструментов веб-аналитики.
Чего GA4 не покажет
Данные, которые не собраны. Система не восстанавливает прошлое. Событие, не размеченное в январе, в январе не появится никогда, сколько бы настроек ни включили в марте.
Полную картину без согласия пользователей. Часть посетителей отказывается от сбора, часть блокирует скрипты. Пробелы система частично достраивает моделированием, и в отчёте это выглядит как обычное число — хотя это оценка.
Деньги за пределами сайта. Оплата по счёту, продление по телефону, возврат через месяц в аналитике не появятся сами. Их приносит связка с базой сделок — механика описана в разборе сквозной аналитики.
Причину, а не только факт. Отчёт покажет, что доля вовлечённых сеансов упала, но не покажет, что на странице сломалась кнопка. Для этого нужны записи сессий, тесты и разговор с людьми — например, A/B-тест вместо догадки.
Ответ на вопрос, который не заложен в схему. Разрез по признаку, который не передавался параметром, собрать нельзя. Поэтому проектирование схемы событий — работа не техническая, а управленческая: список вопросов, на которые вы собираетесь отвечать, и набор показателей для дашборда определяют разметку, а не наоборот.
Спорное место
Событийная модель подаётся как чистое улучшение: гибче, единообразнее, ближе к тому, как устроены продукты. Это правда, и у неё есть неудобная обратная сторона.
Свобода схемы означает, что качество аналитики теперь целиком зависит от того, кто её проектировал. Прежняя жёсткая структура ограничивала, но и защищала: у всех были одинаковые отказы, одинаковые сеансы и сравнимые между собой отчёты. Теперь два сайта с одинаковым трафиком могут показывать несопоставимые цифры просто потому, что по-разному размечены, — и понять это можно, только заглянув в схему событий.
Второе следствие — стоимость входа выросла. Отчёт, который раньше открывался в готовом виде, теперь собирается руками, а ошибка в разметке остаётся в истории навсегда. Для команды с аналитиком это выигрыш; для небольшого сайта, где счётчик ставят один раз и смотрят раз в месяц, — скорее потеря. Совет «переходите на событийную модель и стройте свою схему» полезен не всем, кому его дают; иногда честный ответ — поставить минимальную разметку из готовых событий и не изображать глубокую аналитику. Сопоставимая по задачам альтернатива — Яндекс.Метрика, где часть отчётов работает из коробки.
Частые вопросы
Чем событийная модель принципиально отличается от прежней?
Куда делся показатель отказов?
Что такое ключевые события и зачем переименовали цели?
Почему параметр отправляется, а в отчёте его нет?
Можно ли исправить неправильно названные события задним числом?
Нужен ли BigQuery для обычного сайта?