Qlik OEM/ISV: cómo entregar analytics dentro de tu producto sin construir el front-end

Quien vende software y necesita entregar análisis de datos a sus propios clientes tiene dos cuentas que cerrar. La primera es la del motor analítico, y esa la resuelve la modalidad OEM de Qlik. La segunda es la de la interfaz que el cliente final va a abrir, con la marca de tu producto, y esa sigue siendo problema del socio. Este artículo trata de la segunda.

Qué es la modalidad OEM/ISV de Qlik

OEM viene de Original Equipment Manufacturer. En software significa incorporar una plataforma de un tercero dentro de tu producto en lugar de construir esa capacidad desde cero. Aplicado a Qlik Cloud, el socio integra análisis, datos e IA en su propio software, y el cliente final usa esos recursos a través del producto del socio, bajo la marca del socio.

La arquitectura típica funciona así, según la documentación de Qlik para OEM: aprovisionas un tenant de Qlik Cloud separado para cada uno de tus clientes, mediante una llamada a la API, sin infraestructura manual por cliente. Cada tenant es un entorno aislado, con datos, usuarios y configuración propios. Tu suscripción principal cubre a todos ellos y permite gestionar el conjunto por programa. Qlik se encarga de la infraestructura, de la escala y de la recuperación ante desastres.

Lo que queda de tu lado es lo que la propia Qlik describe como alcance del socio: los modelos de aplicación, los pipelines de datos, la configuración de autenticación y la experiencia de usuario. Es distinto de la reventa o de la alianza tecnológica, donde el cliente final sabe que está usando Qlik y accede a la plataforma directamente. En OEM, Qlik queda debajo, y lo que aparece es tu producto.

El trabajo que le queda al socio

Incorporar analytics no es solo insertar un objeto en una pantalla. En la práctica la lista de tareas crece rápido: montar el mashup con nebula.js o vía iframe y API, integrar la autenticación de tu producto con el tenant, aplicar la identidad visual en cada punto de la interfaz, organizar lo que ve cada perfil de cliente, exponer filtros y navegación de un modo que tenga sentido para quien no es analista, y mantener todo eso funcionando en cada release de la plataforma y de tu propio software.

Ese es un proyecto de front-end con dueño, roadmap y deuda técnica. Un mashup simple en iframe sale rápido. Un mashup propio, con autenticación integrada y varios clientes atendidos por el mismo código, es otro orden de magnitud, y una vez terminado sigue consumiendo capacidad de desarrollo que preferirías estar poniendo en tu producto. Para una software house pequeña o mediana, ahí es donde la cuenta del OEM empieza a apretar: la licencia se volvió viable, el desarrollo no.

La capa de consumo lista

NewHub es esa capa. Un portal de analytics construido sobre Qlik Cloud, en el que la marca y la organización del contenido son configuración, no desarrollo. Conectas el tenant de Qlik Cloud vía OAuth, sin migración y sin copia de datos, y el portal hereda el modelo y los permisos que ya existen en las aplicaciones, incluidas las reglas de Section Access.

Conviene saber dónde empieza y dónde termina esa herencia, porque es el punto que más malentendidos genera en la implantación. Lo que Qlik controla en el acceso al dato sigue valiendo tal como está, sin una segunda capa de permisos que mantener sincronizada. En cambio, lo que los usuarios de tu cliente encuentran en el portal, qué colecciones y qué páginas, es configuración del portal, hecha por quien publica.

• Logo, colores y tipografía configurables sin escribir código
• Subdominio dedicado por cliente incluido en la suscripción, y dominio totalmente propio disponible como ítem contratado por separado
• Conexión vía OAuth, con herencia del modelo, de los permisos y del Section Access de las aplicaciones
• Organización del contenido por perfil, para que cada usuario de tu cliente vea lo que usa
• Inicio de sesión único vía OAuth/OIDC, integrado con el proveedor de identidad
• Ask, la capa conversacional, incluida en la suscripción, con una cuota mensual de consultas compartida por la cuenta y paquetes adicionales bajo demanda
• Módulo de adopción con uso por usuario, por panel y por período

Empresas que entregan analytics a sus propios clientes finales ya operan así hoy, con la marca de su producto delante y el tenant del cliente detrás, sin un equipo de front-end dedicado a la interfaz. El caso de Mersy describe uno de esos arreglos.

Marca y dirección por cliente

En el modelo OEM, cada cliente tuyo tiene su propio tenant. La configuración del portal acompaña esa separación, así que se puede entregar el mismo producto con identidades distintas cuando el contrato lo pide, lo que aparece en dos escenarios comunes. En el primero, entregas todo bajo tu marca y el portal es la interfaz de tu software. En el segundo, un cliente grande quiere su marca en pantalla, y lo atiendes sin mantener un fork del front-end.

Un cuidado que no depende de NewHub: el contrato de licenciamiento define qué puede y qué no puede cambiarse respecto de las marcas de la plataforma, y esa lectura es entre tú y tu contacto comercial en Qlik. Del lado técnico, lo que existe es la posibilidad de configurar identidad visual y dirección en el portal.

La adopción como dato de producto

Para un ISV, el módulo de adopción deja de ser un informe interno de BI y pasa a ser dato sobre tu producto. Ves qué cliente entró, con qué frecuencia, qué paneles se abren y cuáles nunca se tocaron desde la implantación. Eso cambia tres conversaciones concretas: la renovación, cuando llegas con uso en vez de percepción; el upsell, cuando el dato muestra qué área del cliente está pidiendo más; y el roadmap, cuando descubres que el panel que costó tres sprints no lo abre nadie.

Cuándo construir el propio front-end tiene más sentido

Si el análisis es el núcleo de tu producto y la interfaz es parte de tu diferenciación, construir compensa. También compensa cuando la experiencia tiene que mezclarse con el flujo de tu software, con el gráfico dentro de una pantalla de registro o de un proceso de aprobación, y no en un portal aparte. En esos casos la vía nativa de embedding de Qlik es el camino, y las dos cosas incluso conviven: el gráfico incorporado al flujo, el portal para quien quiere explorar.

La capa lista resuelve el otro escenario, que es el más frecuente. Tienes un producto que no es de BI, tus clientes piden análisis de datos, no quieres abrir un frente de front-end para eso y necesitas entregar con tu marca.

Si ese es tu caso, habla con un especialista o crea tu workspace para ver el portal con tu identidad.