CRM-аналитика
Как выбрать Contact Key в Marketing Cloud Engagement
Время чтения: 5 мин
Уровень материала: Для экспертов
Содержание
При внедрении Salesforce Marketing Cloud Engagement команде нужно выбрать поле Contact Key. Часто для скорости берут email: он уже есть в выгрузке и кажется уникальным. Проблема становится заметной позже, когда человек меняет адрес, использует несколько каналов или делит почтовый ящик с другим членом семьи.
Marketing Cloud Engagement — набор инструментов Salesforce для клиентских коммуникаций. Contact Key служит выбранным вами идентификатором контакта между каналами. В Email Studio используется Subscriber Key, который становится Contact Key в Contact Builder. Системный Contact ID — другое, внутреннее значение Salesforce. [1]
Выбор ключа определяет, какие записи платформа будет считать одним контактом. Поэтому его нужно проверить на жизненном цикле клиента до массовой загрузки. Ниже — методика проектирования CRM Lab; конкретные ограничения интеграции проверяют для своей конфигурации Engagement.
Определите смысл клиентской записи
Один человек может иметь несколько аккаунтов, работать в двух компаниях или выступать получателем подарочного заказа. Решите, что представляет контакт в вашем проекте: человека, пользователя продукта или отдельный деловой контакт. Это решение должно совпадать с моделью клиентских данных и правилами коммуникаций.
Если маркетинг хочет объединять человека между брендами, одного общего технического ключа недостаточно. Нужны основания для такой идентификации, правила использования данных и отдельные ограничения коммуникаций. И наоборот: разные номера аккаунтов не обязательно означают разных людей для бизнес-аналитики.
Составьте список источников ключа: сайт, приложение, CRM продаж, сервис поддержки и импорты. Для каждого запишите, кто присваивает значение, может ли оно измениться и как определяется соответствие другим системам. Важно заранее обнаружить случаи, когда один источник представляет человека, а другой — договор.
Выбирайте устойчивый идентификатор
Хороший кандидат остаётся прежним при смене email и телефона, не выдаётся другому человеку и однозначно сопоставляется между каналами. Это может быть постоянный ID из мастер-системы или специально созданный идентификатор, если такая модель совместима с используемыми коннекторами.
Email удобен как адрес доставки, но меняется и бывает общим. Телефон также может перейти новому владельцу. Хэширование email скрывает исходную строку от непосредственного чтения, но не устраняет эти свойства: после смены адреса изменится и хэш.
| Кандидат | Что проверить | Типичный риск |
|---|---|---|
| Постоянный customer ID | Устойчивость и доступность всем каналам | Другие системы не знают этот ID |
| Email или его хэш | Смена адреса и общий ящик | Разрыв истории или ложное объединение |
| ID записи CRM продаж | Создание и преобразование записей | Изменение сущности на пути от лида |
| Составной ключ с источником | Правила сопоставления | Один человек остаётся несколькими контактами |
Исключите случайные совпадения
Salesforce отдельно предупреждает о риске, когда одинаковые значения приходят из разных систем и трактуются как один Subscriber Key. Также Subscriber Key позволяет различать несколько записей с одним email. [2] Это полезные свойства, если команда задала их осознанно.
Условный пример. В розничной системе номер 418 принадлежит Ольге, а в CRM корпоративных продаж номер 418 — Игорю. Нельзя передавать оба значения как общий ключ 418. Префиксы retail и b2b предотвратят случайное совпадение, но сами по себе не объединят Ольгу, если она встречается в обеих системах. Для этого нужна проверенная таблица соответствий или общая мастер-запись.
Согласуйте формат: строка или число, ведущие нули, регистр, пробелы, допустимая длина. Правило преобразования должно быть единым. Самовольное удаление префиксов или ведущих нулей в одной загрузке способно изменить смысл идентификатора.
Проверьте ключ в каждой отправляемой таблице
Data Extension — таблица данных Engagement. Для таблицы, участвующей в отправке, настройка send relationship связывает строку с подписчиком. Salesforce рекомендует последовательно использовать Subscriber Key в отправляемых Data Extensions. [1]
Проверьте, что поле с красивым названием CustomerID действительно участвует в правильной связи. Отправьте тест через email, затем добавьте мобильный канал с тем же ключом. Посмотрите итоговую запись в Contact Builder, а не только успешный статус двух интеграций.
Для клиента с общим семейным адресом отдельно проверьте частоту сообщений и отписку. Возможность технически создать разные ключи на один email не означает, что бизнес хочет отправлять в этот ящик одинаковые письма несколько раз. Ограничения адреса и человека могут потребовать разных правил.
Испытайте изменения до загрузки базы
Обязательные ситуации: смена email при прежнем ключе, два канала одного клиента, два человека с общим адресом, повторный импорт и конфликт номеров разных источников. Если используется CRM продаж, добавьте преобразование лида и объединение дублей. Проверьте, что история и ограничения остаются у правильной записи.
Смена Contact Key в уже работающем проекте требует отдельного плана миграции. Не рассчитывайте, что новая загрузка под другим ключом автоматически перенесёт старую историю. Сначала выясните поведение используемых каналов и коннекторов, оцените дубли и проверьте запреты коммуникаций.
Результат работы — паспорт ключа: какую сущность он представляет, где создаётся, формат, правила сопоставления, изменения и проверки. Его включают в требования к каждой новой интеграции. Тогда расширение CRM не начинается с нового, несовместимого способа нумерации тех же клиентов.
Источники
1. Salesforce. Contact Model Relationships & Data Model. Salesforce Trailhead. Проверено 23.09.2026.
2. Salesforce. Subscriber Key in Marketing Cloud Engagement. Salesforce Help. Проверено 23.09.2026.