Update: 11/30/2017. This article was originally titled "The Foxhole or the Dining Hall? Selecting a strategy for embedding analytics into your product." The title has been changed because, well, the old one was really bad.

It's a great time to be alive if you're a product owner looking to add analytics to your application.  Just five years ago you had very limited options.  Although there were many analytics or business intelligence platforms, few were truly suitable for creating analytical functionality that you could use to monetize your data.  This certainly isn't the case today.

These days you've got options—many, many options for implementing what's generally termed "embedded analytics." It's a hot field right now and that brings its own set of problems.  Specifically, as the embedded analytics space has exploded, the definition of "embedded" has morphed, twisted, and become so diluted that it's sometimes hard to know what vendors mean when they claim "embedded analytics".

As a result of this ambiguity, product owners are sometimes left wondering how they can use various business intelligence platforms to monetize their data. Can I use this for embedding? Can I use this other one as a standalone product? Where do I begin my search?

Before you start evaluating features or selecting vendors, you need to get a handle on what YOU mean when you ask for analytics in your product. Although it seems simple, it really isn't so straightforward. There are many ways to "embed" analytics in a product and the method you choose can create limitations for your product roadmap and determine the overall user experience for your customers.



To start, when a product owner says "embedded analytics" what they often mean is "I'm adding analytics to my product so that my customers will be able to see trends and patterns." The essential parts of this definition are:

  • It's primarily for end-user customers
  • It co-exists alongside an application used by customer

In order to be "embedded analytics" as used here, you must be offering those analytics as part of your product and it must be used by your customers rather than your internal team.  It sounds pretty simple, but wait—there's more...

It used to be that the word "embedded" brought to mind an intrepid war reporter, bravely risking life and limb as they reported the news embedded alongside troops on the front lines of battle.  Of course, even then the term could have different meanings.  It could refer to a brave reporter hunkered down in a foxhole reporting alongside the troops under the most adverse of conditions...  But it could also mean a reporter "embedded" with the dining hall staff, miles from the action with a very different perspective on the situation.  The term "embedded" used in this case might have a wide range of meanings.

The same is true of embedded analytics. Like with the case of the reporter, you can be embedded is many different ways: 

  • Do you log into a different application to get to the analytics?
  • Are the charts and graphs right inside your product, but in a different tab
  • Are your analytics inside your product and integrated into the workflow?

All of these are valid examples of embedding data in your product. A simple definition of embedded analytics isn't enough for your product team.  You need to understand exactly how you will embed your analytics.


Here are three ways to go about embedding analytical capabilities within your product. Think of it like a "Maslow's Hierarchy" for your data: as you move up the hierarchy you gain in tightness of integration into your core product and in improved user experience but at the expense of a (potentially) more complicated project.   


Level 1: A Separate Portal for Analytics

The simplest way to embed analytics into your product is as a "portal." This is simply an instance of an analytics platform that works with, but isn't part of, your product. For example, here's how it might work in a case where the core product is help desk software...

The user of the help desk application is working on closing out issue tickets and would like to see analytics describing their performance. They click a link within the help desk application and are taken out of the system to a dedicated analytics platform (the portal). Once they've completed their mission in the analytics tool, they then click back over to the help desk application to continue their workflow.

Analytics portals can run the gamut from very simple with no single sign-on and limited branding (they sometime aren't even branded with the logo of the core product they assist) to more tightly systems with single sign-on, cohesive branding between the core product and the portal, and links back to the core product.

Here are a few thing to consider when evaluating a portal approach:

Why might you choose this approach?

  • If you are planning on simply replicating existing reports for your users (e.g.  taking your MS Excel reports and making them available on the web) without tailoring the experience to specific personas or missions, a portal works well.
  • It's a great choice if only a few customer need analytics capabilities and you don't want to have to support dashboards for every user.
  • It works well if the customer of the data isn't the same as the customer of your core product (e.g. you've got an application that provides help desk management workflow but the analytics would be for the hardware manufacturers who will never log into the actual help desk app).
  • You aren't concerned about usage or user engagement with the analytics.  If people never click the link to visit the external analytics portal, it's not a concern.

Why wouldn't you choose a portal?

  • It's not the best choice if you want to show analytical information about a user's workflow. The user will have to switch between the application and the analytics portal.
  • It's not the optimal choice if you want a consistent user experience.  Users will have to log in to the portal and navigate a completely different application.  And although you can brand many analytics applications, it's often difficult to make the experience feel seamless for the user.
  • It's a poor choice if you want to compete on your analytical functionality. If your plan is to use analytics to reinforce your position as a "trusted advisor" to your users—the branded portal isn't ideal.  Any "wow" factor resulting from gained insights is at risk of being conferred onto the analytics platform instead of your product as a whole.

