Немає законодавчо визначеної кількості місяців для зберігання даних про кліки. Стаття 5(1)(e) GDPR вимагає, щоб персональні дані зберігалися в ідентифікованому вигляді не довше, ніж це необхідно для мети обробки, і залишає визначення терміну на ваш розсуд, як прямо вказано в тексті регламенту. Наглядовий орган перевіряє не саму цифру, яку ви обрали, а те, чи можете ви її обґрунтувати.
Це простіше, ніж здається, тому що дані про кліки - це не єдина сутність. Вони надходять як необроблений запит, стають подією з видаленою більшістю ідентифікуючих даних і завершуються як лічильник, що не ідентифікує нікого. Кожен із цих етапів заслуговує окремого терміну зберігання, і саме розділення на етапи - це основна частина роботи. Ширші зобов'язання щодо сервісу скорочення посилань розглянуто в основній статті GDPR для сервісів скорочення посилань, під якою розташований цей матеріал.
Чому на це питання немає єдиної відповіді
Обмеження зберігання - це принцип, а не графік. Термін визначають три чинники, і всі три ви встановлюєте самостійно.
Насамперед - мета обробки. Дані, зібрані для звітності про кампанію, потрібні доти, доки кампанію не проаналізовано і не порівняно з попередньою, що для багатьох команд становить максимум рік, а для деяких - три місяці. Дані, зібрані для виявлення зловживань редиректом, потрібні доти, доки могло б обґрунтовано розпочатися розслідування, а це зазвичай значно коротший термін.
По-друге - законна підстава обробки. Аналітика, що ґрунтується на законному інтересі, повинна витримати тест на балансування інтересів, а довгий термін зберігання ускладнює проходження цього тесту. Усе, що зібрано на підставі згоди, має бути видалено одразу після відкликання згоди, без тихої підміни іншою підставою замість неї.
По-третє - зобов'язання, що діють у протилежному напрямку. Податкові правила, договірні зобов'язання перед клієнтом, активний спір чи регуляторна вимога про утримання даних - усе це може вимагати зберігання чогось довше, ніж це випливало б із принципу мінімізації. Такі підстави законні, але водночас конкретні, а отже, мають бути внесені в реєстр як окремі, поіменовані винятки, а не як загальна причина зберігати все підряд.
Три рівні, три терміни зберігання
Практична структура, що витримує перевірку аудитом, розділяє дані про кліки за ступенем їхньої ідентифікуючої здатності.
| Рівень | Що містить | Типовий термін | Чому |
|---|---|---|---|
| Необроблений журнал запитів | повна IP-адреса, user agent, заголовки, мітка часу | дні | лише операційна діагностика та боротьба зі зловживаннями |
| Подія кліку | усічений мережевий префікс, країна, пристрій, кампанія | приблизно 12 місяців | звітність і порівняння рік до року |
| Агрегат | лічильники за днями, посиланнями, країнами, реферерами | необмежено | анонімні дані, більше не є персональними |
Саме на середньому рівні більшість команд непомітно для себе зберігають дані надто довго - зазвичай тому, що інструмент звітності за замовчуванням тримає все, і ніхто це налаштування не змінював. Дванадцять-чотирнадцять місяців - це термін, що дозволяє порівняти цей вересень із минулим і на цьому зупинитися. Якщо вашій звітності справді потрібні три роки деталізованих даних на рівні окремих рядків, це рішення варто записати й обґрунтувати, а не залишати випадковим наслідком конфігурації.
А от верхньому рівню більшість команд приділяють замало уваги. Повна IP-адреса в журналі запитів - це персональні дані, і журнал, який зберігається рік лише тому, що ніхто не налаштував ротацію, - це рік непотрібного ризику, придбаного даремно. Усічення на етапі збору, ще до запису події, усуває проблему в самому джерелі. У статті що варто вимірювати в аналітиці коротких посилань розглянуто, які метрики залишаються доступними після такого усічення, і відповідь - майже всі.
Агрегація - це і є стратегія зберігання
Найкорисніший крок - це не вибір коротшого терміну зберігання. Це така організація процесу, за якої те, що зберігається назавжди, більше не є персональними даними.
Згорніть події кліків у лічильники за днями, посиланнями, країнами, реферерами та класами пристроїв, а потім видаліть рядки, з яких вони були отримані. Те, що залишається, відповідає майже на всі питання, які ставить маркетингова команда: як пройшла кампанія, який регіон відреагував, чи змінилася частка мобільного трафіку. Чого воно не може відповісти - це на будь-яке питання про конкретну особу, і саме в цьому й полягає суть.
Два застереження. Анонімізація повинна бути незворотною, тому якщо ви зберігаєте таблицю відповідностей, яка дозволяє відновити вихідні рядки, це означає, що дані лише псевдонімізовані, а не анонімізовані, і вони й далі підпадають під дію регламенту. І малі групи видають окремих осіб: посилання, надіслане п'ятьом людям, підраховане похвилинно, можна повторно ідентифікувати будь-кому, хто знає цих п'ятьох. Агрегуйте з такою деталізацією, що зберігає групи достатньо великими, і приховуйте комірки, значення яких не досягає порогу.
Налаштувати це один раз краще, ніж переглядати щороку. Аналітика посилань Elido усікає адресу ще до збереження події та формує звіти на основі агрегатів, тому рішення щодо термінів зберігання стосується лише середнього рівня.
Чого насправді сягає запит на видалення
Стаття 17 надає суб'єкту даних право на видалення, і чесна відповідь для добре спроєктованих даних про кліки часто полягає в тому, що видаляти просто нічого.
Якщо подія містить лише усічений мережевий префікс, країну, клас пристрою та кампанію, жодна операція на вашому боці не може пов'язати її з особою, яка звернулася із запитом. Поясніть це, опишіть архітектуру - і запит буде задоволено. Регулятори не ставляться вороже до такої відповіді, якщо архітектура справді її підтверджує.
Відповідь змінюється, щойно кліки прив'язуються до конкретної особи. Сервіс скорочення, який фіксує, який контакт відкрив яке посилання, або CRM, що записує події кліків у картку контакту, зберігає персональні дані, прив'язані до імені, і запит на видалення сягає всього цього. Це цілком законний спосіб роботи - він просто переносить зобов'язання на інший рівень. Якщо ви передаєте кліки в CRM, рішення щодо термінів зберігання стосується обох систем одночасно, і реальний термін визначає та система, у якої він довший. У статті передавання кліків за посиланнями у хронологію CRM показано, що саме записує така інтеграція.
Документування, яке витримує перевірку аудитом
Графік зберігання, що існує лише в чиїйсь голові, - це не контроль. Реальним його роблять чотири артефакти.
- Реєстр операцій з обробки. Стаття 30 вимагає вказувати терміни зберігання для кожної категорії даних. Заповніть цю колонку трьома рівнями, описаними вище, а не однією цифрою, тому що єдина цифра для всіх даних про кліки буде помилковою або для необроблених журналів, або для агрегатів.
- Механізм видалення, на який можна вказати. Налаштований термін закінчення дії для сховища аналітичних даних із видимим налаштуванням переважає задокументований намір. Якщо видалення виконується як планове завдання, зберігайте історію його запусків.
- Резервні копії, зазначені явно. Вкажіть, скільки живуть покоління резервних копій і що відбувається під час відновлення. Опубліковані рекомендації EDPB - це орієнтир для того, як наглядові органи трактують ці питання в різних державах-членах.
- Відповідність вашим договорам із процесорами. Якщо договірний термін зберігання вашого сервісу скорочення довший за вашу політику, на практиці перевагу має договір. Читайте DPA до того, як писати політику, а не після.
Ще один момент, про який часто забувають: експорти. CSV, вивантажений у таблицю, синхронізація зі сховищем даних, інструмент дашбордів із власним кешем. Кожна копія несе із собою те саме зобов'язання щодо зберігання, і жодна з них не враховує термін дії, який ви налаштували на початковому рівні. Внесіть їх у графік зберігання - або визнайте, що графік описує лише частину реальності.
Значення за замовчуванням, яке можна обґрунтувати
Якщо потрібна відправна точка, ось позиція, яка витримує перевірку: необроблені журнали запитів ротуються протягом кількох днів, події кліків зберігаються близько року, щоб працювало сезонне порівняння, агрегати зберігаються необмежено і є справді анонімними, усе, що зібрано на підставі згоди, видаляється після її відкликання, а кожен виняток названо разом із причиною.
Потім переглядайте це раз на рік, порівнюючи з тим, на що команда справді дивиться. Майже кожен термін зберігання, який я бачив, скорочувався після такого перегляду, бо звітність, що виходила за межі тринадцяти місяців, зазвичай виявлялася чимось, що люди казали, ніби потребують, а не тим, що вони справді відкривали. У статті резидентність даних в ЄС для маркетингових команд розглянуто другу половину цієї розмови - те, де саме зберігаються дані, поки ви їх тримаєте.
Читайте серію основних матеріалів
Ця стаття входить до кластеру відповідності (compliance). GDPR для сервісів скорочення посилань є основною статтею, а гід із доказової бази SOC 2 розглядає артефакти аудиту, які супроводжують графік зберігання даних.
Пов'язане в блозі
Поширені запитання
Як довго можна зберігати дані про відстеження кліків згідно з GDPR?
Стільки, скільки можна обґрунтувати метою, для якої ви їх зібрали, і не довше. Стаття 5(1)(e) встановлює обмеження зберігання як принцип, а не як конкретну цифру, тому законодавчого максимуму, на який можна було б послатися, не існує. Регулятор просить саме ваше обґрунтування, викладене письмово, та докази того, що видалення справді відбувається за графіком, який ви встановили.
Чи є IP-адреса в журналі кліків персональними даними?
У звичайному випадку - так. IP-адреса ідентифікує абонентську лінію за допомогою інформації, якою володіє оператор мережі, і цього достатньо, щоб вважати її персональними даними, навіть якщо ви самі ніколи не отримуєте цю інформацію. Усічення адреси на етапі збору, ще до запису, - це те, що виводить поле з цієї категорії.
Чи підпадають агреговані лічильники кліків під дію GDPR?
Ні, якщо вони справді анонімні - тобто ніхто не може виокремити конкретну особу за допомогою будь-яких засобів, які обґрунтовано можуть бути використані. Щоденний підрахунок кліків за країнами легко долає цю планку. А підрахунок кліків за посиланням щохвилини для посилання, надісланого чотирьом людям, - ні, бо група достатньо мала, щоб її можна було повторно ідентифікувати.
Який термін зберігання варто встановити для аналітики посилань?
Обґрунтоване значення за замовчуванням - коротке для необроблених журналів запитів, приблизно рік для псевдонімізованих подій кліків, щоб зберігалося порівняння рік до року, і необмежене для анонімних агрегатів. Коригуйте це під власні цілі: юридичне утримання даних, договірне зобов'язання чи розслідування шахрайства - усе це виправдовує довший термін, і кожна така причина має бути відображена в реєстрі.
Чи охоплює запит на видалення дані про кліки?
Він охоплює все, що пов'язане з конкретною особою. Якщо ваші події кліків містять лише усічений мережевий префікс і жодного ідентифікатора, шукати й видаляти нічого, і ви повинні вміти пояснити чому. Якщо кліки прив'язані до запису контакту в CRM, саме цей зв'язок і потрапляє під дію запиту на видалення.
Чи потрібно видаляти й резервні копії?
Вони мають бути охоплені графіком зберігання, а це не те саме, що видалення в той самий день. Робочий підхід полягає в тому, що резервні копії застарівають за фіксованим циклом, відновлені дані повторно фільтруються перед використанням, а вся ця домовленість задокументована. Саме мовчання про резервні копії перетворює рутинне питання на порушення, виявлене під час перевірки.
Спробуйте Elido
Вставте URL - отримайте коротке посилання
Без реєстрації. Посилання живе 30 днів. Зареєструйтесь, щоб зберегти назавжди.
Безкоштовно, без реєстрації · 2 на день