Why your reports might not reflect the reality of your business (Part 1)

How are data attributes set up?

How did you or your system administrator set up the attributes in your database? Do they fit your business requirements? What I mean by that is easier to explain with a real-life situation. Let's pick the example of a CRM system where you collect information about your clients such as occupation, age, and type of subscriptions they have with your company (imagine a SaaS environment) or products that your company sells. Let's do a small exercise here and try to picture how these three customers’ attributes need to be configured in your organisation. [My recommendations can be found at the bottom of the article]

Mandatory fields

Which fields are required? If data is collected from multiple sources for the same field, do you ensure the consistency of your data? If a report contains empty fields, you might revise if this is actually what you expected. This might also be the expected behaviour as empty values also have a significance.

Type fields

There are numerous types of fields which I will not explain in an exhaustive manner but only mention the most frequent ones:

• text
• numeric value
• checkbox
• dropdown
• boolean (true or false/0 or 1)
• date
• formula

The way you structure your data will massively influence how it is connected between these fields and the ultimate outcomes of your report. Think about your business needs to structure the data. I've seen companies collecting a customer's occupation attribute with a text field. This can result in you having 10'000 different values in your database with plenty of errors. Other companies collect data for this field with a dropdown menu (pre-selected values that you can choose from – only one choice is applicable), ending up with the majority of their clients being "occupation = other".

Updating Methods

This is a rather technical part which you may not be familiar with, but it's important to understand the mechanisms. How data are created might depend on the methods of your interface (or the connector between System A and System B). I will simply mention here two basic functionalities:

• Create/Insert: This is the most basic method when creating a new data record – the value will simply be parsed into your attribute field.
• Update/Overwrite: This is a very important feature where you should decide if your field should be updated or not. Do you want the customer to update his address? Yes, probably. Do you want your customer to update his password? Yes. Do you want your customer to update his date of birth? Maybe not! This information should not vary unless your customer made a mistake upon registration. Think about your services where a special package is only marketed to people below 18 (e.g. 50% off on annual phone plan). If you give the customer the ability to change his or her date of birth, you may encounter someone who has eternally remained in their teens.

Thank you for reading! The second part (a bit more technical and specific) will be published in a few weeks, as I thought it would be too long, in particular for an introduction to data troubleshooting. If you're interested to work on a project with us, just click here:

Please find below my recommendations for the exercise about the setup of 3 attributes for your organisation.

Recommendations for the exercise

Occupation: 
How is this information relevant for your organisation? Keep in mind that some people might have two occupations! People also change jobs –– how do you keep that information up to date? Do you have any client portals so they can amend this information or do you collect only when they first register? Is this field also required in your organisation?

Age: 
Do you want to collect the age of your customers or rather their birth date? As the famous motto states "age is just a number", but it's also a dynamic value which evolves from the date of birth. So you might want to create a date field to collect the customer birthdate and ask your system administrator/data scientist to create a formula field/calculated field to return the correct value into age (basically today's date - date of birth).

Subscriptions/Products: 
Most probably you already know your products/services so you don't want to leave this field open for the client but rather create a dropdown. The concern here is to understand the way your products/services are connected to your client. Can they subscribe to multiple services at the same time? If your client can have only one option, you might set up a dropdown field for this attribute; however, if a customer can have multiple services at the same time, you should opt for a multi-select dropdown field.