Відстеження GA4 без файлів cookie за допомогою серверного GTM

У цифровому світі, що постійно розвивається, підхід до відстеження користувачів та захисту їхніх даних зазнає значних змін. Оскільки веб-браузери поступово відмовляються від сторонніх файлів cookie, а суворі закони про конфіденційність даних набувають чинності, традиційні методи відстеження користувачів швидко втрачають свою актуальність.

Адаптація до цих змін не просто необхідна для бізнесу та маркетологів, які покладаються на інсайти, засновані на даних; це абсолютно обов'язкова умова.

Одним із способів адаптації до новітніх викликів у сфері відстеження є перехід на відстеження без файлів cookie. Незважаючи на те, що остання версія Google Analytics має багато недоліків, вона залишається найпопулярнішою аналітичною платформою. Саме тому в цій статті ми розповімо, як налаштувати відстеження без файлів cookie в Google Analytics 4 за допомогою серверного Google Tag Manager. Ми будемо використовувати sGTM, режим згоди, Firestore та stape User-ID power-up.

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

Що таке відстеження без файлів cookie?

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

Але зараз багато веб-сайтів відмовляються від використання цих файлів cookie для відстеження дій користувачів. Замість цього вони використовують нові методи, які не покладаються на зберігання цих даних у браузерах користувачів. Цей новий спосіб відстеження без файлів cookie називається "відстеження без файлів cookie".

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

Це не тільки допомагає позбутися файлів cookie та зробити відстеження більш точним, але й робить його більш нормативно обґрунтованим та забезпечує більший контроль над даними користувача.

Переваги відстеження без cookie

Відстеження без файлів cookie допомагає адаптуватися до останніх змін у сфері конфіденційності та обмежень щодо відстеження. Ось кілька прикладів:

1. Правила. Регулятори захисту даних в Європі та деяких інших країнах обмежують використання файлів cookie без згоди користувача. Відсоток користувачів, які відхиляють файли cookie, залежить від країни, віку та вимог до банерів з файлами cookie. Але в цілому, близько 50% людей відкидають маркетингові та аналітичні файли cookie.
2. Знецінення сторонніх файлів cookie. Safari і Firefox вже обмежують сторонні файли cookie, Brave не підтримує сторонні файли cookie, а Chrome планує почати поступову відмову від сторонніх файлів cookie в 2024 році. Рекламна мережа використовує сторонні файли cookie, щоб розрізняти, яку рекламу користувачі натиснули до того, як потрапили на сайт, і після цього конвертувати її. Крім того, аналітичні платформи використовують сторонні файли cookie, щоб відстежувати користувачів, які вже відвідували сайт, і показувати повний шлях користувачів. Без файлів cookie належна атрибуція конверсії та диференціація між новими користувачами та тими, що повертаються, стає дуже складною.
3. Повне обмеження відстеження. Apple є лідером у сфері конфіденційності з точки зору обмежень на відстеження. Всі додатки для iOS зобов'язані запитувати дозволи користувачів на відстеження їхніх дій. Крім того, користувачі iOS можуть будь-коли відкликати дозвіл на відстеження їхньої активності. Ще однією тенденцією, яка зростає, є використання блокувальників реклами. Коли блокувальники реклами увімкнені, маркетингові та аналітичні інструменти не отримують жодної інформації про користувачів.

Контекст

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)

Щоб налаштувати відстеження GA4 без файлів cookie, коли користувач не надав згоди, ми скористаємося цими інструментами:

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

Налаштування відстеження GA4 без cookie в sGTM

Щоб визначити, чи було надано згоду чи ні, я використовую параметр gcs. За замовчуванням конфігурація згоди GA4 надсилає запити до sGTM, але в запиті відсутня деяка інформація. Всі запити GA4 записуються до Firestore.

Щоб визначити, чи має користувач без згоди активну сесію в GA4, ми використаємо різницю в позначці часу попереднього та поточного візитів. Якщо різниця перевищує 30 хвилин, ми оновимо параметри сесії у Firestore.

