Construiste un producto SaaS y el cliente quiere ver sus propios números allí dentro — no en otra herramienta, detrás de otro login. Metabase resuelve esto con embedding, pero "embeber un dashboard" esconde tres modos bien diferentes y una pregunta que lo decide todo: cómo garantizar que cada cliente vea estrictamente sus datos.
Por qué embeber el analytics en el producto
Enviar al cliente a una herramienta separada cuesta contexto, login y adopción. Analytics embebido — dashboards dentro de tu propia interfaz, con tu marca — se vuelve parte del producto: el dato aparece donde ocurre la decisión. La cuestión nunca es si, es cómo — y el "cómo" en Metabase tiene tres formas.
Los tres modos de embedding de Metabase
- Static embedding (firmado) — un iframe con un token JWT firmado en el servidor. Los parámetros (ej.: el identificador del cliente) van bloqueados dentro del token; el usuario no interactúa ni los altera. Ideal para un panel fijo por cliente. Disponible en el open source.
- Interactive embedding — el Metabase completo embebido, con login vía SSO (JWT), donde el cliente explora y crea sus propias preguntas. Requiere Pro/Enterprise y combina con data sandboxing.
- SDK de analytics embebido (React) — componentes de Metabase dentro de tu aplicación, con control fino de layout y tema. Recurso Enterprise.
El problema que lo decide todo: aislamiento multi-tenant
En un producto multi-tenant, el peor error posible es que un cliente vea los datos de otro. El aislamiento seguro depende del modo:
- Static embedding — el tenant va como parámetro bloqueado (locked) dentro del JWT firmado en tu backend. Como el token está firmado con un secreto del servidor, el cliente no tiene forma de falsificar otro identificador. Es el camino de aislamiento en el open source.
- Interactive embedding + data sandboxing — el filtro por fila se aplica automáticamente según el usuario del JWT, incluso si explora libremente. Es el aislamiento más fuerte para exploración abierta — y es Enterprise.
- OSS sin sandboxing — cuando necesitas exploración en el open source, la ruta es separar el dato por conexión/schema por tenant (la misma arquitectura de nuestro artículo de gobernanza en Metabase OSS).
Lo que nunca hay que hacer
- Pasar el
tenant_iden un parámetro de URL editable — el cliente cambia el número y ve al vecino. - Embeber sin firma (embed público) creyendo que "nadie va a adivinar la URL".
- Confiar en el front-end para filtrar — el filtro tiene que vivir en el token firmado o en la base de datos, nunca en el JavaScript.
Eligiendo el modo correcto
Regla práctica: si el cliente solo necesita ver un panel por tenant, static embedding firmado lo resuelve — y corre en el open source. Si necesita explorar y crear preguntas con aislamiento por fila, es interactive embedding + data sandboxing (Enterprise). Si la exploración es necesaria pero el presupuesto es OSS, separa el dato por tenant en la arquitectura. El error es elegir por el brillo de la demo, no por el requisito real de aislamiento.
Preguntas frecuentes
¿Se puede hacer embedding multi-tenant seguro en Metabase open source?
Sí, para paneles fijos por cliente: el static embedding usa un JWT firmado en tu servidor con el identificador del tenant bloqueado como parámetro. El cliente no puede falsificar otro. Para exploración abierta con aislamiento por fila automático, ahí sí se necesita el data sandboxing de Pro/Enterprise — o separar el dato por conexión/schema por tenant en el open source.
¿Puede el cliente burlar el filtro y ver datos de otro tenant?
No, si el identificador del tenant está como parámetro bloqueado dentro del token firmado (o aplicado por data sandboxing). Como la firma se hace con un secreto del servidor, alterar el token invalida el embed. La fuga solo ocurre cuando el filtro se pasa por URL editable o se aplica solo en el front-end — exactamente lo que la arquitectura correcta evita.