How To Protect Your DMS Data

by Scott Golembiewski on January 4, 2012 · 0 comments

There has been a lot of conversation lately about dealerships allowing 3rd party access to their data. In this post, I will provide you with some information that you will be able to use in determining how your data is used and some ways you may limit it’s use.

First of all, what is data? What’s the difference between good data and bad data? Why would anyone want to have access to my data? What could they do with my data and how can I monitor what is being done with it?

Data is stored in a database, and the easiest way to visualize a database is to think of an excel spreadsheet. You have rows and columns. At the very top is a row that is divided into columns, and each column has a title.

ID | Name | Address | Email | Phone | ……

Then each row represents a “record” in the database, that makes it unique so that it can be cross referenced by other database tables “other excel spreadsheets” if you will.

Lets assume the following:

1030033 | Fred Smith | 213 Main Street | fred@yahoo.com

The first number, or the ID is tied to Fred Smith. In a real database you wouldn’t see things like the numerical portion of the address in the same column as the name of the street, but I’m just doing it like this to simplify the example.

So 1030033 refers to Fred Smith, and if you had another database table where you wanted to create a new way to reference Fred Smith without using his name you could simply use his ID and create another number. Lets say Fred Smith is a lifetime customer, and each time Fred buys a car you want to create a new ID for him because its a big deal. All of his ID’s will refer back to the original 1030033, but instead of doing that you want to give Fred a “VIP” status so whenever he brings his car in there is a little “VIP” icon next to his name.

One way a web based application could accomplish this feature is like so:

The first digit of the person’s ID identifies how many vehicles they have purchased from your dealership. So if you wanted to know at a glance without diving into data you absolutely don’t have any use for in this particular query, you could simply sort your ID column and immediately you could see you have 6 people that have a user ID that begins with 8. That would mean you have six people who have bought eight cars from you. Then you have 20 that have bought seven cars, and you get the picture.

Well instead of looking at the “raw data” for every customer who walks in, you simply have your web developer design a cool looking little “VIP” icon that will be displayed next to any customers name that has a user ID that begins with a 2 or above. That means anyone who has bought 2 or more cars from you will have a VIP icon.

The purpose of explaining it like this was to illustrate that your data is only meaningful to you when you understand it in the context of how it is stored. If the above example was true in your system, a user ID number would have significant meaning to you as opposed to just looking like a random string of numbers.

Find Out What Data Is Being Shared and With Whom

Now with that being said, the next step is to understand how your data is being stored, who has access to it, and so forth. Let’s just keep with the above example being true, that the first digit represents the number of cars purchased by a customer.

If you were given 15 minutes to select 5 ID’s from a competitors database, don’t you think you’d like to take the five with the highest first digit in their ID? Of course, they would be considered the most profitable customers of that dealership.

However, you would make that selection only because I haven’t given you any other parameters to consider.

Let’s add another field to make it more interesting. The column header just has “CLV” at the top and since I created the database I know that “CLV” stands for Customer Lifetime Value.

Without having been told what CLV stood for, that column wouldn’t have meant much to you, just a three digit column from 000 to 999. Who cares what that means right? Wrong.

This column is the cumulative figure (multiply by 1000) of the total revenue earned to date by this customer.

So if your customer has an ID of 5959393 and their three digit number is 050, you can tell me on average how much they spent per vehicle. ($10k). The first digit tells me they bought 5 cars, the three digit code tells me they’ve spent $50k. Now we are getting somewhere.

That “CLV” column has lot of importance now, perhaps even more important that the first digit of their ID #.

So How Can This Help You Protect Your Data?

This simply boils down to what fields your 3rd party needs access to. In the case of TrueCar, they simply need to know if Fred bought a car from you after he went through their process. They don’t need to know how much he spent, or how many cars he’s bought from you, or anything else.

So the answer to this is to simply create a dedicated True Car database table. This table will only be populated if one of their leads actually buys a car from you.

I’d also suggest time stamping their lead in your own database so if you and another local dealer wanted to do a little “analysis” on how they are distributing the leads, you’d have some ability to identify trends in the data.

Dealers really need to spend some time understanding how their data is collected, stored, analyzed and shared. Your database is gold. Don’t let outside people wander in and out of the vault unless you know what they are doing in there.

And if you know what they’re doing in there, you won’t have to question whether they are up to no good, because you simply give them access to the areas they need and that’s it.

If you ask any legitimate company to provide a recent snapshot of the data they’ve taken they should be able to answer you within 24 hours and if not, lock em out.

Leave a Comment

Previous post:

Next post: