Семь смертных грехов GA4

Все действительно так плохо? Спойлер - да.

В июле 2023 Universal Analytics де-факто прекратит свое существование. Это означает что поддержка ресурсов такого типа будет прекращена, а на работу с историческими данными у пользователей останется 6 месяцев. Поэтому, если вы не являетесь подписчиком GA360, следующая версия Google Analytics совсем скоро останется единственной альтернативой для сбора данных с помощью сервисов Google.

Меня зовут Александр Игнатенко, я занимаюсь маркетинговой аналитикой, консультирую по настройке и принятию решений с помощью данных и также помогаю с обучением, разработкой и внедрением кастомных моделей атрибуции и A/B-экспериментами. Кроме того я веду телеграм-канал о маркетинговой аналитике «Модель атрибуции».

Сейчас остались считанные дни до отключения Universal Analytics. И несмотря на огромные изменения в интерфейсе, логике сбора и обработки данных, GA4 до сих пор не решает целую кучу важных проблем или решает их криво. Материал поможет вам быть готовым к изменениям и подстелит соломки там, где это нужно.

Эта статья – ответ на вопрос о том, чем это плохо для конечного пользователя. GA4 невероятно косячный. Если раньше мы могли свалить косяки сервиса на его сырость, то теперь – спустя почти 3 года после запуска – они выглядят как необъяснимые недоразумения. Всего таковых я насчитал семь. Это и легло в основу заголовка статьи. Итак, поехали.

1 грех - HyperLogLog++

2 грех - Пороговые значения

3 грех - Идентификация пользователей

4 грех - Google Signals

5 грех - AMP-страницы

6 грех - A/B-тестирования

7 грех - Работа с представлениями

На сладкое

Заключение

HyperLogLog++ – это зверь, который используется в интерфейсе GA4 для отчетов и при обращениях по API для оценки количества уникальных значений. Грубо говоря, это алгоритм машинного обучения, который эстимирует определенные метрики (в первую очередь количество пользователей и сеансов) на основании ряда эвристик и заполняет этими циферками ваши отчеты.

Его использование удобно экономией вычислительных мощностей, но для пользователя это оборачивается казусом. Метрика в отчете оказывается не точной цифрой, а приближением с определенным уровнем ошибки. То есть, даже если вы смотрите в несэмплированный отчет-исследование, то все равно имеете дело не с точными цифрами, а с их примерным приближением.

Вот те раз…. Не верите? Давайте вместе посмотрим в документацию:

±1,63%. Еще раз, вы видите не метрику, а ее приближение. И это не чья-то фантазия, а уровень ошибки, описанный в документации Google. То есть, если вам важна точность и сверка данных с CRM и другими источниками, то GA4 тут увы – не помощник.

Пороговые значения – механика в GA4, которая удаляет из отчетов данные, если их объем слишком мал. При этом, каковы эти пороговые значения, Google лаконично умалчивает:

Великолепно. Доподлинно известно одно: пороговые значения используются при включенных Google Signals и для отчетов, содержащих демографические данные. Самые дотошные аналитики выяснили, что при включенных Google Signals из отчетов удаляются например данные о посещениях страниц с менее, чем 50 пользователями. Это распространяется на обращения через API, но не касается выгрузок в BigQuery

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

В отличие от предыдущей версии Google Analytics в GA4 используются аж 4 области идентификации пользователей:

• идентификаторы пользователей;
  
• сигналы Google;
• идентификаторы устройств;
• моделирование.

И вместе они выливаются в 3 доступных метода идентификации:

• смешанная идентификация;
• с помощью наблюдаемых параметров;
• по идентификаторам устройств;

Начнем с того, что по умолчанию используется смешанная идентификация. При этом для ее эффективного использования необходимо включить Google Signals (что само по себе вызывает вопросы).

Но гораздо важнее, что первые два способа являются по сути черным ящиком – поскольку используют либо моделирование (для юзеров, не согласившихся на использование их данных на сайте), либо Google Signals. Для ресурсов с небольшим и средним трафиком это катастрофа – так как просто добавляет шума в и так не очень объемные данные.

И самое главное – способ идентификации по устройствам – наиболее близкий к Universal Analytics – был трусливо спрятан в максимально неочевидный выпадающий список в настройках. Для того чтобы включить его, вам понадобится внимательно почитать документацию и найти малозаметную кнопочку Show all в настройках идентификации.

Что ж, хорошая попытка.

