嵌入式分析：停止製作儀錶板後，樂趣才開始

I've spent the last decade building applications around analytics engines. I've spent the better part of a decade building applications around BI tools. I've built plenty of dashboards too, unfortunately. But the work I enjoy most is building web and mobile applications with custom interfaces, workflows and connections to other services. Occasionally, that means connecting things that probably had no business talking to an analytics engine.

After all these years, I'd still rather do that than build another sales dashboard. Dashboards are useful. People rely on them to do their jobs. But as a software engineer, there's only so much excitement I can get from putting another bar chart next to a KPI card. I'd rather build an application that uses analytics as part of the work someone is already doing.

That time we connected Qlik to Alexa

In my first article, I mentioned experimenting in the early days of Qlik Sense integrating with Amazon Alexa. Yes, Alexa. This was years before software vendors started putting a chatbot into anything with a screen. Yes! it's practical value was debatable, but it was very cool.

I doubt anyone was going to replace their dashboards with a smart speaker. I wanted to see whether I could use the Qlik engine through a voice interface. Ask a question, interpret it, send a request to Qlik and get an answer back. And it worked. I found that far more exciting than the latest chart type. I could build our own interface around Qlik's engine. I've approached analytics that way ever since.

Unpopular opinion

“I find traditional BI work a bit boring sometimes.”

“Data are fun” that was going to be the title of this blog before I settled on “The state of embed”. The data can be fascinating, I enjoy finding patterns and figuring out how things relate to each other. It's delivering the results that gets repetitive.

• Another dashboard.
• Another set of filters.
• Another request to make the numbers bigger.
• Another stakeholder who wants the entire application exported to Excel.

After enough of those requests, I start wondering why we deliver analytics this way. Why does someone need to leave the application they're already using to open a separate BI tool? Why should they have to set filters for a customer they've already selected? The application could pass that context to the analytics engine and show the relevant data. Then the user could act on what they find without leaving their work. That's the appeal of embedded analytics for me.

Stop making people go looking for analytics

Imagine you're building a customer management application. The application already knows which customer you're looking at and what permissions you have. An embedded analytics engine could use that context. You could show the customer's purchasing history and compare it with similar customers, all on the same screen.

You could also combine that data with information from other services or use it to trigger an action in another system. You control how the user explores the data. You can reuse the BI work you've already done.

If you've spent years building data models, business measures and security rules in Qlik, Power BI or Tableau, recreating them from scratch holds little appeal. I'd rather use those models and rules in an application with an interface I control. The engine handles the analytics. The application handles how people use the results. Getting the two to work together can be painful. I've written an entire article about my frustrations with qlik-embed.

What AI adds to the application

Lately, I've been thinking about what AI could add to these applications. AI generating dashboards doesn't excite me much. It's impressive. I wrote about it in my previous article. I'd rather use AI to help someone investigate data and act on it inside an application.

In the Alexa experiment, we had to write much of the logic for interpreting questions ourselves. The language tools available at the time were limited. LLMs, tool calling and MCP make those experiments easier to build today. Someone asks a question. The application supplies the context, the model chooses from the tools you've made available, and the analytics engine returns a result using its existing business rules and permissions.

You decide which users can access each tool and when an action needs confirmation. You can also connect the answer to other services. Imagine a user reviewing an unusual sales trend inside their CRM. They could investigate the numbers and inspect the relevant transactions there. With the right permissions, they could then create a follow-up task for their account manager.

Now that's something I'd enjoy building. None of this requires giving an LLM unrestricted access to your database. You can limit it to specific operations that enforce your existing permissions and business logic. You still have to get authentication, authorisation, data quality and error handling right. An LLM doesn't remove that work.

Why I keep building around analytics engines

Much of the discussion about embedded analytics focuses on business benefits. People use the data more, spend less time switching applications and make decisions sooner. Those are reasonable goals. I'm sure someone in a boardroom has a lovely PowerPoint explaining them.

My interest is more personal.

I like figuring out how to connect two systems that weren't designed to work together. I want control over the interface and what someone can do with the data. And I'd rather reuse an analytics engine's data models, measures and permissions than build all of that myself. That's what I enjoyed about connecting Qlik to Alexa.

Today's AI tools give me a way to try that idea again, with less hand-written logic for interpreting questions.

I still want to build applications where someone can ask about their data, investigate the answer and do something useful with it. Maybe above everything else l want to build something that leaves people asking "How in the state of embed did you do that?"