Database Marketing: Setting Customer Database Priorities

How to develop the application that's best for your company

Determining priorities doesn't stop with choosing the appropriate tools for your end users. You have to “close the loop” and measure the final result against the original application vision

WHOSE VISION of the proposed customer database should you build?

Should it be the vision of the Marketing SWAT Team, armed with sharpened pencils, MBAs and plenty of acronyms? They're convinced a new customer database will enable them to work marketing miracles: lift response rates by 20%, generate $5 million in incremental revenue or increase total order size by a factor of 1.5, for example.

Or maybe it should be the Veg-O-Matic Dentists who want to “slice, dice and drill down” into the data. They want all the bells and whistles, especially powerful data mining tools that will allow them to identify meaningful patterns in the data. These are the SAS gurus who talk endlessly about data visualization and multidimensional online analytical processing tools.

The Nuts and Bolts Team also has a vision. They're fascinated with technology and spend a great deal of time talking about RDBMS, multitiered architectures, ETL, ERP and RAID. Debates go on for hours about MPP vs. SMP and the merits of Oracle vs. Siebel.

Then there are the Grand Poobahs in the corner offices on the executive floor who are convinced they will point and click their way to amazing insights. They expect they'll have an analysis of yesterday's sales information and colorful graphs that monitor Performance vs. Plan waiting for them every morning when they arrive at work.

How about the Customer Therapists who look at the proposed database as a “customer-intimacy machine”? They envision a system your customers will welcome and readily feed with all manner of information in order to establish the relationships they've always wanted with your company. They contend this relationship will only get better as the company fully engages in a meaningful dialogue with its customers.

And what about the Data Gourmands who want to roll up their sleeves and “just get their hands on the data” — all of it. Every possible tidbit of data out there — nothing is considered too insignificant. They are absolutely convinced that somewhere in that pile of information are the golden nuggets that will ensure the future success of your company.

Which group's vision is correct? Which is most realistic, practical, effective? Which is most visionary?

The answer is that all of their visions are correct — and none of them are correct.

Identify Requirements

What's important at the beginning of the development of a database is that you and everyone else in your company take deep breaths while you make sure all the necessary constituencies are brought together to identify the database requirements. This is arguably the most important step in the process. Without it, a million things can go awry. With it, you will still have stumbling blocks, but you'll get over them much more easily. And it's far less likely that any one problem will be an insurmountable obstacle.

You'll have to achieve consensus on database requirements; that is, you'll need general agreement among all the parties concerned. When considering business requirements, begin at a very high level. There's just one question: What business problem are you going to solve with this customer database? The business objective might include increasing market share, reducing costs, cross-selling new products, instituting personalization, improving retention rates, or any number of customer relationship management initiatives.

This decision on the primary business objective should address a challenge and promise measurable results. Quantifying the results of all proposed applications will allow your group to reach consensus about the database's purpose. Generally, it will be clear where the biggest bang for the buck lies after prioritizing each application based on feasibility, cost, potential impact and potential return. (And, of course, the business case for actual development of the database will be based on the projected results of the chosen application.)

Identification will also enable you to prototype and then build the application as quickly as possible. Once the first business application is up and running — and once there are measurable results — it is then much easier to justify further development of the database.

Next, focus on the key features of the system that will address the database application you have chosen. Make consensus decisions about the following:

• Data review. Once you have identified all the data sources available, assess the individual data elements to determine the business value they represent. Be ruthless. Judicious selection of those elements will allow you to complete your application in a reasonable time frame. At this point, you should also decide how far back in time you will collect data and whether it will be necessary to purchase and append demographic or other data from outside your organization. You may also make decisions at this time about data hygiene processes (using NCOA, CASS), data transformations, aggregations and summarizations.

• Relationship identification and continuity. It's also important at this stage to come to an agreement about the definition of a customer and how the data will be grouped for each relationship entity — individual, household, business and site, for example. These issues are never as straightforward as they look on the surface. You need a clear definition of the customer to assess customer value properly across household and business relationships. You should also consider the long-term impact of changes to these relationships because of events like marriage, divorce, address and job changes, and mergers and acquisitions. Processing rules need to deal directly with these events to avoid the gradual erosion of key relationships.

• Logical data model. This step is especially important if you're planning a relational database. The model becomes a high-level map for end users, allowing them to find and link the data they need. The data model should also clearly represent the relationships among your customer base. The issues surrounding grouping your customers into households or business entities should also be considered within the overall design of the processes that will be necessary to build the database as well as the data model.

• Physical data model and the technology decision. Although most end users will not be qualified to evaluate the technical features of the hardware and software, they should nevertheless be included in high-level discussions of technology decisions. End users and IT departments must work together in order to find an application that satisfies the requirements of both groups.

• Update schedule. All constituencies must agree on how often new data will be cleaned and loaded to the database. Although end users might ask that data be loaded every day, everyone involved should examine this issue carefully, weighing costs, work schedules and identifying the point at which updates would absolutely be necessary to meet the goals of the application. An update strategy could include some combination of frequent incremental transaction updates and less frequent full updates.

• Data integrity. Prepare to review your existing data. Designate areas where data quality can be improved through automated processes vs. those that will require procedural changes in your collection processes. If they're not addressed, data quality problems can undermine the value your users place on the database. Rigorous data validation and hygiene processes should be incorporated to detect and address data quality issues at an early stage.

• Security. Decisions must be made about who can access which data, especially because consumer concerns for privacy are becoming more of an issue.

• Metadata. Data about data. End users and technology providers must work together to determine the metadata that's necessary in order to use the database at peak efficiency. Metadata should, at the very least, record the “system of record” (where the datum is from), any transformations that occurred en route to the database, the actual description of the datum, and any changes to the metadata over time. Rich, accurate and current metadata serves to increase the users' confidence in the business intelligence derived from the database.

• Tools. Decide which tools will allow the end users to access the database efficiently and effectively. Determine whether end users need reporting tools, querying tools or a campaign management system. In addition to characterizing the features and functions you need to provide users, you must make sure the chosen tools couple well with your users' comfort levels with technology and the data savvy they possess.

Setting database priorities doesn't stop with choosing appropriate tools for end users. You must “close the loop” and measure the final result against the original application vision. Additionally, because database planning is virtually perpetual, you should implement a continual review process that measures data and applications against the needs of the current business environment. This will ensure that the database is a “living, evolving organism” and not simply a static monolith.

Building a database is never a simple undertaking, but by involving all the groups in the process right from the beginning, you will take a great leap forward toward ensuring your success.

Donna M. Ialongo is senior consultant, analytical services at Nykamp Consulting Group in Downers Grove, IL.