Сигналы Google – попытка компании спастись от ограничения на использование third-party cookies. Вы можете включить эту настройку и GA4 начнет учитывать для связи с пользователями факт того, что они в момент визита были залогинены в свою учетку Google.

Выглядит объяснимо. Но благими намерениями выстилается не только дорожка к релевантным данным. Чем же чревато включение Сигналов Google?

Во-первых, в ваших данных появится больше ненужного шума (писал об этом выше).

Во-вторых, GA-запросы с вашего веб-сайта поменяют домен адресата. Вместо безобидного служебного google-analytics.com начнет использоваться домен второго уровня analytics.google.com. Интересно, да?

В-третьих, перед активацией Google Signals вы увидите интересное (и очень незаметное) сообщение:

Я не профессиональный игрок в покере, но чем дальше углублялся в историю с Google Signals, тем меньше понимал, где за этим "столом" находится так называемый "лох". А это, как правило, очень плохой сигнал. Google Сигнал.

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

В это трудно поверить, но у GA4 нет решения для одного из флагманских продуктов Google – AMP-страниц. Если вы считаете, что это устаревшая и / или не совсем важная фича – держитесь подальше от SEO-специалистов, они поднимут вас на смех. Так как AMP – это облегченные страницы с данными вашего веб-сайта для удобного доступа к нему с мобильных устройств. И это архиважный фактор для ранжирования в Google.

Нет, само по себе решение существует – David Valejo взял на себя роль Кулибина, задокументировал и выложил в свободный доступ JSON-конфигурацию компонента AMP-analytics для GA4 (детали тут). На основе него даже пилят плагины для CMS. Но это самоделка. Которая кстати имеет несколько уязвимостей (например связывание сессий для реализации с GTM Server Side).

Так что если вы получаете массу трафика на ваши AMP-страницы, мои вам соболезнования. Используйте, модифицируйте костыль от David Valejo и оставляйте запрос в поддержке – может кто-то и соблаговолит ответить.

Вместе с Universal Analytics в бездну уходит и другой популярный сервис – Google Optimize (тут я писал обзор сервисов A/B-тестирования на замену уходящему Optimize). Последний был удобен своей ценовой политикой (бесплатно) и бесшовной интеграцией с Google Analytics. Про то и другое имеет смысл забыть.

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

Был анонсирован API для third-party-сервисов с помощью которого их клиенты смогут отправлять данные в GA4, создавать аудитории и анализировать результаты экспериментов. Забудем про то, что это костыль. Важнее другое.

Google предлагает анализировать результаты AB-тестов в интерфейсе GA4. И это смехотворно – в первую очередь из-за HyperLogLog++. Для AB-тестов важна точность, данные должны быть гранулярными, а HLL++ делает это невозможным по сути – поскольку формирует отчеты с примерными (неточными) данными.

Единственно возможный механизм – интерпретация результатов экспериментов в BigQuery. Но чем это лучше работы непосредственно в интерфейсе сервиса AB-тестирования, где тебе и значимость посчитают и все остальное? Непонятно.

Это боль. Если в Universal Analytics вы могли реплицировать свой ресурс исходя из разных ролей / задач / типов трафика / гео, то теперь всего этого не стало. Да появился функционал subproperty / roll-up property (дочерних и агрегированных ресурсов), но он доступен только для подписчиков GA360, а простым смертным осталось изобретать костыли для решения такой очевидной и такой важной задачи, как создание и управление представлениями. Грустим.

Атрибуция – подборка моделей была скорректирована, в качестве дефолтной выбрана многоканальная атрибуция на основе данных – по сути еще один черный ящик.

Пустые значения параметров в отчетах – вполне возможная история (например для отчета по Landing Pages), которая никак не освещается в документации.

Отсутствие специальных параметров с областью действия item / товар – их нет до сих пор, несмотря на анонс.

Отсутствие внятного описания по переезду – непонятно, что произойдет с существующими ресурсами после отключения доступа к историческим данным и когда это собственно произойдет (в справке указаны расплывчаты формулировки "минимум 6 месяцев").

К сожалению за считанные дни до отключения предыдущей версии новая еще до сих пор остается сырой.

Возможно у вас есть свои претензии в GA4 – напишите о них в комментариях.

Другие мои мысли на тему маркетинговой аналитики можно почитать в телеграм-канале «Модель атрибуции».

Вам мог понравиться этот пост – прошу в этом случае оставить лайк и поделиться им с друзьями – для меня это очень важно.