Законодательно закрепленного числа месяцев для хранения данных о кликах не существует. Статья 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 в день