Предпочтения клиента: проверьте адрес, канал, цель и тему сообщения

Начните с назначения сообщения

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

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

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

Разделите человека, контактную точку и область выбора

Карточка клиента представляет участника процесса. Контактная точка обозначает конкретное назначение сообщения: email, телефон или адрес другого канала. Изменение телефона не означает смену человека, но прежнее разрешение по одному номеру нельзя автоматически копировать на другой.

В Microsoft Customer Insights — Journeys предпочтения хранятся на уровне contact point и канала, независимо от того, пришёл адрес из contact, lead или другого поддерживаемого профиля. Это модель конкретного продукта, которую полезно учитывать при проектировании собственной проверки. Microsoft: consent management controls.

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

Цель и тема образуют иерархию

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

Microsoft указывает, что один topic относится только к одному purpose. В restrictive-модели для сообщения с темой нужны разрешающие записи и по родительской цели, и по теме. Разрешение дочерней темы не заменяет отсутствующее разрешение родителя. Microsoft: purposes and topics.

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

Учебная матрица: шесть подготовленных сообщений

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

E1 и E2 обозначают разные email-адреса, P — телефон для SMS. A и B — разные цели. A.news и B.news являются разными идентификаторами тем с похожим названием «Новости». Каждая тема принадлежит своему родителю; одного общего topic у двух целей нет.

• Кандидат 1: E1, email, цель A, тема A.news. Цель разрешена, тема разрешена. Проверка пройдена.
• Кандидат 2: E1, email, A, A.offers. Цель разрешена, тема отклонена. Отправка по этой политике не допускается.
• Кандидат 3: E2, email, A, A.news. Выбор цели неизвестен, тема разрешена. Проверка не пройдена: дочернего разрешения недостаточно.
• Кандидат 4: P, SMS, A, A.news. И цель, и тема разрешены именно для этого номера и канала. Проверка пройдена.
• Кандидат 5: P, SMS, A, A.offers. Цель разрешена, выбор темы неизвестен. Проверка не пройдена.
• Кандидат 6: E1, email, B, B.news. Цель отклонена, тема разрешена. Проверка не пройдена.

Итак, подходят два кандидата из шести: 1 и 4. Это результат учебной проверки условий, а не показатель эффективности кампании, подтверждение доставки или разрешение реально отправить эти сообщения.

Отзыв должен сохранять заявленную область

Теперь получен подтверждённый отзыв, явно ограниченный E1, каналом email и целью A. Для кандидата 1 родительское разрешение меняется на отказ; его тема больше не позволяет продолжить отправку. Кандидат 2 уже был исключён и остаётся исключённым.

В этой строго заданной ситуации из шести подходит только кандидат 4. Прежний выбор для телефона P не изменился. Такой результат допустим именно потому, что область учебного отзыва была явно узкой. Реальную просьбу «больше со мной не связывайтесь» нельзя сужать до email ради продолжения SMS.

Если формулировка неоднозначна, остановите затронутые сообщения и уточните область по принятому порядку. Не угадывайте удобный смысл. Смена канала, новая карточка клиента или переименование цели не должны служить способом обойти выраженное ограничение.

Новый адрес не наследует старую историю автоматически

Допустим, в карточке вместо E1 появился E3. Это изменение контактных данных, а не новое разрешение на коммерческие сообщения. Нужно проверить актуальную связь адреса с клиентом и относящееся к нему основание; пустую запись не заполняют старым значением без подтверждения.

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

Microsoft отдельно требует отражать внешние изменения в contact-point records. Документация также предупреждает, что гибкость email enforcement не распространяется таким же образом на коммерческие SMS и custom channels: для них требуется explicit opt-in. Microsoft: consent records and channel limits.

Проверьте разделяемые настройки

Несколько экранов предпочтений или брендов могут использовать общую цель. В Journeys изменение enforcement общего purpose затрагивает использующие его profiles. Разные названия экранов поэтому ещё не доказывают независимость правил.

Тот же источник предупреждает: деактивация consent record не заменяет изменения значения согласия; существующие процессы могут продолжать использовать запись. Microsoft: область настроек и деактивация. Эти особенности необходимо проверять в конкретной реализации, а не переносить на другие системы автоматически.

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

Данные и приёмочный чек-лист

У записи нужны контактная точка, канал, идентификаторы цели и темы, значение выбора и основание. Сохраняйте время самого выбора отдельно от загрузки, источник, применённую политику и подтверждённую область изменения. Сотруднику достаточно безопасного представления контакта; полные данные доступны только нужным ролям.

1. A.news и B.news имеют разные ID и по одному родителю.
2. Шесть исходных кандидатов дают два подходящих результата.
3. Отказ или неизвестный выбор родителя блокирует тему по учебной политике.
4. Узкий подтверждённый отзыв E1/email/A оставляет только кандидат 4.
5. Широкая просьба клиента сохраняет широкий смысл во всех затронутых процессах.
6. Новый E3 не получает прежнее разрешение автоматически.
7. Изменение общей цели показывает все зависимые настройки.
8. Проверка выполняется по актуальным данным перед предусмотренным действием.

Для SABSUS обсудите записи и источники через CRM и клиентское приложение. Поддержку такой области предпочтений, иерархии и проверки перед отправкой нужно подтвердить в конфигурации.

Частые вопросы

Одного разрешения в карточке клиента достаточно?

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

Разрешённая тема перекрывает отказ общей цели?

В рассмотренной restrictive-модели нет. Нужны положительные основания на обоих уровнях; тема не отменяет родительское ограничение.

Пройденная проверка гарантирует доставку?

Нет. Она подтверждает выбранный участок политики. Доступность канала, доставка и ответ клиента имеют отдельные результаты.

Источники

• Microsoft: Configure consent management controls.
• Microsoft: Create consent records.

Проверено 9 октября 2026 года. Матрица и строгая политика являются учебными.