Ten Tips to Get Better Analytics from Your SaaS Data
- Zohar Strinka
- Jun 9
- 8 min read
Following the right process will drive improvements for your business
To build custom analytics solutions on top of your SaaS data, you need to get that data out of the source and land it somewhere you control.
There are two key components to consider. The first is to ensure that whatever path you start down, the results will drive real business value. The second is to recognize that you cannot know in advance how much technical effort it will take to pull off that specific business value.
We routinely see our clients struggle with the chicken-and-egg problem of what to try and how to know if it will “work”. It’s easy to commit to a plan only to discover that there are a lot more challenges than expected. But until you start trying to build the new capabilities, it’s a mystery whether it will work or not.
In this, the third article from our three-part series on building analytics from SaaS data, Zohar Strinka shares 10 tips for planning and executing a project that builds on your SaaS data. We also share a diagnostic tool you can use when evaluating a particular opportunity.
Tip 1: Understand the potential business value
There are three broad categories of business value you might be trying to achieve by building analytics on top of your SaaS data to drive operational improvements:
New functionality the SaaS vendor hasn’t chosen to pursue such as a recommended decision built on top of the built-in SaaS forecast.
The ability to integrate your data with other systems such as targeted marketing based on past customer orders.
A more accurate view of your data such as the ability to tell the difference between lost sales due to out of stocks versus the weather which leads to better decisions.
When your motivation is that the SaaS vendor hasn’t built a feature you need, first seriously assess why you need the feature. Unless the model would require data from within the SaaS system, you might be able to build it natively in one of your other tools. There are also times when a feature sounds like a great idea, but it’s impractical in reality. Lastly, there may be a different way to achieve the business outcomes you are striving for within the SaaS system itself, if you change how you look at it.
The most common reason to want to get your data out of the SaaS system is to create an integrated analysis across systems. Unless your vendor has already built an integration, it’s on you to build those connections when you need them. So evaluate what will actually be different for your business when you have this integrated data. Will you be able to make better decisions? Be sure to sanity check those ideas with both the people who will have to use the data and someone technical to ensure what you want to do is possible.
If your motivation is simply “to see the data in a better way“, you are likely to be disappointed. If your goal is to “make better decisions”, ask the team how the data in these systems will support those decisions. We also recommend saving these kinds of projects until your team has successfully delivered more tangible results for your business.
The exception to all the above is when the best initial value is determining how hard it will be to do the technical work, and then reviewing the data quality of your SaaS tool. There is no better way to find the issues with the data than looking at it en masse. In this case we recommend treating the project as R&D, and setting a fixed budget with checkpoints when you decide whether it’s worth the effort to keep moving forward.
Tip 2: Evaluate your SaaS vendor’s setup
There are 6 key categories to evaluate when you build analytics on top of SaaS data. In the chart below we cover several questions you can ask to understand the strengths and weaknesses of your vendor.
Download the pdf version here:
Tip 3: Start with manually exported reports as a Proof-Of-Concept.
Once you are clear on the value and have identified how analytics-ready the vendor’s SaaS tool is, we find the best next step is to develop a prototype from manually exported reports. Sometimes this allows you to get a fraction of the value much faster as you test the future tool. But most importantly, it helps you see which data is critical for the future-state solution.
Recognizing what data are missing can be challenging until you start trying to use the information to do something. Better to discover that a crucial data element is unavailable early on than after you’ve already invested months into the project. The initial analysis becomes a blueprint for which data you are looking for when you move on to the analytics infrastructure.
One other key benefit is identifying how the data in a particular system will join to data from other systems. We have seen those joins consistently trip up our clients as there are literally endless connections you might want to make.
Tip 4: Identify the minimum data you need
If you followed Tip 3 it should be pretty straightforward to document exactly which data you need.
We still generally prefer to pull everything when possible, to accommodate changes to the scope, or to facilitate future projects. But if that approach will greatly increase the cost of acquiring the data, we know what’s a must and what’s just nice-to-have.
Additionally, the data in the frontend often looks quite a bit different than it does in exports. Having a checklist can help you ensure you aren’t missing a critical element.
Tip 5: Evaluate all your options for getting the data
If you’re getting data out of a database, there are a variety of effective and affordable ways to pull it off. If you’re getting data out of a SaaS platform, data volumes – including the number of tables, number of columns, and number of rows – may drive up both the development and operational costs.
Extract-Load-Transform tools can be an incredible boon to your project. When we set out to pull data out of a SaaS tool, we review the vendor documentation first. Shortly thereafter we check the various ELT tools to see which ones already have an integration built, which data is covered by their integration, and if they also have data models at the ready to help.
Most of the time, we recommend using ELT tools to get your data out of the source system. Unless you are writing information back to the source, these tools have built-in functionality that really pays for itself. Things like retries, alerting, and the ability to handle changes to the underlying data if your SaaS vendor updates its systems.
The biggest consideration with ELT tools is that they become yet another piece of SaaS software you have to evaluate. Costs can be hard to understand and manage, and the tools themselves vary in performance and features.
You can use the diagnostic tool in Tip #2 to help determine the best path forward.
Tip 6: Ensure your systems are set up securely
When even an organization like Equifax fails at security, you know that this is an important and challenging domain. Here are some of the most common issues we have run into in our work with clients:
Sending or receiving passwords in plaintext emails.
Shared credentials to simplify getting started or reduce licensing costs.
Some SaaS tools may require an enterprise license to allow you to use a single sign on, which either becomes a security risk if you choose not to, or leads to additional costs.
Limited understanding of the strengths and weaknesses of different options such as VPNs, IP whitelists, SSH tunnels, and so on.
Failure to apply the “least privilege principle” that each person or role should have only the permissions they need to do their work, and not more.
Giving admin rights to every user.
Failure to set up proper disaster recovery in the event that systems were compromised.
Failure to secure PII or PHI data appropriately.
This list is far from exhaustive. Evaluating each and every vendor you work with is critical to ensure your company doesn’t become the next headline.
Tip 7: Ensure the data you are getting is accurate
When you move data from a source system to a separate destination, it’s easy for that replication process to fail. Generally, the issues relate to missing rows of data because of an update issue, missing some rows due to filtering, or having duplicated rows.
This is one of the reasons we at Analytics Strategies prefer to use an ELT tool when possible. Well-designed tools handle all of these issues out of the box, and you can focus on the logic that is unique to your business. We also like to put the data in front of our clients as soon as possible. Something as simple as taking the sum of sales can help you validate that the systems are working correctly.
Tip 8: Validate timeliness and automation requirements
The users of your future analytics solution might ask for real-time data. Similarly, your technical team may set out to automate data refreshes so no one has to take the time to do it manually.
In the context of your business goals though, these kinds of requirements may or may not be a “must-have.”
For operational tasks, staying in the source system is an option for most of the use-cases that truly need live data. When you’re using the power of analytics to look at a historical view of the data, it’s usually fine for there to be a 15+ minute delay. And even daily or weekly data meets the business needs of many of our clients.
When it comes to automation, we have seen how costly it can be if treated as non-negotiable if the SaaS vendor has the wrong infrastructure or your own business has data quality issues. On the flip side, we have also seen tools that were very useful, but there was no one with the right technical skills to update the data once the tool was built.
Tip 9: Fix the data at the source if there are issues
Until you look at the data outside the SaaS platform, it’s easy to think there are no issues with data quality. That is, until you create a chart and discover your most common product category is “null” or you have 50 million dollars of backlogged sales scheduled for 2035.
There may be good process reasons for the data to look that way – we have had multiple clients future-date real orders that don’t yet have a desired ship date. Those processes are often themselves a fix for past process failures.
The analytics team should be working closely with the users of the SaaS tools to understand why the data looks the way it does. Each of these issues can then be evaluated and fixed at the source or in the analytics system. In the latter case, we have one additional warning: make those fixes as visible and easy to modify and validate as possible.
Tip 10: Work early with the vendor
We wrote this article series in part to help companies like yours get better service from SaaS vendors. Having worked both with companies trying to integrate their SaaS data into a data warehouse, and with SaaS vendors trying to build their offering, we see both sides of the issue.
It is far too easy to underestimate the work it takes to build analytics on top of the SaaS data, leaving both sides frustrated and spinning their wheels. These tips will help you avoid that fate.
This three-part series provides practical tips to consider when working with a SaaS vendor to gain greater access to your data. We at Analytics Strategies specialize in helping you get the most out of your data. Click here to schedule an exploratory call.
Comments