Our Blog Posts

What does a Single Customer View mean?

I don’t mind admitting that when I first entered the world of data at the end of 2011, I didn’t quite understand the difference between a data warehouse and a single customer view (“SCV”), often using the references interchangeably. Fast forward nine years and not only do I know the difference between these two, I can also talk about data lakes, client data platforms (CDPs) and data management platforms (DMPs) – but let’s face it, if I couldn’t do that, you’d be wondering how I’ve been spending my last nine years, right?

So what I’ve attempted to do below is highlight the key issues you need to be thinking about and give you a bit of a steer in the right direction. The key thing to bear in mind is a Single Customer View should not be an IT project – it’s a business project – and however long you think it might take to develop, double it, or maybe even triple it. If you are at the start of your project, take a read through the following key steps and use each one as key task.

 

What is a Single Customer View?

Firstly, let me provide you with my definition for a single customer view: it’s an environment that provides a view of all your fans, customers, participants and other stakeholders, and the relationship they have with your organisation. Imagine the value of seeing how your ticket buyers, members, store buyers, players, referees, and volunteers overlap, showing where they have more than one relationship with you. You can also watch our 90 second video definition.

What does a Single Customer View Mean?

The reason I refer to an “environment” as opposed to a database, is because your single customer view could come in all shapes and sizes. You could be an organisation that has the need, budget, and knowledge to take advantage of dedicated off-the-shelf products from global software brands, or you could be just starting out, not yet able to justify too much budget, not having the business need for leading-edge software, or not knowledgeable enough to use it if you did pay for it. And of course, you could be somewhere in between – making use of the database functionality in software that serves a different primary purpose but has adequate data management functionality that you can replicate some of an SCV’s primary purpose (an email marketing platform is a great example of this.)

Secondly, what are the key criteria, the key considerations when developing your own SCV, regardless of the environment it’s in?

You need to be clear about the reason you need a single customer view. It’s not enough to just be able to say what it is – you need to be able to clearly state what it can do for you, For example, you could say “if I have an SCV that can show me the relationship I have with all my fans/customers around the business, I will be able to…..

  • offer a discounted ticket to anyone who hasn’t yet purchased one and bought our replica shirt this season.”
  • personalise an email to all my fans that meet my sponsor’s target customer profile, are coming to my event next week, and previously entered one of my sponsor-branded competitions.”
  • create an automated engagement campaign that promotes the different areas of our business that I know they’re interested in.”

Identifying the data sources that will contribute to your single customer view and then figuring out how you’ll get it is another key step. Your data sources might include:

  • Your ticketing system, often provided by a third party such as Ticketmaster SeatGeek, Advanced, etc.
  • Your online store, provided by your technical equipment sponsor, or a third party such as Fanatics, JD Sports, etc.
  • A simple newsletter sign-up or account creation function on your website
  • A competition landing page, used within your website, freestanding, or within a social channel.  

You could also work with external parties to bring data into your database – your sponsors and partners can help generate lots of new opt-ins for you when they partner on a co-branded promotion and you can use companies such as Acxiom and Experian to provide you with data appendages (that’s a short way of saying “more things about your fans that you didn’t already know” – lifestyle, household income, family status, etc.)

Once you’ve identified your data sources you then need to consider how to get the data to you and we generally use one of three way:

  • Automate the process via an API (application programming interface) that will automatically take the data from the source system and send it into your SCV on a frequency that can vary from once per day to once per minute.
  • Use a manual import/export process: yes this is time-consuming but is sometimes the best option because the data source is temporary (e.g. a promotion hosted on a sponsor’s website) or you can’t yet secure the budget for the additional programming needs for an integration. (On this point – while I’ve included “lack of budget” as a reason here, I don’t necessarily agree with it, purely because an API removes the need for a manual process, thereby removing the need for an individual’s time, and in this day and age it’s often the case that time is worth more than money. But getting management to provide a budget for automation can still be a challenge until we can demonstrate an ROI).
  • A hybrid approach that might involve an FTP site provided by the vendor that you can then automate a download from.

What Data do you need in a Single Customer view?

Crucially when you develop a single customer view, it’s not all the data you have about your customers/fans that we’re after, it’s just the data that supports your identified purpose: the information that you need to support your targeted marketing campaigns and to help you make decisions. An example of this is your ticketing data – we want to know who’s purchased (first name, last name, postal address, email address, mobile phone number, gender and date of birth if we have it in the form), what they’ve bought (which event, what seats, etc.), how much they’ve spent (in €, £, $, etc.) and the date of their transaction. But we don’t need their credit card details or their PayPal log-in details – that data is used in the payment process and we don’t need it for our strategy. Similarly, when it comes to out athlete registration systems, we want their contact data, we want to know their role (athlete, coach, referee, volunteer, etc.), when they last played/appeared, if they scored/achieved a personal best, etc., but we don’t need necessarily their height and weight! Most importantly, particularly when you’re thinking about data-driven marketing, you also need the tick box that shows they have agreed to receiving marketing communications from you.

What Data Format should you use in a Single Customer View?

