Reverse-ETL ломается не в коннекторе, а в схеме и матчингe ключей

Reverse-ETL ломается не в коннекторе, а в схеме и матчингe ключей

Reverse-ETL — это не «залить сегменты в CRM», а поддерживать согласованность между warehouse и системами активации. Если в DWH нет стабильного customer_id, нормального source_of_truth и понятного приоритета полей, то Hightouch, Census или любой другой слой доставки просто ускоряет разнос мусора по CRM, email и ads.

Перед запуском проверьте три вещи:
— есть ли единый ключ для join: user_id, account_id, email — но не «всё сразу» без правил;
— определены ли владельцы полей: кто пишет revenue, consent, lifecycle stage;
— есть ли флаги качества: свежесть, null-rate, дубль, конфликт источников.

Самая дорогая ошибка — отправлять в activation сырые витрины. Тогда маркетинг начинает триггерить не на поведение, а на артефакты ETL: дубли, просроченные статусы, неверные сегменты. Вторая ошибка — строить логику на нестабильных полях вроде last_touch или last_seen без SLA на обновление. Третья — не логировать, что именно ушло в downstream: потом невозможно понять, почему CRM «само» поменяло сегмент.

Нормальный reverse-ETL начинается с data contract: какие поля обязательны, какие nullable, как часто обновляются, что делать при конфликте значений. Если этот контракт не описан, то интеграция превращается в ручную синхронизацию багов.

Сначала зафиксируйте ключи и правила приоритета, потом включайте активацию. Иначе вы автоматизируете хаос, а не customer data.