Чи збирає Google Analytics персональні дані за GDPR?
Почніть із конкретної конфігурації: яку властивість Google Analytics використовують і як її налаштовано?
Коротка відповідь: іноді. Чи збирає Google Analytics персональні дані за GDPR, залежить від того, які дані надсилає конкретний сайт, як їх обробляє Google і чи можна пов’язати цю інформацію з особою, яку можна ідентифікувати. Самої назви продукту недостатньо, щоб дати відповідь на це запитання.
Спершу з’ясуйте, яку властивість використовують. На сайті може бути налаштовано Google Analytics 4 (GA4), старішу властивість Universal Analytics або обидві — на час переходу. Методи збору даних і доступні засоби керування в них відрізняються, а функціональність продуктів Google із часом змінюється. Перевірте поточні налаштування властивості й тегів, а не покладайтеся на стару інструкцію зі встановлення.
Далі з’ясуйте, як влаштована решта системи. Тег GA4 може працювати через Google Tag Manager, платформу керування згодою, рекламний тег або плагін, який автоматично додає поля. Інструмент для роботи з формами чи база даних клієнтів також можуть передавати ідентифікатори в аналітику. Тому одна й та сама властивість може створювати різні питання щодо приватності на двох різних сайтах.
Визначте конкретні межі перевірки: одну властивість, набір тегів і дані, які вони фактично надсилають. Якщо в обліковому записі є окремі властивості для публічного блогу та сервісу з авторизацією, перевірте кожну окремо. Їхні цілі та потоки даних можуть відрізнятися.
Простежте шлях одного відвідування через систему аналітики
Уявіть, що відвідувач переходить із результатів пошуку на сторінку товару. На сторінці завантажується тег Google Analytics, який може надіслати таку подію, як перегляд сторінки, разом із даними, налаштованими на сайті. Залежно від реалізації, серед них можуть бути адреса сторінки, відомості про браузер, назва події або ідентифікатор. Щоб з’ясувати, які саме відомості передає сервіс, поставте практичне запитання: «Які дані передає Google Analytics» у цій конфігурації?
Потім Google отримує запит і обробляє його відповідно до налаштувань продукту та застосовних умов. Сайт також може передавати інформацію через пов’язані сервіси, як-от рекламні функції чи імпортовану аудиторію. Відвідування не обов’язково обмежується одним ізольованим записом: налаштування можуть впливати на те, як події пов’язуються між собою, відображаються у звітах або передаються іншим інструментам.
Уважно перевірте адресу сторінки. URL може містити адресу електронної пошти, пошуковий запит, номер облікового запису чи інші відомості, якщо сайт додає їх до параметра запиту. Наприклад, посилання для скидання пароля може містити токен. Якщо тег записує повну URL-адресу, сайт може надсилати більше, ніж просто назву сторінки.
Іноді достатньо одного запиту.
Це не означає, що кожне відвідування дає змогу встановити ім’я конкретної особи. Однак власник сайту має перевірити сам запит і пов’язані з ним системи, а не вважати, що аналітика отримує лише анонімні підрахунки. З’ясувати, що саме надсилається, допоможуть інструменти розробника в браузері, попередній перегляд тегів і тестове відвідування. Зафіксуйте результати для властивості, яку перевіряєте.
Відокремте збір даних від питання, чи є вони персональними
Збір даних і питання про те, чи є ці дані персональними, пов’язані, але це не одне й те саме. Подія перегляду сторінки — це дані. Чи вважаються вони персональними даними відповідно до GDPR, залежить від їхнього вмісту й контексту, зокрема від того, чи можна прямо або опосередковано ідентифікувати особу за допомогою інформації, доступної сайту чи іншій стороні.
Ідентифікатор, який здається випадковим, усе одно може мати значення. Якщо він дає змогу розрізняти браузер упродовж певного часу або пов’язати його із записом клієнта, то може допомогти виокремити особу, навіть якщо в аналітичному звіті не вказано її імені. Якщо сайт може пов’язати ідентифікатор події з обліковим записом авторизованого користувача, потрібно оцінити цей зв’язок, а не лише назву поля.
Контекст змінює відповідь.
Розгляньмо два записи з однаковою назвою події — «view_item». Перший — загальний підрахунок переглядів публічної сторінки товару. Другий містить постійний ідентифікатор користувача, який компанія може зіставити з обліковим записом і історією покупок. Назва події не змінилася, але можливість пов’язати запис з особою — так.
Тому на запитання «Чи збирає Google Analytics персональні дані за GDPR» не можна відповісти загальним «так» або «ні» для всіх сайтів. Під час практичної оцінки враховують ідентифікатори, додаткові дані, доступ до них і можливість пов’язати їх з особою в межах конкретної обробки. Псевдонімізована інформація не стає автоматично анонімною лише тому, що в ній немає імен.
Перевірте поля та функції, що впливають на оцінку
Перевірте поля та функції, які можуть впливати на можливість ідентифікувати особу або обсяг зібраної інформації. Не вважайте функцію ввімкненою чи вимкненою лише тому, що вона згадувалася в попередній інструкції з налаштування. Перевірте поточні налаштування властивості й документацію Google.
Обробка IP-адрес: З’ясуйте, які дані отримує й обробляє поточна версія продукту та які засоби керування доступні. Не робіть висновків про анонімізацію IP-адрес на основі налаштування зі старішої версії Analytics.
Ідентифікатори користувачів: Якщо сайт надсилає ідентифікатор облікового запису, перевірте, чи є він постійним, чи можна зіставити його з клієнтом і чи має сайт право надсилати його для заданої мети.
Google Signals і рекламні функції: Перевірте, чи ввімкнено їх, яку інформацію вони використовують і чи впливають вони на звітування або передачу даних для цієї властивості.
Параметри URL: Перевірте реальні сторінки на наявність персональних відомостей у рядках запиту, фрагментах URL і посиланнях для перенаправлення. Токен або адреса електронної пошти можуть потрапити в адресу сторінки, навіть якщо ніхто не збирався використовувати їх як поле аналітики.
Спеціальні параметри й події: Перегляньте назви та значення, які надсилає сайт. Спеціальне поле «тип тарифу» в одній конфігурації може бути цілком безпечним, тоді як поле з адресою електронної пошти, відповіддю у вільній формі чи відомостями про здоров’я створює іншу проблему.
Також перевірте, що відбувається з даними після того, як вони потрапляють у властивість. Пов’язані облікові записи, експорти й інтеграції можуть розширити коло тих, хто має доступ до інформації, або змінити спосіб її використання. Налаштування, яке обмежує збір даних, не відповідає на всі запитання щодо їх подальшого використання.
Що визначають, а чого не визначають роль і умови Google
У договірних документах Google можуть описуватися ролі Google і клієнта в межах певних процесів обробки, зокрема випадки, коли Google виступає обробником даних. Ознайомтеся з умовами, що застосовуються до сервісу й облікового запису, та перевірте їхню актуальну редакцію. Самого опису продукту недостатньо, щоб визначити повний статус сайту відповідно до GDPR.
Власник сайту все одно має оцінити власні цілі, правову підставу, прозорість, налаштування, а також застосовні вимоги щодо розкриття інформації чи передачі даних. Постачальник може пропонувати налаштування й договірні умови, але це не означає, що будь-яке використання аналітики автоматично є законним. Так само наявність банера згоди не доводить, що теги працюють так, як обіцяє цей банер.
Ролі також можуть залежати від конкретного процесу обробки. Сайт може визначати, навіщо йому потрібно вимірювати відвідуваність і які події надсилати, тоді як постачальник обробляє інформацію відповідно до конкретних умов сервісу. Важливі деталі — не визначайте ролі за загальним шаблоном, не перевіривши фактичні умови надання послуги.
Невеликому видавцю варто задокументувати властивість, теги, пов’язані сервіси, цілі та застосовні умови. Якщо сайт працює з чутливою інформацією або використовує складні рекламні інтеграції, зверніться по кваліфіковану консультацію з питань приватності, а не вважайте перегляд сторінки налаштувань юридичною перевіркою.
Цільова перевірка для власника сайту
Коротка задокументована перевірка корисніша за розпливчасту обіцянку «використовувати налаштування з урахуванням приватності». Щоб зрозуміти, як перевірити налаштування GA4 для відповідності GDPR, виконайте ці кроки для кожної властивості Analytics:
Складіть перелік властивостей і тегів. Зафіксуйте, чи використовує сайт GA4, старішу властивість, Google Tag Manager, плагіни або безпосередньо вбудований код. Укажіть сторінки, на яких завантажується кожен тег.
Перевірте відвідування. Відкрийте чистий сеанс браузера, відвідайте важливі сторінки й перевірте вихідні запити за допомогою інструментів розробника браузера або засобу налагодження тегів. Зафіксуйте назви подій, адреси сторінок та ідентифікатори, а потім видаліть або замаскуйте виявлені конфіденційні значення.
Перевірте роботу згоди. Спробуйте обидва варіанти вибору в інтерфейсі згоди на сайті. Переконайтеся, що теги аналітики очікують, блокуються або працюють інакше, і порівняйте результат із заявленою політикою сайту.
Перегляньте події та інтеграції. Перевірте спеціальні події, ідентифікатори користувачів, пов’язані рекламні сервіси, імпорт і експорт даних. Запитайте відповідальну за кожну інтеграцію команду, які дані вона надсилає і з якою метою.
Перевірте строки зберігання та доступ. Перегляньте налаштування зберігання даних у властивості, користувачів облікового запису й місця експорту. Скасуйте доступ, який більше не потрібен для роботи, і задокументуйте поточні налаштування.
Виправте ненавмисну передачу даних. За можливості видаляйте персональні відомості з URL або значень подій ще на джерелі. Якщо певне поле не слід надсилати, зупиніть його до того, як воно потрапить у тег, а не покладайтеся лише на фільтр звіту.
Повторіть перевірку після оновлення дизайну або встановлення нового плагіна. Новий процес оформлення замовлення, авторизації чи заповнення форми може змінити дані, що надсилаються, навіть якщо ніхто не змінює саму властивість Analytics.
Дайте відвідувачам чітку й точну відповідь
У повідомленні про приватність варто описувати фактичну практику сайту, а не робити загальну заяву, що «Google Analytics анонімна». Назвіть мету — наприклад, з’ясувати, якими сторінками користуються відвідувачі, — і поясніть, які категорії даних збираються, чи передаються вони іншим сторонам і які варіанти вибору доступні відвідувачам. Текст має відповідати роботі тегів, зафіксованій під час перевірки.
Поясніть правову підставу, на яку сайт спирається для кожної відповідної мети, і як відвідувач може скористатися своїми правами. За певних обставин для деяких видів відстеження може знадобитися згода, але вона не є універсальною відповіддю на всі запитання щодо GDPR: сайт має оцінити процес обробки та застосовні правила.
Чітко опишіть обмеження. Якщо сайт використовує ідентифікатор, який можна пов’язати з обліковим записом авторизованого користувача, скажіть про це точно; якщо такий ідентифікатор не надсилається, не створюйте враження, що це відбувається. Відповідь має відповідати властивості, тегам і потоку даних, перевіреним на сайті, а не загальному опису Google Analytics.