The analytics portal, while it can be considered as "embedded analytics", is closer to the example of the reporter embedded over by the dessert section of the dining hall than that of the reporter up close to the action.

Level 2: Analytics application embedded as a separate section within your product

An alternate method for embedding analytics in your application is the "embedded but separate" approach. Here, the analytics are accessible as a part of the core product—you don't need to exit the main application and log into a separate analytical tool to view your data.  Although the analytics are often provided by a separate application behind the scenes, to the user it feels like all the same application.  Returning to our help desk product example, here's what a user of an "embedded but separate" analytical product might experience:

The user of the help desk application is again working on closing out issue tickets and would like to see analytics describing their performance. This time however, the simply click on the "analytics" tab of their application and can immediately start viewing their performance. Behind the scenes, the user's credentials were passed from the help desk application to the analytics platform which was then displayed in a frame inside the help desk app. The user likely wasn't aware of the distinction between systems and in most cases the branding (color schemes, naming conventions, logos, etc.) were consistent to further tighten the experience.

Sounds awesome—this is the method chosen by many companies for their data products—but there are a few considerations when going the "embedded but separate" route:

Why might you choose this approach?

  • You want to use analytics to strengthen your product by showing insights as part of the main application—not a separate application.
  • You want control over the user experience and don't want users having to log into a separate system.
  • You want to make sure that users know the analytics are there and increase the probability of their regular use.
  • You've got an immature product and by showing the logo of the analytics provider within your application will lend a small degree of credibility in your capabilities.

But, you might not want to use this approach if:

  • The people who use the core product aren't the same as the people interested in the analytics (e.g. help desk employees want to use the workflow aspects of the product but not analytics while vendors wouldn't use the workflow, but need analytical insights).
  • You can't provide a consistent experience between the core application and the analytics tab or page.  For example, your product has logic to convert prices to local currency but the analytics would be based only on U.S. dollars using confusion for users.
  • The analytics are most valuable if shown alongside the work being performed, not in a separate area.

With the "embedded but separate" approach we've move from the dining hall and a bit closer to the action. We're not exactly on the front-lines, but we can see them from here.

Level 3: Analytics embedded in context

The top of the embedded analytics hierarchy is reserved for analytics embedded in context.  In this model, the analytics are displayed alongside workflow elements performed by the core product. For example, 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.

In this model the analytics may still provided by an analytics vendor, but instead of being accessed as a bundle inside a dedicated application or tab within your product, individual charts and tables are pulled from the platform and embedded into the core product. This approach has a number of benefits and a few drawbacks to consider:

Here's why you might choose this method:

  • You want to allow users to see performance as they work, potentially increasing engagement.
  • You need to reinforce the product's role as trusted advisor to the user ("see, we don't just show you what you need to do, we also help you understand your performance!).
  • You want to increase the overall utility of the analytics by combining them with other interactions such as commenting or root cause analytics. Users will be able to see the data and then take action based on what is displayed.
  • You plan to offer actions or remedies that the user can take based on the insights from the analytics (i.e.  conversion rate is going down—we recommend that increase ad buys).

But, you need to consider some drawbacks:

  • This method often takes longer to implement. You may need to re-architect sections of your product to accommodate the analytics alongside the workflow components.
  • If the analytics don't perform well, they can bring your whole product to a crawl. Imagine seeing your help desk list of open tickets framed by a bunch of spinners where the analytics are still loading...
  • You're now much more tightly coupled to the future of your analytics vendor. It's much more difficult to replace analytics embedded in this manner than those on a portal or separate tab if necessary.



Three different methods—all of which can be considered "embedded analytics" but which follow very different paths. In order to choose between these techniques, your product needs to ask itself: "what are we trying to accomplish with our analytics?"

If the answer is "give data to users outside of our normal product use case", "provide analytics to a subset of users", or "make our existing report available online" then the portal approach might be for you. 

  • If you want to reinforce your product as provider of analytical insights, then you should consider tighter embedding like the "embedded but separate" method.
  • If you want a completely seamless experience where users see analytics alongside workflow and can take action based on what they see, the "embedded in context" direction is the one you need.

The important thing to keep in mind is that while each method outlined here is valid and can value for the user, what they will experience differs greatly across techniques. Do you want to be in the foxhole with your customers or is it fine to be a bit farther down the road?  Understand your goals and which benefits your users need from the analytics and then pick the best approach for your situation.