Что такое GDPR и зачем он e-commerce
GDPR (General Data Protection Regulation) — регламент Европейского союза, действующий с 25 мая 2018 года. Он описывает, на каких условиях компания вправе собирать и обрабатывать персональные данные и какие права есть у человека, чьи данные обрабатываются.
Для интернет-магазина это не абстрактная юридическая рамка, а требования к архитектуре: где хранятся профили, кто имеет к ним доступ, как включается трекинг, что происходит, когда клиент просит удалить о себе всё.
Важная оговорка: материал написан для продуктовых и маркетинговых команд как объяснение практики. Это не юридическая консультация — периметр применимости, формулировки политик и договоров согласовывает юрист.
Ключевые понятия
| Понятие | Что означает на практике |
|---|---|
| Законное основание | До сбора данных нужно понимать, почему их можно собирать: согласие, исполнение договора, законный интерес |
| Согласие | Явное действие пользователя. Преотмеченная галочка и «продолжая пользоваться сайтом, вы соглашаетесь» согласием не считаются |
| Минимизация данных | Собирается только то, что нужно для заявленной цели. «Соберём на всякий случай» — антипаттерн |
| Ограничение цели | Данные, собранные для доставки заказа, нельзя молча переиспользовать для рекламного таргетинга |
| Срок хранения | У каждой категории данных есть срок, после которого они удаляются или обезличиваются |
| Право на доступ | Пользователь может запросить, какие данные о нём есть и откуда они появились |
| Право на удаление | Запрос на удаление отрабатывается во всех системах, а не только в основной базе |
| Право на переносимость | Данные отдаются в машиночитаемом формате, чтобы человек мог унести их к другому оператору |
| Контролёр / обработчик | Контролёр решает, зачем обрабатывать данные; обработчик делает это по его инструкции |
Отдельно стоит выделить категорию чувствительных данных — здоровье, религиозные и политические взгляды, биометрия. Для e-commerce это неочевидная ловушка: аптечная или интимная категория товаров в истории покупок фактически превращает поведенческий профиль в чувствительные данные, и обращаться с ним нужно строже, чем с историей просмотра бытовой техники.
Согласие на аналитику, согласие на рекламный таргетинг и согласие на маркетинговые рассылки — три разных согласия. Объединять их в одну галочку «согласен со всем» — самая частая практическая ошибка, к тому же она бьёт по opt-in-статистике: пользователь отказывается от всего сразу.
GDPR и российский 152-ФЗ: как это выглядит на практике
Обе рамки решают одну задачу — защиту прав человека при обработке его данных, — но акценты разные. Ниже — обобщение того, как команды обычно организуют работу, а не перечень юридических обязанностей.
| Аспект | GDPR (ЕС) | 152-ФЗ и смежные нормы (РФ) |
|---|---|---|
| Основной фокус | Основания обработки и права субъекта данных | Согласие субъекта, уведомление регулятора, требования к защите |
| Где хранятся данные | Требования к трансграничной передаче, но не к географии как таковой | Требование о размещении баз с данными россиян на серверах в РФ |
| Согласие | Явное, отзываемое, раздельное по целям | Явное, с указанием целей и перечня действий с данными |
| Права пользователя | Доступ, исправление, удаление, переносимость, возражение | Доступ, уточнение, блокирование и уничтожение данных |
| Регулятор | Профильные надзорные органы стран ЕС | Роскомнадзор |
Что команды делают на практике, работая с двумя рынками:
- Разводят контуры данных. Российский контур — на локальной инфраструктуре, европейский — отдельно. Общая для обоих часть — модель согласий и справочник целей обработки.
- Пишут единый реестр обработки. Таблица «какие данные, откуда, зачем, где лежат, сколько хранятся, кому передаются». Она же становится основой для ответа на запрос пользователя.
- Делают более строгий контур базовым. Поддерживать две принципиально разные логики трекинга дороже, чем один раз собрать управление согласиями и включить его везде.
- Фиксируют отношения с подрядчиками договором. Платформа персонализации, ESP, хостинг, аналитика — обработчики, и объём передаваемых им данных описывается явно.
Что это значит для CDP и персонализации
Персонализация работает на профиле пользователя, поэтому CDP оказывается центральной точкой, где сходятся все требования регулирования.
Управление согласиями. Согласие — это атрибут профиля, а не строка в базе юристов. У профиля должно быть машиночитаемое состояние: на какие цели пользователь согласился, когда, из какого источника (баннер CMP, чекбокс в форме, личный кабинет), и какая версия текста ему показывалась. Персонализационные механики читают это состояние перед запуском.
Аудит источников данных. Для каждого атрибута профиля полезно знать происхождение: пришёл он из заказа, из формы, из поведенческого трекинга или из внешней выгрузки. Атрибуты неизвестного происхождения — первый кандидат на удаление, потому что доказать законность их обработки нельзя.
Обработка запроса на удаление. Это инженерная задача, а не письмо в поддержку:
Запрос на удаление →
единый ID клиента (см. дедупликацию)
→ CRM / заказы (что можно удалить, что хранится по закону о торговле)
→ CDP: профиль, атрибуты, членство в сегментах
→ поведенческие события и аффинити-профиль
→ рекомендательный движок: история взаимодействий
→ аналитика и BI-витрины
→ выгрузки в рекламные кабинеты и ESP
→ бэкапы: срок ротации и правило неиспользования
→ подтверждение пользователю
Без единого идентификатора клиента этот маршрут не проходится: данные одного человека разложены по системам под разными ключами. Поэтому дедупликация клиентов — не только про качество сегментов, но и про способность выполнить запрос на удаление.
Смещение к first-party. Ограничения на third-party cookie и рамки вроде ATT в мобильной среде двигают отрасль в сторону данных первой стороны и zero-party данных — того, что пользователь сам сообщил в квизе, подписке или личном кабинете. Такие данные проще объяснить пользователю и проще защитить.
Чек-лист для продуктовой команды
- Реестр обработки. Составить таблицу «данные → цель → основание → система → срок хранения → получатели». Без неё все остальные пункты держатся на памяти сотрудников.
- Раздельные согласия. Минимум три независимых переключателя: аналитика, рекламный таргетинг, маркетинговые коммуникации. Отказ от одного не должен ломать остальные.
- Согласие как атрибут профиля. Состояние согласий доступно всем системам по API, а не хранится только в куке браузера.
- Отзыв согласия за один шаг. Отписка и отзыв согласия должны быть не сложнее, чем их выдача.
- Срок хранения по каждой категории. Поведенческие события обычно живут заметно меньше, чем история заказов. Данные без назначенного срока хранятся вечно — это и есть риск.
- Тестовый прогон удаления. Раз в квартал прогнать сквозной запрос на удаление по тестовому клиенту и проверить каждую систему из карты потоков.
- Договоры с обработчиками. Для каждого внешнего сервиса зафиксировано, какие данные он получает и зачем.
- Проверка сегментов. Убедиться, что построенные сегменты не используют атрибуты, на обработку которых согласия нет.
Практичный способ проверить зрелость работы с данными: попросить команду за один рабочий день ответить на вопрос «какие данные о клиенте X у нас есть и в каких системах». Если ответ занимает недели — запрос на удаление тоже не будет выполнен корректно.