Firestore буде використовувати UserID як назву документа і зберігати деталі про сеанс користувача в цих документах. Хоча це простий спосіб організації Firestore, існує безліч інших підходів до збереження даних про всю роботу користувача у Firebase.

1. Користувач зі згодою на аналітичні файли cookie.

1.1 Використовуйте стандартне налаштування на стороні сервера GA4.

1.2 Якщо потрібно, запишіть дані до Firestore. Для цього я використовую тег Firestore Writer. Будь ласка, ознайомтеся з цим детальним гайдом про те, як використовувати тег Firestore Writer. Я використовую колекцію UserID. Для кожного ідентифікатора користувача я створюю новий документ, який використовує cid як ім'я документа.

1.3 Тег на стороні сервера GA4 має стандартну конфігурацію і спрацьовує кожного разу, коли клієнт GA4 звертається до нього, а користувач дає згоду на використання аналітичних файлів cookie.

2. Користувач без згоди на аналітичні файли cookie

2.1 Існуючі користувачі з активною сесією

2.1.1 Якщо згода на аналітичні файли cookie не була надана, я використовував функцію Stape User ID, щоб додати ідентифікатор користувача в заголовки запитів sGTM.

2.1.2 За допомогою тегу Firestore Writer я записую дані до Firestore і використовую Stape User ID як назву документа.

2.1.3 Щоб перевірити, що сеанс активний, я використовую змінну Firestore Reader, щоб витягти мітку часу, яка пов'язана з останнім відвідуванням цього користувача у Firebase. Потім я перевіряю різницю між попередньою міткою часу сеансу користувача і поточною міткою часу. Якщо різниця менше 30 хвилин, користувач має поточний сеанс.

2.1.4 Оновлення параметрів відбувається так, як показано нижче:

• cid та client_id - це значення Stape UserID
• 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 Існуючий користувач без активних сесій

2.2.1 Якщо згода на аналітичні файли cookie не була надана, я використовував функцію Stape User ID, щоб додати ідентифікатор користувача в заголовки запитів sGTM.

2.2.2 Знову запишіть дані користувача на основі Stape User ID у Firestore за допомогою тегу Firestore writer.

2.2.3 Щоб перевірити, що сеанс активний, я використовую змінну Firestore Reader, щоб витягти мітку часу, пов'язану з цим користувачем у Firebase. Потім я перевіряю різницю між останньою міткою часу сеансу користувача і поточною міткою часу. Якщо різниця більше 30 хвилин, то розпочався новий сеанс.

2.2.4 Оновлення параметрів відбувається так, як показано нижче:

• cid і client_id - це значення Stape UserID.
• ga_session_id - це значення ga_session_id з Firestore, попередньо встановлене на мітку часу в секундах.
• ga_session_номер - це номер ga_session_номеру, який ви маєте у 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 Новий користувач

2.3.1. Якщо аналітичні файли cookie заборонені, використовуйте функцію ідентифікації користувача Stape для створення ідентифікатора користувача.

2.3.2. Перевірте, чи користувач з таким самим UserID вже існує у Firestore. Якщо користувача з таким ідентифікатором не знайдено, скористайтеся тегом Firestore Writer, щоб створити користувача з даними сеансу в базі даних.

2.3.3 Оновлення параметрів відбувається так, як показано нижче:

• cid і client_id - це значення Stape UserID.
• ga_session_id - це ga_session_id з Firebase.
• ga_session_номер - це номер ga_session_номеру, який ви маєте у Firestore.
• x-ga-system_properties.ss (початок сеансу) дорівнює 1.
• x-ga-mp2-seg (зайнятий сеанс) дорівнює 1.
• x-ga-system_properties.fv (перший візит) дорівнює 1.

2.3.4 Надішліть змінені дані до GA4.

Висновок:

Впровадження відстеження без файлів cookie в Google Analytics 4 через сервер Google Tag Manager є значним кроком вперед в адаптації до мінливого ландшафту конфіденційності даних в онлайні та вподобань користувачів. З розвитком цифрового світу збір цінної інформації без використання файлів cookie стає все більш важливим.

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