The Hierarchy of Embedded Analytics

March 28, 2019
Kevin Smith's picture
VP, Product Marketing
Kevin Smith is Vice President of Product Marketing for GoodData. Prior to GoodData, Kevin was responsible for delivering consulting services such as analytic product strategy, data monetization, and go-to-market services at NextWave Business Intelligence. He is the author of numerous ebooks, articles, and webinars on embedded analytics and building data products. In addition to NextWave, Kevin has held leadership positions heading analytics teams, designing SaaS products, and performance and managing product teams for both small start-ups and Fortune 500 companies such as SAP, ServiceSource, and Qwest Communications. Kevin holds a B.S. in Finance, as well as an M.B.A. in Quality/Process Management, both from the University of Maryland, College Park.

Just a few years ago, product leaders had limited options if they wanted to add analytics to an application. These days, the embedded analytics space has exploded, and the definition of "embedded" has become so diluted that it's sometimes hard for companies to know what vendors mean by "embedded analytics."

In reality, a simple definition of embedded analytics isn't enough for your product team.  You need to understand exactly how you will embed your analytics. That’s because there are many ways to "embed" analytics in a product and the method you choose can determine the overall user experience for your users.

Those different ways of embedding analytics within your product typically fall into one of three categories: in a portal, in a separate area of your application, and in context. Each of these ways of embedding analytics reflects a different degree of analytic integration within your core product.  

1. Use a separate portal for analytics

The simplest way to embed analytics into your product is as a "portal" that works with but isn’t technically part of your application.

Think of someone using a help desk application to close out issue tickets. To get some more insight into her performance, she clicks a link within the application to visit a dedicated analytics application. After reviewing her performance in the portal, she returns to the help desk application to continue working.

While this option tends to appeal to companies who just want to get their feet wet with analytics, it’s not the best choice for a number of reasons. First, it requires the user to switch back and forth between the application and the analytics portal—which isn’t an easy or intuitive way to use analytics. Second, it creates a disjointed experience for the users. Even if you brand the analytic application, it’s still an uphill battle to make the experience seamlessly integrated for the user. It’s easy to overlook that the portal and insights are available if one has to go to a different location.

2. Embed analytics as a separate section within your product

An alternate method for embedding analytics in your application is the "embedded but separate" approach. Although the analytics are often provided by a separate application behind the scenes, a user would likely think it’s all part of the same application because they don’t have to use a separate tool to get to the insights.

In our help desk example, our user would simply click on the "Analytics" tab of the application to start reviewing her performance. Behind the scenes, her credentials are passed from the help desk application to the analytics platform, which is then displayed in a section inside the help desk app.

This is better than a separate portal, but it’s still not ideal. Though they’re working out of one application, users are tasked with remembering that they should be using analytics and then navigating to the part of your application that houses them. Not exactly the most intuitive process and the outlook isn’t great as far as user adoption goes.

3. Embed analytics in context

When analytics are embedded in context, they’re displayed alongside workflow elements performed by the core product. Our help desk user no longer has to log into an external portal or navigate to a separate tab to see performance. Instead, she sees analytics describing her open tickets, closure rate, and customer satisfaction score on the same page as her work queue.

This approach has major benefits, and chief among them is that users can see the important insights from where they’re already working. Now users can see at a glance how they’re performing, and they can explore recommended next best actions based on the insights presented. This helps them understand how their workflow and business will be impacted instead of just occasionally referencing a visual.

These three different methods can all be considered "embedded analytics," but what they can accomplish varies widely. If you want a completely seamless experience where users see analytics alongside or within their workflow and can take action based on what they see—which is what most companies want— then "embedded in context" is the option you should pursue.

Want to ask about something specific?

Contact us