The modern standard for embedded analytics, and how to evaluate a platform against it.
.avif)
Embedded analytics used to mean putting reports inside an application. That definition is no longer sufficient.
Analytics is becoming part of the product experience itself, so it must be as fast, intuitive, personalized, and trustworthy as the application around it.
For B2B software companies, one of the highest-value applications of data is proving the outcomes the product was hired to create. That proof can affect adoption, retention, and expansion.
More broadly, embedded analytics is about putting data in the world where decisions and actions happen, rather than asking people to leave their workflow and go to a separate analytical environment.
Modern embedded analytics means taking advantage of what is newly possible with AI: building artifacts more quickly and providing natural language Q&A for end users. It also means meeting a higher bar on the fundamentals: speed, visual quality, personalization, security, integration, and maintainability.
The standard should be a modern product experience, not simply a BI tool placed inside another application.
Historically, embedded analytics forced a difficult build-versus-buy choice: large, expensive applications on the “buy” side and large, expensive in-house projects on the “build” side.
These projects often took so long that many companies stopped at operational analytics: counts of things that happened rather than clear proof of the outcome a product or service created. But for customer-facing analytics, the higher-value job is often to communicate the core value being delivered. That executive-level framing can be the difference between a product that is understood and one that is quietly deprioritized during the next budget cycle.
Traditional approaches also create an experience gap. Static reports are controlled but do not allow exploration. Traditional BI can provide breadth but often brings compromises in performance, product integration, visual control, or economics. Custom applications can deliver exactly the desired experience, but require ongoing expertise in front-end engineering, data, visualization, security, performance, and maintenance.
The traditional build-versus-buy choice had no great options. Today that equation is changing.
Generative AI has made it dramatically easier to produce a chart, dashboard, or analytical application. A developer can give a coding agent a dataset and a prompt and get something useful in minutes. For ad hoc analysis, prototyping, or personal analytics, that is a major advance.
But generating a dashboard is not the same as operating customer-facing analytics in production. Maintenance and performance optimization take more time than expected. A production system still needs support for large data volumes, consistent governance, reliable refreshes, fast interaction, responsive design, observability, accessibility, and an ongoing path for change.
On top of that, customers always have more questions. In the past that meant custom reports. Today, augmenting dashboards with a natural-language data agent solves the need for more answers. However, it introduces more to manage to make that experience great: guardrails, evaluation, validation, context management, and monitoring.
However you arrive at the analytics, the hard part is everything required to make the experience trustworthy, secure, fast, and durable.
This changes the build-versus-buy calculation rather than eliminating it. AI collapses the cost of generating software, but does not change the deployment dynamics.
The “buy” side should change as well. Buyers should no longer accept the old bargain of trading engineering effort for a slow, rigid, disconnected analytical experience.
New technology makes it possible to combine an exceptional user experience with benefits for builders:
There are three reasons buyers of embedded analytics should expect more now.
Twenty years ago, organizations might have had a Postgres database and CSV files. No semantics, no governance.
Today the stack is much more mature: cloud data warehouses, lakehouses, transformation systems, semantic layers, governance systems, and APIs. Analytics no longer has to try to own all of that.
A modern analytical layer can, and should, build on that data stack and respect the systems already in place.
For years, “business intelligence” was treated as all things to all people: an environment for deep analysts, dashboards for executives, and embedded reporting for customers. That never worked equally well for every audience.
AI is forcing a sharper question: who needs what, and when? Ad hoc analysis, deep analytical work, and broadly shared embedded analytics have different needs and may best be served by different product experiences.
For much of the past decade, the user-facing analytics experience changed relatively little even as the rest of the data stack modernized.
AI, browser technology, and new application architectures are now reopening basic assumptions about how analytical products are built, delivered, and used.
Embedded analytics is about broad sharing of data to help people understand and act. Companies should evaluate a platform in that light and look for the following elements:
From a strategic standpoint, user experience is the ultimate driver of data value. Ifr the experience is poor, people won't use it.
For product teams, the historical cost of embedding analytics has been high-touch, custom work. Taking advantage of AI-native build tools lets teams ship better analytics, faster.
The analytics experience reflects on the experience of the product as a whole. It should look and feel like the host application and work seamlessly with it.
Analytics is shifting from monolithic platforms to composable layers: manage data, build, and deploy.
From a strategic standpoint, user experience is the ultimate driver of data value. The entire system is designed to communicate important insights and allow people to interrogate or act on them.
The critical aspects of the system for an end user are:
Sub-second performance can sound like an infrastructure detail, but it changes the way people work with data.
Put the same person on the consumer web and they expect web pages, search, and video to respond almost instantly. Put that person in front of analytics and many legacy systems ask them to wait 10 or 15 seconds every time they click a filter.
"Sub-second buttery interactions."
Tim Ngwena, Principal Analytics Consultant, Aimpoint Digital; Just Tim Podcast, speaking about browser-native performance in Ridge AI.
Slowness breaks the analytical loop. If the audience is a seller, executive, partner, or customer, they won’t wait through a long server round trip every time they investigate the data. Once they lose interest once, you have effectively lost the audience.
This was a longstanding problem in traditional BI. Teams could celebrate optimizing a query from 19 seconds to 11 seconds because the percentage improvement was large, while the actual experience was still far too slow for interactive work.
The modern standard is different: interaction should feel fluid.
Modern architectures can move parts of analytical computation closer to the user rather than requiring every interaction to wait on a remote server round trip. The specific technologies will evolve, but the requirement is durable: filtering, selecting, hovering, and drilling should respond at the speed of thought.
People process and understand data richly when it is visual. When you are telling a story to a broad group of people, especially people seeing a dataset or domain for the first time, you need to organize the story for them. A well-designed visual experience gives people orientation: what matters, what is normal, what changed, how things compare, and where to look next.
That role becomes even more important as analytics reaches broader audiences. A blank chat box assumes the user already knows what to ask. Many users do not. They first need help processing the data and understanding the domain. Visuals establish that shared frame.
Visual quality is therefore not decoration. The system should apply established principles of visual perception and communication so that the output is understandable, especially for non-analyst audiences. An executive-facing experience should feel appropriate for an executive audience: clear, fast, branded, and intentional.
Once users are oriented, conversational analytics solves a different problem: the next question.
Dashboards provide a curated view of the questions that matter most, but they cannot anticipate every useful follow-up.
The old answer to a new analytical question was often to build another dashboard. That is not scalable, and results in long, frustrating cycles to produce dashboards that are used only rarely. A better model is head and tail: use a curated visual experience for the important, repeatable questions and let a data agent address the long tail.
A dashboard might establish the big picture around retention, fund performance, workforce productivity, or product adoption. The underlying dataset may contain dozens of additional dimensions that are part of the data but do not belong on the screen. Natural-language exploration lets users ask the next question without requiring the builder to anticipate and encode every useful cut in advance.
"Being able to ask free-form questions in the data agent makes dashboards vastly more flexible and useful."
Phil O'Neill, Chief Data Officer, ISSA
This is why visual and conversational analytics are complementary rather than substitutes. Visuals establish shared understanding; conversation lets each user pursue the question they have next. The requirement is not that every embedded experience needs a chatbot. It is that users should be able to investigate reasonable follow-up questions without entering an endless cycle of dashboard requests.
For product teams, the historical cost of embedding analytics has been high-touch, custom work. Shifting the abstraction layer from dashboard-building to business-level intent allows teams to ship better analytics, faster.
The most important change AI can bring to building analytics is not simply automating clicks in an old interface. It is changing the level of abstraction.
A traditional BI builder asks the user to make a long series of implementation decisions: do you want a bar chart or line chart, what belongs on the x-axis, what belongs on the y-axis, how should it aggregate, which menu contains the right formatting option?
A modern build experience should ask different questions: What are your goals? What does this metric mean to you? What signal are you trying to communicate? What questions should the audience be able to answer?
The experience should feel more like sitting next to a strong data analyst who understands the business. The builder knows the product, the customer, and the business objective. The system should bring the analytical and visualization expertise.
This is a deeper change than “AI assistance.” It allows non-specialists to work at the business level while still producing a production-quality analytical experience.
Creation is only the beginning. Routine changes should not require a specialized BI developer or engineering project.
Business or product teams should be able to modify the analytical story, define or revise metrics, change filters and segmentation, refresh underlying data, and create additional experiences from new datasets. The operational question is not only “how fast can we build version one?” but “who owns version 20?”
If every new or updated dashboard opens a queue for engineering, the organization has not really solved the analytics problem; it has moved it.
The analytics experience reflects on the experience of the product as a whole. It should look and feel like the host application and work seamlessly with it.
Embedded analytics often serves many distinct customers, prospects, partners, or internal audiences from the same application. The platform should support personalization at scale without creating a new dashboard or engineering project for every audience.
That means a reusable analytical experience should be able to receive secure context: customer identity, segment, geography, account, product configuration, or another authorized partition. Initial filters and presentation can change with that context while the underlying application remains maintainable as one system.
Security boundaries matter here. A user should not be able to alter a URL or browser parameter to access another customer’s partition. Tenant identity and authorization need to be enforced through signed or server-validated mechanisms, and those same boundaries must apply to both visual interactions and natural-language questions.
The goal is not hundreds of independently maintained dashboards. It is one application that can safely become hundreds or thousands of personalized, relevant experiences.
Agentic creation should not mean giving up control.
Embedded analytics is part of a product, not a foreign object inside it. Builders need control over visual hierarchy, typography, color, interaction, responsive behavior, and overall presentation. Brand and design requirements should be durable and reusable rather than reconstructed dashboard by dashboard.
The standard should be that the analytical experience can inherit or match the host product closely enough that users experience it as part of the application, not as a BI tool placed in a box.
Embedded analytics should be able to sit in the application, workflow, portal, or customer experience where the decision is actually being made. That integration should extend beyond appearance. Analytics should be able to receive context from the surrounding application and, where appropriate, help users take the next action.
A modern platform needs straightforward ways to load analytics into a host application and programmatically manage state, identity, filters, events, rendering status, exports, and other interactions. Some use cases may be well served by a simple iframe. Others require deeper integration where analytics behave as part of the page rather than as a box inside it.
The architectural principle is more important than a specific embedding technique: the analytical experience should be able to participate in the host application.
Modern integration should also extend to building and managing analytics, not only displaying them. APIs and protocols such as the Model Context Protocol (MCP) can make analytical capabilities available to other software and agents. For example, an agent might instantiate a new analysis on demand, apply the appropriate semantics and security context, and place the result back into the host application.
This turns analytics creation into a capability that other systems can invoke, rather than a task that must always happen inside a dedicated BI authoring interface. The platform should therefore support programmatic creation, configuration, retrieval, and lifecycle management of analytical experiences alongside traditional embedding.
Analytics is shifting from a monolithic platform to composable layers that work together.
The modern data stack has evolved. Storage, transformation, semantics, governance, identity, and application workflows increasingly live in specialized systems that already exist. Modern embedded analytics should build on those systems rather than recreate them. The analytical layer can specialize in the human-data interface: helping people understand, explore, and act on data.
That means a modern analytical layer should sit cleanly on an existing data and semantic stack, support declarative analytical experiences, expose APIs and protocols for embedding and agentic workflows, receive identity and context from the host application, and coordinate visual and conversational interfaces over shared state.
The result is a lighter architecture that can support one reusable analytical application across many users, customers, and workflows without rebuilding the surrounding data stack.
The data stack has matured. Analytics should leverage what exists, not rebuild it in another app.
The principle is composability: let the systems that already own data preparation, semantics, and governance continue to do that work, while the analytical layer specializes in the experience of data by the people using it.
A prototype can work on a CSV. A production analytical product needs a reliable data lifecycle.
That includes connections, refresh, caching, changing schemas, performance as data volume grows, and secure partitioning for the audiences being served. These capabilities should be designed as part of the system rather than assembled separately for every deployment.
Security cannot stop at the dashboard boundary.
Traditional embedded analytics already requires strong authentication, authorization, tenant isolation, and governance. AI raises the bar because free-form questions can expose paths through the data that a dashboard author did not explicitly anticipate.
The same authorization boundary must therefore apply whether a user is looking at a chart, applying a filter, making an interactive selection, or asking a natural-language question. A secure system should expose only the data a user is authorized to see and should not rely on editable client-side parameters to enforce those boundaries.
The cost of analytics is not the cost of the first dashboard.
A modern platform should reduce the ongoing engineering responsibility associated with deployment, updates, performance tuning, permissions, model changes, evaluation, bug fixes, and feature requests. This is where “build it with AI” can become deceptively expensive: the code is easy to generate, while ownership accumulates over time.
The best test is simple: after launch, what infrastructure does your team still have to own?
Embedded analytics succeeds when more people use it. Traditional pricing priced per user, or for server peak loads. That inhibits the very experience you want to create.
Buyers of embedded analytics should understand what causes cost to increase: authors, viewers, customer accounts, dashboards, queries, data volume, compute, AI usage, or some combination. The specific model can vary, but it should be predictable and aligned with the value of the embedded experience.
This matters especially for customer-facing products. A pricing model designed around a small number of internal BI seats may fit poorly when the goal is broad distribution to thousands of customers or end users.
The new standard is an analytical product experience:
AI raises expectations for both users and builders, but it does not remove the need for design, reliability, governance, or maintainability. At the same time, modern data infrastructure and browser technology make it possible to deliver experiences that were impractical a decade ago.
The build-versus-buy decision remains, but the bar on both sides has changed. Buyers should evaluate not merely whether a platform can render charts, but whether it can become a durable, native, scalable part of the product experience.