Last week we discussed why it makes sense for marketers to invest in analytics. This week we’d like to dig deeper into what a single source of truth should and should not be.
Before we go any further, we’d like to clarify that a single source of truth (SSoT) is not synonymous with where people visualize the data.
A single source of truth is the result of multiple departments signing off on data definitions, standing up a data warehouse or data lake that unifies and makes sense of data across multiple applications, then signing off on the output.
It’s a lot of work, but the beauty of having a reliable SSoT is that your data definitions and calculations are consistent no matter who or where someone is viewing the output. You can pipe data back into your CRM, MAP, Tableau, Sisense, Power BI, or any number of data visualization tools and be confident that everyone is looking at the same number for any stat in a given time range.
Anyone who has had the unfortunate experience of sitting through a board meeting and watching multiple departments report different numbers for the same statistic and then waste time arguing about who is right understands why an SSoT is a must-have.
Why a CRM Can’t Be an SSoT
Your CRM is the main hub for sales activity and many other departments may endeavor to store information in your CRM so sales remains informed. But there is a lot of critical information that never (and frankly shouldn’t) goes into your CRM.
LinkedIn advertising data, paid search data, manufacturing data, and accounting information is typically housed in external systems and (with the exception of accounting data, hopefully) will not be easy to marry up to CRM data without calculations (name/location matching) or enrichment.
Furthermore, attempting to pipe everything into a CRM taxes custom field limits, data storage limits, and API calls–and attempting to unify the data with standard object records will surpass what should be done with something like Salesforce flows.
Deduplication tools can be bolted onto a CRM (Lean Data, Cloudingo, and a few others come to mind), but when it comes to marrying website activity to CRM standard object records or standardizing job roles from free text title data, you’re unnecessarily taxing your CRM. A data lake or data warehouse is made to combine disparate data sources. Data can be deduplicated, normalized, and unified more reliably within a data warehouse or data lake and then ported back into your other systems.
While flows in Salesforce can achieve a lot of great things (even territory routing if you have zero additional budget), it’s not advisable to tax CRM processing limits on something like data normalization or marrying disparate data sources. It’s also not practical to store hundreds of thousands of website interaction records in a CRM.
Digital activity provides an essential goldmine of buyer intent data, but will quickly blow up a CRM with too many records. Once you get the data into your CRM, you’ll undoubtedly hit a stumbling block when you try to connect the dots between data sources that speak a different “language.”
The Main Ingredient for a Successful SSoT: Collaboration
Developing an SSoT for an organization takes a lot of work before you even decide what kind of data storage and transformation tool you want to move forward with.
At CaliberMind, we’ve helped a lot of organizations stand up an SSoT. The organizations that are the most successful do the following:
- Tie the SSoT going live to an OKR
- Designate an executive sponsor
- Designate a stakeholder team
- Develop a list of key milestones to track throughout the buyer journey
- Develop data definitions
- Sign off on all milestones and definitions prior to building the SSoT
In our experience, the most painstaking part of standing up an SSoT isn’t putting milestone reporting and data definitions in place. Many times people are unsure of what they want to track and how they want to track it. They also may not realize that they should obtain cross-functional sign-off. If these things aren’t established prior to kick off, the project will stall (multiple times) before go-live.
The three things we’ve seen cause executives to openly question data are:
- Variable historical reporting (the numbers change because of retroactively applying filters or a lack of reliable snapshots)
- Lack of agreement on how to define a metric
- Different departments reporting different numbers for the same stat
Choosing an SSoT
Whether you’re evaluating an analytics solution or building your own, there are several factors you must consider when selecting a tool:
- Bi-directional connectivity to integral applications
- Level of internal effort for initial implementation
- Skill-sets needed to build the required data models
- Flexibility and ongoing support LOE
- Skill-sets needed for ongoing support, reporting, and development
- Report visualization requirements
If you’re solving business problems and don’t have the internal bandwidth to take on a project like standing up an SSoT, we recommend you work with an organization that specializes in your specific data problems (if you’re a B2B organization trying to understand your customer journey, that could be us). At any rate, we recommend you read up on the 10 Pillars Every Marketing Analytics Tool Must Have and let us know if you have any questions.
Check back soon for more on best practices for defining key marketing metrics.
