If you’re looking for an effective way to deliver value to customers and hit your product KPIs, customer-facing analytics can be a great investment. It makes your product stickier, gives more value to your end-users, and helps them make better, more data-driven decisions.
The approach you choose can have a huge impact on your product and engineering teams, your customers, and the costs to your business, both directly and indirectly.
There are broadly three approaches to adding charts and dashboards to a customer-facing application:
- Embed a general-purpose BI tool
- Develop them yourself
- Use a headless embedded analytics tool
The goal of this article is to help you to make an informed decision about which approach works best for your product and engineering team, and ultimately, your customers.
We’ll cover:
- What is customer-facing analytics?
- Why is it valuable?
- What to consider when choosing an approach
- An overview of each approach
- Advantages and disadvantages
- A summary of your options
TL;DR
- Embedded analytics gives your users direct access to data insights inside your app, helping them make better decisions without switching tools.
- You can embed analytics in three ways: use a general-purpose BI tool like Looker or Power BI, build your own dashboards from scratch, or use a headless embedded analytics platform like Embeddable.
- Out-of-the-box BI tools are fast to implement but limited in customization, performance, and user experience, especially when embedded via iframes.
- Building from scratch gives you full control but is expensive, time-consuming, and hard to maintain, with years of ongoing dev work and infrastructure overhead.
- Embeddable is a developer-first, production-ready alternative to iframe-based tools. It combines the best of both worlds: it lets you build fast-loading, fully custom dashboards using your own components and charting libraries, in a fraction of the time.
- With Embeddable, product and customer-facing teams can update charts and dashboards without engineering help, while security, performance, and data access are handled automatically.
What is customer-facing analytics, and why is it valuable?
Customer-facing analytics (also referred to as embedded analytics, embedded dashboards, or user-facing analytics) involves incorporating charts, dashboards, and other analytics into your application.
Unlike traditional business intelligence, which is typically used by internal team members, customer-facing analytics dashboards are, as the name implies, designed for your customers / the users of your service or application.
The main purpose of customer-facing analytics is to provide an engaging and useful reporting experience for your customers, users, partners, investors, or other stakeholders, giving them access to insights and actionable information.
There are lots of specific use cases for showing reports and dashboards to users of your app or platform. For instance:
- Deliver core insights to customers about their business or operations.
- Communicate the value of your service to their business.
- Summarize your customers’ activity with your app.
- Enable customers to self-serve data requests.
- Empower front-line employees with data, so they can quickly and easily make data-informed decisions
- Show engaging statistics to increase engagement, retention, and referrals.
Check out this article to see some real-life examples of user-facing-analytics. We've included Stripe, Squarespace, Spotify, Mailchimp, Intercom, and Shopify, and detailed what makes each of them so effective.
What to consider when choosing your approach
We’ve spoken to thousands of companies looking to incorporate charts and dashboards into their customer-facing applications. Whilst there are many technical considerations that apply to specific use cases, here are some common themes in what teams are looking for when making a decision:
Common questions teams ask when choosing an approach to a customer-facing analytics project:
- Will it feel native? - teams want their analytics experience to feel like it’s part of their application – not like it’s another product sitting in their app
- How much control will we have? - i.e. will they be restricted in the experience they can deliver to customers, from the ability to apply the app’s visual language and design system, to the ability to display data in the exact way they want to.
- Will it load fast? - customers expect every page of your application to load in less than 3 seconds – this requirement is a key difference vs. internal BI.
- How fast can we build and make changes? - delivering any product feature takes time, but dashboards and charts can take a lot of time. Experienced teams know this and want to reduce time-to-market.
- How much development time will we spend? - teams want to spend as little of their precious (and expensive) development time as possible on delivering the project.
- How extendable is it? - teams want to know how easy it will be to introduce advanced features in the future, and whether there’s anything they won’t be able to do.
- How much will it cost? - this is obviously a key decision-making factor for any business, and it can be direct and indirect.
Most teams will also consider more-specific technical questions like where their data is hosted, how they will implement monitoring, compatibility with their modelling layer, etc., and may also have specific feature requirements.
We’ll keep it simple in this article and help you to understand how each approach scores across the seven common decision-making factors as we continue.
How to build analytics experiences into your app: the three approaches
There are three broad approaches to building an analytics experience into your platform, each with its own advantages and disadvantages for certain use cases.
(1) Embed a general-purpose BI tool
As noted in the introduction, there are 3 broad approaches - and this approach covers a wide range of solutions like Power BI, Looker, Metabase, Tableau etc. We’ll only cover these tools in the context of customer-facing dashboards and analytics.
Common advantages
The premise of this approach is that it gives you a much faster time-to-market vs. building your charts and dashboards in-house.
You’ll save hours and hours of engineering time vs. doing a custom build in-house, and save time every time you want to update or create new dashboards in your application.
One other great benefit of the embedded general-purpose BI tools is that you don’t need to learn a new tool if you’re already using it for other applications. This can make it easier for you to manage licensing, reduce your learning curve, and enable you to get set up even faster.
You’ll save dev time, but what are the trade-offs?
Common disadvantages of embedding a general-purpose BI tool
Each of these BI tools offers different advantages and disadvantages for embedding, but they share many disadvantages in common that are derived from the fact that they were built for internal general-purpose business intelligence first, and later adapted for embedding.
You can learn more about each tool’s specific features in this comparison of embedded analytics tools.
Some of the common issues you might recognise are:
- They won't look like a part of your own platform - most allow you to change the color scheme and fonts, but this only touches the surface of what product and design teams really consider important for UX and design
- Slow loading - loading spinners on dashboards is probably something you’re familiar with, and caching is usually an afterthought or surprisingly often just completely missing. This is made worse by…
- They embed via iframes – which has many disadvantages when it comes to embedding dashboards in your application, most notably: slower loading, no-responsiveness, security concerns, low/no interactivity, etc.
- Feature bloat, and steep learning curve - a learning curve for an internal BI tool is usually expected, but adopting one specifically for embedding might seem unnecessarily hard due to the vast array of internal BI features that make it feel bloated.
- Not built for a multi-tenant database architecture - internal BI assumes a single-tenant database architecture, so these tools have to provide workarounds to enable you to apply it to your multi-tenant application. This typically requires maintaining a user record in the third-party application.
This Looker customer quote does a good job of summarising the issues:
Why are general-purpose BI tools typically slow, inflexible, and expensive?
The tools in this group all share one thing in common: they were not built specifically for customer-facing analytics – these are tools that were initially built as internal, general-purpose business intelligence tools but have added the option of embedding into a product or web page.
This is important because internal BI and customer-facing analytics have some key differences, most notably:
- Internal teams understand that data requests can be slow, whereas your customers expect your analytics to load immediately
- It doesn’t matter if internal dashboards have your exact design system and branding, whereas your in-app dashboards need to look like a native part of your application.
- Internal BI assumes a single-tenant database architecture, whereas most customer-facing apps are multi-tenant
- Internal BI typically handles business product usage charts, whereas your customers might need to see specialised charts that aren’t provided (e.g., candlestick charts for real-time trading, or sankey diagrams for flow analysis)
- Due to their architectures, most general-purpose BI can only be rendered as an iframe.
- It makes some sense to price internal BI on a seats-based model, but not with customer-facing dashboards, which typically see unpredictable user numbers and high variation which can lead to huge cost uncertainties.
We know the problems well… We’ve been running Trevor.io since 2016, a BI tool designed for internal business intelligence. We had customers asking us for help with their customer-facing analytics projects, but when we looked into it, we saw that building customer-facing analytics on top of an internal BI architecture was not going to be a great experience. That’s why we built Embeddable.
Essentially, due to the fact that they were not initially built for the job, they tend to under-deliver on the requirements of a customer-facing analytics experience.
How to think about embedding a general purpose BI tool in your customer-facing application
- Will it feel native? - Very unlikely ❌
- How much control will we have? - Limited (typically colours, layout & fonts). ❌
- Will it load fast? - Probably not as fast as you’d like 🫤
- How fast can we build and make changes? - Very Fast ✅
- How much development time will we spend? - Not very much, in most cases ✅
- How extendable is it? - Not very extendable - you have a fixed menu of charts and modifications you can make ❌
- How much will it cost? - This can vary, but can become expensive if you have many users. 🫤
This brings us to the next approach.
(2) Build your customer-facing analytics in-house
Until now, the only alternative to using a third-party out-of-the-box analytics tool has been to build the experience from scratch and code it manually.
Typically, an in-house build would leverage charting libraries like Chart.js, D3 or HighCharts, which give you a head-start on building your frontend components. We’ll assume that anyone taking this approach would leverage these resources.
Advantages of building customer-facing dashboards in-house
The biggest advantages of building in-house are the exact opposite of embedding a general-purpose BI tool – i.e.:
- An in-house build gives you full control over your frontend UX and UI, meaning that your charts and dashboards can adopt your design system, neatly fit into your brand’s visual language, and feel 100% native in your application.
- Your dashboards will be fully extendable, meaning that there is no feature you can't build, and no chart type you can’t incorporate – assuming you have the time and resources to build them
- You don’t have to share your data with any third parties or rely on them to maintain a service that your customers depend on.
- There’s no platform fee - once it’s built (assuming you make no changes), there are no additional costs or licenses tying you into payments to a third-party supplier.
- You can apply your own product analytics and monitoring, which is not the case with an iframe embed.
Disadvantages of building customer-facing dashboards in-house
There are some great benefits to taking control over your UX and UI, but building customer-facing analytics in-house is hard.
The main drawbacks are all related to a reliance on manual work by engineers, who tend to be expensive and in many cases might not be specialised analytics engineers. They include:
- High development and maintenance costs. It’s not a one-off sprint where “when it’s done, it’s done”. It is a long-term commitment, with the opening of a door to never-ending feature and data requests from your own data-hungry customers.
- Opportunity costs - every sprint your developers are working on dashboards, they can’t work on your other high-priority product initiatives and features. This is the ‘hidden cost’ of a custom build, and can often be the biggest cost.
- Tech debt can pile up, and you might find that the developer(s) who worked on the dashboards leave and take their knowledge with them. This can lead to issues with keeping your service performant and well-maintained.
- Managing data consistency can be a challenge, especially if you’re writing the SQL behind each chart, though this can be improved by using a semantic modeling layer like Cube.js.
- Deprioritisation of dashboarding tickets. Many teams find that optimisations, extensions and maintenance of dashboards are deprioritised when they have other key engineering initiatives competing for resources.
- Advanced features are often hard to build and manage, for example, enabling your customers to build their own views of dashboards, and things like handling currencies/languages/timezones (conversely, these are usually easy to implement in embedded tools).
Here are some quotes from tech leaders that we've picked up along the way.
“We've invested years of effort in building our custom filtering + dashboard/reporting capabilities” (Head of Product, People Tech Company, US)
“We’ve spent a year building out our customer-facing analytics platform. Still not finished.” (CEO, Public Sector Data Platform, Germany)
"Dashboarding has been planned and prioritized but we've been putting it off because it’s too complicated" (CEO, Adtech Platform, US)
How to think about building customer-facing analytics in-house
- Will it feel native? - Yes ✅
- How much control will we have? - Full control ✅
- Will it load fast? - Maybe, with the right data preparation work 🫤
- How fast can we build and make changes? - Not quickly, you’ll need to design, plan, estimate, build, QA and run a full project with your engineering team ❌
- How much development time will we spend? - A lot. Every single change will have to go through engineering ❌
- How extendable is it? - Fully extendable, with effort ✅
- How much will it cost? - No platform fee, but a potentially huge cost in developer hours 🫤
(3) Headless Embedded Analytics (Embeddable)
A headless embedded analytics tool is one that enables you to extend and modify the provided charts and components, or import your own frontend components, giving you unlimited control and extendability, and is built specifically for the customer-facing use case.
It is a fast-growing but comparatively recent development pioneered by the team behind Embeddable, which is the only fully headless embedded analytics tool known to us at the time of writing. As a result, this section will focus on Embeddable only.
This approach was designed specifically to solve the issues associated with the other two options we covered (i.e., custom builds and embedded BI tools); focusing on:
- Reducing development costs
- Increasing speed-to-market
- Ensuring fast, performant loading
- Retaining full control & infinite extensibility
- Ensuring an excellent developer and customer experience
The solution was built from the ground up on top of Cube.js. This semantic modeling layer ensures data consistency and reliability while offering caching capabilities that enable sub-second loading speeds. This can be provided as part of the core Embeddable service, or it can be connected natively to your Cube Cloud or Core setup.
These are the main benefits that teams already adopting this approach are saying about it, for example:
"We have been able to dramatically improve our dashboard product offering in our web applications and now have a solid foundation to iterate and continuously offer new ways of visualizing data for our customers" - Brian Rountree, VP of Engineering at Monta (Energy-tech, 400 people)
“With the help of Embeddable, we’re able to deliver a user experience that surpasses that of other vendors in our space who often have 10x+ the team and budget.” - Julian McCarty, CEO at Mosaic Voice (Y-Combinator Startup).
If you want the speed to market of an embedded analytics tool, with the control of a custom build, with the promise of fast-loading dashboards for your customers, then this approach might be a good option for you.
Advantages of building customer-facing dashboards with Embeddable
The main advantages of using a tool like Embeddable are tied back to the core concept being designed for one specific job: helping engineering and product teams to build charts and dashboards for customers in their SaaS applications.
As a result, you can expect the following benefits:
- You can build and iterate fast.
An intuitive dashboard management platform allows your team to build, modify, and toggle advanced features for customers without support from engineering. This means that your product and customer-facing teams can easily handle customer requests and deploy advanced features like exporting and enabling your customers to build their own dashboard views. - It will look and feel native in your app
Instead of offering a limited menu of charts presented inside an iframe – you can style, extend, or import charts in code, and they will render as HTML in your app via web components or native React/Vue embeds. The result is a responsive experience that blends into your product completely.
- Dashboards load fast
With a performant data service, lightweight embedding, and two fully configurable caching layers, it enables you to achieve sub-second loading times for your customers.
- You can extend it infinitely
The headless nature of Embeddable means you can import any React component you like, with any functionality, meaning that any chart type, any chart setting, any customer interactions ,and almost any customer experience can be achieved.
- It’s built for multi-tenancy
Row-level and column-level security is handled intuitively through filters, which are dynamically applied to your data models when the SQL is generated. You don’t need to maintain dozens of versions or worry about maintaining a separate user record in a third-party tool. - Shipping advanced features is easy
You can enable your customers to build their own custom dashboards and views (which can be highly valuable but is notoriously hard to manage and achieve with a custom build), while other features like exporting, caching, cross-filtering and localization also come built in. You can toggle these on when needed, instead of having to build every feature from scratch.
“The way embeddable looks in our app is seamless and really looks like it belongs versus just something thrown in there like with an iframe. The releases have only gotten better with each update, and the people you work with are great.” - Alex S., G2 Reviewer
Disadvantages of building customer-facing dashboards with Embeddable
Of course, all approaches come with trade-offs, and while the headless approach has some great advantages for building customer-facing charts and dashboards, there are some considerations to keep in mind.
- If you want to take advantage of the ability to customize your charts, then it might take more development time vs. embedding a general-purpose BI tool – but much less than a fully-custom build.
- You’ll pay a license fee, which is not the case with a custom build.
- It’s a customer-facing analytics solution only - you won’t get a general-purpose BI tool for your internal team in the same tool.
As with any tool, there may also be technical reasons like your data-sovereignty or hosting requirements or that are a blocker for working with Embeddable - the best way to find this out is by reviewing the docs or setting up a call with one of the team via the site.
How to think about headless embedded analytics (with Embeddable)
- Will it feel native? - Yes, you can apply your exact design system & branding in code ✅
- How much control will we have? - You have full control, in code, down to the pixel ✅
- Will it load fast? - Yes, if you use Embedable’s caching layer ✅
- How fast can we build and make changes? - Very fast, via the no-code dashboard builder ✅
- How much development time will we spend? - It depends on how much you want to extend it, but basic dashboards are very fast ✅
- How extendable is it? - Infinitely extendable ✅
- How much will it cost? - There’s a platform fee, but it's low cost in development time.
Summary: How do the three approaches compare?
Which approach should you use for building customer-facing analytics?
Selecting an approach for your project is never simple. There are many factors that can affect a decision outside of the main factors we’ve covered here, like technical fit, your team resources and cost.
However, if you’re planning to build customer-facing analytics, then these two statements are probably true:
- You want a great user experience that loads fast and feels like your application.
- You want to build it fast, at low cost.
With this context in mind, in general, you should consider to:
- Embed a general-purpose BI tool if you are already using it internally, and just need to get a dashboard up quickly without learning a new tool.
- Build your dashboards in-house if you’re building a basic MVP, or you just need 1 or two charts, which will be quick to build and low maintenance. In this case, paying for a software license might be an overhead that you don’t need.
- Explore the option of headless embedded analytics if you want to save engineering time and get a fully native, fast-loading customer experience.
If you want to explore more about how Embeddable can help you to deliver your customer-facing analytics project, you can find out more here, or take a look at the docs.
Frequently asked questions
1. What’s the difference between embedded analytics and traditional BI tools?
Traditional BI tools are built for internal teams to analyze company data. Embedded analytics is meant for your users: it gives them access to relevant metrics and reports directly inside your app. It’s customer-facing, not just for internal teams.
2. Why are iframe-based BI tools not ideal for embedding dashboards?
Iframes often lead to clunky interfaces, slow performance, poor mobile responsiveness, and limited control over styling. They feel like a bolt-on rather than part of your product. You also run into limitations around user-level permissions, monitoring and customization.
3. When does it make sense to build dashboards from scratch?
If you need total control over every pixel, have a highly specialized data structure, and the budget to dedicate a full-time team long term, building from scratch might work. But be ready for ongoing maintenance, feature requests, and data access challenges. There are better options in most cases.
4. What React-based tools can I use for embedded analytics?
Embeddable is the embedded analytics tool that allows you to extend, modify and import React charts and components into its dashboard management platform, and embeds natively in React applications. This gives you the full freedom of React on the frontend while it handles everything else for you.
5. Can Embeddable be used with React?
Yes. Embeddable can embed in any frontend and works great with React. It lets you import custom components from charting libraries, allowing you to maintain design consistency across the app while delivering fast, dynamic reporting.
6. Can I use Embeddable with charting libraries like Recharts, HighCharts, or Chart.js?
Yes. Embeddable enables you to import React components, so you can use the charts provided or use charts from another library. You can also extend the charts provided in React, giving you full control over your frontend user experience.
