Editor’s note: this article is brought to you by GoodData and Product School. Don’t forget to sign up to our unmissable workshop; Build Customer Facing-Analytics with Headless BI with GoodData PMs.
If you’re a Product Manager in the SaaS space, we don’t need to tell you the importance of a good data analytics experience. Data is already your bread and butter. You need it to provide the insights that help you perform continuous delivery, design, user research, and prioritization.
But for teams building SaaS products, even if you’re not building specifically a data product, it’s important to remember how important analytics is to your customers.
SaaS products, like any other product, are typically designed to do one specific job and do it very well. Whichever audience or vertical your SaaS product serves, most aim to serve one or maybe two particular user needs. And no matter what kind of product you have, it’s collecting tons of data.
Your end users likely need and want access to their data, as it tells them important information about the problem they’re trying to solve or the goal they’re trying to achieve with your tool. Sometimes this need is obvious, and a top priority as a feature of a SaaS product. Email marketing tools provide data that helps teams to perfect their funnels, heatmap tools provide key data to help teams build better websites. Having access to the data gathered by the tool is non-negotiable for the end user.
Sometimes the need for the data gathered by a SaaS product is not quite so clear. This is particularly true for products that teams are only supposed to use internally, like HR tools or project planning suites. Users may still need access to this data to measure their output/team performance. If there are any credible use cases for a data analytics experience within your product, it’s worth doing well.
More often than not will find themselves having to export it out of the product in order to manage and analyze it. This puts you at risk of losing your users to competitors who may have a less powerful tool than yours, but one which provides a better analytics experience. If a competitor is able to, for example, allow users to generate their own reports within the product, your product may feel incomplete in comparison.
It goes beyond the simple fact that the more users can do with your product, the more they’ll like it. Of course, when the ability to track, manage, and analyze data is included within the user experience of your product, users stay engaged with it. And this helps you to maintain your competitive advantage.
Being able to provide a more complete analytics experience gives you more opportunities to upsell. For example, you provide freemium users with 50% of your analytics capabilities and leave the other 50% behind a paywall.
So you know the value of analytics, you know the value of keeping your customers engaged and out of your competitors’ reach. So the natural conclusion is to provide your users with a great data experience within your product.
Depending on how seriously you plan to bring an analytics experience to your users, you have the option of providing them with differing levels of analytical tools.
On the first level, you can provide simple reports and charts that you place on a relevant product screen. Although this effort looks like an easy engineering investment, connecting to the database and visualizing the graph with any JS library on the market poses a big challenge for product management. You have to plan carefully which reports and charts are essential and valuable for all of your users. And you cannot clutter your product experience with charts for any occasion either. The scope of analytics usually leads to new change requests, either in the range of the data or the format. If your customer base is not homogeneous, you will have difficulty prioritizing which reports and charts to include.
On the next level, you will bring charts and reports into a dashboard experience. Your product engineering team can create dashboards according to use case or the user persona, which allows better personalization than a simple chart for everyone. To narrow down the search, a user should apply filters within the dashboard, such as date or attribute filters. However, with dashboards, you will invest more effort due to the responsiveness of any device. And also, here, your users will likely seek different stories than the dashboard conveys, eventually ending at your support team’s desk with a change request.
On the next level, the analytics can extend the product use cases at the point of work as a hint for a decision, such as approving or denying a claim based on a specific measure. Here, instead of going to the dashboard to get acquainted with current numbers, the user sees the result directly within the step of the product user flow, just as a simple number or help.
All of the approaches above bring a great analytical experience but pose a risk for the product teams — overloading them with customers’ requirements for additional reports or change of scope. Maintaining such an environment with custom queries for each of the customers is unmanageable for any growing product. The solution that covers all the above approaches is to provide self-service analytics. With self-service tools, where users can drag and drop measures, attributes, and filters to create their reports that they can add to their own or their team’s dashboards, you will save your backlog from the clutter of change requests. However, this approach requires an enormous development effort if built in-house. Besides the obvious security concerns — meeting all the compliance requirements and ensuring that the users see and query only the data they are entitled to — you need to ensure that users understand the information they use. However, understanding the meaning of all the data artifacts is difficult if your database schema is not a simple schoolbook example with one fact table and four dimensions. You have to introduce a catalog for your users that corresponds with the business semantics and translates the requests to the back-end and the data sources. This concept is called a semantic model. Moreover, it would help if you allowed the ability to compose predefined metrics to simplify the creation of ad hoc queries and minimize the risk of your users making decisions based on incorrect data, which can lead to more of a headache than having no analytics.
Unless your SaaS product is primarily a data product, you probably don’t have the engineering skillset to build an application with scalable-friendly architecture. Moreover, you should not limit your roadmap to analytics features since your main value proposition focuses on different use cases.
To achieve a complete analytical experience while not jeopardizing your core product roadmap is to integrate with a 3rd party embedded analytics platform. Such a platform should work either as a hosted service or as a cloud-native application. With cloud-native architecture, your teams can deploy it to your current product stack, ensure real-time data processing, and skip the data copying between servers. Embedded analytics is a data analytics software integrated into another business software solution, where two individual elements are brought together as one. Often, so seamlessly integrated, the non-technical user is unaware that they are working with two pieces of software.
However, it is not only about having static dashboards and reports embedded into another business application or portal. In particular, it’s about integrating and managing all the pieces of the puzzle that make accurate, interactive, and attractive data visualization possible. That includes connection to various data sources, including federated queries, fast, accurate updates and changes of your analytics scope, and meeting data privacy and security standards such as GDPR or CCPA, to mention a few. These technical aspects that your users don’t see — unlike self-service or visualization — are crucial for the product’s operation.
It’s preferable to use a solution that provides a front-end SDK for rapid development of the analytical interface and open and declarative APIs to the analytical platform with low-code and no-code services built on top of these APIs that can combine and compose as you need. This approach is also called composable data and analytics, where the core element, headless BI, ensures the core BI capabilities, such as metrics consistency and management. It empowers your product developers to build features that can fit into your core application. Either by predefined building blocks or with custom code, making the delivery of analytics into your product just another software development project that fits to your engineering teams’ lifecycle.
Integration of analytics as code into your existing product is the most seamless way of embedding, one where your customers and users won’t be able to recognize that they are using another piece of software. It also gives you endless possibilities in building the feature set you and your users require, allowing your teams to work with APIs rather than embedding a fixed dashboard or report. To succeed in the world of SaaS products, you need to rely on your product team and on the technology you provide to your customers. For analytics, building it from scratch in-house brings a lot of risks. Therefore you should partner with a 3rd party analytics platform that brings the power of composable data and analytics as well as headless BI to your developers, like GoodData. But you also need a strong product vision and the ability to execute. The only way is to invest in your product team by enabling them with education — and that’s where Product Management certifications come in, teaching the essential skills needed for building any digital product.
About the Author
Tom Kratochvil is a Senior Manager of Product Marketing at GoodData. With over 11 years and counting in the global software industry, Tom always strives to build the right products and services for the right audience, at the right time, while wearing the hats of technical product management and product marketing.