Как устроить единый профиль для нескольких брендов

У группы компаний несколько брендов, и одни люди покупают у разных магазинов. Кажется естественным собрать единую клиентскую базу: меньше дублей, полнее история, удобнее аналитика. Но единый профиль легко превращается в общее поле, где бренд B видит сведения бренда A и использует чужое разрешение на рассылку.

Здесь нужно разделить узнавание человека и отношения с отдельным брендом. Первое отвечает на вопрос «это тот же клиент?». Второе описывает покупки, настройки, разрешения и доступы в конкретном контексте.

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

Выделите общую и брендовую части

В общей части могут храниться постоянный ID, связи с подтверждёнными аккаунтами и минимальный набор согласованных атрибутов. В брендовой — локальный ID, история отношений, интересы, программа лояльности и настройки коммуникаций.

Один клиент при этом может быть активным покупателем бренда A и новым посетителем бренда B. Если записать общий статус «лояльный» без указания контекста, welcome-программа второго бренда получит неверные условия.

Не используйте одно поле согласия

Поле marketing_allowed = true не объясняет, кому, куда и о чём можно писать. Техническая запись должна хранить принятую область действия: бренд или отправитель, канал, назначение, контакт, основание и актуальное состояние.

Запрет тоже имеет область. Отказ от SMS одного бренда и отказ от всех сообщений группы могут требовать разных действий. Интерфейс предпочтений должен передавать именно выбранный клиентом смысл, а интеграции — сохранять его без расширения.

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

Ограничьте доступ на уровне данных и выгрузки

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

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

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

Разделите общую аналитику и маркетинговое действие

Руководству может быть нужен агрегированный отчёт о пересечении покупателей, а маркетологу — аудитория конкретной акции. Это разные задачи с разным объёмом необходимых данных и прав.

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

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

Условный пример двух магазинов

Один клиент покупает спортивную одежду у бренда A и товары для дома у бренда B. Его аккаунты подтверждённо связаны общим ID. У A разрешён email, у B клиент отказался от рекламы.

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

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

Проверьте общие ограничения между брендами

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

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

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

Проверьте модель через запреты

На тестовом клиенте создайте разные разрешения для брендов, смените контакт и отзовите одно из разрешений. Попробуйте получить запрещённое поле через интерфейс, выгрузку, API и рассчитанный сегмент. Проверьте, какой отказ фиксируется и кто его увидит.

Затем проверьте независимые изменения: отписка в B не должна случайно удалить допустимые настройки A, если выбранный клиентом отказ не был общим. Обратное правило тоже важно: общий отказ обязан распространиться на все предусмотренные каналы и бренды.

Результатом должна стать схема общего профиля, таблица областей действия и проверенные права доступа. Она позволяет объединять данные ровно настолько, насколько это нужно и допустимо для конкретных процессов.

Источники

Adobe. Attribute-Based Access Control Overview. Adobe Experience Platform. Разделы Permissions, Destinations и Profile. Проверено 22.09.2026.