Start Tracking Customer Data Points Before You Need Them

This article contains some content that I've posted previously, but I’ve fleshed it out a little here, and pulled it all into one place.

As a Data Analyst at a start-up, one of the things your Business Development and Product teams are going to be looking for is your product and revenue data broken down by different groups of customers, particularly in the B2B space (or B2B2B, where that third “B” can get big, fast – and it’s also where a ton of hidden insights are). Sales teams might want to see how different groups are using the products, to help with attracting new clients in a specific industry or use case, or to see if some clients are potentially stickier, or more profitable. Product teams will want to see how different features have been accepted, to guide the creation or evolution of new features. Eventually someone will want to see data specific to your ecommerce, travel, or small business clients, and you need to be prepared for this – ideally with the help of other teams.

In a B2B company, especially if the client businesses are small to medium, this can be a lot of companies. For larger client companies, there might be some information available from various sources, like Dun & Bradstreet and ZoomInfo, where you can purchase the data and then try to match it to your clients. For smaller companies, this information might be unavailable, or inaccurate – and probably hard to link to your client information.

One of the things I’d recommend doing early on is creating your own table(s) of client data, before you (hopefully) get too many clients to make it practical to add later – it’s much easier to keep something updated than to go back and try to add data for hundreds or even thousands of clients that may not even be with you anymore (and now you have to analyze churn on companies you know nothing about). Some of this information may come directly from the product data or engineering team, and some of it might be better sourced from Salesforce or another CRM tool – and some of it might need to be added as custom fields in your CRM tool, to get the information that’s most useful to your company. And while you can always add new fields later, adding as much as you can think of as soon as possible will pay off as you grow.

Some data items I’d recommend are:

• when the client joined or signed their contract
• when they were fully onboarded
• who their sales and customer success reps are
• how they found you
• what products or features they have access to
• what time zone(s) they are in
• how big are they (both $s and people)
• your expected revenue
• how you would categorize them – industry, use case, business type.

Some of these things may seem obvious, like dates related to customer onboarding, although I'd definitely recommend erring on the side of too many rather than too few dates - you can always ignore extra dates later, but it will be hard to recreate missing dates from memory or an email chain. Others might be less obvious, or easier to overlook - I'm going to dig a little deeper into a few of these, to show how they might benefit your data, business, and engineering teams.

Customer Time Zones

Storing customer time zones might seem a little redundant. You might expect the data you get to have time zones, that it doesn't matter because you can just translate everything to one time zone, or that all your customers are local. However, I've seen data from some sources come in with no time zone, but clearly not be local or UTC. I also live right at the edge of a time zone, so I know that even local customers might be an hour different from you. And no one wants to look at an hourly activity chart and have to translate to their local time. So keeping track of your customers' time zones can make things easier down the line.

Knowing when something happened can be very important when analyzing or viewing data – and most events do come with a timestamp for the record as well as date or time information specific to the event, which is great. Sometimes these date/times are in UTC, sometimes in the time zone where they occurred and sometimes in your time zone. And sometimes, but not always, they indicate the time zone they are in – which can be less great.

If you are sharing data insights or reports with your clients, they might expect to see data in their own time zone. They won’t always want to translate a visual from UTC to their local time, so being able to automatically switch a dashboard to their time zone can make client conversations much smoother. This could also be important at the date granularity – for US time zones, the 4+ hour difference to UTC can mean that data appears on a different day than the local time, which can make daily totals appear mismatched (ie one source says 2 events yesterday and 3 today, and another says 3 and 2, because one of them happened at 2am), and make it hard to confirm that you are getting all the events.

However, for internal views, it might be important to look at everything in a single time zone – maybe UTC, or maybe your local time. This might be useful for teams to see when the data is coming in, to know when it’s updated, or just to make comparisons between different companies’ processes. In this case it might be useful to translate all data to one time zone – using a company level date starting point.

I’ve also seen data, particularly in healthcare, where some times are stored in UTC and some are local, and there’s no indication of which is which. When analyzing the data, you can see that they probably aren’t in the same time zone – you’re comparing two values that should be minutes or even seconds apart, but they appear to consistently be hours apart – or even appear to occur in the wrong order. In this case, you probably know how to solve this issue – move one value to or from UTC – which is easy if you know what you are moving it to or from. This helps when reporting service times, and when keeping track of product performance – and can help with finding the source of performance issues or the context for client questions.

Knowing the time zone of your client is a crucial aspect of data management that can make a significant difference in client conversations and internal reporting. Yes, dashboards can be built to accept a custom time zone offset – but this still means someone must know the offset to add. Adding it to a table means that someone only needs to know that once – after that, the data knows it for you.

Product and Feature Access

Another set of data that it's important to keep track of is product or feature access, and when that access was turned on or off. This is something that's probably available in some back end table somewhere, at least from an implementation standpoint, but I'm suggesting that this also be tracked at the customer level.

Knowing what clients have which features can help the product team. If the data suggests that someone is, or isn't, using a feature, it would be useful to have a source of truth to compare that to. Then you can track things like speed of adoption, feature churn, or even when things haven't been turned on or off properly in the back end.

The business development or customer success team will likely want data related to who is using which product, how, and the ROI they are seeing, in order to help sales. Knowing exact dates for before and after comparisons, or even just quickly seeing which customers have a certain tool, can speed up that analysis.

Finally, from a data perspective, having this information in a table can make creating a filter or list much easier and accurate than having to analyze usage patterns or reverse engineer an audit or log table. It's also a place where the business and engineering data can be compared, to ensure both sides have the same information - and it can help the data team audit what they see in the data.

