Customer data ломается не в CDP, а в момент, когда команды называют одно и то же разными именами

Customer data ломается не в CDP, а в момент, когда команды называют одно и то же разными именами

Если в CRM есть user_id, в продукте account_id, а в рассылке — email без устойчивого ключа, дальше начинается ручная склейка. CDP тут не магия: она просто хранит и активирует то, что уже приведено к одной модели. Без общей схемы у тебя будут дубли, кривые сегменты и атрибуция, которая спорит сама с собой.

Базовый набор сущностей обычно такой:
— person / user: человек как субъект;
— account / household / company: если у тебя B2B или семейные покупки;
— event: действие с временем и контекстом;
— identity graph: связи между email, phone, device_id, crm_id.

Самая дорогая ошибка — смешивать идентификаторы в одном поле. Если в event иногда лежит email, а иногда internal_id, ты не сможешь нормально строить retention, frequency cap и аудитории для reverse-ETL. Лучше хранить сырые ключи отдельно, а в activation отдавать уже нормализованный primary key.

Еще одна боль — отсутствие правил для событий. Для каждого event заранее фиксируй: обязательные свойства, типы данных, источник, допустимые значения. Иначе через три месяца у тебя purchase начнет приходить то как число, то как строка, а revenue в BI придется чинить скриптами.

Если хочешь, чтобы customer data работали годами, делай не “сбор всего подряд”, а короткий контракт: какие сущности есть, как они матчятся и какие поля разрешено использовать в сегментах. Тогда CDP перестает быть складом мусора и становится рабочим слоем активации.