Qlik OEM/ISV: delivering analytics inside your product without building the front end

Anyone who sells software and has to deliver data analysis to their own customers has two bills to settle. The first is the analytics engine, and Qlik's OEM model settles that one. The second is the interface the end customer opens, carrying your product's brand, and that one stays with the partner. This article is about the second.

What Qlik's OEM/ISV model is

OEM stands for Original Equipment Manufacturer. In software it means embedding somebody else's platform inside your product instead of building that capability from scratch. Applied to Qlik Cloud, the partner integrates analytics, data and AI into their own software, and the end customer uses those capabilities through the partner's product, under the partner's brand.

The typical architecture works like this, following Qlik's OEM documentation: you provision a separate Qlik Cloud tenant for each of your customers through an API call, with no manual infrastructure per customer. Each tenant is an isolated environment with its own data, users and configuration. Your main subscription covers all of them and lets you manage the set programmatically. Qlik takes care of the infrastructure, the scaling and disaster recovery.

What stays on your side is what Qlik itself describes as the partner's scope: the app models, the data pipelines, the authentication setup and the user experience. This differs from reselling or from a technology partnership, where the end customer knows they are using Qlik and reaches the platform directly. In OEM, Qlik sits underneath and what shows is your product.

The work that stays with the partner

Embedding analytics is not just dropping an object onto a screen. In practice the task list grows quickly: building the mashup with nebula.js or through an iframe and the API, integrating your product's authentication with the tenant, applying the visual identity at every point of the interface, organising what each customer profile sees, exposing filters and navigation in a way that makes sense to someone who is not an analyst, and keeping all of it working through every release of the platform and of your own software.

That is a front-end project with an owner, a roadmap and technical debt. A simple iframe mashup goes live quickly. A mashup of your own, with integrated authentication and several customers served by the same code, is another order of magnitude, and once it is done it keeps consuming development capacity you would rather be spending on your product. For a small or mid-sized software house, that is where the OEM arithmetic starts to hurt: the licence became viable, the development did not.

The ready-made consumption layer

NewHub is that layer. An analytics portal built on Qlik Cloud, where the brand and the organisation of the content are configuration rather than development. You connect the Qlik Cloud tenant through OAuth, with no migration and no copy of the data, and the portal inherits the model and the permissions that already exist in the apps, Section Access rules included.

It is worth knowing where that inheritance begins and ends, because it is the point that causes the most confusion during rollout. What Qlik controls in access to data keeps applying exactly as it is, with no second permission layer to keep in sync. What your customer's users find in the portal, which collections and which pages, is portal configuration, done by whoever publishes.

• Logo, colours and typography configurable without writing code
• A dedicated subdomain per customer included in the subscription, with a domain entirely your own available as a separately priced item
• OAuth connection, inheriting the model, the permissions and the Section Access rules of the apps
• Content organised by profile, so each of your customer's users sees what they actually use
• Single sign-on through OAuth/OIDC, integrated with the identity provider
• Ask, the conversational layer, included in the subscription, with a monthly query allowance shared across the account and additional packages on demand
• An adoption module with usage by user, by dashboard and by period

Companies that deliver analytics to their own end customers already work this way today, with their product's brand in front and the customer's tenant behind, without a front-end team dedicated to the interface. The Mersy case describes one of these arrangements.

Brand and address per customer

In the OEM model each of your customers has their own tenant. The portal's configuration follows that separation, so you can deliver the same product under different identities when the contract calls for it, which shows up in two common scenarios. In the first, you deliver everything under your brand and the portal is your software's interface. In the second, a large customer wants their own brand on screen, and you accommodate that without maintaining a fork of the front end.

One caution that has nothing to do with NewHub: the licensing agreement defines what may and may not be changed regarding the platform's trademarks, and reading it is between you and your commercial contact at Qlik. On the technical side, what exists is the ability to configure the visual identity and the address in the portal.

Adoption as product data

For an ISV, the adoption module stops being an internal BI report and becomes data about your product. You see which customer signed in, how often, which dashboards get opened and which have never been touched since rollout. That changes three concrete conversations: the renewal, when you arrive with usage instead of impressions; the upsell, when the data shows which area of the customer is asking for more; and the roadmap, when you find out that the dashboard which cost three sprints is opened by nobody.

When building your own front end makes more sense

If analysis is the core of your product and the interface is part of your differentiation, building pays off. It also pays off when the experience has to blend into your software's flow, with the chart inside a registration screen or an approval process rather than in a separate portal. In those cases Qlik's native embedding route is the way, and the two can coexist: the chart embedded in the flow, the portal for those who want to explore.

The ready-made layer solves the other scenario, which is the more frequent one. You have a product that is not a BI product, your customers are asking for data analysis, you do not want to open a front-end front for it, and you need to deliver under your own brand.

If that is your case, talk to a specialist or create your workspace to see the portal carrying your identity.