Виняток для «суворо необхідних» cookie: що підпадає, а що ні
Чому цей виняток важливий
Згідно з Директивою ePrivacy (стаття 5(3)), зберігання або читання інформації на пристрої користувача зазвичай потребує попередньої згоди. Є два винятки, і найчастіше видавці спираються на виняток для зберігання, яке суворо необхідне для надання сервісу, явно запитаного користувачем. Усе, що не охоплює цей виняток, перебуває за вашим банером згоди.
Багато сайтів розтягують цей виняток на аналітику, A/B-тестування, обмеження частоти показу реклами та персоналізацію. Регулятори неодноразово заперечували проти такого трактування, тож варто точно розуміти, де проходить межа.
Двоскладовий тест
Виняток не про те, що зручно вам. Він ставить два запитання:
- Користувач явно запитав сервіс? Завантаження статті — це запит. Додавання товару до кошика — це запит. Відкриття чат-віджета, який ви нав'язали на кожній сторінці, — ні.
- Зберігання суворо необхідне для надання саме цього сервісу? Якщо сервіс працював би й без cookie чи ідентифікатора, нехай і менш зручно, то зберігання, імовірно, не є суворо необхідним.
Зауважте: “необхідно для нашої бізнес-моделі” не те саме, що “необхідно для сервісу, який запитав користувач”. Дохід від реклами підтримує життя безкоштовного сайту, але рекламні ідентифікатори таргетингу не потрібні для показу статті.
Загальновизнані приклади
- Сесійні cookie та cookie автентифікації, які зберігають вхід авторизованого користувача протягом сесії.
- Cookie кошика, що запам'ятовують товари, поки користувач оформлює замовлення.
- Ідентифікатори балансування навантаження, які спрямовують запит на потрібний сервер.
- Cookie безпеки, що використовуються для виявлення повторних невдалих входів або захисту від підроблених запитів.
- Сам запис про згоду, бо запам'ятовування вибору користувача потрібне, щоб його дотримуватися.
- Налаштування інтерфейсу, які користувач задав свідомо, наприклад мова, коли вони зберігаються на час сесії або тому, що їх обрав сам користувач.
Приклади, які часто класифікують помилково
- Аналітичні cookie. Деякі органи допускають обмежене вимірювання аудиторії із захистом приватності за вузьких умов, але стандартні теги аналітики, як правило, потребують згоди. Перегляньте настанови органу, що стосується вашої аудиторії.
- Рекламні ідентифікатори та ідентифікатори ретаргетингу. Вони ніколи не потрібні для доставки самого контенту.
- Кнопки соціальних мереж і вбудовані віджети, які встановлюють сторонні cookie під час завантаження сторінки.
- A/B-тестування та персоналізація, не запитані користувачем.
- Обмеження частоти показу реклами. Воно покращує досвід користувача, але не є суттєвим для доставки сторінки.
Термін і обсяг усе ще мають значення
Справді необхідний cookie все одно може стати проблемою, якщо він живе довше або збирає більше, ніж потребує функція. Сесійний cookie, що зберігається рік, або cookie безпеки, який заодно записує маркетинговий профіль, втрачає свій захист. Робіть термін життя коротким, а вміст мінімальним.
Документуйте своє обґрунтування
Для кожного cookie чи елемента сховища, який ви відносите до суворо необхідних, запишіть три речі: користувацьку функцію, яку він забезпечує, чому ця функція зламалася б без нього, і його термін життя. Достатньо короткої таблиці поруч із вашою інвентаризацією cookie. Під час перегляду списку ставте під сумнів кожен запис: якщо єдиний аргумент — “ми завжди так робили”, перемістіть його за згоду.
Виняток стосується не лише cookie. Local storage, session storage, фінгерпринтинг пристрою та ідентифікатори SDK у застосунках підпадають під ту саму логіку статті 5(3), тож включіть їх до перевірки.
Де місце FlexyConsent
FlexyConsent — CMP, сертифікована Google (CMP ID 317), із сертифікацією IAB Europe та IAB Canada і банером 57 мовами. CMP дає змогу утримувати несуттєві теги, доки користувач не зробить вибір, а справді необхідні елементи продовжують завантажуватися. Рішення, до якої категорії належить кожен cookie, залишається за вами, тож підтримуйте своє задокументоване обґрунтування актуальним.
Ключові висновки
- Виняток охоплює зберігання, суворо потрібне для сервісу, явно запитаного користувачем, а не зберігання, потрібне для вашого доходу.
- Типові приклади, що підпадають, — cookie сесії, кошика, балансування навантаження, безпеки та запису про згоду.
- Аналітика, реклама, соціальні віджети та персоналізація, як правило, потребують згоди.
- Термін і вміст мають значення: робіть необхідні cookie короткотривалими та мінімальними.
- Застосовуйте той самий тест до local storage, session storage та ідентифікаторів застосунків.
- Документуйте обґрунтування для кожного елемента, який ви відносите до суворо необхідних, і регулярно переглядайте його.