<b>Customer data разваливается не в CRM, а раньше — на этапе сбора и склейки событий</b>

<b>Customer data разваливается не в CRM, а раньше — на этапе сбора и склейки событий</b>

Если у вас в заказе один email, в подписке другой, а в оплате третий идентификатор — дальше ломается всё: сегменты, триггеры, LTV и атрибуция. Customer data живёт только тогда, когда у каждого события есть понятный owner, стабильный user_id и единая логика identity resolution.

Проверьте базовый набор:
— event_name без зоопарка из клонов;
— обязательные свойства у заказа, лида, возврата;
— один источник истины для контакта и статуса;
— отдельные поля для анонимного и известного пользователя;
— запрет на “магические” ручные правки в CRM без логирования.

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

Если хотите, чтобы customer data работали на activation, а не на красивые дашборды, начните с инвентаря событий и таблицы соответствия идентификаторов. Пока этого нет, любая CDP будет просто дорогим почтовым ящиком.