<b>Reverse ETL ломается не в коннекторе, а в схеме: 5 ошибок, которые убивают активацию</b>

<b>Reverse ETL ломается не в коннекторе, а в схеме: 5 ошибок, которые убивают активацию</b>

Reverse ETL нужен не для «залить сегмент в CRM», а чтобы полезные поля из DWH стали рабочими атрибутами в ad platforms, email, helpdesk и CDP. Если схема кривая, вы отправляете мусор быстрее, чем он успевает попасть в интерфейс.

— Нет единого ключа на сущность. Email, phone и external_id живут отдельно, поэтому один клиент размножается на три записи.
— Нет правил на null и пустые значения. В итоге сегмент «активные» внезапно перетирается пустым флагом.
— Сырые события едут в activation без нормализации. Форматы дат, валют, стран и статусов должны быть одинаковыми до выгрузки.
— Нет watermark и дедупликации. Одно и то же обновление улетает несколько раз, а downstream начинает сам себя переобувать.

Отдельная боль — маппинг полей под каждую систему. В CRM можно обновлять только stable attributes: статус, LTV bucket, lifecycle stage. В рекламу лучше лить агрегаты и сегменты, а не весь профиль. В саппорт — только то, что помогает оператору, иначе вы превращаете реверс-ETL в склад личных данных.

Хороший тест: если поле нельзя объяснить за 10 секунд пользователю downstream-команды, его не надо активировать. Сначала чистая модель данных, потом маршрутизация.