Qlik OEM/ISV: como entregar analytics dentro do seu produto sem construir o front-end

Quem vende software e precisa entregar análise de dados para os próprios clientes tem duas contas para fechar. A primeira é a do motor analítico, e essa a modalidade OEM do Qlik resolve. A segunda é a da interface que o cliente final vai abrir, com a marca do seu produto, e essa continua sendo problema do parceiro. Este artigo trata da segunda.

O que é a modalidade OEM/ISV do Qlik

OEM vem de Original Equipment Manufacturer. Em software, quer dizer embarcar uma plataforma de terceiro dentro do seu produto em vez de construir aquela capacidade do zero. Aplicado ao Qlik Cloud, o parceiro integra análise, dados e IA ao próprio software, e o cliente final usa esses recursos através do produto do parceiro, sob a marca do parceiro.

A arquitetura típica funciona assim, conforme a documentação do Qlik para OEM: você provisiona um tenant do Qlik Cloud separado para cada um dos seus clientes, por chamada de API, sem infraestrutura manual por cliente. Cada tenant é um ambiente isolado, com dados, usuários e configuração próprios. Sua assinatura principal cobre todos eles e permite gerenciar o conjunto por programa. A Qlik cuida da infraestrutura, da escala e da recuperação de desastre.

O que sobra do seu lado é o que a própria Qlik descreve como escopo do parceiro: os modelos de aplicativo, os pipelines de dados, a configuração de autenticação e a experiência do usuário. É diferente da modalidade de revenda ou da parceria de tecnologia, onde o cliente final sabe que está usando Qlik e acessa a plataforma diretamente. No OEM, o Qlik fica embaixo, e o que aparece é o seu produto.

O trabalho que sobra para o parceiro

Embarcar analytics não é só embutir um objeto numa tela. Na prática, a lista de tarefas cresce rápido: montar o mashup com nebula.js ou via iframe e API, integrar a autenticação do seu produto com o tenant, aplicar a identidade visual em cada ponto da interface, organizar o que cada perfil de cliente vê, expor filtro e navegação de um jeito que faça sentido para quem não é analista, e manter tudo isso funcionando a cada release da plataforma e do seu próprio software.

Esse é um projeto de front-end com dono, roadmap e dívida técnica. Um mashup simples em iframe entra no ar rápido. Um mashup próprio, com autenticação integrada e vários clientes atendidos pelo mesmo código, é outra ordem de grandeza, e depois de pronto continua consumindo capacidade de desenvolvimento que você preferiria estar colocando no seu produto. Para uma software house pequena ou média, é aí que a conta do OEM começa a apertar: a licença ficou viável, o desenvolvimento não.

A camada de consumo pronta

O NewHub é essa camada. Um portal de analytics construído sobre o Qlik Cloud, no qual a marca e a organização do conteúdo são configuração, não desenvolvimento. Você conecta o tenant do Qlik Cloud via OAuth, sem migração e sem cópia de dados, e o portal herda o modelo e as permissões que já existem nos aplicativos, incluindo as regras de Section Access.

Vale saber onde essa herança começa e termina, porque é o ponto que mais gera mal-entendido na implantação. O que o Qlik controla no acesso ao dado continua valendo como está, sem uma segunda camada de permissão para manter em sincronia. Já o que os usuários do seu cliente encontram no portal, quais coleções e quais páginas, é configuração do portal, feita por quem publica.

• Logo, cores e tipografia configuráveis sem escrever código
• Subdomínio dedicado por cliente incluído na assinatura, e domínio inteiramente próprio disponível como item contratado à parte
• Conexão via OAuth, com herança do modelo, das permissões e do Section Access dos aplicativos
• Organização do conteúdo por perfil, para que cada usuário do seu cliente veja o que usa
• Início de sessão único via OAuth/OIDC, integrado ao provedor de identidade
• Ask, a camada conversacional, incluída na assinatura, com cota mensal de consultas compartilhada pela conta e pacotes adicionais sob demanda
• Módulo de adoção com uso por usuário, por painel e por período

Empresas que entregam analytics aos próprios clientes finais já operam assim hoje, com a marca do produto delas na frente e o tenant do cliente atrás, sem um time de front-end dedicado à interface. O case da Mersy descreve um desses arranjos.

Marca e endereço por cliente

No modelo OEM, cada cliente seu tem o tenant dele. A configuração do portal acompanha essa separação, então dá para entregar o mesmo produto com identidades diferentes quando o contrato pede, o que aparece em dois cenários comuns. No primeiro, você entrega tudo sob a sua marca, e o portal é a interface do seu software. No segundo, um cliente grande quer a marca dele na tela, e você atende sem manter um fork do front-end.

Vale um cuidado que independe do NewHub: o contrato de licenciamento define o que pode e o que não pode ser alterado em relação às marcas da plataforma, e essa leitura é entre você e o seu contato comercial na Qlik. Do lado técnico, o que existe é a possibilidade de configurar identidade visual e endereço no portal.

Adoção como dado de produto

Para um ISV, o módulo de adoção deixa de ser relatório interno de BI e passa a ser dado sobre o seu produto. Você vê qual cliente entrou, com que frequência, quais painéis são abertos e quais nunca foram tocados desde a implantação. Isso muda três conversas concretas: a renovação, quando você chega com uso em vez de percepção; o upsell, quando o dado mostra qual área do cliente está pedindo mais; e o roadmap, quando você descobre que o painel que custou três sprints não é aberto por ninguém.

Quando construir o próprio front-end faz mais sentido

Se a análise é o núcleo do seu produto e a interface é parte da sua diferenciação, construir compensa. Também compensa quando a experiência precisa se misturar ao fluxo do seu software, com o gráfico dentro de uma tela de cadastro ou de um processo de aprovação, e não em um portal separado. Nesses casos, a via nativa de embedding do Qlik é o caminho, e as duas coisas até convivem: o gráfico embarcado no fluxo, o portal para quem quer explorar.

A camada pronta resolve o outro cenário, que é o mais frequente. Você tem um produto que não é de BI, seus clientes pedem análise de dados, você não quer abrir uma frente de front-end para isso e precisa entregar com a sua marca.

Se esse é o seu caso, fale com um especialista ou crie seu workspace para ver o portal com a sua identidade.