It’s commonly said that Dashboards Sell SaaS. As part of the B2B sales process, dashboards convey the ROI of your platform to potential customers and dashboards continue to validate the value it provides post-sales. Customer facing dashboards can give you a leg up on the competition, but they can also be your Achilles heel – so how do you avoid common pitfalls when building multi-tenant dashboards?
Understanding User Requirements
It’s best to work backwards when building a dashboard to understand your customer’s business goals and to see who, when, and how they will use these features. Adding dashboards and other data experiences like email digests are a great way to expand your reach into customers’ organizations to provide information to many types of users that may not be the regular users of your platform.
After identifying the personas that you will support with dashboards and reports, work with your customers in these roles to understand how they expect data to help them. It’s important to view this from your customer’s perspective outside of just your platform because your customer is likely to work in many systems and use data from each one. By better understanding your client’s job you’ll be able to decipher between what they ask for and what they truly need.
Throughout this process it can be tempting to have your engineering or data team start prepping or combining data expecting that you’ll figure out what output will be required down the road. However, this usually leads to a lot of rework that ends up delaying the project and increasing its cost. Patience will pay off, especially on more complex features.
After you’ve really understood what your users need and outlined what data you’ll provide in you will be better equipped to create a single source of truth for reporting. Bringing all of the necessary data into a centralized source is important for the performance of the dashboards and it allows you to combine disparate data sets. For example, if your platform stores information like pageviews in one data store and order details in another, there must be some kind of data relationship to link those entities if you want to create a chart that shows the average number of pageviews per order. Even if your data is stored in a single database you should not rely on your production database as your central source for reporting because it will not scale efficiently.
Bringing your data together starts with a data lake, where the main purpose is to store raw data while allowing you to combine disparate data types into a single source without requiring a lot of manipulation of the data. To get data into your data lake you’ll set up a way to transfer the data. The speed and frequency of transferring this data is a major factor in the efficiency of your reports. The most efficient and performant way is to incrementally transfer data via small loads, enabling users to view their data quickly with little delay. Once your data is centralized, you’ll have a solid foundation to build from, as you work towards great dashboards that your customers will actually want to use.
Data Security and Access
Segmenting and limiting the data that users can view is especially important in multi-tenant environments because everyone’s data is stored together and it’s critical that users only see the data they are supposed to. Even though your platform might have user authorization setup, there will still be a lot of work needed to set the rules that control what data a user can see.
This segmentation is where the complication of multi-tenancy can really come into play. Data is segmented using row-level security which means designating who can see data from each row of the database. Typically, this is done on each query used to generate reports. You can imagine how laborious a task this can be, with the complexity increasing as your data grows. As the security schema changes and new data is added, row-level security rules must be reapplied to avoid lapses in security and data accuracy. Each time a new table, query, or piece of data is added, row-level security must also be updated. Getting this correct is imperative for data security. If the rules are written incorrectly or missing all together – people will see incorrect data or worse, see data that they are not allowed to see. Ensuring that this sensitive information is masked appropriately is equally important for customers and any compliance certifications you may have.
Providing Fast Results
While security is critical, maintaining a highly performant dashboard is one of the most difficult aspects in SaaS platforms. Dashboards must load quickly for every user, every time, without impacting the performance of the rest of the system for other users. To further complicate matters, SaaS customer-facing dashboards are particularly difficult because it’s hard to predict the usage of your reports, not just by one user but by many simultaneous users. As systems grow and the amount of data managed grows with it, dashboards become a bigger liability.
To create a highly performant dashboard, data should be pre-aggregated, so results are returned quickly, and your production databases are not used as the source. In most cases, creating materialized views in your data warehouse is a highly efficient way to achieve fast load times. A materialized view pre-calculates the necessary aggregations for the reports that your users run, returning results almost immediately.
Starting off on the right foot is critical to long term dashboard and platform success. Without the longer-term view, dashboards and reports can quickly become an Achilles heel of a platform, dragging down overall system performance and slowing down iteration cycles for all new features on the platform. A great foundation makes it easier to continue iterating on your analytics features and avoid stale dashboards that often occur in SaaS platforms.
With tools offered by SaaS companies, product and engineering teams can stay nimble while implementing sophisticated data experiences quickly. These solutions provide a configuration-based process to manage your data infrastructure, models and dashboards that keep your engineers focused on your core product. This approach is a great fit for companies looking to implement new analytics features and those who have been struggling to maintain their current reporting features.