What's Covered
Many software companies have built, or want to build, analytics into their applications to improve the user experience and deliver additional value to their customers or users.
Depending on your customer needs, you might be looking to display valuable insights like the revenue/savings your product has generated for them over time, real-time analytics insights about the status of their inventory, or any other data you hold in your database about individual users, products, events, or behaviour.
There are a number of different approaches to delivering customer-facing analytics, which we cover in this writeup. Before we built Embeddable, the approaches were either to Build or to Buy.
If you’ve looked into embedding a traditional business intelligence tool into your app - the ‘buy’ option - you’ll know that these tools often come with a set of limitations (like inflexibility, limited customisation options and sub-par performance/loading speed) that mean you can’t always deliver your dream analytics experience for your customers with them.
Like other tools out there, our own BI tool, Trevor.io, is great for internal BI but it wasn’t built from the ground up to be perfect for displaying to your customers on the fly.
We’ll go into more depth on the limitations of embedded BI tools in another post, but for this article we’ll focus on the Build option, and explore what it really costs to develop your own customer-facing analytics.
How did we get here?
If you’re exploring options for implementing customer-facing analytics, you’ve probably identified an opportunity to deliver value to your customers and quickly discovered that it’s not quite as simple as it might seem.
Maybe you’re in the product team and trying to get your visions to life, or maybe you’re in engineering and have been asked to look into an analytics project by your product team.
You might have followed this common set of steps:
- Product team adds user-facing analytics epic to the roadmap
- Engineers scope out the project to decide on an approach and make estimations
- They return with:
- Option A: we build it ourselves, but it’s going to cost about ~5 sprints and push back everything else on the roadmap by months (and we’ll have to consider ongoing maintenance).
- Option B: we use a BI tool to build the dashboards and then embed it, with very little engineering cost - but there are some compromises (mentioned above!)
- Product LOVES the sound of the timeline on Option B, but HATES the idea of using a limited set of inflexible, pre-canned components into their carefully-crafted user experience.
- The Customer-Facing Analytics Epic moves to the backlog, and remains there.
It’s a really common scenario, but always frustrating for everyone involved.
We spoke to Ran Sasportas, DaaS R&D Lead at Similarweb who said "We've built our existing dashboard solution over 2 years to provide users with insights. But, it takes a lot of maintenance, a lot of work. We basically need an army of full-stack developers to make it work." This is not an uncommon scenario.
Let’s explore why so many companies keep ending up in this situation.
Why does it take so long to build charts, graphs and dashboards from scratch?
As with many conflicts, at the core of the issue is a misunderstanding. Because we use them every day in apps like Excel, Google Sheets and BI tools, it’s easy to underestimate the complexity of the components that we’re using.
To actually build those components take a lot of planning, design and development that is often not immediately obvious. Sure, there are charting libraries like Tremor and ChartJS that can give us a head start on building the charting component itself, although a lot of work is still needed to massage it into something that resembles your initial designs.
On top of that, you’ll need to consider
- creating a secure database connection;
- performance and loading speeds (a common issue with embedded BI tools);
- a caching layer - multiple layers if you want the best performance;
- an architecture that scales up and down as required to ensure cost-efficiency,
- authentication and row-level security;
- custom interactions like filters and drill-downs, requiring their own considered architectural and UX approach;
- “oh and you want it to say ‘yesterday’ instead of the dd/mm/yyyy date when a user selects it using the date picker”;
- “and we want…” the list goes on.
The levels of complexity compound as you peel back each layer of the task you’re undertaking and what seemed like a simple user story is now an epic (in the literal and metaphorical sense).
Charting Element Teardown
The best way to explain why building charts is so costly is to take a simple chart with some custom interactions and highlight some of the considerations that were needed to build it.
Let’s give an example from a tool we love : Stripe (if you are reading this, bravo - you guys did an excellent job!)
We’ve chosen the simplest data insight chart, that any business will be familiar with - a payments chart.
Looks like a simple horizontal stacked bar graph, a key/data table, some titles and a date picker, right?
Well, let’s drill down into how much functionality Stripe’s product and engineering team had to consider to get this ‘simple chart’ into action.
Below is an exploded view of the chart with a breakdown of considerations and design decisions that Stripe have worked with their engineering team to then build (the list is not exhaustive).
And what about that ‘simple date picker’?
Below you’ll see another exploded view of the date modifier element, its subcomponents and interactions. Maybe Stripe used a component from an open-source library and modified it, but take note of the level of customisation Stripe would have to have designed, planned and implemented in order to make it behave in line with the rest of their platform, e.g. the transitions on opening, closing and navigating through the calendar view.
Not to mention that it’s hooked up to all of the other graphs on the dashboard and each of those has its own built-in logic to handle modifications.
“Ok, so it’s complicated. But it’s not that hard to build” I hear you say.
Remember this is only one ‘simple’ chart (on a dashboard of 7 major, and 2 minor analytics components), and a ‘simple’ date modifier. All of those charts and elements load instantly, and dynamically change when the ‘test mode’ is selected in the top right corner of the page. Stripe also allows you to interact, reorder and configure which charts you see. This is not possible with any embedded BI tool on the market.
By building this themselves, they have also given themselves the opportunity to add actions and behaviours that invoke other changes in the users' experience, like persisting your date range selection as you navigate away and load completely separate parts of the app, e.g. from Dashboard to Billing - which by the way is home to a further 17 fully-custom, interactive, interconnected charts.
You get the point. Building truly remarkable, fully-custom analytics from the ground up takes a colossal amount of design, product and engineering effort. All scarce resources.
So, what approach should you take to add analytics to your app?
If you're reading this article, you've probably identified an opportunity to deliver valuable data insights as a part of your customer experience. Maybe you've explored embedded analytics tools available and found that the options to deliver that value to your end users are not ideal:
You could decide to create your embedded analytics using a BI tool and deal with the inflexibility, low customisation and inferior performance. You could make the investment in building it yourself and reach the dizzy heights of Stripes (frankly first-class) user-facing analytics experience - at an astronomical cost.
Or, you can choose to create your own remarkable, fully-custom analytics experience in just 10% of the time, with Embeddable.
Embeddable combines a front-end toolkit, backend engine and no-code builder to give you full flexibility over your user experience, whilst handling the complexities of performance, authentication, caching, row-level permissions and maintenance for you.
Find out more about how it works by checking out Embeddable.com, and getting in touch with the team.
*Please note, researching Stripe’s analytics was completed on August 15th 2023 using Google Chrome, on a Macbook Pro 13” at 100% zoom - it does not cover any custom/responsive behaviour for different screen types/browsers.