Reverse-ETL ломается не в коннекторе, а в схеме данных и дедупликации

Reverse-ETL ломается не в коннекторе, а в схеме данных и дедупликации

Reverse-ETL нужен не для «залить сегменты в CRM», а чтобы вывести в активацию уже нормализованные customer-данные: кого можно таргетировать, кому писать, кого исключать. Если в warehouse лежат дубли профилей, разъехавшиеся ключи и сырые события без правил, любой Hightouch или RudderStack будет просто ускорять хаос.

Перед запуском проверь 4 вещи:
— единый ключ личности: user_id, email, phone, но с понятным приоритетом;
— таблицу consent/opt-out, чтобы не лить в каналы тех, кто отписался;
— бизнес-правила свежести: что считать актуальным статусом, а что уже мусор;
— idempotency: одна и та же запись не должна переехать в CRM дважды из-за повторной синхронизации.

Самая частая ошибка — отправлять в activation не готовую витрину, а сырые джойны из staging. Тогда маркетинг видит «живых» клиентов, которых уже удалили, закрыли или объединили в другой профиль. Вторая ошибка — тащить в CRM все поля подряд. Чем больше атрибутов без владельца, тем быстрее ломается интерфейс, маппинг и логика сегментов.

Хороший reverse-ETL начинается с вопроса: какое действие должен совершить downstream-сервис, и какое поле для этого действительно нужно. Всё остальное — лишняя нагрузка и будущий инцидент.