Como Criar um Relatório BI no Bitrix24 com o BI Constructor

O que é o BI Constructor do Bitrix24 (Alaio)

O BI Constructor é o módulo nativo de business intelligence do Bitrix24, construído sobre o Apache Superset (motor de consultas: Trino), que permite criar dashboards analíticos diretamente sobre os dados do CRM - sem transferir informações para sistemas externos e sem adquirir licenças adicionais.

Em funcionalidade, ele é comparável ao Google Looker Studio, mas opera dentro da infraestrutura do próprio Bitrix24. Os termos "relatório" e "dashboard" são usados como sinônimos na interface do produto: ambos referem-se a páginas com gráficos, tabelas e painéis de filtros cujos dados se atualizam automaticamente.

Por ser baseado em Apache Superset - software open-source - , você não fica dependente de um fornecedor externo que possa cortar o acesso. Se necessário, o mesmo Superset pode ser implantado em infraestrutura própria e as configurações migradas. Isso é uma vantagem relevante em comparação com ferramentas SaaS de BI de terceiros.

Há três perfis de dashboard que o BI Constructor suporta:

Para equipes que já utilizam automações avançadas, vale combinar os dashboards do BI Constructor com as ferramentas de IA no Bitrix24 para enriquecer a análise com dados de chamadas e interações automatizadas.

Pré-requisitos e acesso

Para usar o BI Constructor na versão on-premise (self-hosted) do Bitrix24, é necessário ter o módulo biconnector instalado na versão ~24.900.0 ou superior; na versão cloud, o acesso depende do plano contratado.

Pontos práticos antes de começar:

• Versão on-premise: instale ou atualize o módulo biconnector (~v24.900.0+). Consulte a documentação oficial do desenvolvedor para o procedimento de instalação.
• Primeiro uso: comece com volumes pequenos de dados (ex.: período de uma semana). Confirme estabilidade antes de ampliar o intervalo.
• Acesso via menu: navegue até o seção BI Constructor no Bitrix24. Os relatórios existentes aparecem em lista e são abertos diretamente.
• Forma mais rápida de se familiarizar: copie um relatório padrão do sistema (Menu (≡) → Editar) e modifique-o adicionando seus próprios gráficos.

Se você gerencia uma instalação self-hosted, veja também o guia de dimensionamento de hardware para Bitrix24 para garantir recursos suficientes para as consultas do Superset.

Pipeline de criação: do dado ao dashboard

O fluxo completo de construção de um relatório BI no Bitrix24 segue cinco etapas sequenciais. A progressão lógica - da pergunta de negócio até o dashboard publicado.

O pipeline começa sempre em uma pergunta de negócio concreta (ex.: "quais produtos são comprados juntos?"), passa pela definição do dataset no CRM, pela construção de gráficos em cima desse dataset, pela configuração de filtros interativos e termina na montagem final e publicação do dashboard para os usuários.

flowchart LR
    A[Pergunta de negócio] --> B[Projeto: Dashboard Canvas]
    B --> C[Dataset físico ou virtual\nSQL Lab / Trino]
    C --> D[Gráficos\ntabela, barra, linha, heatmap...]
    D --> E[Filtros\nperíodo, funil, estrutura...]
    E --> F[Montagem do layout\ndashboard finalizado]
    F --> G[Publicação / compartilhamento]

A tabela abaixo resume cada etapa com o entregável esperado:

Etapa 1 - Projetar antes de abrir a ferramenta

O erro mais comum ao criar relatórios BI é começar pelo gráfico em vez de pela pergunta - o resultado são visualizações bonitas que não geram nenhuma decisão.

A metodologia recomendada é o Dashboard Canvas: uma estrutura de planejamento que responde sequencialmente a cinco perguntas antes de abrir o BI Constructor:

1. Quem usa o dashboard? (gerente comercial, diretoria, analista de dados)
2. Que perguntas ele precisa responder? (ex.: "quais produtos são mais vendidos juntos?")
3. Quais métricas respondem essas perguntas? (frequência de combinações, valor médio por combo)
4. Quais cortes/dimensões são necessários? (período, funil, responsável, categoria de produto)
5. Qual visualização comunica melhor cada métrica? (tabela, heatmap, ranking, linha de tendência)

