Product Analytics refers to using data analysis techniques to gain insights into the usage, performance, and user behaviour of a Software as a Service (SaaS) product.
Embedded Analytics refers to integration of analytical capabilities directly into SaaS applications or business processes, allowing users to access insights about their own data without leaving the application environment.
Product Analytics
SaaS Product Analytics tools work by collecting, processing, and analysing data generated by user interactions with a software application or platform.
- The process begins with the instrumentation of the software application or platform with tracking code or SDKs (Software Development Kits).
- This code is integrated into the application's frontend, backend, or both, depending on the type of data to be captured.
- The tracking code collects various types of events and user data, such as clicks, page views, feature usage, user attributes, and custom events defined by the application's developers.
- Once the tracking code is deployed, it starts capturing data whenever users interact with the application.
- The data is typically sent asynchronously to the analytics tool's servers via HTTP requests or other communication protocols.
The data may include information such as timestamps, user IDs, session IDs, device types, operating systems, browser types, and any other relevant metadata. How is this used?
Understanding user behaviour
Whether prioritising product features, optimising marketing strategies, or refining user experiences, product analytics helps SaaS solution providers make decisions based on empirical evidence rather than subjective assumptions. Common areas of measurement include:
- User Adoption: The number of users signing up for the product and how frequently they use it.
- User Engagement: Metrics such as time spent in the application, number of sessions, and frequency of logins.
- Feature Usage: Which features of the product are being used most frequently and which are being underutilised.
- Retention and Churn: How many users are continuing to use the product over time (retention) versus how many are cancelling their subscriptions (churn).
- Conversion Rates: The percentage of users who take a desired action, such as upgrading to a paid plan or completing a specific workflow within the product.
- Customer Satisfaction: Feedback gathered through surveys or other means to gauge user satisfaction with the product.
Agile product development
Through A/B testing, cohort analysis, and funnel optimization, solution providers can refine their products iteratively, addressing problem areas and enhancing usability.
User-centric engagement, retention & differentiation:
By analysing user behaviour and feedback, businesses can tailor strategies to enhance engagement, reduce churn, and foster enduring relationships with their customer base.
Embedded Analytics
Whether your SaaS solution is focused on: education & e-learning; energy & utilities; finance & banking; healthcare; insurance; retail & ecommerce; telecommunications; transportation & logistics or other industries B2B SaaS solutions serve; analytic insight is going to be a top 3 criterion to select one solution over another.
Let’s explore those two words “embedded” and “analytics” in the context of how B2B SaaS solution providers want to use this to deliver value to their customers:
Embedded
A way to think about embedded (analytics) is across three technology stack levels: (i) data; (ii) logic; and (iii) UX.
Embedded DATA
Data sources may be human, as people interact with your application, they input data. There might be, often IoT, sensors collecting data as machines carry out automated tasks, perhaps monitoring environmental conditions or your application is monitoring status changes resulting from business rules or application logic. Data might be sourced from other applications or perhaps 3rd party data sources such as benchmark data.
How is this data stored?
The first, perhaps greatest, challenge is data might be stored in different formats, in different operational data sources such as Structured Query Language (SQL)-queried RDBMSs, No-SQL data repositories, files and file systems as well as other (often REST web service connected) data sources.
ETL
There needs to be a way, normally an extraction, transform and load (ETL) process, on an automated, ongoing basis (data collection doesn’t normally stop), to merge these different data sources into a single format, dynamically updated, rationalised and modelled. This way, realistic and credible, analytic value can be derived and without loading operational systems. This probably represents 60% - 80% of the time and effort.
Technology diligence
There are different ways to store this analytic view of the data and selection of an appropriate technology for this warrants some diligence.
An obvious choice would be a RDBMS. The advantage of this is the technology is almost certainly in use in your company as well as your customers today.
Another choice for analytics-focused applications, are in-memory data repositories. These are typically coupled with query syntax optimised for analytics.
Reporting or analytics?
SQL works well for simple queries, ideally for algorithms requiring few traversals of the data or optimal usage of the foreign keys resulting in flat tabular structures…sometimes visualised as reports.
Analytics is often not like that. Analytic user experiences can be combinations of interactive tables and other visualisations working dynamically together to explore numbers-behind-the-numbers, whys-behind-the-what's and navigate root-causes behind anomalies…not just flat tables.
Using a query method that can exploit dimensional models in memory, means the data infrastructure is designed to respond in real-time to analytic journeys which can be challenging for SQL-oriented RDBMSs.
Embedded LOGIC
Once an analytic data repository has been selected as a “single version of the truth” for analytic purposes, thought needs to go into producing “real” or “truthful” answers to queries which “add-up”. This includes calculations, scores, KPIs, filters and aggregations which are reflective of business rules, understood and accepted, contextually, by end-customers:
Filters & aggregations
Even with simple filters and aggregations like a “sum” or a “count”, it’s surprising how quickly this turns into a “discussion” or even a debate….”counting what and how?” or “summing what and how?”.
Missing or inaccurate data will give skewed results undermining the confidence of customers. Perhaps filtering one way gives one result, while a similar filter another way gives a worryingly different result.
This is why verified definitions (such as what is “cost” or “profit” or a “customer”?...for instance) which describes how things are counted and aggregated, are important for the credibility of the solution and the satisfaction of the customer.
Business rules and management-by.exception thresholds
When a customer buys something, what happens? Is that person or company categorised, counted and measured differently? Do processes change for that customer to drive loyalty and recurring purchases?
Business processes and rules drive these processes and must also be reflected in the analytics. We flag the status of people and things so that they can be measured and analysed.
Management-by-exception thresholds are useful for this. For instance:
- If high revenues are “good”, we should have a definition for revenue and define a (presumably numeric) threshold above which revenues are “good” so that customers can look at how, why and where that is happening and capitalise further.
- If low profits are “bad”, we should have a definition for profit (a %age of revenue calculated how?) and define a (presumably numeric) threshold below which profit margins are “bad” and presumably need attention.
Navigation
With dashboards, users naturally want to start navigating to explore the numbers behind the dashboard. That’s a benefit of using a dimensional model. Instead of coding every analytic interaction, dimensions and measures can be used to expose navigation paths without the need to code everything.
Security
Pairing dimensional navigation with security results in robust, granular and easy-to-maintain “cell-level” security…in other words, automatically determining which users have access to which measure across which dimensions.
There should be no need to duplicate user management nor any reason to duplicate the security regime that you have in your SaaS already. The expected scenario would be a translation script, or “handshake”, where the host application sends security parameters on-the-fly for each user dynamically and the model excludes anything that user should not be able to see based on their roles and permissions.
Calculations, KPIs, Scores
There are simple calculations like adding up order lines, or perhaps industry benchmarks (such as CAC, NPS, LTV, valuation…) but these can get more sophisticated and sometimes this sophistication is differentiation for your customer.
Sophisticated might come in the form of dynamic variables, perhaps based on operational performance (e.g. what’s selling well/badly), or in the use of statistical formulae or models (prediction based on a regression for instance).
You might go one step further and develop your own predictive and other algorithms and process result sets in your embedded analytics.
Embedded UX
Despite often being the focus for SaaS product and development teams, analytic visualisation and user experience are the relatively easy parts of the equation. Here visualisations (sometimes called “widgets” or “gadgets”), most commonly:
- Tables
- Charts
- Gauges
- Maps
- Custom visualisations
- Filters
are rendered individually, in multiples or in combination as part of your UX.
It’s common for people to use the word “dashboards” as if analytics is comprised solely of dashboards; however analytic visualisations either individually or in combination, typically add value as not just dashboards, but also immersed contextually and pervasively throughout your SaaS solution:
- For a fleet management SaaS solution, in a vehicle, ship, aircraft, container, bill-of-lading or shipment
- For a workforce management SaaS solution, in an individual employee, location or resource such as a room or (remote/virtual) desk
- For a property management SaaS solution, in building unit or asset under management such as a lift, boiler or air conditioner
- For a healthcare SaaS solution, in a bed, patient, healthcare worker or piece of equipment such as scanning machine
- For a procurement SaaS solution, in a PO, supplier, article or SKU
The idea that analytics is just about dashboards under-delivers against the value of embedded analytics. Analytics should be present wherever it adds value…potentially every level of detail, including at individual record level.
With embedded analytics, you expect out-of-the-box visualisations. 3rd party visualisations can be plugged-in or perhaps you design your own (typically javascript) custom unique visualisations such as floor-plans, machine or process workflow diagrams.
You’ll have a method to feed data and variable (filter) parameters to/from these visualisations to reflect the data being visualised contextual to the process or part of the application and based on who the user is.
There will also be theming, typically beyond CSS alone, as well as a means to define behaviour of the visualisation…for instance what happens when you click on the slice of a pie-chart…perhaps this renders a filter or drill-down to a more detailed perspective.
These analytic user experiences, comprising single or multiple visualisations, are typically inserted into web-pages using html <iframe> or <div>.
Analytics
3 phases to embedded analytics
A first step for SaaS solution providers is to develop an API to enable customers to export data from the SaaS application. That’s a shame, because that circumvents an opportunity for solution providers to give the customer added value typically through analytics-focused IP.
The next option is using javascript visualisation libraries. These make it possible to create attractive frontend analytic user experiences, but it doesn’t really address the issue…which are data complexity, data integrity and query performance.
Subsequently, a SaaS solution provider might investigate embedding a BI tool, though 2 challenges are: (i) BI tools are ideal for data analysts and data scientists in a standalone scenario, they’re less suited to disappearing into applications where the user is not a data analyst or data scientist; (ii) their licensing and pricing are often challenging for SaaS licensing models.
The idea with embedded analytics is to bring the best of all approaches (exports, visualisation and dynamic/interactive user experiences) into one platform.
Analysis or getting things done?
When using the word “analytics”, the assumption can be the primary purpose is analysis. Solution providers start down the path of providing BI like functionality inside their SaaS product. This often means a self-service and ad hoc analytics focus.
While analysis may be of interest to non-analysts, the primary question to answer is: “What to do DO with that analysis?” or “What action to drive from that analysis?”
For embedded analytics, this requires close integration with the host SaaS not only to navigate to parts of the application where actions can be executed, but also potentially at scale (multiple actions), at the click of a button, where each action execution is individually parameterised.
Conclusion
Product Analytics and Embedded Analytics are both important capabilities that bring value to SaaS solution providers, but they are not at all the same.
Product Analytics will help you monitor your SaaS usage and product engagement internally, while Embedded Analytics will bring the value of your SaaS as analytic capabilities for your customers.
Let’s make sure we have a clear understanding for each before exploring the value they can bring, perhaps together in concert.
See our Embedded Analytics page to see how we are doing embedding.