Отслеживание GA4 без cookie-файлов с помощью серверного GTM

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

Адаптация к этим изменениям не просто необходима для компаний и маркетологов, полагающихся на данные, - это абсолютное требование.

Один из способов адаптации к новым проблемам отслеживания - переход на отслеживание без файлов cookie. Несмотря на то что у последней версии Google Analytics есть множество минусов и плюсов, она остается самой популярной аналитической платформой. Именно поэтому в этой статье мы расскажем о том, как настроить бесконтактное отслеживание в Google Analytics 4 с помощью серверного Google Tag Manager. Мы будем использовать sGTM, режим согласия (consent mode), Firestore и power-up User-ID.

Ведутся споры о том, соответствует ли отслеживание без использования файлов cookie требованиям GDPR. В этой статье мы приводим пример того, как можно реализовать отслеживание без cookie с помощью Google Tag Manager. Перед настройкой проконсультируйтесь с вашим DPA, чтобы проверить правила стран.

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

Но сейчас многие сайты отказываются от использования этих файлов cookie для отслеживания действий пользователей. Вместо этого они используют новые методы, которые не предполагают хранения этих данных в браузере пользователя. Этот новый способ отслеживания без файлов cookie называется "cookieless tracking".

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

Это не только помогает избавиться от cookies и сделать отслеживание более точным, но и обеспечивает более высокий уровень соответствия требованиям и контроль над пользовательскими данными.

Отслеживание без cookies помогает адаптироваться к последним изменениям в области конфиденциальности и ограничений отслеживания. Вот несколько примеров:

1. 1.
   Регламент. Регуляторы защиты данных в Европе и некоторых других странах ограничивают использование файлов cookie без согласия пользователя. Процент пользователей, отказавшихся от cookies, зависит от страны, возраста и требований к баннеру cookie. Но в целом около 50 % людей отказываются от маркетинговых и аналитических файлов cookie.
2. 2.
   Ограничение количества сторонних файлов cookie. Safari и Firefox уже ограничивают сторонние файлы cookie, Brave не поддерживает сторонние файлы cookie, а Chrome планирует начать постепенный отказ от сторонних файлов cookie в 2024 году. Рекламная сеть использует сторонние файлы cookie, чтобы различать, на какую рекламу пользователи нажимали до того, как попали на сайт, и после этого конвертировать. Кроме того, аналитические платформы используют сторонние файлы cookie для отслеживания пользователей, которые уже посетили сайт, и отображения полного пути пользователей. Без файлов cookie правильная атрибуция конверсий и дифференциация между новыми и вернувшимися пользователями становится очень сложной.
3. 3.
   Полное ограничение отслеживания. Apple лидирует в области конфиденциальности в плане ограничений на отслеживание. Все приложения для iOS обязаны запрашивать у пользователя разрешение на отслеживание его действий. Кроме того, пользователи iOS могут в любой момент отозвать разрешение приложений на отслеживание их активности. Еще одна растущая тенденция - использование блокировщиков рекламы (AdBlockers). Когда блокировщики рекламы включены, маркетинговые и аналитические инструменты не получают никакой информации о пользователях.

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

Чтобы получить право на машинное обучение, недвижимость GA4 должна соответствовать определенным требованиям:

• Режим согласия включен на всех страницах
• Теги должны срабатывать до появления диалогового окна согласия
• Теги Google загружаются во всех случаях, а не только при согласии пользователя
• 1 000 событий в день с analytics_storage='denied' в течение как минимум 7 дней.
• 1 000 ежедневных пользователей, отправляющих события с analytics_storage='granted' в течение как минимум 7 из предыдущих 28 дней

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

Чтобы GA4 работал корректно и распознавал возвращающихся пользователей, вы должны предоставить GA4 следующую информацию:

• Client ID (cid)
• Session ID (sid)
• Session Count (sct)
• First Visit (_fv)
• User Engagement (seg)

Чтобы настроить отслеживание без cookie GA4, когда пользователь не дал согласия, мы будем использовать эти инструменты:

1. 1.
   Server Google Tag Manager.
2. 2.
   Server GA4.
3. 3.
   Разделите согласие пользователя с помощью параметра GA4 gsc.
4. 4.
   Подключите Google Service Account к stape.
5. 5.
   Запишите данные в firestore.
6. 6.
   Считайте данные из Firestore.
7. 7.
   Stape user ID power-up.

Чтобы определить, было ли согласие получено или нет, я использую параметр gcs. Конфигурация согласия GA4 по умолчанию отправляет запросы в sGTM, но в запросе отсутствует некоторая информация. Все запросы GA4 записываются в хранилище Firestore.

Чтобы определить, есть ли у пользователя без согласия активная сессия в GA4, мы используем разницу во временной метке предыдущего и текущего визита. Если разница составляет более 30 минут, мы обновим параметры сессии в Firestore.

Firestore будет использовать UserID в качестве имени документа и сохранять подробности о пользовательской сессии в этих документах. Хотя это простой способ организации Firestore, существует множество других подходов к сохранению данных о полном опыте пользователя в Firebase.

