Tableau Semantics: cómo preparar tus datos para Tableau Next

Para que Tableau Next funcione, tus datos tienen que pasar por tres pasos antes de que un agente responda: llegar a Data 360 (por ingesta o federación zero copy), quedar limpios y relacionados como objetos, y recibir significado de negocio en un modelo semántico de Tableau Semantics con métricas, relaciones y descripciones. El tercer paso es el que decide si Concierge responde bien o mal, y es donde la mayoría de las implementaciones se atoran. Salesforce lo dice con claridad: Tableau Semantics es la capa semántica integrada en Data 360 que da a Tableau Next y a Agentforce un entendimiento unificado del negocio, y los agentes dependen de ella, según la página oficial de Tableau Next consultada en octubre de 2026.

En EGOS BI llevamos más de 10 años modelando datos para Tableau en México y más de 40 arquitecturas sobre Snowflake. Esta es la guía práctica que seguimos para preparar datos antes de activar agentes, con lo que ha cambiado con Data Pro y Semantics AI.

¿Qué es Tableau Semantics y por qué los agentes dependen de ella?

Tableau Semantics es una capa semántica con IA que vive en Data 360. Un modelo semántico agrupa objetos de Data 360, sus relaciones, cálculos y metadatos, y ofrece un almacén de métricas con definiciones gobernadas que se reutilizan en dashboards, en Slack, en Agentforce y en Tableau Cloud o Server conectados a Semantics, según la página oficial de Tableau Next.

La razón por la que los agentes dependen de ella es simple: cuando preguntas “¿cuál es el margen por tienda este mes?”, Concierge no consulta columnas crudas; busca el concepto “margen”, la dimensión “tienda” y el periodo definido en el modelo. Si “margen” existe tres veces con fórmulas distintas, o no existe, la respuesta es inconsistente o vaga. Inspector solo puede vigilar métricas definidas. Data Pro solo puede crear cálculos sobre objetos relacionados. Lo desarrollamos a fondo en qué es una capa semántica y por qué la IA no funciona sin ella.

Hay otra consecuencia práctica: el modelo semántico es compartido. Lo que construyas para Tableau Next sirve a Tableau Cloud, así que el esfuerzo se amortiza en toda la plataforma.

Paso 1: ¿Cómo llevas los datos a Data 360?

Data 360 es la capa de datos de Tableau Next y soporta los mismos conectores que el resto de Salesforce. Las opciones, de menor a mayor esfuerzo:

Opción	Cuándo usarla	Qué implica
Federación zero copy	Ya tienes Snowflake, BigQuery, Databricks o Redshift como plataforma central	Data 360 consulta tu lakehouse en vivo sin copiar datos; opcionalmente cachea para bajar latencia, con costo
Conector nativo de Salesforce	Datos de Sales, Service, Marketing o Industries	Objetos del CRM disponibles de origen; apps prearmadas de Tableau Next sobre ellos
Ingesta por lotes o streaming	Fuentes sin zero copy: PostgreSQL, MySQL, archivos, APIs	Los datos se copian a Data 360 y consumen almacenamiento
CSV y Excel ad hoc	Análisis puntuales, catálogos, presupuestos	Carga directa desde la experiencia de autor

Fuentes: página oficial de Tableau Next y arquitectura de referencia Data 360 y Snowflake, consultadas en octubre de 2026. SQL Server aparece como conector planeado, no disponible, así que si tu ERP vive ahí, hoy el camino es Snowflake en medio.

Para la mayoría de nuestros clientes en México la recomendación es la primera fila: centralizar primero en Snowflake y federar a Data 360 con zero copy. Tres razones. Snowflake ya es el repositorio donde cruzas punto de venta, ERP, e-commerce y lealtad, como en nuestro caso de centralización de más de diez fuentes en retail de moda. El zero copy evita duplicar almacenamiento y créditos de Data 360. Y la limpieza pesada se hace en Snowflake con herramientas maduras, en lugar de repetirla en cada destino.

Si todavía no tienes una plataforma central, el orden correcto es construirla antes de Tableau Next. Lo explicamos en arquitectura de datos moderna.

Paso 2: ¿Qué hay que limpiar antes de modelar?

La limpieza que importa para agentes es distinta de la que importa para un dashboard. Un analista tolera un campo mal nombrado porque sabe qué es; un agente no. Esta es la lista que revisamos en cada piloto:

