CRM-аналитика
Запрос на удаление данных: как пройти по всей цепочке CRM-систем
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
Поддержка удалила профиль в CDP — платформе клиентских данных — и закрыла обращение. Через сутки ночная выгрузка создала профиль заново, а история заказов осталась у подрядчика. Проблема здесь не в кнопке удаления: компания не определила, где заканчивается цепочка обработки данных и кто подтверждает исполнение на каждом участке.
Запрос на удаление — управляемый процесс с проверкой заявителя, перечнем затронутых данных, правовыми основаниями решения и доказательством исполнения. Удаление профиля, прекращение рекламы и прекращение любой обработки — разные действия. Их нельзя обещать одной фразой, если система выполняет только первое.
Уточните объём запроса до технического запуска
Начните с того, чего требует человек: прекратить рекламу, удалить аккаунт, отозвать согласие или уничтожить определённые данные. Проверьте личность способом, соразмерным риску, не собирая для этого лишние сведения. Запрос по общему семейному адресу не даёт права удалить данные всех пользователей этого адреса.
Далее определите применимые основания и сроки. Статья 21 российского 152-ФЗ различает ситуации прекращения обработки, устранения нарушений и уничтожения; для них предусмотрены разные условия. Отзыв согласия не всегда означает, что можно немедленно уничтожить документы, для хранения которых есть иное законное основание.[1]
Поэтому в регламенте нужны ветки решения, согласованные с ответственным за персональные данные. Нельзя подменять их единым обещанием «всё удаляем через 30 дней», взятым из условий одного поставщика.
Постройте маршрут данных
Составьте перечень систем, куда попадали сведения: сайт, CDP, сервис рассылок, хранилище, аналитические витрины, поддержка, выгрузки агентству и резервные копии. Отдельно отметьте прямые передачи из приложения, которые обходят центральную платформу.
Это не теоретическая оговорка. Документация Segment различает удаление и подавление дальнейшей обработки; действия в подключённых системах зависят от возможностей интеграции. Передача запроса внешнему получателю сама по себе не подтверждает завершённое удаление у него.[2]
Для каждого узла зафиксируйте владельца, ключ поиска, доступное действие, срок исполнения и способ подтверждения. Список «вендоры, с которыми заключён договор» недостаточен: временная таблица или ручной экспорт тоже могут содержать данные.
Сначала остановите повторное появление
До удаления запретите необоснованное повторное поступление затронутых данных из старых источников. Иначе исправная интеграция восстановит то, что другая команда только что уничтожила. Для рекламных сообщений отдельно исполняется единый запрет рассылок.
Техническая отметка о выполненном запросе помогает блокировать повторный импорт, но её состав, основание и срок хранения тоже необходимо определить. Хеш email не становится автоматически обезличенным только из-за преобразования: возможность связать его с человеком сохраняет значение.
| Участок | Действие по регламенту | Подтверждение |
|---|---|---|
| Рабочий профиль | Удаление или ограничение разрешённых полей | Результат операции и контрольный поиск |
| Очереди и сегменты | Отмена ещё не исполненных действий | Отсутствие заданий на отправку |
| Внешний получатель | Запрос в согласованном формате | Ответ о завершении, а не о приёме |
| Законно сохраняемые документы | Отдельный режим и ограничение использования | Основание, срок и ответственный |
| Резервные копии | Утверждённый порядок обращения и восстановления | Проверка, что удалённые данные не возвращаются в работу |
Условный пример: профиль с двумя идентификаторами
Клиент зарегистрировался на сайте, затем купил офлайн. У него есть web_id и loyalty_id, а в ESP остался старый email. Удаление только web_id не затронет остальные записи.
Команда до выполнения собирает подтверждённые связи идентификаторов и передаёт минимально необходимый набор каждому исполнителю. Один узел отвечает «готово», другой — «задача в очереди», третий — «часть документов сохраняется на таком основании». Общий запрос остаётся открытым до прохождения согласованных проверок, а ответ клиенту отражает реальный объём исполнения.
Если обнаружена ошибочная склейка профилей, сначала уточняют принадлежность данных. Массовое удаление всех совпавших контактов может затронуть другого человека и не является безопасным способом ускорить процесс.
Что делать с резервными копиями
Резервная копия не должна служить обходным архивом для маркетинга. Доступ к ней ограничивают задачами восстановления, а регламент определяет жизненный цикл и порядок исполнения требований. Техническую неизменяемость копии нельзя автоматически объявлять юридическим исключением.
При восстановлении рабочей системы сначала применяют накопленные ограничения и решения об удалении, затем возобновляют доступ и отправки. Иначе аварийное восстановление CRM превратится в массовое возвращение старых подписчиков. Проверять нужно весь порядок запуска, а не только наличие списка запросов.
Как закрыть запрос доказуемо
Храните в карточке процесса номера подзадач, результаты по системам, согласованные исключения и минимальные сведения, необходимые для подтверждения исполнения. Не копируйте туда полную историю покупок «для отчётности».
После удаления попробуйте найти тестового клиента по всем подтверждённым идентификаторам, повторить старый импорт и запустить отправку. Проверка должна объяснять как отсутствие данных там, где они удалены, так и ограничения там, где они законно сохранены. Завершение процесса — это подтверждённый результат по цепочке, а не закрытый тикет в одной платформе.
Источники
[1] Российская Федерация. Федеральный закон от 27.07.2006 № 152-ФЗ, статья 21. Действующая редакция; текст нормы в СПС «КонсультантПлюс». Проверено 22.09.2026.
[2] Twilio Segment. User deletion and suppression. Документация Privacy. Проверено 22.09.2026.