1.1 Используйте стандартную настройку серверного GA4.

1.2 При необходимости запишите данные в Firestore. Для этого я использую тег Firestore Writer. Ознакомьтесь с подробным руководством по использованию тега Firestore Writer. Я использую коллекцию UserID. Для каждого идентификатора пользователя я создаю новый документ, в котором в качестве имени документа используется cid.

1.3 Серверные теги GA4 имеют стандартную конфигурацию и срабатывают каждый раз, когда клиент GA4 заявлен, а пользователь дает согласие на аналитические куки.

2.1.1 Если согласие на аналитические куки не было получено, я использовал Stape User ID power-up для добавления идентификатора пользователя в заголовки запросов sGTM.

2.1.2 С помощью тега Firestore Writer я записываю данные в Firestore и использую Stape User ID в качестве имени документа.

2.1.3 Чтобы проверить, активна ли сессия, я использую переменную Firestore Reader для извлечения временной метки, связанной с последним посещением этого пользователя в Firebase. Затем проверяю разницу между временной меткой предыдущей сессии пользователя и текущей временной меткой. Если временная метка меньше 30 минут, у пользователя есть существующая сессия.

2.1.4 Параметры обновляются следующим образом:

• cid и client_id - это значение идентификатора пользователя Stape.
• ga_session_number - значение номера ga_session_number в хранилище Firestore
• ga_session_id - значение ga_session_id в хранилище Firestore
• x-ga-mp2-seg (задействованная сессия) установлено на 1
• x-ga-system_properties.fv (первое посещение), x-ga-system_properties.ss (начало сессии), x-ga-system_properties.nsi (идентификатор новой сессии) удалены.

2.1.5 Отправка измененных данных в GA4. Чтобы обновить данные перед отправкой в GA4, я использую трансформацию.

2.2.1 Если согласие на аналитические куки не было получено, я использовал Stape User ID power-up для добавления идентификатора пользователя в заголовки запросов sGTM.

2.2.2 Снова запишите данные пользователя на основе Stape User ID в Firestore с помощью тега Firestore writer.

2.2.3 Чтобы проверить, активна ли сессия, я использую переменную Firestore Reader для извлечения временной метки, связанной с этим пользователем в Firebase. Затем проверяю разницу между временной меткой последней сессии пользователя и текущей временной меткой. Если временная метка превышает 30 минут, значит, началась новая сессия.

2.2.4 Параметры обновляются следующим образом:

• cid и client_id - это значение идентификатора пользователя Stape.
• ga_session_id - значение ga_session_id из Firestore, ранее установленное как timestamp в секундах.
• ga_session_number - это номер ga_session_number, который вы имеете в Firestore, плюс 1.
• x-ga-system_properties.ss (начало сеанса) установлено на 1.
• X-ga-mp2-seg (Задействованный сеанс) установлен на 1.
• x-ga-system_properties.fv удален.

2.2.5 Отправка измененных данных в GA4. Чтобы обновить данные перед отправкой в GA4, я использую трансформацию. Тег срабатывает, когда клиент GA4 заявлен, согласие не получено, а разница во времени между сессиями составляет более 30 минут.

2.3.1. Если аналитические файлы cookie запрещены, используйте функцию Stape User ID для генерации идентификатора пользователя.

2.3.2. Проверьте, существует ли уже пользователь с таким же UserID в Firestore. Если пользователь с таким же идентификатором не найден, используйте тег Firestore Writer для создания пользователя с данными сеанса в базе данных.

2.3.3 Параметры обновляются следующим образом:

• cid и client_id - это значение идентификатора пользователя Stape.
• ga_session_id - это ga_session_id из Firebase.
• ga_session_number - это номер ga_session_number, который у вас есть в Firestore.
• x-ga-system_properties.ss (начало сеанса) установлено на 1.
• x-ga-mp2-seg (задействованная сессия) установлено значение 1.
• x-ga-system_properties.fv (первый визит) имеет значение 1.

2.3.4 Отправьте измененные данные в GA4.

Внедрение отслеживания Google Analytics 4 без использования cookie-файлов через сервер Google Tag Manager представляет собой значительный шаг вперед в адаптации к меняющемуся ландшафту конфиденциальности данных в сети и предпочтений пользователей. По мере развития цифрового мира сбор ценной информации без использования файлов cookie становится все более необходимым.

Используя возможности серверного тега и Google Tag Manager, компании могут сохранять приверженность принципам конфиденциальности данных и при этом использовать важнейшие данные, предоставляемые GA4. Такой подход не только обеспечивает соответствие новым нормативным требованиям, но и способствует укреплению доверия пользователей, обеспокоенных сохранением конфиденциальности онлайн. По мере того как мы движемся в будущее без cookie, использование таких инновационных решений, как отслеживание на стороне сервера и GA4, поможет компаниям оставаться конкурентоспособными и актуальными в цифровом мире.