Many of our conversations start out with how Verb Data is different from any business intelligence tool or embedded analytics tool on the market. From our experience, it’s important to separate internal and external-facing analytics because they are very different used cases and require different outputs. We’ve put together this post on how to take an iterative, product-mindset approach to customer-facing analytics.
Different Requirements and Approach to Data Infrastructure
Firstly, think about who will be the audience of your data. Most customer-facing solutions only require product data whereas internal analytics will require many more sources. Where you curate this ingested data is also a different decision when embedding SaaS dashboards in your product for customers. Performance is equally important to consider. The load time is much more important for your customers than internal users. When there are slow load times it reflects poorly on your entire product and can even impact other areas of your product.
Most of our customers run analytics in a multi-tenant environment meaning that segmenting and securing their data is more complex. As the product evolves, it’s vital that security rules evolve with it. You can also protect your users from breaking changes. When a data pipeline breaks or schemas change, the service level agreements may be questioned and tolerance for issues is generally higher internally than when the issues affect customers.
Where to separate the customer analytics and internal analytics is an important decision to make but it is different for everyone. We’ll write about that in a later blog post.
A Product Approach to Analytics Dashboards
Your product is used by many people and each one is going to have slightly different use cases and processes so it will be impossible to create the exact dashboard that every user wants. However, settling for a dashboard that is only 80% correct (showing the metrics a user wants or calculating a metric the way a user expects), will not provide enough value to your users. As a data product manager, it’s your job to find an approach that works well for everyone but creating custom dashboards for each customer is unrealistic.
Your customer-facing analytics programs may incorporate more than just dashboards and data visualizations. Sharing data with customers so that they can combine with additional sources outside of your system through downloads or data integrations can provide flexibility that is even more valuable than dashboards that an internal user might need. For example, we have built REST APIs for customers to pull their data into their CRM and BI tools. This was a key part of the analytics strategy because customers needed to combine data from our system and others to get the true value of it.
Part of a Bigger Picture
One of the coolest parts of dashboards in your product is that they can be actionable. Users can identify areas that need attention or the system might alert them on the dashboard. The user can then click the alert and go straight to the area of the product to manage the issue. Imagine if a procurement software alerts a manager to an unfinished or low-performing RFP, the user can click the section of the dashboard or chart and the system will bring the user directly to that page to manage the RFP in question.
However, being part of a larger system requires attention to detail. It’s important to consider how the data is viewed in the context of the other pieces of the system. In addition, when there are new features added to the product we need to ensure the dashboard is updated as well. For example, if the procurement software added a new feature to classify different types of RFPs, the analytics dashboards and reports will need to show RFPs segmented by this type, or provide an option to view by segment. Sometimes changes aren’t reflected visually in the data but the schemas may change.
It’s important to approach customer-facing analytics with a product mindset, not only because the analytics often live inside of a broader platform but because they require an iterative approach, much like the rest of the product.
It’s clear trying to combine all of your analytics programs, both internal and external, may sound like a simple way to manage different use cases, but it often ends up limiting what is possible and causing more issues than it solves.