Scriptly Helps Pharmacies Identify Trends in Real Time with Reveal
🎥 Watch the full webinar: Designing Embedded Analytics Your Users Actually Use Key Takeaways The problem nobody wants to admit: your dashboards aren’t getting used You bought the BI tool. You rolled it out. Your team built the dashboards. The launch email went out. And then… silence. If that sounds familiar, you’re not alone. At […]
Executive Summary:
🎥 Watch the full webinar: Designing Embedded Analytics Your Users Actually Use
You bought the BI tool. You rolled it out. Your team built the dashboards. The launch email went out. And then… silence.
If that sounds familiar, you’re not alone. At a recent industry conference, one session opened with a line that stuck with us: nobody is asking for more dashboards. And yet, the default response to every new business question is to build another one.
This is dashboard fatigue, and it follows a predictable vicious cycle:
The dashboard the data team shipped on Monday is stale by Friday. The person who built it understands what every field means – your business stakeholders don’t. And in a SaaS context, the cost is even higher: every time a user has to leave the workflow they’re in to go “check a dashboard” somewhere else, they lose context, lose momentum, and eventually stop bothering altogether.
The result? An expensive BI investment that informs almost nothing.
Every product team building embedded analytics gets caught between two failure modes:
| Too much freedom | Too much control |
|---|---|
| Open self-service creates chaos. Six departments, six definitions of “revenue.” Trust in the data erodes fast. | Locked-down dashboards frustrate users who can’t answer their own follow-up questions. They go build shadow analytics in Excel. |
Neither extreme works. The early 2000s gave us governance lockdown. The 2010s low-code era gave us shadow IT and rogue spreadsheets. Now, with AI in the mix, teams are tempted to clamp down again — and they’ll lose users all over again.
The right shift isn’t more freedom or more control. It’s better service. Most users don’t actually want to build analytics. They want direct, contextual answers delivered to them, in the workflow they’re already in.
Here’s the reframe that changes everything: in 2026, ease of use isn’t a “nice-to-have.” It’s the strategy.
Think about how you bank on your phone. How you order food. How you book a flight. The consumer software bar is now the corporate software bar – and if your embedded analytics feels like enterprise software from 2008, your users will route around it.
Two shifts are driving this:
Natural language is rapidly becoming the expected way to ask questions of data. “Show me deposits by state.” “How does our actual revenue compare to monthly budget?” Users shouldn’t have to learn SQL, data modeling, or your dashboard configuration tool to get an answer.
The next frontier isn’t a prettier dashboard – it’s analytics that surface insights before the user knows to ask. KPIs that update in context. Alerts that fire when a threshold is crossed. Notifications delivered where decisions actually happen.
The payoff is measurable: organizations that integrate self-service and natural language into their analytics workflows report up to a 50% drop in net-new dashboard requests, freeing engineering teams for higher-value work.
One of the biggest mistakes in embedded analytics is treating “the user” as a single persona. In reality, you have at least three:
If you only design for one of these, you’ll lose the other two. This is exactly where an embedded analytics SDK has a structural advantage over an iframe-based BI embed: the SDK gives the developer the primitives to deliver each persona a tailored experience inside the same product, instead of dropping all three of them into the same locked-down viewer.
Here’s where most “AI BI” stories fall apart.
You point an LLM at your raw schema. A user asks “what’s our revenue this quarter?” The LLM cheerfully returns a number – but is it gross revenue? Net? Recognized? Booked? Including renewals? The model doesn’t know, so it guesses. And because LLMs are generative, you’ll get a slightly different guess every time.
That’s not analytics. That’s faster, prettier mistakes.
The fix is a contextual layer over your data – a layer that translates business meaning into data logic. With Reveal, this is configured through simple JSON or APIs that tell the AI:
This is the difference between a semantic layer (a translation layer for humans) and a contextual layer (a translation layer for AI). In the world we’re now in, context is king.
Even with great dashboards and great NLQ, there’s still a fundamental problem: analytics still waits to be asked. The next frontier is decision intelligence – embedding explainable insights directly into the operational workflows where decisions actually get made.
Three patterns that matter here:
Because Reveal is an SDK, you can drop a single KPI visualization next to a workflow, fire a notification when a threshold is crossed, or surface a chat-driven recommendation right where the user is already working. You’re not bolting on a separate “analytics zone.” You’re embedding intelligence into the product.
In the webinar walkthrough, we put all of this together inside Acme Analytics – a fictitious SaaS app built on the Reveal SDK. A few highlights worth jumping to:
If your only embedded analytics option is an iframe, you’re stuck with whatever experience the BI vendor decided to ship. You can’t tailor the UX to different personas. You can’t drop a single KPI into a workflow. You can’t add custom tooltip actions, custom dashboard linking, or a chat experience that lives natively in your product.
An SDK like Reveal flips that. You get JavaScript APIs on the client and a .NET, Java, or Node back end on the server, which means:
That’s the difference between users adopting your analytics and users ignoring them.
Ease of use is not a feature. It’s the strategy that determines whether your embedded analytics investment pays off or quietly dies in a backlog of “more dashboards please.”
If you want users to actually use your analytics:
For the full breakdown — including the live Reveal BI product demo showing AI dashboard assistance, NLQ chat, dashboard linking, single-visualization mode, and theming — watch the complete session on YouTube:
▶️ Designing Embedded Analytics Your Users Actually Use
About the author: Jason Beres leads product and content strategy at Infragistics, the makers of Reveal embedded analytics and Ignite UI. He works with SaaS and ISV teams to design analytics experiences users actually adopt.
Most embedded analytics projects fail because users do not adopt them. The issue is usually not that the dashboards are poorly built, but that they are disconnected from the user’s workflow, difficult to act on, or unable to answer follow-up questions quickly.
Dashboard fatigue happens when every new business question leads to another dashboard. Over time, users face too many reports, inconsistent definitions, stale data, and too much effort to find the answer they need.
An embedded analytics SDK gives product teams control over the user experience. Instead of placing a separate BI interface inside an iframe, an SDK lets developers embed dashboards, single visualizations, natural-language chat, custom actions, theming, and analytics workflows directly into the host application.
A contextual layer defines the business meaning behind the data so AI can answer questions consistently. For example, it tells the AI exactly what “revenue” means, which fields to use, and which governed definitions apply.
Natural-language analytics lets users ask questions in plain English instead of learning SQL, dashboard tools, or data models. This makes analytics more accessible to business stakeholders while still supporting deeper exploration for power users.
Decision intelligence moves analytics beyond static reporting. It delivers proactive insights, risk scores, recommendations, alerts, and plain-language explanations directly inside the workflows where users make decisions.
Embedded analytics should be designed for at least three personas: business stakeholders who want guided answers, power analysts who need deeper exploration, and developers who need flexible tools to embed analytics into the product experience.
Back to Top