Princípio central: toda métrica deve levar a uma decisão. Métricas cuja variação não influencia nenhuma ação são desperdício de espaço e atenção.

Uma observação prática sobre métricas como taxa de conversão: não existe "conversão universal". Ela é sempre "de algo para algo". Calcular sobre negócios fechados (ganhos + perdidos) dá uma visão diferente de calcular sobre todos os negócios criados - e o mesmo período medido hoje e daqui a uma semana pode dar números diferentes se houver negócios ainda abertos. Essa escolha deve ser consciente e documentada no Canvas antes de qualquer linha de SQL.

Etapa 2 - Criar e configurar o dataset

No BI Constructor, todo gráfico nasce de um dataset - uma tabela com dados do Bitrix24 (negócios, leads, produtos, tarefas, chamadas, smart processes) que pode ser física (nativa do sistema) ou virtual (um SQL salvo que combina múltiplas tabelas).

Datasets físicos disponíveis "de fábrica"

Os datasets físicos padrão cobrem as principais entidades do Bitrix24. Alguns exemplos:

• crm_deal - negócios (deals)
• crm_lead - leads
• crm_deal_product_row - produtos dentro dos negócios
• Tarefas, chamadas, smart processes e campos personalizados

Todos ficam na esquema bitrix24 do Trino. Ao criar um dataset via interface, você informa: banco de dados = trino, esquema = bitrix24, tabela = nome do dataset desejado.

Datasets virtuais: SQL Lab

Para cruzar dados de múltiplas tabelas (ex.: negócios + produtos para uma análise de mix), use o SQL Lab (menu SQL → SQL Lab). Escreva e depure a query, depois salve como dataset virtual.

Boas práticas para datasets virtuais:

• Granularidade adequada: o dataset deve retornar linhas detalhadas (ex.: "combinações por dia"), não agregações pré-calculadas - deixe as agregações para o nível do Superset.
• Um dataset, no máximo dois: datasets excessivamente fragmentados dificultam a manutenção.
• Nomes de colunas claros: use AS nome_legivel na query ou renomeie na aba "Colunas" do dataset.
• Proteja as bordas: trate divisões por zero e seleções vazias já no SQL.

O SQL usado é Trino SQL - dialeto próximo ao SQL padrão, mas com particularidades (sem algumas funções do PostgreSQL; conversão de tipos via CAST()). Os dados do Bitrix24 residem em MySQL internamente, o que é relevante ao analisar planos de execução com bi_explain_query().

Etapa 3 - Montar os gráficos

Na prática, dashboards eficazes no BI Constructor se sustentam em 5 a 7 tipos de visualização que qualquer gestor lê sem preparo: tabela, gráfico de linhas, barras, cartão (KPI), pizza, heatmap e gráfico combinado com dois eixos Y.

O Superset oferece dezenas de tipos de gráfico - nuvem de palavras, treemap, "sunburst", velocímetros. Use-os apenas quando a audiência for técnica e a visualização realmente comunicar algo que os tipos básicos não conseguem. Escolha a visualização pela pergunta e pela audiência, não pela sofisticação visual.

Para cada gráfico, configure:

Cross-filtering: cada gráfico pode filtrar os demais ao ser clicado. Configure o escopo de cada ligação - nem sempre faz sentido que todos os gráficos se influenciem mutuamente.

Para clonar um gráfico com variação mínima (ex.: mesma tabela com filtro diferente), use "Salvar como novo" - é muito mais rápido que recriar do zero.

Etapa 4 - Configurar filtros

Os filtros são o que transforma um relatório estático em uma ferramenta de análise interativa - configure pelo menos um filtro de período e um de dimensão relevante (funil, responsável, categoria) para que o dashboard seja útil no dia a dia.

Tipos de filtro disponíveis no BI Constructor:

