Você construiu um produto SaaS e o cliente quer ver os próprios números lá dentro — não em outra ferramenta, atrás de outro login. O Metabase resolve isso com embedding, mas "embarcar um dashboard" esconde três modos bem diferentes e uma pergunta que decide tudo: como garantir que cada cliente veja estritamente os seus dados.
Por que embarcar o analytics no produto
Mandar o cliente para uma ferramenta separada custa contexto, login e adoção. Analytics embarcado — dashboards dentro da sua própria interface, com a sua marca — vira parte do produto: o dado aparece onde a decisão acontece. A questão nunca é se, é como — e o "como" no Metabase tem três formas.
Os três modos de embedding do Metabase
- Static embedding (assinado) — um iframe com um token JWT assinado no servidor. Os parâmetros (ex.: o identificador do cliente) vão travados dentro do token; o usuário não interage nem os altera. Ideal para um painel fixo por cliente. Disponível no open source.
- Interactive embedding — o Metabase completo embarcado, com login via SSO (JWT), onde o cliente explora e cria as próprias perguntas. Exige Pro/Enterprise e combina com data sandboxing.
- SDK de analytics embarcado (React) — componentes do Metabase dentro da sua aplicação, com controle fino de layout e tema. Recurso Enterprise.
O problema que decide tudo: isolamento multi-tenant
Em um produto multi-tenant, o pior erro possível é um cliente ver o dado de outro. O isolamento seguro depende do modo:
- Static embedding — o tenant vai como parâmetro travado (locked) dentro do JWT assinado no seu backend. Como o token é assinado com um segredo do servidor, o cliente não tem como forjar outro identificador. É o caminho de isolamento no open source.
- Interactive embedding + data sandboxing — o filtro por linha é aplicado automaticamente conforme o usuário do JWT, mesmo que ele explore livremente. É o isolamento mais forte para exploração aberta — e é Enterprise.
- OSS sem sandboxing — quando precisa de exploração no open source, a rota é separar o dado por conexão/schema por tenant (a mesma arquitetura do nosso artigo de governança no Metabase OSS).
O que nunca fazer
- Passar o
tenant_idem um parâmetro de URL editável — o cliente troca o número e vê o vizinho. - Embarcar sem assinatura (embed público) achando que "ninguém vai adivinhar a URL".
- Confiar no front-end para filtrar — o filtro tem que viver no token assinado ou no banco, nunca no JavaScript.
Escolhendo o modo certo
Regra prática: se o cliente só precisa ver um painel por tenant, static embedding assinado resolve — e roda no open source. Se ele precisa explorar e criar perguntas com isolamento por linha, é interactive embedding + data sandboxing (Enterprise). Se a exploração é necessária mas o orçamento é OSS, separe o dado por tenant na arquitetura. O erro é escolher pelo brilho da demo, não pelo requisito real de isolamento.
Perguntas frequentes
Dá para fazer embedding multi-tenant seguro no Metabase open source?
Sim, para painéis fixos por cliente: o static embedding usa um JWT assinado no seu servidor com o identificador do tenant travado como parâmetro. O cliente não consegue forjar outro. Para exploração aberta com isolamento por linha automático, aí sim é preciso o data sandboxing do Pro/Enterprise — ou separar o dado por conexão/schema por tenant no open source.
O cliente consegue burlar o filtro e ver dados de outro tenant?
Não, se o identificador do tenant estiver como parâmetro travado dentro do token assinado (ou aplicado por data sandboxing). Como a assinatura é feita com um segredo do servidor, alterar o token invalida o embed. O vazamento só acontece quando o filtro é passado por URL editável ou aplicado só no front-end — exatamente o que a arquitetura correta evita.