Depending on the nature of your business and the relationship that you have with your customers you may have several different types of customer master data that you choose to manage and maintain. There are other types of customer data that you may need to manage too, data types that you don’t necessarily always think of as master data but which may benefit from being stored and retrieved centrally as required.
Quantitative and Qualitative
Typically, you can think of customer data as falling to one of two camps, either qualitative or quantitative. So what is the difference?
If you think of this in the context of survey data, for example, quantitative data is values that are representative summations or counts. Each data element is exclusively numerical. The values are quantifiable and can be used in statistical and mathematical analyses and calculations. They’re certain quantities, amounts, or ranges. Typically they are also accompanied by measurement units such as kilos, years, meters, etc. In the case of say, the height of a person. It makes sense to set boundary limits (validity ranges) to such data. It may also be useful to apply arithmetic operations or calculations to that data, like converting to an alternative unit of measure.
As for qualitative data, in master data for customers, in particular, this may be data values like sizing standards – S for small, M for medium and L for Large, and so on. Others might be colors, preferences, types assortments, etc. As long as numbers are not assigned, even though they may equate to numbers, this is likely considered qualitative. Similarly, the country, state, or province in which a person claims to be a resident is qualitative because the indicator is an attribute characteristic.
Now you might ask, why would I care about whether this is quant or qual? The answer may lie in how you do your segmentation and reporting. When you are dealing with numeric values it is a great deal easier to create reports and extracts of data and to select ranges in particular if you are using quantitative data. You could for example have people defined as young, youthful, middle-aged, old or ancient but that’s not as useful as knowing the actual age. This is particularly important if I want all people over 18 and less than 80 for example. In addition, I could potentially calculate who these people are if I know their date of birth.
Declared and Inferred
Now that we have distinguished between quant and qual, it is worth also considering data that is inferred vs declared. Declared data is much more definitive, much more absolute at a point in time when compared with inferred data. Often the declared data is provided by the customer themselves or acquired from a system or provider that they may have provided that data to.
Inferred data is conversely derived. It may, for example, be the result of combining data from one or more sources and then effectively joining the dots between data points to draw some sort of conclusion.
Again, you might question, why you would care. The main reason might lie in the fact that your business needs to know the basis on which you hold and maintain customer data and then also consider how you arrive at decisions based on that data.
Data privacy matters continue to evolve, from Europe’s General Data Protection Regulation (GDPR) to the UK’s equivalent and Brazil’s Lei Geral de Proteçao de Dados (LGPD), Australia’s Privacy Act, the California Consumer Privacy Act (CCPA), Japan’s Act on Protection of Personal Information, South Korea’s Personal Information Protection Act, Thailand Personal Data Protection Act (PDPA), New Zealand’s Privacy Act, India’s Personal Data Protection Bill (PDPB), South Africa’s Protection of Personal Information Act (POPIA), The People’s Republic of China publicly released draft of the Personal Data Protection Law, PDPL and several others. It is important to recognize the approach that your business has to data collection. Data, personal data in particular is an emotionally charged topic with changes in consumer opinion ever constant.
Declared Data willingly shared by the user through form-fills, cookie opt-ins, and submissions through social media accounts often carries the highest value to different aspects of your business as this data is 100% based on the customer or prospect’s activity. Ideally, you will also have gathered a consent indicator from the person who provided this data, which can help inform you on how this data can be used. Optimally, error-free barring deceit on the part of the submitter, you may use this data to determine appropriate access to certain products and services that you offer.
Inferred is often considered amongst the most contentious of data because as the name suggests, you’re joining dots. Data like this is engineered or developed. It has been created without express input from the person that it relates to, it may be systematically generated based on transactions, or activity. This data is neither better, nor worse than declared data, it is simply different and is most contentious, often because it is calculated algorithmically and is based on assumptions, perhaps well-informed, but nonetheless, not declared by the person that they relate to.
You might have a customer who declares that their preferred beverage is coffee but you often see tea or chai in their orders. Does that tell you that they lied? Well no, they have declared their preference to be coffee but they may often order other beverages for others in their party and that’s why you’re seeing an anomaly. You have derived a preference perhaps, from all their known transactions but that doesn’t make your inferred data correct.
So, you have these classes of data, but now let’s consider other aspects of the data that you may have.
Basic data and the rest
This is a very subjective discussion. The main reason is that what one company may consider basic customer data may be considered much more than another company may need. The decision as to what you choose to create and maintain and the reasons you may define the data in different ways may vary wildly from the needs and expectations of a competitor or another industry or even a use case within your organization.
Pretectum’s Customer Master Data management system (C-MDM) doesn’t prescribe what you should or should have as that basic data definition, it is entirely up to you. While we may offer some standard models (schemas) and your systems may have specific minimum requirements, those can be supported but the end decision is up to you.
A coffee shop may only need an email address and a first name to maintain their loyalty card or loyalty system. A retailer on the other hand may require a full customer name, phone numbers, email addresses, gender, and addresses in order to make deliveries, etc. A bank may require much more, not just for the purposes of giving the customer a great experience, but also because it may be a legal requirement.
When you embark on the implementation of your master data management solution, these are some of the aspects that you might want to consider.
Either way, Pretectum’s C-MDM is able to support you in leveraging all of these different ways of deciding what to store and what the criteria are around the values that you might store, qualitative, quantitative, declared, or inferred. All types of data are supported in a highly configurable way according to your specific business needs.
If you’re wondering whether you can achieve a particular outcome in your use of Pretectum’s master data management system to improve sales, support a particular initiative, or simply provide your customers with a great personalized customer experience, contact us and we’ll tell you what you need to know about how the system can help.