Интернет-магазин узнаёт покупателя через множество точек контакта: оформление заказа, подписку на новости, обращение в поддержку, регистрацию в программе лояльности. Для команды всё это часто выглядит как одна клиентская база. Для самого человека это разные решения: оставить телефон для доставки, получать предложения или разрешить использование данных для другой цели. Предложенная платформа согласий делает эту разницу особенно важной для бизнеса.

30 сентября 2026 года Минцифры представило третий пакет мер против кибермошенничества для общественного обсуждения. Так РБК передал сообщение пресс-службы ведомства. Среди инициатив названы платформа согласий на «Госуслугах» и изменения в организации массовых СМС-рассылок. Рассматриваем эти предложения как повод проверить работу с клиентскими данными. Окончательные требования к сайтам и сроки их применения по новостному анонсу определить нельзя.

Что предлагают и на каком этапе находится пакет

Официальный портал Объясняем.рф сообщил 30 сентября, что подготовка законопроекта завершается, а внесение в Госдуму планируется на осеннюю сессию. В публикации описана единая платформа: человек сможет увидеть согласия на обработку персональных данных, выданные онлайн и офлайн, отозвать их и сообщить о возможных нарушениях. В пакет также включены предложения об обороте сим-карт и работе рассылок. Это описание инициативы, а не объявление о запуске платформы для всех организаций.

У идеи понятная пользовательская задача: собрать в одном месте сведения, которые сейчас человеку приходится искать в разных сервисах. Для компании потенциальная сложность лежит глубже интерфейса. Если клиент меняет решение, нужно понимать, к каким операциям оно относится и какие системы должны получить обновление. Одна кнопка в личном кабинете не решает эту задачу, когда история действий разнесена по сайту, CRM и сервису сообщений.

Текст проекта, окончательная редакция закона и технические правила интеграции отвечают на разные вопросы. Первый показывает обсуждаемые формулировки. Второй позволяет определить принятые требования. Третьи объясняют, как системы будут обмениваться сведениями. До подтверждения этих документов преждевременно обещать клиентам подключение к государственной платформе или закладывать конкретную дату обязательного перехода.

Почему отметки «согласен» в CRM бывает недостаточно

Представим условный магазин товаров для дома. В CRM есть контакт Ольги и поле «согласие: да». По этому полю невозможно восстановить, что именно происходило. Ольга подписалась на советы по уходу за текстилем или заполнила форму заказа? Какой текст она увидела? Согласилась на письма, СМС или оба канала? Вносил ли сотрудник информацию вручную после разговора? Эти вопросы относятся к качеству учёта, независимо от судьбы нового пакета.

Для технического разбора удобнее представить согласие отдельной записью со своей историей, а не постоянным свойством человека. У записи есть источник, время события, связанная цель, версия показанного текста и состояние. Такая модель помогает разобраться в конкретном обращении. При этом состав юридически необходимых сведений и основания обработки определяют по действующим документам с профильным специалистом, а не по предложенной нами схеме базы.

Особое внимание стоит уделить импорту. Файл из старой CRM может содержать адреса и положительную отметку, но потерять даты и происхождение. Если команда переносит только контакты, она делает новую базу удобнее для отправки, одновременно ухудшая возможность объяснить её историю. Поэтому перед переносом полезно выяснить, какие сведения сохраняются вместе с клиентом и кто отвечает за проверку спорных записей.

Как проверить путь решения клиента

Начните с одного сценария и проведите его через все используемые системы. Например, человек оставляет адрес в форме подписки, затем получает письмо и позже отключает эту подписку. Отслеживать нужно не только внешний экран. Важно увидеть, какая запись создаётся на сайте, что попадает в CRM, когда обновляется сервис рассылки и где сотрудник проверяет итоговое состояние.

Для такой проверки можно составить короткую рабочую карту. Это организационный пример Digi-Web, а не перечень новых обязанностей из законопроекта:

• Где возникает действие: форма сайта, личный кабинет, бумажный документ или разговор с сотрудником.
• Что видит человек: понятная цель, выбранный канал связи и действующая версия текста.
• Куда поступает событие: база сайта, CRM, почтовая система и другие связанные сервисы.
• Как меняется состояние: отключение отдельной подписки, исправление ошибки или другой подтверждённый запрос.
• Кто проверяет исполнение и разбирает расхождение между системами.

Вернёмся к Ольге. Она отключила рекламные письма, но ожидает информацию о доставке уже оформленного заказа. Техническая система должна уметь различать эти сценарии. Автоматическая пометка «не писать нигде» может нарушить обычное обслуживание, а сохранённая старая рекламная подписка — привести к нежелательному сообщению. Юридическую допустимость конкретных сообщений оценивают отдельно; задача разработчика — обеспечить точное выполнение принятого решения.

У обновлений есть и время. Если сайт изменил статус сразу, а почтовая система получает выгрузку раз в сутки, между ними появляется промежуток несогласованности. Команде полезно знать его фактическую длину, порядок обработки ошибок и источник, который считается главным. Тогда вопрос клиента разбирают по событиям, а не по предположению, что «интеграция должна была всё передать».

Рассылки: какие вопросы задать подрядчику

Предлагаемые изменения в массовых СМС-рассылках пока не дают оснований объявлять всем магазинам срочную смену поставщика. Но они позволяют заранее выяснить, как устроена текущая цепочка. Кто предоставляет услугу, какие участники передают сообщения, где хранится список получателей и как подрядчик получает изменения? Ответы нужны для управления системой уже сейчас.

Проверку лучше проводить на тестовых данных. Создайте внутренний контакт, включите разрешённую тестовую подписку, измените её состояние и убедитесь, что новая настройка дошла до нужного канала. Затем повторите проверку при временной ошибке обмена. Если система просто прекращает обработку и не уведомляет ответственного сотрудника, команда может долго не замечать расхождения.

В договоре, интерфейсе и техническом журнале используются разные термины. Попросите подрядчика объяснить, что означают «отписан», «заблокирован», «удалён» и «неактивен». Это может быть разное поведение: запрет одной кампании, остановка всех отправок или исчезновение записи. Для магазина важно согласовать значения до того, как потребуется массовое изменение базы.

Что разумно подготовить до появления окончательных правил

Практический результат предварительной работы — карта источников данных и список конкретных непонятных мест. Одной компании потребуется восстановить историю форм сайта. Другой — исправить передачу состояния между CRM и рассылкой. Третьей — определить ответственного за запросы клиентов. Такие изменения следует планировать по обнаруженным проблемам, а не по предположительным требованиям будущей платформы.

У рекламы и аналитики есть соседняя задача — корректное использование клиентских идентификаторов. Её мы разбирали в материале про универсальный сегмент Яндекс Аудиторий. Наличие технической возможности загрузить базу само по себе не отвечает на вопросы о целях её использования и истории решений клиентов.

Следующий этап наблюдения за инициативой — появление доступного текста, подтверждённого парламентского статуса и, при принятии, опубликованной редакции с переходными положениями. После этого можно сопоставить требования с процессами компании и оценить объём доработок. Сейчас полезнее наладить понятный учёт действий клиента: он даст команде основу для дальнейших решений и сократит число ситуаций, в которых никто не может объяснить происхождение одной отметки в CRM.