• Valor / lista de referência - produto, funil, responsável
• Período - data de criação, data de fechamento, intervalo personalizado
• Intervalo de tempo - define a janela temporal do relatório
• Unidade de tempo / agrupamento - dia, semana, mês (útil para alterar granularidade da série histórica)
• Estrutura organizacional - filtra por subordinação hierárquica (o usuário vê apenas sua equipe ou toda a estrutura conforme permissão)

Defina quais filtros se aplicam a todos os painéis e quais se aplicam apenas a painéis específicos - isso evita comportamentos inesperados em dashboards com múltiplas páginas.

Um filtro de "estrutura organizacional" adicionado a um relatório já existente amplia significativamente sua utilidade com custo mínimo de desenvolvimento - pense nisso ao revisar dashboards em produção.

A configuração de permissões por papel (quem vê, quem edita, quem administra) também é gerenciada dentro do BI Constructor. Para equipes maiores, isso se integra ao modelo de papéis e grupos do Bitrix24.

Etapa 5 - Montar e publicar o dashboard

A montagem final segue a lógica "do geral para o específico": KPIs e resumos no topo, análises detalhadas e tabelas de drill-down abaixo - o olhar do usuário percorre o dashboard de cima para baixo naturalmente.

Passos finais antes de liberar o acesso:

1. Compor o layout: arraste e redimensione os gráficos na grade do dashboard. Agrupe visualmente blocos temáticos.
2. CSS e estética: ajuste visual fica para o final - não bloqueie a lógica analítica por causa de cores.
3. Limpar dados de demonstração: se você usou dados de teste durante o desenvolvimento, remova-os antes de compartilhar.
4. Testar em dados reais: valide os números contra fontes conhecidas (ex.: total de negócios fechados no mês deve bater com o relatório padrão do CRM).
5. Configurar permissões: defina quem pode visualizar, quem pode editar e quem administra o módulo.
6. Compartilhar: o dashboard pode ser compartilhado via link direto ou disponibilizado no menu do Bitrix24 para os usuários autorizados.

Para projetos de implementação onde o BI Constructor faz parte do escopo, o questionário de discovery do Bitrix24 ajuda a levantar os requisitos analíticos já na fase de planejamento - evitando retrabalho na etapa de dataset.

Checklist antes de publicar o relatório

Use este checklist antes de liberar qualquer dashboard para usuários finais - ele cobre os pontos que mais causam retrabalho em projetos reais.

Projeto e dados

• Todas as métricas estão vinculadas a uma decisão de negócio documentada
• A definição de cada métrica é unívoca (ex.: conversão "de leads para negócios ganhos", não apenas "conversão")
• O dataset tem granularidade adequada (linhas detalhadas, não apenas agregações)
• Divisões por zero e seleções vazias estão tratadas no SQL
• Nomes de colunas são legíveis (sem field_uf_123, use AS nome_legivel)
• Período padrão do dataset está definido (comece pequeno; amplie após validação)

Gráficos e filtros

• Tipos de gráfico são compatíveis com a audiência (máx. 5-7 tipos diferentes por dashboard)
• Cada gráfico tem LIMIT configurado (no SQL e no row limit do gráfico)
• Cross-filtering está configurado apenas onde faz sentido analítico
• Há pelo menos um filtro de período e um de dimensão relevante
• Filtros com escopo "somente este painel" estão separados dos filtros globais
• Formatação de valores está correta (moeda, separador de milhar, casas decimais)

Publicação e acesso

• Dashboard testado com dados reais (não apenas demo)
• Números validados contra uma fonte de referência conhecida
• Permissões de visualização, edição e administração configuradas
• Dados de demonstração removidos
• Módulo biconnector ~v24.900.0+ instalado (self-hosted)

Para equipes que constroem relatórios de vendas e funis, os dashboards do BI Constructor complementam bem a configuração descrita em design de funis de vendas no Bitrix24 - os mesmos estágios do funil viram dimensões de análise no Superset.

Se você está avaliando o Bitrix24 para uma operação com necessidades analíticas avançadas, veja também a comparação honesta Bitrix24 vs HubSpot para entender como as capacidades de BI se comparam entre as plataformas.