Что на самом деле означает «приоритет конфиденциальности» в вашем стеке аналитики
Эта фраза повсюду, но большинство инструментов, использующих её, по-прежнему хранят идентификаторы, отпечатки или хэшированные email. Вот как выглядит технически обоснованная модель данных с приоритетом конфиденциальности.
«Приоритет конфиденциальности» стал маркетинговой фразой. Инструменты, использующие её, варьируются от тех, которые действительно не хранят персональных данных, до тех, которые просто переместили свои cookie в серверное хранилище и назвали себя соответствующими. Чтобы оценить заявление, нужно посмотреть на три конкретные вещи: что собирается, как это хранится и можно ли это обратить.
Уровень 1: Что собирается
Каждый инструмент аналитики что-то собирает. Вопрос в том, квалифицируется ли что-либо из этого как персональные данные согласно GDPR, LGPD или CCPA. Следующие данные, как правило, безопасны — они являются агрегированными или сами по себе неидентифицирующими:
- URL и путь страницы
- Домен реферера (не полный URL)
- Страна (выведена из IP на краю, никогда не сохраняется)
- Тип устройства (мобильное или настольное, выведено из ширины экрана и общих шаблонов User-Agent)
- Семейство браузеров (Chrome, Safari, Firefox и другие грубые семейства, выведенные на стороне сервера из User-Agent запроса)
Эти данные безопасны, потому что ни одно из них, по отдельности или в сочетании, надёжно не идентифицирует конкретного человека. Домен реферера говорит вам, что кто-то пришёл с Hacker News — но не кто из пользователей Hacker News это был.
Линия пересекается, когда вы начинаете хранить IP-адреса, полные User-Agent, отпечатки устройств или любой постоянный идентификатор — даже хэшированный, который вы сохраняете между сессиями.
Уровень 2: Как хранятся данные
Безопасный сбор данных отличается от безопасного их хранения. Многие инструменты заявляют, что не используют cookie, а затем хранят идентификатор посетителя в серверной сессии, привязанной к IP-адресу. IP-адрес является персональными данными согласно GDPR. То, что cookie переместилось на сторону сервера, не меняет того, что отслеживается.
Подлинно ориентированное на конфиденциальность хранилище содержит только то, что указано выше — и идентификатор посетителя, который нельзя связать с каким-либо лицом. Подход Monoid — это ежедневный односторонний хэш:
visitor_hash = SHA-256(IP + UA + SALT_SECRET + YYYY-MM-DD)
Три свойства делают это безопасным:
Односторонний: SHA-256 необратим. Вы не можете восстановить IP-адрес из хэша. С солью: Серверный SALT_SECRET означает, что хэш не может быть атакован радужными таблицами, даже если алгоритм известен. Ежедневный: Дата на входе означает, что один и тот же посетитель завтра производит другой хэш. Нет постоянного идентификатора между сессиями.
Хэш бесполезен для отслеживания человека во времени. Он полезен только для дедупликации посетителей в течение одного дня, что является единственным, что он должен делать.
Уровень 3: Можно ли это обратить?
Это тест, который отделяет настоящие инструменты с приоритетом конфиденциальности от маркетинговых заявлений. Если достаточно мотивированный противник — включая правительство с юридическим ордером — получил бы вашу базу данных аналитики, что он мог бы узнать?
С моделью данных Monoid: они могли бы узнать, какие страницы были посещены, из каких стран, на каких устройствах и в какие дни. Они не могли бы узнать, какой конкретный человек посетил конкретную страницу. Хэш ничего им не говорит без оригинального IP, оригинального User-Agent, секретной соли и правильной даты — всё это никогда не хранится вместе.
Сравните это с «анонимизированными» данными GA4, которые сохраняют идентификаторы клиентов (постоянные идентификаторы на основе cookie), отметки времени событий с миллисекундной точностью и компоненты отпечатков устройств. Эти данные не анонимны — они в лучшем случае псевдонимизированы и связываемы с реальными пользователями с умеренными усилиями.
Как на самом деле выглядит база данных
Запись просмотра страницы Monoid содержит: site_id, path, referrer, country, device, browser_family, visitor_hash (односторонний ежедневный хэш) и timestamp. Это полная запись. Нет столбца IP-адреса, полной строки User-Agent, версии браузера, постоянного идентификатора пользователя или токена сессии. В схеме нет ничего, что отображалось бы на реального человека.
Вот как выглядит приоритет конфиденциальности на уровне модели данных. Всё остальное — дашборды, подсчёты в реальном времени, разбивки по странам — вычисляется из этих полей.
Почему различие важно на практике
Если ваш инструмент аналитики хранит персональные данные, вы являетесь контролёром данных GDPR с обязательствами: вы должны опубликовать законное основание для обработки, вести записи деятельности по обработке и отвечать на запросы доступа субъекта данных. Вам также нужен механизм согласия, если ваше законное основание — это согласие.
Если ваш инструмент аналитики хранит только неперсональные агрегированные данные, эти обязательства не применяются — потому что нет персональных данных для контроля. Юридические накладные расходы исчезают вместе с баннером согласия.