Since there are fewer businesses in the world than there are people, B-B databases by nature are smaller than B-C. However, as you'll soon see, they're considerably more difficult to manage.

                                               A Look at B-C

To elaborate, let's begin by considering a typical B-C database. B-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, so in Figure A I've added a table called "Addresses."

Solicit data is my term for 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 that qualify. One reason to segregate solicit data is to discourage workaholic overzealous marketers from running inefficient string searches on name/address fields (more on this later). Solicit data includes fields such as name & 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 for a total of five. Other than a few supplemental tables used to translate codes such

as SKUs, that's about it with B-C.

Sites vs. Contacts

Now let's look at a B-B database. In the B-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-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. Because (a) there are plenty of bright people who can help us with this, and (b) I'm not one of these people, I'll stick to simpler problems and assume there's already some notion of who we want to solicit. Whether this be through sophisticated modeling or educated dart-throw, 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-C world, let's add 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.

B-B Solicit Data

When dealing with solicit data, there are several B-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 the same, each contact has a different first and last name, while the business name stays constant for all contacts within.

As shown in figures B and C, 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, as in

Figure D.

Being the renegade IT lightning rod that I am, I say break the rules and go with option two. One less table means one less place to look when we need something. Besides, this really isn't quite as earth shattering as our eversoeagertoplease DBA would have us believe. 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) take place. 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 - unless you're a creamy weenie - 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 practice isn't crippling, it causes unnecessary confusion amongst those poor stressed-out marketers, trying to figure out what data's stored where. Besides, it's such an easy thing to avoid that there's practically no reason not to do so.

Our completed B-B design is in Figure E. While it looks almost as simple as the B-C model, we're not done yet.

Useful Flags, Codes, and Aggregates.

Since I've already digressed, let me go further and say that too often I see 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. I've said this before, so listen up or I'll smack you: move query complexity 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 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 "website" 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 can usually be assumed the company website. 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 vs. personal.

With website in hand, we can have even more fun. Everyone knows about domains ending in ".com" and ".org." A quick google search yields a few more standard domain extensions and their meanings:

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:

Other B-B Issues

Other challenges faced by B-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 person who needs and uses the product. Usually, companies deal with this by storing both names as separate contacts within the database, but keeping both a bill-to and ship-to contact_id on the Order record. Which of these is considered our customer is a debate I'll leave to the experts, but there are valid arguments either way.

Title slugs, albeit an unappealing phrase, means using a generic title such as "Business Owner" instead of a person's name on a solicitation. This is not usually handled within the database, but instead is done on the back end by a service bureau or lettershop. So next time an envelope addressed to "Big Kahuna" appears in your inbox, before patting yourself on the back; realize that 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-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 for medium sites, and 10 for large sites based on recency.

As you can see, with databases, minding your business is not always easy. No matter what kind of peanut butter you like.

Copyright 2002, PRIMEDIA Business Magazines & Media Inc.  All rights reserved.