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

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

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

Проверьте 4 вещи до запуска:
— единый ключ идентичности: user_id, email, phone — но один главный, остальные как fallback;
— правила дедупликации: что делать с несколькими событиями, несколькими лидами и merged-профилями;
— freshness SLA: какие поля можно отправлять раз в час, а какие должны обновляться почти сразу;
— идемпотентность: повторная отправка не должна создавать новый лид, сделку или подписку.

Самая частая ошибка — слать в downstream сырые события вместо готовых атрибутов. CRM не любит event-stream, ей нужен понятный профиль: стадия, флаг, сумма, сегмент, причина отказа. Для ads-активации наоборот важны стабильные аудитории и предсказуемый refresh, иначе вы каждый раз обучаете алгоритм на новой каше.

Еще один грабль — маппинг полей без владельца. Пока никто не отвечает за соответствие «source → target», через пару месяцев в одной системе будет last_purchase, в другой last_order_date, а в третьей пусто. Назначайте владельца на каждый критичный атрибут и логируйте ошибки доставки, а не только успехи.

Начинайте reverse-ETL не с «куда лить», а с одного сценария, где есть понятный выигрыш: триггер в CRM, suppression list, возврат неактивных, handoff в саппорт. Когда один маршрут стабилен, масштабировать проще, чем чинить пять полуразобранных.