Cheat Sheet: Is Your Database Marketing Ready?

Many data-related projects end up as big disappointments. And, in many cases, it is because they did not have any design philosophy behind them. Because many folks are more familiar with buildings and cars than geeky databases, allow me to use them as examples here. Imagine someone started constructing a building without a clear purpose. What is it going to be? An office building or a residence? If residential, for how many people? For a family, or for 200 college kids? Are they going to just eat and sleep in there, or are they going to engage in other activities in it? What is the budget for development and ongoing maintenance? If someone starts building a house without answering these basic questions, well, it is safe to say that the guy who commissioned such a project is not in the right state of mind. Then again, he may be a filthy rich rock star with some crazy ideas. But let us just say that is an exceptional case. Nonetheless, surprisingly, a great many database projects start out exactly this way. Just like a house is not just a sum of bricks, mortar and metal, a database is not just a sum of data, and there has to be design philosophy behind it. And yet, many companies think that putting all available data in one place is just good enough. Call it a movie without a director or a building without an architect; you know and I know that such a project cannot end well. Even when a professional database designer gets involved, too often the project goes out of control—as the business requirement document ends up being a summary of everyone's wish lists, without any prioritization or filtering. It is a case of a movie without a director. The goal becomes something like "a database that stores all conceivable marketing, accounting and payment activities, handling both prospecting and customer relationship management through all conceivable channels, including face-to-face sales and lead management for big accounts. And it should include both domestic and international activities, and the update has to be done in real time." Really. Someone in that organization must have attended a database marketing conference recently to get all that listed. It might be simpler and cheaper building a 2-ton truck that flies. But before we commission something like this from the get-go, shall we discuss why the truck has to fly, too? For one, if you want real-time updates, do you have a business case for it? (As in, someone in the field must make real-time decisions with real-time data.) Or do you just fancy a large object, moving really fast? Companies that primarily sell database tools often do not help the matter, either. Some promise that the tool sets will categorize all kinds of input data, based on some auto-generated meta-tables. (Really?) The tool will clean the data automatically. (Is it a self-cleaning oven?) The tool will establish key links (by what?), build models on its own (with what target data?), deploy campaigns (every Monday?), and conduct result analysis (with responses from all channels?). All these capabilities sound really wonderful, but does that system set long- and short-term marketing goals for you, too? Does it understand the subtle nuances in human behaviors and intentions? Sorry for being a skeptic here. But in such cases, I think someone watched "Star Trek" too much. I have never seen a company that does not regret spending seven figures on a tool set that was supposed to do everything. Do you wonder why? It is not because such activities cannot be automated, but because: Machines do not think for us (not quite yet); and Such a system is often very expensive, as it needs to cover all contingencies (the opposite of "goal-oriented" cheaper options). So it becomes nearly impossible to justify the cost with incremental improvements in marketing efficiency. Even if the response rates double, all related marketing costs go down by a quarter, and revenue jumps up by 200 percent, there are not many companies that can easily justify that kind of spending. Worse yet, imagine that you just paid 10 times more for some factory-made suit than you would have paid for a custom-made Italian suit. Since when is an automated, cookie-cutter answer more desirable than custom-tailored ones? Ever since computing and storage costs started to go down significantly, and more so in this age of Big Data that has an "everything, all the time" mentality. But let me ask you again: Do you really have a marketing database? Let us just say that I am a car designer. A potential customer who has been doing a lot of research on the technology front presents me with a spec for a vehicle that is as big as a tractor-trailer and as quick as a passenger car. I guess that someone really needs to move lots of stuff, really fast. Now, let us assume that it will cost about $8 million or more to build a car like that, and that estimate is without the rocket booster (ah, my heart breaks). If my business model is to take a percentage out of that budget, I would say, "Yeah sure, we can build a car like that for you. When can we start?" But let us stop for a moment and ask why the client would "need" (not "want") a car like that in the first place. After some user interviews and prioritization, we may collectively conclude that a fleet of full-size vans can satisfy 98 percent of the business needs, saving about $7 million. If that client absolutely and positively has to get to that extra 2 percent to satisfy every possible contingency in his business and spend that money, well, that is his prerogative, is it not? But I have to ask the business questions first before initiating that inevitable long and winding journey without a roadmap. Knowing exactly what the database is supposed to be doing must be the starting point. Not "let's just gather everything in one place and hope to God that some user will figure something out eventually." Also, let's not forget that constantly adding new goals in any phase of the project will inevitably complicate the matter and increase the cost. Conversely, repurposing a database designed for some other goal will cause lots of troubles down the line. Yeah, sure. Is it not possible to move 100 people from A to B with a 2-seater sports car, if you are willing to make lots of quick trips and get some speeding tickets along the way? Yes, but that would not be my first recommendation. Instead, here are some real possibilities. Databases support many different types of activities. So let us name a few: Order fulfillment Inventory management and accounting Contact management for sales Dashboard and report generation Queries and selections Campaign management Response analysis Trend analysis Predictive modeling and scoring Etc., etc. The list goes on, and some of the databases may be doing fine jobs in many areas already. But can we safely call them "marketing" databases? Or are marketers simply tapping into the central data depository somehow, just making do with lots of blood, sweat and tears? As an exercise, let me ask a few questions to see if your organization has a functioning marketing database for CRM purposes: What is the average order size per year for customers with tenure of more than one year? —You may have all the transaction data, but maybe not on an individual level in order to know the average. What is the number of active and dormant customers based on the last transaction date? —You will be surprised to find out that many companies do not know exactly how many customers they really have. Beep! 1 million-"ish" is not a good answer. What is the average number of days between activities for each channel for each customer? —With basic transaction data summarized "properly," this is not a difficult question to answer. But it's very difficult if there are divisional "channel-centric" databases scattered all over. What is the average number of touches through all channels that you employ before your customer reaches the projected value potential? —This is a hard one. Without all the transaction and contact history by all channels in a "closed-loop" structure, one cannot even begin to formulate an answer for this one. And the "value potential" is a result of statistical modeling, is it not? What are typical gateway products, and how are they correlated to other product purchases? —This may sound like a product question, but without knowing each customer's purchase history lined up properly with fully standardized product categories, it may take a while to figure this one out. Are basic RFM data—such as dollars, transactions, dates and intervals—routinely being used in predictive models? —The answer is a firm "no," if the statisticians are spending the majority of their time fixing the data; and "not even close," if you are still just using RFM data for rudimentary filtering. Now, if your answer is "Well, with some data summarization and inner/outer joins here and there—though we don't have all transaction records from last year, and if we can get all the campaign histories from all seven vendors who managed our marketing campaigns, except for emails—maybe?", then I am sorry to inform you that you do not have a marketing database. Even if you can eventually get to the answer if some programmer takes two weeks to draw a 7-page flow chart. Often, I get extra comments like "But we have a relational database!" Or, "We stored every transaction for the past 10 years in Hadoop and we can retrieve any one of them in less than a second!" To these comments, I would say "Congratulations, your car has four wheels, right?" To answer the important marketing questions, the database should be organized in a "buyer-centric" format. Going back to the database philosophy question, the fundamental design of the database changes based on its main purpose, much like the way a sports sedan and an SUV that share the same wheel base and engine end up shaped differently. Marketing is about people. And, at the center of the marketing database, there have to be people. Every data element in the base should be "describing" those people. Unfortunately, most relational databases are transaction-, channel- or product-centric, describing events and transactions—but not the people. Unstructured databases that are tuned primarily for massive storage and rapid retrieval may just have pieces of data all over the place, necessitating serious rearrangement to answer some of the most basic business questions. So, the question still stands. Is your database marketing ready? Because if it is, you would have taken no time to answer my questions listed above and say: "Yeah, I got this. Anything else?" Now, imagine the difference between marketers who get to the answers with a few clicks vs. the ones who have no clue where to begin, even when sitting on mounds of data. The difference between the two is not the size of the investment, but the design philosophy. I just hope that you did not buy a sports car when you needed a truck.

CRM

Cheat Sheet: Is Your Database Marketing Ready?

Stephen H. Yu

About

Subscriptions

Events

Publications

WORK SMARTER - LEARN, GROW AND BE INSPIRED.

Subscribe today!

Stephen H. Yu