Using analytics embedded in your application to drive new revenue streams isn't exactly easy. In fact, I think that it's a much more difficult problem to solve than implementing analytics for your own team's use. It's really not too surprising because, while companies have been implementing business intelligence applications inside their organizations for years now, the concept of an "OEM" or embedded analytic product is relatively new. And as a result, we are collectively still working understand some of the basic concepts that are fundamental to creating great data products.
A great place to start understanding embedded analytics is by reviewing the "Three Faces of Embedded Analytics". It's a nice starting point because this concept is directly tied to defining the underlying data you'll need to access and to the ways you might offer your data product to users. Get it wrong and you can end overlooking some valuable ways to generate revenue.
The three faces of embedded analytics are:
- Primary data (or "your data")
- Secondary data (or "our data")
- Tertiary data (or "others' data")
This requires some explanation. These three ways of thinking about data are sort of a maturity model for embedded analytics. As you work your way up the pyramid, you unlock new ways to monetize your analyticsLet's start with the most common method for embedding analytics: primary data.
Primary data ("your data")
This is where most product teams start—and stop—when they are thinking about adding analytics their product. The conversation goes something like this: "hey, we've got this data that users produce as they are using our application; why don't we display that data in a nice visual format?" The team then gathers the information in their transactional systems, data warehouses, cloud platforms, etc. and combines it into a single view for the customer. As users, we get to see "our data" displayed in a manner that makes it easier to see patterns and outliers and identify where we might need to explore further. Nothing wrong here, but don't stop with primary data. There are other ways to create value.
Secondary data ("our data")
Secondary data is the next level up on the embedded analytics maturity scale. Here, you're adding the data of others to your own to create new insights into performance. Often, this is thought of as benchmarking but a more apt term might be "comparative data". Picture this: you've implemented your embedded analytics product based on primary data—each customer can see their own performance using charts and tables—but they can see ONLY their own data. Is it good? Bad? Who knows? This is where secondary data comes into play. As the analytics provider, you might aggregate data across your customer base (anonymized of course) and then use those averages, minimums, and maximums to allow users to compare themselves to the rest of the world. Instead of just seeing "our data", I can now compare myself against "your data" and decide if I'm at, above, or below your performance. It's a great way to help users put performance in context. But wait, there's more...
Tertiary data ("others' data")
Every product team embedding analytics understands primary data and many consider secondary data. But what about the 3rd use of data—tertiary or "others' data." This case is completely different from the first two in which you are displaying data generated by a user to that same user, perhaps in comparison to other users' performance. In the tertiary data case, you are displaying the data to consumers other than those who generated it in order to deliver insights. A good example of this is census data. Although generated by individual households, census data is rarely used by the people who generated it (the households). Instead it's used by businesses who are interested in market size, buyers' incomes, or where to locate the next store. It's data being generated by someone different than the final user.
It works the same way with data generated from the use of applications. Say you've got an application used to dispatch trucks all over the country to deliver good from the shipper to the store where those good will be sold. In this situation primary data would be analytics based on the dispatching of your trucks, secondary data would be the averages, and min/max times derived from aggregating the data from all users, and tertiary data would be if you then bundled that data and sold it to a firm that used it to predict traffic flow patterns. Clearly these tertiary data users aren't the same as those who you'd normal think of as your customers, but they can receive value from your data nonetheless.
Using these concepts in the real world
Too often product teams only think about primary data when developing a data product. They ask "what analytics can we show our users to add value?" Most then add benchmarking or other forms of secondary data to later stages in the product roadmap. This is a great starting point, but a terrible place to stop. To maximize the revenue potential from your analytics you have to consider all three types of data use: primary, secondary, and tertiary.
Launch your embedded analytic product based on primary data. It's a logical place to start and the easiest to explain to potential buyers.
After launch, consider adding a secondary data-based option—an add-on purchase that the customer can select that will give them access to comparison data. Being able to see how you perform agains others in the industry is an enticing proposition.
Finally, consider other use cases for your data. If you aggregated and anonymized your data, could it be of use to some other business beyond your primary customer? Could you sell these aggregated insights as economic indicators or as patterns that might benefits a wholly different customer set? A great way to answer these questions is through a simple brainstorming exercise. Start writing the types of data to which you have access on a sheet of flip chart paper (eg. sales data, pricing information, location data, etc.) Next, combine each type of data you listed with another and see if the combination might be useful — sales data mixed with location, truck routes by buyer type, etc. and see if any of the combinations might be valuable. Finally, for any data combos that you listed that might have value, identify who might use such data (financial institutions, data brokers, etc.). Each of these combo/buyer sets is a potential data product that you might offer.
Each case is obviously different, but tertiary data represents a vast untapped market for many businesses. As long as you're adding analytics, why not think beyond the standard use cases and make the most of your investment?