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.
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.
