How to Successfully Manage One-to-One Campaign Databases

The key to success when deploying any one-to-one communications campaign is proper database management. It may seem like a foreign subject to many print providers new to variable data printing (VDP) or cross media, but it can make or break any campaign.

We have all, at one time or another, received personalized direct mail or e-mail messages with a name misspelled or an irrelevant offer. Not only are these communications ineffective, but they can damage the reputation of the organization sending the communication. In this article, I will highlight the ways you can prevent data mishaps and ensure your client’s database is campaign ready.

A Clean Database Is a Happy Database

A clean database ensures the right message with the highest relevance reaches recipients. It also means fewer errors and returns on print and e-mail messages, reducing wasted resources. Though it is usually the client’s responsibility to supply good, clean campaign data, providing a data cleansing service may be a great opportunity for your operation to expand into a new service-based offering and generate additional revenue.

When cleaning a database, it is good to avoid duplication of effort and do as much as you can at once. If you are in the database cleaning up addresses and phone numbers, make sure other data meets standards as well. For example, are names all upper case when you prefer mixed case? Or are there extra spaces in text fields or unwanted characters, such as percent or pound signs floating around? Handling any potential problems at one time will take slightly longer, but the effort will pay off greatly in the long run.

It is also helpful to have another colleague who is familiar with the client, project, and information to double check the data. When reviewing similar information repeatedly, you can often overlook glaring mistakes.

Lastly, once the database is clean, it is imperative to develop a plan to ensure the cleansed database does not lapse back into disrepair as existing data is altered or new data is added. It will make the process before deploying a campaign much faster and easier if you know the data has been regularly maintained.

An important place to look when planning for ongoing data cleanliness is in applications that write back to the database. Some cross media solutions, for example, have a built-in rules engine that not only reads databases and applies business rules, but also has the ability to apply business rules or logic to data being written back into a database. This capability provides a way for a set of rules to be created that automatically ensures new data meets existing rules.

Use Applications Designed for Data

Many organizations store data in applications that are not designed to be databases. For example, Excel is often used and referred to as a database, but in actuality it is an application designed to perform calculations. That is why several issues come up when running a VDP or cross media campaign from an Excel spreadsheet. Who among us hasn’t had a zero drop off the front of a zip code when working with mailing addresses in Excel?

To avoid potential data pitfalls, use Access, SQL, Oracle, or another application designed for data. If a client provides you with an Excel spreadsheet, you can simply convert the file to CSV format and deal with any potential issues, such as missing zeros in zip codes, during the conversion process.

Another option is to use a VDP or cross media application that allows you to write business rules addressing issues, such as the common zip code problem, ensuring your data appears perfectly every time. Many companies use both techniques in conjunction. That way, if something slips past the conversion process it can be caught by the business rules.

Limit Freeform Text Fields

There are many instances when it seems necessary to include freeform text fields in a database, such as when entering the name of a product or service level. However, this manually entered information can create more harm than good, allowing errors or typos during data input, increasing the likelihood of incorrect information in the final product.

A good example is a cell phone company that has three service levels—Bronze, Silver, and Gold—designated for its customers. By depending on freeform data entry of these levels, the data in the database for “Bronze” could be BRONZE, Bronze, bronze, bronse, “b,” or a variety of other variations.

Think about how that could look to the final recipient, or what would happen if you applied programming logic to that field—“if Service Level = ‘Bronze’” would work for only one of the above examples.

An easy way to avoid including freeform text fields in a database is by assigning a numerical value to the common freeform information included. In the above example, numbers could be used to represent the service level, such as 1 for Bronze, 2 for Silver, and 3 for Gold. Then in the output business rules engine, a simple business rule, such as “if Service Level = 1…” could be written.

Remember to apply similar business rules to the applications that populate the database as well.

Use Appropriate Field Types

Database applications provide a host of field types—including text, numerical, and Boolean. Good database practice dictates using the appropriate field type for the appropriate type of data. To continue with our cell phone company example, when a field is created for the service level, it should be defined as an integer. Doing so makes it easier to write business rules later and prevents other errors.

The same is true for Boolean or yes/no data. Things that may be described as check marks on the data input side are probably best stored as a Boolean value. That way, the business rule on the way out can be as simple as, “if Additional Coverage Purchased then…”

A corollary to this tip has to do with storing data about dates. While it might seem straightforward to create an integer field called “Age” to store recipients’ ages, it will only be valid for so long. The next year, all of the values will be off by one. Instead, store the individuals’ birth dates and let the rules engine perform the calculation. For example, “Age = YearDifference(Birth_Date, Now()).”

Where To Store Business Rules

A database is not the place to house business rules. This is especially important as you look to incorporate more advanced personalization into campaigns—such as discounts tied to customer reward level.

For instance, today the cell phone company offers its Gold customers 30 percent off a service, Silver receives 20 percent, and Bronze receives 10 percent. If the company wants to change the percentages to 40 percent, 30 percent, and 20 percent off for a special, limited time promotion, someone will need to manually change the rule in the database and then change it back at the conclusion of the promotion. If the rule lives outside the database, the rule will only need to be changed in one place.

While some database applications allow you to perform this type of logic in the database itself, doing so may become limiting. For example, you may use multiple data sources for a single job. Using our cell phone company example, the data for variable data production may come from individual store locations, each providing a copy of the data.

By storing the data in a database, each store would have to update its local database. Instead, by keeping the rule in the rules engine, you don’t limit yourself to a single data source. Any data source can be used to produce print, e-mail, Web, or mobile output.

Use the Web To Enhance the Database

Just because a client does not have a robust repository of customer data, doesn’t mean they can’t benefit from a one-to-one campaign. A great way to build a database is through the Web. Depending on whether you have mailing or e-mail addresses available, you can deploy a print or email-based campaign incorporating personalized URLs (PURLs) for the recipients.

PURLs can include information relevant to the campaign, but with some one-to-one software, can also be used to collect new customer information to build a more comprehensive database.

Using PURLs also allows you to confirm or correct existing information, saving significant time and resources on internal data cleansing.

In addition, if you are using an integrated system with a business rules engine for personalized print, Web, and e-mail communications, you can maximize the reach of your next interactions with even more accurate and relevant information. This type of solution should also allow you to create business and logic rules that define how the data goes back into the database.

As you can see, data management is a critical task before, during, and after every campaign. However, if you follow these guidelines, your client’s campaigns will be more accurate, relevant, and successful. And that means more business for you and your client.

Phil Rose is the former product marketing manager for XMPie Inc. Learn more about XMPie’s products and services at