Reverse ETL es el patrón de mover datos fuera de tu data warehouse hacia herramientas operativas como CRM, plataformas de ads y sales engagement. Es el inverso del ETL tradicional, que mueve datos hacia el warehouse para análisis. Reverse ETL es lo que hace usable al warehouse como sistema de registro para la motion go-to-market.
Por qué existe
Durante la mayor parte de la historia de la analítica, el warehouse era un callejón sin salida. Los data engineers cargaban comportamiento de cliente, uso de producto y revenue en Snowflake o BigQuery, los analistas construían dashboards, y las herramientas operativas (Salesforce, HubSpot, Marketo) vivían en un mundo separado. Cuando marketing quería “usuarios que iniciaron sesión tres veces la semana pasada”, alguien tenía que escribir una integración custom o esperar un CSV.
Reverse ETL cierra ese loop. Herramientas como Hightouch, Census y Polytomic te permiten escribir SQL una vez contra el warehouse, definir un sync hacia un destino y hacer que los datos aparezcan como campos en Salesforce o audiencias en Facebook en minutos.
Cuándo importa
Reverse ETL es el patrón correcto cuando tres condiciones se cumplen: los datos sobre los que quieres actuar ya viven en el warehouse y son difíciles de recomputar en otro lado; la herramienta destino tiene una API usable o conector nativo; y el equipo que opera los syncs es lo suficientemente alfabetizado en data como para ser dueño de los modelos SQL.
Los casos de uso clásicos son product-qualified leads (sincronizar señales de uso de producto al CRM como lead scores), targeting de audiencias (empujar segmentos del warehouse a plataformas de ads), y customer health (sincronizar datos de soporte, billing y producto al tooling de CSM).
Qué reemplaza
Reverse ETL compite con tres patrones más viejos: integraciones de API hechas a mano (lentas, frágiles), iPaaS como Zapier y Workato (buenas para workflows simples, caras a escala), y CDPs empaquetados (más opinionados, menos flexibles). El patrón de CDP componible es esencialmente reverse ETL más un modelo de identidad.
Errores comunes
- Sincronizar el grain incorrecto. Empujar cada evento de producto a Salesforce lo destruirá. Agrega al grain correcto (cuenta-semana, usuario-día) antes de sincronizar.
- Dejar que los modelos se desvíen. Un sync de reverse-ETL depende de un modelo dbt upstream. Cuando el modelo cambia, el destino se rompe en silencio. Agrega tests y ownership.
- Activar antes del consentimiento. Reverse ETL respeta cualquier consentimiento que el warehouse conozca. Si el consentimiento no está modelado en el warehouse, estás empujando datos no compliant.
Relacionados
- Data warehouse vs CDP — la elección de arquitectura
- CDP — el patrón alternativo
- RevOps tech stack — dónde encaja reverse ETL