Більшість проєктів B2B-персоналізації впираються в ту саму стіну на другому тижні. Маркетинг уже має сегменти й варіанти заголовків, а потім хтось із юридичного відділу запитує, як ідентифікація відвідувачів працює з огляду на GDPR, — і ні в кого немає письмової відповіді. Проєкт чекає.
Цей матеріал — відповідь, яку ми хотіли б мати в письмовому вигляді. Він розглядає конфіденційність даних під час персоналізації B2B-сайтів у межах трьох наборів правил, що викликають найбільше питань (GDPR, правила ЄС ePrivacy щодо cookie та доступу до пристрою, а також каліфорнійські CCPA/CPRA), що насправді вимагає кожен із них, і містить чекліст перед запуском, який можна передати юристам. Це не юридична консультація. Мета — швидше вивести маркетинг і юристів на спільну розмову, з посиланнями на першоджерела, щоб ваш юрист міг їх перевірити.
Чому B2B-персоналізація має інший профіль конфіденційності
Більшість настанов щодо конфіденційності написано для споживчих сценаріїв: відстеження реклами на сайтах інтернет-магазинів, поведінкові профілі, які продають третім сторонам. Персоналізація B2B-сайтів зазвичай виглядає інакше:
- Основні вхідні дані — дані на рівні компанії (галузь, розмір, розташування, технології), які зазвичай визначають за IP-адресою відвідувача.
- Результат помірний: відвідувач із виробництва бачить кейси з виробництва замість фінтех-кейсів.
- Багато відвідувачів приходять із компаній, яким ви вже продаєте або на які націлюєтеся, тож є обґрунтована бізнес-причина показувати їм релевантний контент.
Усе це не звільняє B2B-персоналізацію від дії законів про конфіденційність. За кожною IP-адресою все одно стоїть людина, і закони захищають саме її, а не компанію. Змінюються рівень ризику і те, яка правова підстава реалістична. Правильна класифікація — це більша частина роботи.
GDPR: питання IP-адреси
Перше запитання юристів буде таким: чи є IP-адреса персональними даними? Чесна відповідь — «часто так, залежно від того, у кого вона». У справі Breyer (справа C-582/14) Суд ЄС постановив, що динамічна IP-адреса є персональними даними для оператора вебсайту, якщо цей оператор має законні засоби ідентифікувати відвідувача за допомогою додаткової інформації, що зберігається в інтернет-провайдера. Справу було вирішено згідно зі старою Директивою про захист даних, але визначення персональних даних у GDPR у статті 4(1) прямо називає «онлайн-ідентифікатор» серед того, що може зробити людину ідентифікованою, тож та сама логіка застосовується й тут.
Наша думка: плануйте так, ніби кожна IP-адреса, яку ви обробляєте, — персональні дані. Доводити протилежне майже нічого не дає, а ваша документація в очах регулятора виглядатиме ухильною.
Вибір правової підстави
Стаття 6 GDPR перелічує шість правових підстав. Для персоналізації сайту релевантні дві:
| Правова підстава | Де доречний | Що ви винні відвідувачу |
|---|---|---|
| Законні інтереси, ст. 6(1)(f) | Персоналізація на рівні компанії за IP-пошуком, коли на пристрої нічого не зберігається | Задокументований тест балансу інтересів (Legitimate Interest Assessment), зрозуміле повідомлення про конфіденційність і робочий спосіб заперечити відповідно до статті 21 |
| Згода, ст. 6(1)(a) | Усе, що потребує cookie чи подібного доступу до пристрою, і будь-який профіль, пов’язаний з конкретною особою | Згода, надана вільно, конкретно, поінформовано й однозначно, яку можна відкликати так само легко, як і надати (стаття 7(3)) |
Тут важливі дві деталі. По-перше, у пресрелізі щодо справи Breyer також зазначено позицію Суду: оператор вебсайту може мати законний інтерес в обробці даних відвідувачів, якщо його зважено з правами відвідувача. Саме цей баланс і має показати ваша LIA. По-друге, якщо персоналізація є частиною прямого маркетингу, статті 21(2) і (3) надають відвідувачу абсолютне право на заперечення: щойно він заперечив, ви припиняєте. Зробіть механізм відмови до запуску, а не після першої скарги.
Скільки може коштувати помилка з GDPR
Згідно зі статтею 83(5), порушення принципів обробки, правил щодо правових підстав зі статті 6, умов згоди зі статті 7 і прав суб'єктів даних зі статей 12–22 можуть тягнути штрафи до 20 млн € або 4% світового річного обороту, залежно від того, що більше. Це максимуми, а не типові штрафи. Реалістичніша ціна для B2B-команди середнього сегмента — запит регулятора, через який доведеться призупинити персоналізацію, поки ви готуєте документи, які мали б уже мати.
ePrivacy: де неправильно розуміють «без cookies»
Директива ePrivacy (2002/58/EC, Article 5(3)) — це правило, що стоїть за банерами cookie. Вона вимагає згоди перед збереженням інформації на пристрої користувача або отриманням доступу до неї, якщо таке збереження чи доступ не є суворо необхідними для послуги, яку запросив користувач. Вона діє паралельно з GDPR, і їй неважливо, чи є ця інформація персональними даними.
У Великій Британії відповідне правило міститься в PECR. Настанови ICO чітко кажуть, що згода має бути надана активно і чітко, і що cookies, які лише корисні чи зручні, теж її потребують. Cookies персоналізації належать до цієї групи.
Ось що оминають багато блогів постачальників. Чимало маркетингу персоналізації стверджує: «серверна, без cookie, тож згода не потрібна». Це надто спрощено. Guidelines 2/2023 on the technical scope of Article 5(3) від EDPB (остаточна версія — жовтень 2024 року) зазначають, що відстеження лише на основі IP-адрес може підпадати під Article 5(3), і якщо ви не можете гарантувати, що IP-адреса не походить із пристрою користувача, слід вважати, що вона підпадає. Ті самі настанови кажуть, що Article 5(3) застосовується, коли клієнтський код наказує браузеру надсилати вам ідентифікатори.
Що це означає на практиці:
- Разовий серверний пошук IP, що використовується для вибору заголовка на поточному перегляді сторінки, — найменш ризикований підхід. Деякі юристи все одно захочуть покрити його згодою або чітким аналізом винятку згідно з настановами EDPB, тож запитайте свого.
- Використання IP-адреси для відстеження відвідувача між сторінками чи сесіями — це трекінг, і, на думку EDPB, він потребує такого самого аналізу щодо згоди, як і cookies.
- Будь-який JavaScript-сніпет, що зчитує або встановлює ідентифікатори в браузері (cookie, локальне сховище, сигнали фінгерпринтингу), потребує згоди перед запуском, якщо він не є суворо необхідним.
Примітка щодо термінів: запланованого Регламенту ePrivacy, який мав замінити Директиву, більше немає. Європейська комісія оголосила у своїй робочій програмі на 2025 рік, що відкликає пропозицію, тож чинна Директива та національні закони про її імплементацію залишаються в силі. Не чекайте нових правил ЄС щодо cookie, щоб правильно налаштувати згоду.
CCPA/CPRA: чи стосується це вас узагалі?
Каліфорнійський закон застосовується лише до комерційних компаній, що ведуть бізнес у Каліфорнії й відповідають принаймні одному порогу. За даними California Privacy Protection Agency, це:
- Валовий річний дохід від 26,625 млн $ (сума з урахуванням коригування з 1 січня 2025 року).
- Купівля, продаж чи передача персональної інформації 100 000 або більше жителів чи домогосподарств Каліфорнії.
- Отримує 50% або більше річної виручки від продажу персональних даних жителів Каліфорнії або обміну ними.
Для B2B-команд важливо, що тимчасовий виняток для ділових контактних даних і даних працівників закінчився 1 січня 2023 року. Покупець, який переглядає ваш сайт із робочого ноутбука в Каліфорнії, за законом є споживачем.
Якщо це на вас поширюється, ось зобов'язання, що стосуються персоналізації:
- Розкрийте в політиці конфіденційності, що ви збираєте дані на основі IP для персоналізації, і які категорії даних використовуєте.
- Якщо партнери зі збагачення даних або реклами отримують дані відвідувачів у спосіб, що вважається «продажем» або «передачею» (передача охоплює кроссконтекстну поведінкову рекламу), розмістіть посилання «Не продавати й не передавати мою персональну інформацію» та виконуйте запити на відмову.
- Відповідайте на запити про доступ, видалення чи виправлення даних протягом 45 календарних днів, з можливістю продовження ще на 45 днів, якщо ви повідомите людину, згідно з CPPA FAQ.
Штрафи було проіндексовано на інфляцію 1 січня 2025 року: адміністративні штрафи до 2663 $ за кожне порушення та 7988 $ за кожне умисне порушення, згідно з оголошенням CPPA. Інші штати США мають власні комплексні закони про конфіденційність з іншими порогами, тож якщо у вас помітний трафік із цих штатів, аналізуйте їх окремо, а не припускайте, що аналіз для Каліфорнії вас покриває.
Робочий фреймворк: три рівні даних
Найпростіший спосіб зробити це керованим — класифікувати кожне джерело даних, яке використовує ваша персоналізація, ще до того, як щось будувати.
| Рівень | Дані | Типова правова позиція | Порядок запуску |
|---|---|---|---|
| 1. На рівні компанії, для кожного запиту | Галузь, розмір, місцезнаходження за серверним IP-пошуком, нічого не зберігається на пристрої | Законні інтереси за GDPR з LIA; аспект ePrivacy перевірте з юристом | Перший |
| 2. Поведінкова, на основі пристрою | Повторні відвідування, переглянуті сторінки, оцінки залученості, що зберігаються в cookie чи локальному сховищі | Згода за ePrivacy до встановлення будь-чого; правова підстава за GDPR | Після того, як налаштування згоди запрацює |
| 3. Індивідуальний профіль | Іменовані контакти, email-адреси, пов'язані з переглядами, етап угоди в CRM, стороннє збагачення даних про людину | Згода або ретельно задокументована правова підстава, DPA з кожним постачальником, повний обсяг прав суб’єктів даних | Останнім і лише там, де це окупається |
Наша думка: запускайтеся з рівня 1. Щоб показати логістичній компанії ваш логістичний кейс, не потрібно нічого знати про людину, яка його читає. Більшість очевидних перемог персоналізації (галузевий заголовок, релевантні докази, акцент на цінах за розміром компанії) — на рівні 1. Рівні 2 і 3 додають цінності, але й додають залежності від згоди та паперову роботу, тож додавайте їх, коли рівень 1 виміряно й він стабільний.
Крок за кроком: запуск із дотриманням вимог
1. Розділіть досвід залежно від згоди
Типова помилка — блокувати будь-яку персоналізацію, доки відвідувач не натисне «Прийняти». Краща схема:
- До згоди: лише персоналізація рівня 1 на основі серверного запиту, без збереження ідентифікаторів на пристрої. Без історії поведінки.
- Після згоди на cookie персоналізації: почніть фіксувати повторні візити й залученість і використовуйте їх для правил рівня 2.
- Після надсилання форми: пов’яжіть акаунт із даними CRM (рівень 3), якщо це покривають ваше повідомлення про конфіденційність і правова підстава.
Перевірте це нудним способом: відкрийте сайт у чистому профілі браузера, відхиліть усе і перевірте вкладку Application у DevTools. Жодного cookie персоналізації чи ключа в local storage з'явитися не повинно. Потім прийміть і перевірте знову.
2. Узгодьте категорії згоди з реальністю
Відвідувач, який погодився на «аналітику», не погоджувався на «персоналізацію». Якщо у вашому інструменті згоди є детальні категорії, додайте категорію персоналізації (або віднесіть персоналізацію до наявної категорії «функціональні» чи «маркетинг», яка точно її описує) і переконайтеся, що скрипт персоналізації реагує саме на цю категорію.
3. Перевірте кожного постачальника в потоці даних
Для кожного вендора, який працює з даними відвідувачів (IP-збагачення, аналітика, CDP, CRM, інструмент згоди), запишіть:
- Які дані вони отримують із вашого сайту і що надсилають назад.
- Де вони зберігають і обробляють дані та який механізм передачі покриває будь-яку передачу за межі ЄЕЗ.
- Чи використовують вони дані про ваших відвідувачів для власних продуктів. Якщо так, вони можуть діяти як контролер, а не обробник, що змінює ваші контракти та повідомлення про конфіденційність.
- Чи підписано угоду про обробку даних (DPA) і де вона зберігається.
Договір покриває лише половину; друга половина — те, як кожен постачальник насправді захищає дані. Якщо у вашій команді немає власної експертизи з безпеки, зовнішні послуги з кібербезпеки можуть перевірити контроль доступу та зберігання даних у постачальників до підписання.
Приклад того, що зазвичай виявляє такий аудит (умовний): інструмент аналітики, умови якого дозволяють використовувати дані клієнтів для створення власних аудиторних продуктів. Це не відносини обробника, тож ви або переукладаєте угоду, або належно це розкриваєте, або переходите на інструмент, що залишається в ролі обробника, як-от налаштування аналітики персоналізації, яке обробляє дані лише за вашими вказівками.
4. Напишіть три документи
- Розділ політики конфіденційності. Що ви збираєте (дані про компанію на основі IP, поведінкові дані за згодою), навіщо (щоб показувати релевантний контент), правова підстава, строк зберігання, постачальники й те, як заперечити.
- Оцінка законного інтересу. Тест мети (показ релевантного контенту бізнес-відвідувачам), тест необхідності (чому даних на рівні компанії достатньо і більше не потрібно), тест балансу (жодних чутливих даних, результат на рівні компанії, легке заперечення, короткий строк зберігання).
- Політика cookie. Кожен cookie чи ключ сховища, який встановлює система персоналізації, його мета, строк дії та категорія.
5. Встановіть строки зберігання, яких можете дотримуватися
Принцип обмеження зберігання GDPR у Article 5(1)(e) означає, що персональні дані не можна зберігати довше, ніж потрібно для мети. Закон не встановлює конкретного терміну, тож оберіть його самі та обґрунтуйте. Приклад: поведінкові дані — 90 днів, збагачені дані акаунтів — 12 місяців, щоб покрити типовий B2B-цикл продажу. Хоч би що ви обрали, налаштуйте це в інструментах, щоб видалення відбувалося автоматично.
6. Відрепетируйте запит суб’єкта даних
Згідно з Article 12(3) ви маєте відповідати на запити щодо доступу, видалення та заперечення без зайвих затримок і протягом одного місяця з можливістю продовження ще на два місяці за потреби. Каліфорнія дає 45 днів. Проведіть тестовий запит до запуску: оберіть колегу, який відвідував сайт, і спробуйте знайти, експортувати й видалити все, що ваш стек зберігає про нього. Якщо ваш інструмент ідентифікації відвідувачів не може зробити це для IP-адреси чи контакту, у вас є проблема, яку треба вирішити до запуску.
Типові помилки з дотриманням вимог
Називати дані про компанії «анонімними»
Ідентифікація компанії — це не те саме, що обробка анонімних даних. IP-адреса, яку ви використали для пошуку, за більшості реалістичних сценаріїв є персональними даними. Укажіть це у своїй документації, спирайтеся на задокументовану правову підставу й рухайтеся далі.
Вважати, що «серверний» означає «без згоди»
Як зазначено вище, EDPB тлумачить статтю 5(3) достатньо широко, щоб охопити відстеження на основі IP і збір ідентифікаторів на стороні клієнта. Серверні пошуки компанії для кожного запиту — дизайн із найнижчим ризиком, але це дизайнерське рішення, яке слід обговорити з юристом, а не автоматичний виняток.
Немає способу заперечити
Якщо ваша правова підстава — законні інтереси, відвідувач може заперечити. Посилання в політиці конфіденційності, що веде на поштову скриньку, яку ніхто не перевіряє, не рахується. Дайте відвідувачам налаштування, яке вимикає персоналізацію, і дотримуйтеся його в рушії персоналізації.
Використання даних про намір від третіх сторін без перевірки їхнього походження
Дані про намір від третіх сторін часто збирають на основі переглядів на різних сайтах. Якщо постачальник не може показати, як для цього збору отримано згоду чи іншу правову підставу, ви успадковуєте цю слабкість щойно почнете ними користуватися. Попросіть документацію про походження даних до підписання й віддавайте перевагу власним поведінковим сигналам. Компроміси детальніше розглянуто в нашому посібнику про дані про намір для персоналізації B2B-сайту.
Безстрокове зберігання
Інструменти персоналізації часто за замовчуванням зберігають усе. Перевірте налаштування строку зберігання в кожному інструменті стеку, а не лише в основній платформі персоналізації.
Чекліст перед запуском
- Інвентаризацію даних виконано, кожен вхідний параметр віднесено до рівня 1, 2 або 3.
- Правову підставу задокументовано для кожного рівня, з LIA для рівня 1.
- Аналіз пошуку IP і будь-якого клієнтського скрипту за ePrivacy, перевірений юристом.
- Банер згоди має категорію, що охоплює персоналізацію, а тест у чистому браузері підтверджує, що до згоди нічого не зберігається.
- DPA підписано з кожним постачальником; місця зберігання та механізми передачі задокументовано.
- Політику конфіденційності та політику cookie оновлено.
- Шлях заперечення та відмови працює, і рушій персоналізації його дотримується.
- Строки зберігання налаштовано в кожному інструменті.
- Тестовий запит суб’єкта даних виконано в строки, визначені GDPR і CCPA.
- Сферу дії CCPA перевірено за трьома порогами, а закони інших штатів США враховано, якщо звідти є трафік.
Чому обмеження конфіденційності роблять персоналізацію кращою
Це частина з думкою, і деякі команди з нею не погодяться. Робота в межах правил приватності підштовхує вас до тієї персоналізації, яка й так зазвичай працює.
Сегменти на рівні компанії охоплюють кожного відвідувача, зокрема тих, хто відмовляється від cookie, тож ваш перший тест не обмежується тими, хто натиснув «Прийняти». Для меншої кількості ширших сегментів (наприклад, п'яти-шести за галуззю й розміром компанії) легше написати добрий контент, ніж для десятків мікросегментів, побудованих на патернах перегляду, і кожен сегмент отримує достатньо трафіку для вимірювання. А коли не можна спиратися на сторонні дані, ви інвестуєте в стратегію first-party даних, побудовану на тому, як люди насправді користуються вашим сайтом, — саме ці дані відображають їхній інтерес саме до вас.
Якщо вам потрібна відправна точка для цих сегментів, наша стаття про фірмографічні сегменти, що конвертують пояснює, як їх обирати, а стаття як працює ідентифікація відвідувачів на рівні компаній — що може і чого не може сказати пошук за IP.
Як почати й не застрягти на юридичному погодженні
Реальний ризик для більшості B2B-команд — не штраф. Це місяці листування, бо ніхто не дав юристам конкретної схеми для перевірки. Дайте її:
- Одностороння схема потоку даних, що показує IP-пошук, що повертається і що зберігається.
- Таблиця рівнів вище, заповнена для вашого стеку.
- Чернетка LIA та розділу політики конфіденційності.
- Результати тесту згоди в чистому браузері.
Потім запустіть рівень 1 на кількох сторінках з високим трафіком, вимірюйте 30 днів і додайте рівень 2, коли згода працюватиме, а цифри це виправдовуватимуть.
Markettailor відповідає такому порядку дій: його фірмографічна сегментація працює з даними на рівні компаній, тож ви можете почати з правил рівня 1, поки завершується робота над згодою. Якщо хочете порівняти тарифи перед розмовою з юристами, перегляньте ціни Markettailor.