Company Categorization

Some of the most important, and most difficult, data points to keep track of are the many ways to categorize your customers. Your business development team will one day want to target entertainment companies, or law firms, or SMBs with fewer than 500 employees, and will want data to help their pitch. Your product team will want to interview everyone with a specific use case about a new feature. If you don't already know who these companies are, it's going to be very difficult to figure it out just from their behaviour, or from on-the-fly research, and thus very difficult to pull the data your teams need.

You may want to categorize your customers by company size (# of employees and/or annual revenue), location, industry, and use case. These will allow you to normalize for analysis, use your data to predict the ROI of specific companies, or give your sales team targeted data to present to prospective clients. While there are public sources for this data, these are less likely to have (accurate) data for smaller or newer companies.

Company Size

Company size, either number of employees, annual revenue, or market cap, seem like pretty straightforward ways to categorize a customer. However, there may be nuance that could add analytic value.

For larger companies, the data may be available from external sources - but if you are only dealing with a single department, subsidiary, or location, the stats from the parent company may be misleading. For example, if you are working with one fast food franchisee, but counting the employees of the parent company, then the analytics won't necessarily match the reality. Or if you are working with multiple branches of one company, you may have to carefully consider how to categorize them - are they just parts of a whole, or should each one be analyzed separately?

For smaller companies, the data is not as easy to find, and it can also change more quickly. You may need to do your own internet research, ask them to categorize themselves with surveys, or reach out the companies directly. This is something that is definitely best not left in just the hands of the data team, and shouldn't be left until there are hundreds of customers. What you learn as you go through this process in early days can improve how and what you collect as you grow.

Industry

When you are looking at a company’s industry, it might be something like retail – which doesn’t tell you if they are ecommerce or brick and mortar, or if they sell surfboards or software. They can be in entertainment, but maybe they sell theatre tickets, or are a sports team, or a movie studio. These nuances can be significant when you are comparing how your customers use your service or product – and how you reach out for new client or upselling opportunities.

I would recommend setting up a hierarchy that includes at least two levels (ideally more) including industry, their place in that industry, and possibly medium. So one client can be in entertainment, and they sell tickets, and they do that online. Or retail, and they sell sports equipment, B&M only. Maybe you want to capture that they only sell sports tickets, or only sell hockey equipment – this could be meaningful when looking at seasonality. And you may also want to indicate that ticket sales is also retail, and the sporting equipment could also be entertainment, so that data can be included in multiple analyses - so multiple levels may let you be more accurate.

This is complicated, and the outcome will affect multiple departments – like marketing, sales, and product. Previously, I recommended that you start collecting this data ASAP – and here, I’d add ensuring that there is a mechanism to keep it updated and to involve the stakeholders. The data team should be responsible for this, and have the final say in format – but they aren’t who is closest to the clients. Add fields in your CRM tool so that the sales and customer success teams can keep this data updated – and have a taskforce that meets regularly to make sure that the current options reflect the customer mix and are providing value, and that they are being used.

As I said, this won’t be easy. But you shouldn’t wait until you have hundreds, or even thousands, of clients. And you shouldn’t try to save effort by using high level categories – at some point your sales team will want to make a presentation to a new sports team or go to an advertising conference ?- and if you can’t tell the difference between a sport team and a movie theatre, or between a marketing or a movie studio, you may not be able to provide them the data that they need.

Use Case

Knowing how your customer intends to use your product, the business problem they are trying to solve, or what they expect to get out of your solution can be very helpful. It can provide context when analyzing your product's success, features you may want to add, or how to best serve your current and future customers.

Luckily, you may be able to get some of this information from your own data. You can look at what features of your product they are actually using, what sort of transactions they are making, how often they use it, or who is using it. Unfortunately, this may not tell you the whole story - you can see the what, but will only be able to guess the why.

To really learn a customer's use case, you probably need to speak with them. This can be done during the sales process, or during onboarding, or through customer success. It could be a direct conversation, but it could also be survey - and that survey can be informed both by how you think you product will be used, but also by the data - and can evolve over time, as you learn more about your customers. However, if you haven't started tracking use cases as soon as possible, it will take even longer to do later, as you won't be able to add the customer's context to their data to really understand what it's saying.

Customer Relationships

In the Company Size section I mentioned that you might have smaller parts of a larger company as clients. It may be beneficial from an analytics perspective to track the parts individually, but you probably also need to be able to relate them to the whole, for finance or business development reasons. Additionally, you may allow users or teams to sign up individually, but still want to relate them back to a parent company.

There needs to be a way to track the relationships between individual entities or organizations. For simple parent/child relationships, you can probably track those relationships and statuses with the addition of a few fields to the main customer table. For more complicated or layered customer relationships, one or more additional tables could help to form levels in a hierarchy.

Regardless of the method you choose, starting this process early, and keeping it updated, can be invaluable for dashboard building, customer analysis, and even data accuracy.

Summary

Eventually, you are going to want to know as much as possible about your customers, to serve them better and to help you reach more companies. It may be easy to leave collecting this information until you've grown, but that makes the job exponentially harder - and you might miss insights and opportunities that will help you grow. Start collecting and storing everything you can, as soon as you can, and involve stakeholders outside of the data team (or before the data team) - I've had to try to backfill customer information as a small data team, and it can be very hard, without enough resources or direct knowledge of the customers. The benefits of good and extensive customer data will help the data team, but will be invaluable to everyone else, including business development, customer success, and product teams. Start tracking it now.