Reverse-ETL ломается не в синке, а в грязной семантике полей и identity

Reverse-ETL ломается не в синке, а в грязной семантике полей и identity

Reverse-ETL нужен не для «залить сегмент в CRM», а для активации уже нормализованных данных. Если в DWH у вас customer_id, user_id и email живут как три разных сущности без моста, дальше начинается ад: дубли в CRM, лишние триггеры, кривые аудитории и ручная чистка перед каждым запуском.

Перед запуском проверьте три вещи:
— есть ли один source of truth для профиля и событий;
— стабильно ли маппится identity между web, app, CRM и order data;
— не тащите ли вы в активацию сырые поля, которые меняются от источника к источнику.
Если поле не переживает merge/dedup, его нельзя использовать как условие для отправки.

Самая частая ошибка — слать всё подряд в маркетинговые инструменты без правил приоритета. Правильнее сначала описать: какие поля могут перезаписывать друг друга, какие только дополняют профиль, а какие вообще не должны покидать warehouse. Иначе reverse-ETL превращается в автоматизированный хаос с красивым логом синка.

Хороший тест: если маркетолог не может объяснить, почему этот юзер попал в сегмент, значит схема активации ещё не готова. Сначала identity, потом дедуп, потом маппинг полей — только после этого reverse-ETL начинает экономить время, а не создавать новые инциденты.