There’s a really good chance your data sources will be using different data field formats – while your ideal scenario is you have a set of data standards that all your partners use, there aren’t many rights owners that could dictate a ticketing r online store provider change the process they use across their whole client base to meet the specific needs of one. Hence you need to understand the format of the data you’re receiving from each of the sources and how you can transform it to the format of your single customer view. An easy example I always use when discussing this is the date of birth field: here in Europe we use dd/mm/yyyy as a standard field but in the US, the format used is mm/dd/yyyy, so if a European rights owner works with a US-based vendor there’s a chance the date of birth field will be transposed. This could lead to a fan born on 2nd November receiving a birthday email on 11th February! Even if we’re working with a non-US vendor, unless we make it clear we need a dd/mm/yyyy field, we could end up with dd/month/yy, or worse then that a FREETYPE field which allows 2nd Nov 66, November 2 1966, 02 Nov 1966, or any other text string that does not resemble our desired format of dd/mm/yyyy. And this all matters because when you bring together all your data in an SCV you’re merging records and merging fields – you’re de-duplicating records for fans that appear in multiple data sources and unless your data fields match in format, they won’t merge. Worse than that, the mismatching fields may cause a system failure!

Different formats of date of birth – these need to be standardised in an SCV
Different formats of date of birth – these need to be standardised in an SCV

What are the Deduping and Merging Rules for a Single Customer View?

So how do you deal with the reality of mismatching data fields and duplicate records? How do you decide which filed at accept, which field to over-ride, which duplicate to keep and which one to remove? This all comes down to the “rules” you set when performing a merge process and these can be built into your automated API or into your manual process. The things you need to consider are:

  • what unique identifier(s) you will use to confirm they’re a duplicate. The easiest and “foundational” one we use is an email address but as many people now use more than one (the average is supposedly 1.4 addresses per person using email) it’s not an accurate measure – one person may have two email addresses or one email address may be used within a household to represent four different family members.
  • the format of the source database and your data standards (i.e. the format of your SCV), as discussed above.
  • the primacy of the incoming data (i.e. the order in which the data is generated – we have to assume that the most recent data is the most accurate).

Should I Develop a Bespoke Single Customer View or Buy Off-the-shelf?

While an SCV is a key element of your approach to using data, it can be challenging to achieve: a 2015 survey by Experian of 1,000 marketers, 89% of respondents admitted they are having difficulty creating an SCV. For this reason it can be easy to just buy the market leader or what your peers at another organisation are using, but it’s really important that you take the approach that’s right for your business. If you’re not particularly advanced, and you can’t yet justify the cost of an off the shelf purchase, then building something in SQL that’s hosted in the cloud is often a cheaper solution, more cost effective solution for you. And as I mention  at the start, if you’re at least using email marketing, the right platform can provide you with a database function that allows you to use it as an SCV. You should also bear in mind that “off the shelf” never really means that – you will still need to tailor the modules you purchase to suit your particular business need.

So, as you can see there are many things that have to be considered when developing an SCV but don’t let that deter you – the importance of your SCV really can’t be understated. It’s one of the most crucial elements of your technology stack. Without it, any other contributory components cannot function with full efficiency or efficacy. Imagine your marketing campaign platforms attempting to send the right message to the right person, when the data in your SCV is incorrect, or your system holds your fans twice, or three times because of the presence of duplicates! Your SCV provides the hub of the data you need for your data-driven activities. When you combine your unique records with marketing technologies you can generate insights that support your marketing decisions. You can easily visualise and analyse your data at speed to identify the perfect audience for your targeted marketing.

Finally, don’t just take my word for it  here’s what Paul Rogers, Chief Strategy Officer at AS Roma, has to say about the importance of an SCV in the upcoming second edition of our best-selling book, Winning with Data for the Business of Sports: 

Paul Rogers, Chief strategy officer, AS Roma
Paul Rogers, Chief strategy officer, AS Roma

“Getting our ticketing and online store partner onboard from day one instead of two or three years into our contract with them would have been ideal – on the other hand we didn’t know what we needed to tell them when we first signed our contracts. Our focus was on finding the right suppliers to ensure we could sell tickets and merchandise to as many fans as possible, as efficiently as possible, while making it easy for our fans; making sure the systems worked and were easy to use. With the increased focus we’re now putting on opt-ins, and the importance of our SCV, I wish all these companies that want to sell me so-called new and exciting digital platforms that will help improve the fans’ experience would also think about this before asking us to sign a contract. That’s what I think is missing – an understanding from all these companies trying to sell to us that while it’s paramount that we give our fans a great experience, that we make it easy for them, and that our fans feel valued, they need to take the data their interactions create and help me get it into our systems. If they add that to their sales pitch, I’ll pay more attention.”

To summarise here are just 5 key points to remember:

1) A single customer view should provide you with a complete view of the customers you have across your organisation but it’s not an IT project – it should be a business project.

2) You need to be clear about the benefits an SCV will bring to your organisation – that will enable you to focus on what’s important. This includes the data that you need in your SCV – remember it’s not ALL your data, it’s just the data you need to achieve your objectives.

3) You have to think about how the data will get into your SCV – an automated process is preferable but you need the flexibility to use manual imports should there be no rationale for an automation.

4) You need to document the standards or format of the data fields in your SCV so you can easily refer to them when considering incoming and outgoing data flows, particularly when you consider your de-duplicating and merging rules.

5) Don’t just buy off-the-shelf software because you think it’s the right thing to do – go through a proper process to understand exactly what you need, and why you need it, to help inform your decision.

Comments


Leave a Reply

Your email address will not be published. Required fields are marked *