Загальний регламент про захист даних (GDPR) зробив необхідним захист конфіденційності користувачів. Відповідно до GDPR, перед передачею даних користувача до будь-якого інструменту, що належить США, необхідно видалити будь-яку інформацію, що дозволяє ідентифікувати особу. Цей крок став необхідним у зв'язку з втратою чинності Privacy Shield.
У цій статті я розповім, як автоматично видаляти дані користувачів за допомогою stape Anonimyzer і вручну редагувати дані користувачів через веб і сервер GTM. Це продовження статті, опублікованої в нашому блозі, в якій розповідається про те, чому потрібно використовувати проксі-сервер для використання Google Analytics в GDPR-сумісному режимі.
У країнах ЄС (Італія, Франція, Австрія, Данія) було кілька випадків, коли люди зверталися до місцевих органів захисту даних, щоб перевірити, чи підпадає використання Google Analytics на сайті під дію GDPR. Відповідь у всіх випадках була одна - використання Google Analytics не відповідає вимогам GDPR.
Основна причина полягає в тому, що американські компанії (в тому числі Google) не забезпечують достатніх заходів безпеки для захисту персональних даних користувачів ЄС. Саме тому обмін PII з американськими компаніями суперечить GDPR. Більше інформації про це ви можете знайти в нашій попередній статті в блозі.
Хороша новина полягає в тому, що є рішення, як використовувати Google Analytics і при цьому відповідати вимогам GDPR. CNIL (французький орган із захисту даних) заявив, що для використання GA у GDPR-сумісний спосіб, слід впровадити дві основні речі: ЄС проксі-сервер та псевдонімізацію даних користувачів перед експортом.
Проксі-сервер забезпечує відсутність прямого контакту між сайтом та американським інструментом аналітики. Найпростішим способом реалізації такого проксі-сервера є використання сервера-контейнера Google Tag Manager. Проксі-сервери повинні відповідати ряду критеріїв. Основна область: компанія, яка надає вам проксі-сервер, повинна бути зареєстрована в ЄС; сервери, які використовуються для розміщення вашого контейнера sGTM, повинні бути фізично розташовані в ЄС. З цих двох причин ви не можете використовувати Google Cloud (GCP) для sGTM. По суті, це та ж причина, що і у випадку з Google Analytics - Google, американська компанія, є її власником.
Ще одна гарна новина полягає в тому, що компанія Stape вже вирішила цю проблему. У нас є спеціальний продукт - Stape Europe, який відповідає всім вимогам до проксі-сервера ЄС. Stape Europe зареєстрований в ЄС (Естонія) і використовує хмарний сервер ЄС, наданий компанією Scaleway, для роботи вашого контейнера sGTM.
У цій статті я хочу більше зупинитися на другій частині закону, а саме на псевдонімізації даних користувачів. Ми в Stape впроваджуємо перелік функцій, які допоможуть вам автоматично видаляти дані користувачів. Саме тому я розділю статтю на дві частини:
Перелік даних користувачів, які підлягають псевдонімізації, є досить розпливчастим.
Наразі ми розробляємо додаток Stape Anonymizer тільки для GA4. Однак у наступних оновленнях він буде адаптований і стане доступним з функцією анонімізації UA.
Важливо розуміти, що список параметрів, які надсилає GA4, може змінюватися. Ми будемо оновлювати цю статтю, але переконайтеся, що ви протестували анонімізацію даних користувачів, перш ніж публікувати її у виробництво.
Найкращий інструмент, який я знайшов, який допомагає відстежувати та визначати параметри GA4, - це ось цей.
Процес псевдонімізації даних користувача відбувається всередині тегів GA4 у веб та серверному GTM контейнері. Якщо ви ще не налаштували сервер GA4, виконайте наступні дії.
У нас немає суворих вказівок щодо того, які дані повинні бути видалені. Ви самі вирішуєте, як ви хочете, щоб ваша компанія була захищена. Наприклад, ви можете видалити IP-адресу користувача або відредагувати останні кілька цифр. Інше велике питання стосується таких параметрів, як країна, мова, браузер тощо. Кожен параметр окремо не дає достатньо інформації для ідентифікації користувача, але набір параметрів може її надати.
Немає питань щодо того, чи слід видаляти такі параметри, як ідентифікатор клієнта або URL запитів. Використання кожного параметра окремо може призвести до ідентифікації користувача через унікальний ідентифікатор в Google.
Скажімо, вам може бути важливо проаналізувати мобільний та десктопний трафік або конверсії в різних браузерах. Чи варто видаляти всі дані, які можуть бути використані для зняття відбитків пальців та ідентифікації користувача, чи лише деякі? Чи можна залишити браузер і пристрій, якщо видалити всі інші параметри?
Переконайтеся, що ви обговорили ці питання зі своїми юристами або DPO, щоб мати хороший захист, якщо регулятор прийде до вас. Я вважаю, що видалення всіх ідентифікаторів користувачів, які можуть бути використані для зняття відбитків пальців та повторної ідентифікації, є кращим способом убезпечити вашу компанію.
Ця стаття не претендує на роль інструкції. Ми просто ділимося досвідом щодо видалення або псевдоанонімізації даних і того, як stape робить це автоматично. Ви можете не використовувати наш інструмент анонімізації або вручну анонімізувати кожен параметр.
Нещодавно ми випустили "Анонімайзер". Він доступний для всіх користувачів Stape. Основна мета анонімайзера полягає у видаленні або анонімізації даних користувача в Google Analytics 4 та Universal Analytics.
Щоб увімкнути анонімайзер, відкрийте контейнер sGTM в stape, натисніть кнопку power-up та відкрийте анонімайзер.
Цей продукт включає дані GeoLite2, створені MaxMind, доступні за адресою https://www.maxmind.com
Вам потрібно буде вибрати, які параметри ви хочете залишити як є, видалити або анонімізувати. Після налаштування параметрів слід оновити URL-адресу сервера тегів для Google Analytics 4 та Universal Analytics. Якщо ви раніше використовували URL-адресу сервера тегів https://sgtm.example.com при включеному анонімайзері, оновлена URL-адреса сервера тегів буде виглядати як https://sgtm.example.com/anonymize. Ми проксіруємо ваші запити до sGTM через шлях /anonymize і видаляємо вказані дані.
Коли запити GA проходять через URL-адресу сервера тегування, що містить /anonymize, ми автоматично видаляємо або анонімізуємо вибрані параметри.
Після ввімкнення та налаштування Анонімайзера переконайтеся, що ви змінили транспортну URL-адресу GA4/UA у тезі конфігурації Web GTM на ту, яка закінчується на /anonymize.
Нижче наведено список всіх параметрів, які Анонімайзер може видалити та анонімізувати. При створенні Анонімайзера нашою метою було надати нашим клієнтам можливість видалити всі параметри, які так чи інакше можуть бути розцінені як персональні дані користувача. Ви можете вибрати, які параметри ви хочете видалити. Поговоріть зі своїм DPO або юристами, щоб визначити, які параметри необхідно видалити.
Для більшості параметрів у вас буде два варіанти: залишити як є або видалити. Для двох параметрів (IP та ідентифікатор клієнта) ви побачите опції Анонімізувати та Строго анонімізувати.
IP
Anonymize - видаляє останній октет.
Anonymize Strictly - видаляє останні два октети
Client ID. Працює тільки за умови використання JavaScript Managed client identification.
Anonymize - використовуйте хеш IP+UserAgent і додайте рік+місяць.
Anonymize Strictly - використовуйте хеш IP+UserAgent та додайте мітку часу, crc32_hash(IP+UA).timestamp
| Назва параметра | Опис | GA4 Параметр | Anonymize |
| IP | User IP | IP Address | Anonymize - видаляє останній октет. Anonymize Strictly - видаляє останні два октети |
| Client ID | Google Analytics Client ID, _ga, _ga_*, FPLC, FPID cookies | cid, _ga, _ga_*, FPLC, FPID | Anonymize - використовуйте хеш IP+UserAgent і додайте рік+місяць. Anonymize Strictly - використовуйте хеш IP+UserAgent та додайте мітку часу, crc32_hash(IP+UA).timestamp |
| User ID | User ID, Google Developer ID, Firebase ID | uid, gdid, _fid | - |
| Session ID | Session ID, New Session ID | sid, _nsi | - |
| Query parameters | Remove query paramaters from Document Location | dl | - |
| Referer | Document Referrer Header, Document Referrer Parameter | referer header, dr | - |
| User Agent | Document User-Agent header, Sec-Ch-Ua header, Sec-Sh-Ua-Platform header, Sec-Ch-Ua-Mobile header, User-Agent Parameter | user-agent header, sec-ch-ua header, sec-ch-ua-platform header, sec-ch-ua-mobile header, ua | - |
| User Country | Geographical ID, Current country for the user | geoid, _uc | - |
| Browser plugins | Java Enabled, Flash Version | je, fl | - |
| Screen Info | Browser screen resolution, Viewport size | sr, vp | - |
| Screen Colors | Specifies the screen color depth | sd | - |
| User Language | Browser active locale | ul | - |
| User Agent Architecture | uaa | - | |
| User Agent Bitness | uab | - | |
| User Agent Full Version List | uafvl | - | |
| User Agent Mobile | uamb | - | |
| User Agent Model | uam | - | |
| User Agent Platform | uap | - | |
| User Agent Platform Version | uapv | - | |
| User Agent WOW64 | uaw | - |
| Campaign Medium | cm | - | |
| Campaign Source | cs | - | |
| Campaign Name | cn | - | |
| Campaign Content | cc | - | |
| Campaign ID | ci | - | |
| Campaign Term | ck | - | |
| Campaign Creative Format | ccf | - | |
| Campaign Marketing Tactic | cmt | - | |
| Google Ads ID | gclid | - | |
| Google Display Ads ID | dclid | - |
Параметри, які збирає Google Analytics 4, час від часу змінюються. Тому потрібно перевіряти свої запити GA4, щоб переконатися, що всі дані користувачів видалені.
Після того, як ви налаштували параметри в Anonimiser і змінили транспортну URL-адресу GA4 на ту, яка містить /anonymize в кінці, ми видалимо або анонімізуємо вказані параметри.
Після увімкнення Анонімайзера та оновлення транспортної URL-адреси GA4, будь ласка, використовуйте web/sGTM відладчики, консоль та відладчик GA4, щоб перевірити, чи всі необхідні параметри були видалені.
Цей метод відносно простий у реалізації, але має певні суперечності. Google має вбудовану функцію видалення останнього байта IP-адреси. Видаляючи попередній байт, ймовірність того, що Google зможе ідентифікувати користувачів, становить 1 до 256. У поєднанні з іншими параметрами IP-адреса дозволяє швидко ідентифікувати конкретну особу.
Дехто вважає, що достатньо обрізати останній октет. Інші вважають, що потрібно взагалі видаляти IP користувача. Моя думка полягає в тому, що краще повністю перевизначити IP користувача. Ніколи не знаєш, чи буде Google повторно використовувати IP.
"Слід зазначити, що онлайн-ідентифікатори, такі як IP-адреси або інформація, що зберігається в файлах cookie, зазвичай можуть використовуватися для ідентифікації користувача, особливо в поєднанні з іншими подібними типами інформації. Це ілюструється ст. 30 GDPR, згідно з якою присвоєння онлайн-ідентифікаторів, таких як IP-адреси та ідентифікатори файлів cookie, фізичним особам або їх пристроям може "залишати сліди, які, зокрема, у поєднанні з унікальними ідентифікаторами та іншою інформацією, отриманою серверами, можуть бути використані для створення профілів фізичних осіб та їх ідентифікації".
Щоб видалити IP користувача, я використав тег server GA4 і встановив ip_override на випадковий IP.
Google присвоює парі пристроїв браузера унікальний ідентифікатор клієнта і використовує його для ідентифікації, коли той самий користувач повторно відвідує ваш сайт. Цей параметр необхідно видалити або псевдоанонімізувати перед відправкою в GA4.
" Для забезпечення ефективної псевдонімізації алгоритм, що здійснює заміну, повинен забезпечувати достатній рівень колізійності (тобто достатню ймовірність того, що два різних ідентифікатора після хешування дадуть ідентичний результат) і включати компонент, що змінюється в часі (додавання до хешованих даних значення, яке змінюється в часі, так що результат хешування не завжди буде однаковим для одного і того ж ідентифікатора)".
Існує безліч підходів до анонімізації ідентифікаторів клієнтів, все залежить від вашої уяви та набору інструментів, які ви використовуєте. Але переконайтеся, що ідентифікатор клієнта є унікальним і що ви додали компонент, який змінюється в часі.
Можна використовувати хеш агента користувача, IP, випадкову числову змінну GTM тощо. На відміну від IP користувача, ми не знайшли способу відредагувати ідентифікатор клієнта на стороні сервера, тому зробили це на стороні клієнта.
Після того, як ви анонімізували ідентифікатор клієнта Google Analytics, ви можете замінити файли cookie GA4 новими значеннями, щоб гарантувати, що GA4 не встановлює жодних ідентифікаторів користувачів. Для цього я використовував шаблон тегу Cookie Monster для серверного контейнера GTM. Все, що вам потрібно зробити, це додати імена і значення файлів cookie. як тільки це буде зроблено, не забудьте скористатися консоллю і перевірити файли cookie, які встановлює GA.
Після того, як ви відредагуєте ідентифікатор клієнта, це суттєво вплине на звітність GA4. Оскільки ідентифікатор клієнта буде унікальним, GA не зможе визначити, чи є він новим відвідувачем або відвідувачем, що повернувся. А також багатоканальну атрибуцію та події, такі як початок сесії, перший візит тощо.
Зовнішній реферер призначений для того, щоб визначити, як користувач потрапив на ваш сайт. Чи був це органічний, платний або, можливо, соціальний трафік.
Для видалення слід переписати page_referrer.
Основне призначення параметрів в URL-адресі - визначення походження рекламних кампаній. Параметрами URL можуть бути utm_souce, utm_medium, різні типи ідентифікаторів кліків тощо. Крім того, деякі платформи автоматично вставляють в URL-адресу дані користувача.
Для видалення параметрів URL-адреси необхідно переписати URL-адресу сторінки. Кілька змінних в галереї веб-шаблонів GTM можуть допомогти вам у цьому. Я використовував Trim Query. Вам просто потрібно вказати blocklist або allowlist параметрів запиту, який зробить всю магію за вас.
Такою інформацією може бути агент користувача, пристрій, браузер, роздільна здатність екрану, мова, операційна система тощо. Переконайтеся, що ви відредагували всю інформацію, яка може бути використана для зняття відбитків пальців.
Переконайтеся, що ви не використовуєте міжсайтових ідентифікаторів, таких як ідентифікатор користувача або ідентифікатор CRM.
Цю частину трохи важко зрозуміти, але я пропоную перевірити запит, який ваш контейнер sGTM надсилає до GA, і переконатися, що в ньому немає параметрів, які можуть бути використані для повторної ідентифікації користувача.
Є кілька способів перевірити, чи всі необхідні дані були видалені або псевдонімізовані. Спочатку потрібно зайти в налагоджувач GTM сервера і подивитися вихідні запити GA4. Переконайтеся, що ви тестуєте різні сценарії, коли є параметри користувача проти відсутності параметрів користувача, параметри URL, різні події, реферали тощо.
Другий спосіб - скористатися відладчиком Google Analytics 4 і подивитися, які дані обробляє GA4.
Не лише Google збирає дані користувачів з ЄС та передає їх до США, чим порушує GDPR. Багато компаній роками збирали персональні дані європейців, і тепер, схоже, їхня практика буде обмежена повсюдно у відповідь на деактивацію Privacy Shield та рішення про те, що передача даних користувачів з ЄС до США є незаконною відповідно до GDPR.
Якщо ви є власником веб-сайту в Європейському Союзі, настав час почати змінювати дані, якими ви ділитеся з американськими компаніями, інакше ви можете наразитися на ризик бути оштрафованим регуляторними органами.
1. Як використовувати проксі-сервер для GA при реалізації через gtag.js?
Якщо ви використовуєте gtag.js на своєму сайті для відправки подій в серверний контейнер, ви можете додати параметр transport_url до існуючого тегу:
gtag('config', 'TARGET-ID', {
'transport_url': 'https://analytics.example.com',
'first_party_collection': true,
});
Ви можете використовувати URL-адресу анонімайзера для анонімізації даних користувача в GA, якщо це реалізовано через gtag.js. Припустимо, ви використовуєте stape-анонімайзер і ваша URL-адреса анонімайзера - https://sgtm.site.com/anonymize. Вам просто потрібно додати https://sgtm.site.com/anonymize в якості транспортного URL-адреси в gtag config.
