Reverse-ETL ломается не в коннекторе, а в схеме: вот 7 проверок до запуска

Reverse-ETL ломается не в коннекторе, а в схеме: вот 7 проверок до запуска

Reverse-ETL нужен, когда данные уже лежат в DWH, а команде надо отправить их в CRM, ads-кабинеты, support или продуктовые инструменты. Проблема в том, что многие начинают с «куда лить», а не с того, какие поля вообще можно безопасно активировать.

— У каждого поля должен быть owner и смысл: что это, откуда берётся, как часто обновляется.
— Нужен стабильный ключ для матчингa: email, phone, user_id, account_id — но не «что-нибудь одно».
— Сначала проверяй null-rate, дубли и формат, потом уже маппинг в destination.
— Любое вычисляемое поле должно быть воспроизводимо в SQL, а не жить только в BI-слое.

Отдельная боль — identity resolution. Если в DWH склеены разные сущности под одним человеком, reverse-ETL начнёт отправлять мусор: не тот сегмент, не та стадия, не тот оффер. Ещё хуже, когда в source лежит «последний известный статус», а downstream ожидает историю изменений.

Перед запуском сделай dry-run на 100–500 записей, сравни counts между source и destination и заведи алерт на расхождение. Если сегмент нельзя объяснить в двух предложениях, его нельзя активировать. Иначе вы просто автоматизируете ошибку, а не данные.