Reverse-ETL ломается не в коннекторе, а в схеме: вот где теряются деньги

Reverse-ETL ломается не в коннекторе, а в схеме: вот где теряются деньги

Reverse-ETL — это не «залили сегмент в CRM и поехали». Это слой, где warehouse становится источником для activation: CRM, email, ads, support. Если в DWH лежат грязные id, дубли событий и кривые статусы, downstream начинает пушить не тех людей, не в то время и не тем оффером.

Проверь три вещи до запуска:
— есть ли единый ключ для матчинга: user_id, email_hash, phone_hash;
— есть ли правило приоритета, если ключей несколько;
— определены ли поля, которые можно отправлять наружу, а какие нельзя.

Вторая типовая ошибка — слать не сущности, а сырые события. Для активации нужны стабильные объекты: customer, subscription, cart, lead. Если в reverse-ETL летит «event stream», CRM превращается в помойку из дубликатов и гонок статусов. Делай слой маппинга и дедупликации до выгрузки, а не в интерфейсе канала.

Третья ошибка — не задавать частоту и окно обновления. Одни поля должны обновляться почти сразу, другие — раз в день. Иначе ты либо давишь API лишними апдейтами, либо отправляешь в ретеншн уже неактуальные данные.

Правило простое: сначала схема и ownership полей, потом коннектор. Если upstream грязный, reverse-ETL не чинит data quality — он только размножает ошибку.