Son, there are two kinds of people in this world. Those who like chunky peanut butter, and those who eat creamy.” I uttered these profound words to the brash 6-year-old next door, as we stacked firewood one winter while engaged in a serious discussion about breakfast. Little did I know then that I’d be saying this to you now: “There are two kinds of marketing databases, business-to-consumer and business-to-business.”

Since there are fewer businesses in the world than there are people, B-to-B databases by nature are smaller than B-to-C. However, they’re far more difficult to manage.

Let’s begin by considering a typical B-to-C database. B-to-C catalogers market directly to consumers, who respond by placing orders for one or more items. As such, these databases generally consist of three primary tables: customers, orders and items.

As a matter of preference, I like keeping solicit data in a separate table rather than storing it with customer data. Solicit data is data needed to solicit a person, but — with some exceptions like state or ZIP — not used to decide whether you should.

For example, although you clearly need a street address to send someone a catalog, you wouldn’t use it in the selection logic of a campaign. Selections are done using demographics, purchase behavior, preferences and/or model scores, while street addresses are used to reach the individuals who qualify.

One reason to segregate solicit data is to discourage overzealous marketers from running inefficient string searches on name/address fields. Solicit data includes fields such as name and address, phone numbers (home, work, fax) and e-mail address.

Lastly, we’ll need to keep track of who we send catalogs to — letting us analyze responses — so we’ll add a promotion history table to our list. Other than a few supplemental tables used to translate codes such as stock-keeping units (SKUs), that’s about it with B-to-C. Sites vs. Contacts

Now let’s look at a B-to-B database. In the B-to-B world, we don’t exactly solicit people or companies. Instead, we market to people who work in companies, since a company by itself can’t read a catalog or place an order, and the person placing the order doesn’t pay for it. Consequently, B-to-B databases have to manage data at both the company and individual level, commonly referred to as the site and contact.

Unless we’re a large ISP, we probably want to use targeted mailings rather than sending a catalog to everyone in the database. Whether this be through sophisticated modeling or educated dart-throwing, we’ll probably need to store site-level attributes such as company size, revenue, number of employees and SIC code, as well as contact-level data like job title, recency of last order, lifetime orders and lifetime order dollars.

So…in addition to the tables used in the blissfully simple B-to-C world, let’s keep a site table to hold site-level data. In conjunction, we’ll need to add two important fields to all the other tables: site_id and contact_id. Doing this allows us to tie orders and items to contacts and sites, and lets us compute order and item totals at both an individual and site level.

When dealing with solicit data, B-to-B databases present a few challenges. For one, both businesses and contacts have addresses, but on occasion the address of a contact is different than that of the business. In addition, contacts often need extra pieces of information like a floor number or department. Finally, even when the addresses are identical, each contact will have a different first and last name, while the business name stays constant for all contacts within.

One way to handle these issues is to maintain solicit data at both a site and contact level as two separate tables: site address and contact address. Solicit data for sites include company name, street address, city, state and ZIP. For contacts it includes name, department, e-mail address and phone number. And of course, the site_id field links each contact to his or her respective site.

Another approach is to break the rules — again — and store solicit data only at the contact level, essentially repeating site-level fields for each contact within a site, but giving us one less table in the database to worry about (see graphic above).

I say break the rules and go with option two. One less table means one less place to look when we need something. Marketing databases are typically loaded and maintained through a series of steps, performed in something called a “staging database.” Think of this as a work area where data massaging (cleansing, sorting, aggregation and other processes) is done.

The result of this massaging eventually becomes the friendly marketing database that we know and love. Having a staging process means data can be loaded and maintained in a way that’s easy for IT to manage, and then — at update time — transposed into a format easier for marketers to use. (Translation: You can have your chunky peanut butter…and eat it, too!)

As an aside, keeping the staging database separate is an important concept that’s often overlooked. Time and again I see staging tables being put in the same physical database as marketing tables. While this isn’t crippling, it causes unnecessary confusion among those poor stressed-out marketers trying to figure out what data is stored where. Useful Flags, Codes and Aggregates

Too often, marketers create overly complex queries to ask routine questions. For example, searching a name field for values such as “Inc.” or “Co.” to try to identify businesses. Query complexity should be moved away from the marketer and into the update process, making it easy to ask an easy question.

In this instance, a simple “customer_type” field should be added and populated with a ‘B’ for business or ‘C’ for consumer. In keeping with this spirit, and to get back to the matter at hand, let’s add a couple of flags to our contact table to indicate whether there’s a phone number and e-mail address for the contact.

Another cool idea is to glean useful information from e-mail addresses. For example, we can add a “Web site” column to the site table, using the text after the “@” in non-ISP e-mail addresses. (ISP addresses have domain suffixes such as “yahoo.com” or “comcast.net.”) The domain shared by the most number of contacts within a site usually can be assumed to be the company Web site. And hey, since we’re checking for ISP e-mail addresses, let’s add another flag on the contact table to tell us if the e-mail address is work or personal.

With the Web site address in hand, we can have even more fun. A quick Google search yields several standard domain extensions and their meanings: .aero (aeronautic), .biz (business), .com (commercial), .coop (cooperative), .edu (education), .gov (government), .int (international), .mil (military), .net (network), and .org (nonprofit).

Armed with this information, we can add a “company_type” field to the site table, thus making it easy to do stuff like exclude (or include) contacts at military or educational sites. A few other ideas along this line are:

Add a “contact_count” field to the site table by counting the number of contacts in our database at each site. This might be a determining factor when deciding how many pieces to send to a site. *

People tend to change jobs more frequently than they move. (My company still gets offers for people who haven’t been with us for more than five years. After years of griping, we’ve concluded that it’s easier to try rehiring people than it is to stop getting their mail.) Given the transient nature of B-to-B databases, let’s store a “recency” field on the contact table. This can be done by taking the most recent order for each contact. *

Add a few more standard aggregates such as date of first order, date of last order and lifetime order dollars.

Other challenges faced by B-to-B catalogers include bill-to/ship-to situations, title slugs and max-per-site processing. With bill to/ship to, the basic problem is that the person who places the order is often not the one who needs and uses the product. Usually, companies deal with this by storing both names as separate contacts on the database, but keeping both a bill-to and ship-to contact_id on the order record. Which of these is considered the customer is a debate I’ll leave to the experts, but there are valid arguments either way.

Title slug means using a generic title such as “Business Owner” instead of a person’s name on a solicitation. This is not usually handled in the database, but instead is done on the back end by a service bureau or lettershop. So the next time an envelope addressed to “Big Kahuna” appears in your inbox, don’t pat yourself on the —. To the sender you’re simply a slug.

Max per site is a fairly easy concept to grasp, but a bit tricky to enforce. While I can’t offer much help with enforcement (this is a function of B-to-B campaign management systems), the idea is to avoid inundating a site with catalogs, and by extension avoid having an irate office manager deposit them all in a circular file. You do this by limiting the number of pieces sent to each site.

Ideally the max/per is done based on conditions, such as most recent order. For example, you may decide to send no more than two catalogs to small sites, five to medium sites, and 10 to large sites, based on recency.

With databases, minding your business is not always easy. No matter what kind of peanut butter you like.

Son, there are two kinds of people in this world. Those who like chunky peanut butter, and those who eat creamy.