1. Una fila por entidad, con llave única. Clientes duplicados por acento o espacio (“Mónica” y “Monica”) rompen las relaciones. Data 360 tiene resolución de identidad, pero conviene llegar limpio.
2. Nombres de campos en lenguaje de negocio. vta_neta_mxn debe ser “Venta neta (MXN)” en el modelo, con descripción. Data Pro y el generador de descripciones ayudan, pero el analista valida.
3. Fechas y zonas horarias consistentes. Ventas en hora local de tienda contra pedidos en UTC generan comparaciones falsas al cierre del día.
4. Monedas explícitas. Pesos y dólares en la misma métrica sin campo de moneda es el error más común que vemos en empresas que operan en México y Estados Unidos.
5. Jerarquías cerradas. Tienda pertenece a zona, zona a región, región a país, sin huérfanos. Inspector vigila por nivel de jerarquía.
6. Catálogos de SKU vigentes. Productos descontinuados sin marcar inflan los quiebres de stock y confunden al agente. Lo cubrimos en cómo analizar un catálogo de miles de SKU.
7. Permisos por fila definidos en origen. Qué gerente ve qué tienda se decide en Data 360 y el modelo semántico lo hereda; no se parcha en el dashboard.

Esta limpieza se hace en Snowflake (o en el origen) y se documenta. Es el 60 % del tiempo de un piloto bien hecho.

Paso 3: ¿Cómo se construye el modelo semántico con Data Pro?

Con los objetos limpios en Data 360, el modelo semántico se arma en el editor de Tableau Semantics. Con Semantics AI habilitado por el administrador, el flujo que seguimos es:

1. Seleccionar los objetos del dominio. Clientes, pedidos, líneas de pedido, productos, tiendas, lealtad. Uno o dos dominios por modelo; no todo el negocio en un solo modelo.
2. Dejar que Data Pro sugiera relaciones. La función Semantic Model Curation propone las llaves entre objetos. El analista acepta, corrige o rechaza.
3. Definir métricas una sola vez. Venta neta, margen, ticket promedio, cobertura de inventario, con su fórmula y su periodo por defecto. Data Pro crea campos calculados a partir de una instrucción en español; el analista revisa la fórmula.
4. Escribir descripciones. El generador de descripciones (beta) propone textos por entidad; se editan antes de guardar. Estas descripciones son lo que Concierge usa para entender tus términos.
5. Correr la optimización del modelo. Semantic Model AI Optimization (beta) marca problemas con soluciones guiadas.
6. Calibrar preguntas. Q&A Calibration (beta) permite probar preguntas reales de usuarios y ajustar las respuestas antes de abrir el agente a toda la empresa.

Los nombres y el estatus beta de cada función vienen de la guía de configuración de Tableau Next, paso 4, consultada en octubre de 2026. La creación automática completa de modelos semánticos también estaba en beta en la versión 2026.2, así que la usamos como borrador, nunca como producto final.

¿Qué errores vemos al modelar para agentes?

• Modelar todo el negocio en un solo modelo semántico. Las respuestas se vuelven lentas y ambiguas. Un modelo por dominio con métricas compartidas funciona mejor.
• Dejar métricas duplicadas entre Tableau Cloud y Next. Si “venta neta” se define en una fuente publicada de Cloud y otra vez en Semantics, los agentes de una y los tableros de la otra dan números distintos. Una sola definición, en Semantics, consumida por ambos.
• No definir el periodo por defecto. “¿Cómo van las ventas?” sin periodo da una respuesta inútil. Cada métrica necesita su comparación natural: mes contra mes anterior, semana contra misma semana del año pasado.
• Describir en inglés para usuarios que preguntan en español. Las descripciones y sinónimos deben estar en el idioma en que la gente pregunta. “Ventas”, “venta”, “facturación” e “ingresos” tienen que resolver al mismo concepto.
• Saltarse la calibración. Abrir Concierge a 500 usuarios sin probar 50 preguntas reales primero garantiza una mala primera impresión, y la adopción no se recupera fácil.

¿Cuánto tarda y quién lo hace?

En un piloto de Tableau Next de 4 a 6 semanas, la preparación de datos y el modelo semántico ocupan de 3 a 4. Un dominio bien acotado (ventas por tienda, pipeline comercial, casos de servicio) con fuentes ya en Snowflake se modela en dos semanas; si hay que ingerir desde el origen y limpiar, el doble.

Quien lo hace importa tanto como el método. Nuestros consultores están certificados en Tableau, Snowflake y Data 360, trabajan en español desde Monterrey y, cuando el equipo interno es pequeño, una célula de trabajo se queda administrando el modelo semántico: nuevas métricas, cambios de catálogo, permisos y calibración continua. Porque un modelo semántico no se termina; se mantiene. Toda la práctica de Tableau está en nuestra página de partner.

Siguiente paso

Lleva a la discovery call el diagrama (aunque sea a mano) de dónde viven hoy tus datos de ventas, inventario o clientes, las cinco métricas que más se discuten en tus juntas y sus fórmulas actuales si existen por escrito. Con eso te decimos qué dominio modelar primero, si conviene zero copy desde Snowflake o ingesta, y cuánto tarda tener a Concierge respondiendo bien. Agenda la sesión aquí.