Customer-Centric Marketing – Part II

By Jeff Fowler

In my last article, I closed with the point that data warehouses (or Great Big DataBases) are not directly useful for marketing. Since the word “marketing” covers an awfully wide spectrum, I’ll qualify this statement: for large scale outbound marketing operations such as mailing a half million catalogs or (for fundraisers) appeals, data warehouses contain far too much detail to efficiently segment millions of donors and gifts and produce business reports or extract large subsets of names. I’ve seen queries take nearly a day to create fewer than 50 direct mail segments, which in today’s instant-gratification world is simply intolerable.

So all this is why many companies create a marketing datamart as an offshoot of their GBDB. And naturally it begets the question: why go to all the trouble of building a warehouse if we can’t use it for reporting or segmentation? The answer is: ‘cause there’s a lot more to CRM than running direct mail campaigns and generating cross tabs.

Database marketing processes fit into two general categories: interactive vs. batch. Without lapsing into technical mumbo-jumbo, batch jobs chug through hundreds of thousands (if not millions) of customers and/or donors, while interactive jobs deal with one person at a time. Realize also that for marketing purposes, it’s not cost effective to mail just a handful of offers. Lettershops and merge/purge vendors quote prices by the thousand, not by the dozen, and they offer volume discounts for large jobs but penalties for small jobs. The US Post Office provides discounts to bulk mailers, and to take advantage of these discounts, mail files undergo processes such as CASS (Coding Accuracy Support System), NCOA (National Change Of Address), postal presorting, and so on. So think of a batch job as an assembly line and an interactive job as a single craftsman or mechanic. Using a data warehouse for bulk mail is like cranking up an assembly line to build a single car.

In techno-geek parlance, interactive processes happen in “real time,” which means now. If you use a website to place an order, it happens in real time. However, if you fill out an order form and mail it, your order is processed sometime in the future – hopefully! Also, interactive marketing processes tend to be event (or trigger) driven, like emailing a “thank you and welcome” message to a first time donor or a displaying a cross sell offer to a repeat customer placing an order. In each instance, the gift or order acts as a trigger, stimulating a “real time interactive process” (whew) to create the reply. Also, because customer centric messages usually examine multiple donor touch points such as gifts, inbound contacts, and preferences; in order to drive the message the database must perform a series of small, fast queries fetching information for one donor from many different places, instead of a single large query going to one place and processing a fixed set of attributes for thousands or millions of donors.

Incidentally, database and hardware vendors measure these two activities differently, referring to them as seek time vs. throughput. When responding to a mouse click, fast seek time is of paramount importance in database design. But for sorting a hundred million transactions, throughput becomes king. When explaining why a single database can’t be optimized to do both, the analogy I prefer is to compare a baseball stadium to a football stadium: they don’t use one stadium for both sports because the playing fields have different shapes. Similarly, a database designed for interactive queries is just not suited for batch ones.

In summary, we’ve talked about using a marketing datamart to run large marketing campaigns or reports, which we now see are batch processes. (Or, if you really want to impress your IT person, batch processes performed against a datamart that’s optimized for throughput.) But the qualities that make our datamart great for reporting and segmentation render it a poor choice for interactive operations, which is where our GBDB shines! These operations include event driven messages, inbound call centers, and websites. So now you can proudly tell your IT person: “we use our data warehouse for real time interactive queries that pull data from multiple donor touchpoints, because it’s optimized for fast seek time rather than throughput.” Congratulations, you’ve passed the geek test!