En este paso llevas el dato de todos los sistemas a un warehouse (ETL) y devuelves lo calculado —segmentos, LTV, scoring— a las herramientas donde el equipo trabaja (Reverse ETL). El dato deja de solo "estar" y empieza a producir. Y no: no toda empresa necesita esto hoy. Empecemos por ahí.

¿Necesitas un warehouse? La prueba rápida

Un data warehouse (BigQuery, Snowflake, Redshift) se justifica cuando aparecen estas señales:

• Un reporte necesita 3 o más fuentes. El CAC real mezcla pauta, CRM y ERP; el LTV mezcla pedidos, facturación y soporte. Cruzar eso en planillas es artesanía; en un warehouse, una consulta.
• El BI le pega directo a producción. Si el dashboard del gerente hace lenta la tienda o el ERP, ya es hora de separar la lectura analítica de la operación.
• Cada área reporta un número distinto. Tres definiciones de "venta del mes" es un problema de gobernanza que el warehouse ayuda a centralizar.

Si tus reportes salen completos de un solo sistema, todavía no lo necesitas: no montes infraestructura por moda. Cuando sí, BigQuery es el punto de entrada más amable para presupuestos LATAM: sin servidores que administrar y con un nivel gratuito que aguanta a la mayoría de las empresas medianas durante meses.

ETL: del sistema al warehouse

Extraer, cargar y transformar. La versión moderna es ELT: cargas el dato crudo con conectores administrados (Fivetran, Airbyte, Stitch) y transformas dentro del warehouse con SQL versionado (dbt es el estándar de facto). ¿Frecuencia? Un lote nocturno le sobra al 90% del BI. El streaming en tiempo real cuesta caro en dinero y mantenimiento: reservalo para cuando un caso de negocio lo pida con nombre y apellido.

La regla que evita el caos: cada métrica tiene una definición única, escrita en el código de transformación. "Venta neta" se calcula en un solo lugar y todos los dashboards beben de ahí. Si la definición vive en cinco planillas, el warehouse solo va a centralizar la discusión.

Reverse ETL: del warehouse a la operación

Aquí está la parte que la mayoría se salta, y es la que paga el proyecto. Un score de propensión guardado en una tabla no vende nada. Vende cuando vuelve a las manos del equipo:

• Al CRM: el LTV y el segmento RFM como propiedades en HubSpot, para que ventas priorice a quién llamar hoy.
• Al CDP: audiencias calculadas (por ejemplo "alta propensión a recompra") activables en journeys omnicanal; si usas Insider, la guía de implementación de Insider muestra ese circuito completo.
• A la pauta: audiencias de mejores clientes para lookalikes en Meta y Google, en vez de segmentar a ojo.

Un ejemplo que repetimos seguido: un ecommerce calcula RFM en BigQuery cada noche y lo sube como propiedad a HubSpot. El equipo comercial deja de perseguir la lista entera y llama primero a los "campeones dormidos". Mismo equipo, mismo dato, otro resultado. Herramientas: Hightouch o Census si quieres velocidad; un job programado a medida si el volumen es simple y ya tienes middleware del paso 2.

Un dashboard no llama a nadie. El dato produce cuando vuelve al CRM, al CDP o a la pauta: adonde alguien puede actuar hoy.

Reglas para no crear un segundo desorden

El warehouse es la verdad derivada (métricas, agregados, scores); los sistemas operativos siguen siendo la verdad operativa según lo que definiste en el paso 3. El Reverse ETL escribe campos calculados nuevos, nunca pisa los campos que un sistema operativo posee. Y documenta el linaje: de qué fuentes sale cada métrica y por qué transformación pasó. Cuando un número se vea raro —y va a pasar—, el linaje es la diferencia entre 10 minutos y una semana de arqueología.

Errores comunes en este paso

• Montar warehouse sin caso de uso. Infraestructura sin pregunta de negocio es un costo mensual con logo bonito.
• Streaming porque suena pro. Si nadie actúa en menos de una hora sobre ese dato, el lote nocturno era la respuesta.
• Reverse ETL pisando campos operativos. El score puede convivir con el teléfono del cliente; no puede sobrescribirlo.
• Métricas sin definición única. Tres "revenues" distintos en tres dashboards destruyen la confianza más rápido de lo que el warehouse la construyó.

Checklist antes de pasar al siguiente

• Caso de uso concreto que justifica (o pospone) el warehouse, por escrito.
• Pipeline ETL corriendo con la frecuencia acordada y conectores administrados.
• Métricas clave con definición única versionada en la capa de transformación.
• Primer Reverse ETL activo: al menos un segmento o score visible en el CRM o CDP.
• Linaje documentado: cada métrica sabe de dónde viene.

Ya tienes el dato fluyendo en las dos direcciones. Ahora hay que hacerlo indestructible: paso 6, errores, colas y reintentos. El índice completo está en la guía de integración de datos.