<b>CDP ломается не на интеграции, а на грязной схеме событий и identity</b>

<b>CDP ломается не на интеграции, а на грязной схеме событий и identity</b>

CDP почти всегда продают как «единый профиль клиента», но на практике там три узких места: ingestion, склейка identity и активация. Если в событии нет стабильного user_id, а device_id живёт отдельно, профиль распадается при первом же входе с другого устройства. Если названия событий гуляют, downstream-автоматизация начинает стрелять мимо сегментов.

Перед внедрением проверьте три вещи:
• кто владелец каждой сущности: user, account, anonymous, order
• какие идентификаторы обязательны в web, app, backend
• какие события можно слать только после валидации схемы

Вторая частая ошибка — тащить в CDP всё подряд. Лишние свойства, дубликаты и «пока пригодится» поля быстро убивают качество сегментов. Лучше 20 стабильных атрибутов, чем 200 мусорных. Иначе reverse-ETL начнёт залипать на пустых значениях, а CRM-команды будут чистить рассылки руками.

Третья зона боли — активация. Если сегмент строится на сырых событиях, а не на нормализованных сущностях, маркетинг получает разные списки в email, push и ads. Делайте один слой truth для ключевых полей: email, phone, consent, LTV, last_order_at. Всё остальное — вторично.

CDP полезна только там, где есть дисциплина по схеме и владельцам данных. Нет схемы — будет дорогой транспорт для хаоса.