David Raab Article Archive

Database Marketing for Newspapers
David M. Raab
DM News
July, 1995

The newspaper industry came late to database marketing. On the whole this was probably an advantage, since newspapers got to use applications already developed for other markets. But it also caused something of an identity crisis, as newspapers attempted to decide which applications were most important.

As business-to-business marketers, should they focus on sales force automation for the advertising staff? As direct marketers, should they do sophisticated segmentation for subscription sales? As communication service providers, should they develop customer loyalty programs to reduce churn rates? Or should they build household databases that unify information from the subscription, prospecting and classified ad systems, like other marketers with data scattered among multiple operational systems? All of these applied, but priorities had to be set.

A couple years have now passed and the picture is much clearer. Newspaper database marketing turns out to have its own character, driven by a newspaper’s unique physical connection with its local market. Specifically, newspaper marketing databases must explicitly distinguish between a physical address and the customer at that address.

In part this is because newspapers have delivery routes and geographic advertising zones, which mean it truly matters where a customer lives. It is also because newspapers generally consider their prospects to be everyone within their geographic area, meaning they want a comprehensive database of all dwellings in their region, even when they know nothing about the occupants. Finally, newspapers often want to leverage this comprehensive database by adding customer lists from other local businesses for profiling and joint promotions.

Newspapers build these databases from a variety of sources including their own subscriber files and telemarketing operations, as well as external databases including compiled address lists, telephone directories, and postal files. Their database systems must be able to merge these to eliminate duplicate entries for the same location.

Another characteristic–not unique but still important–is that many newspapers have limited marketing and computer resources, so newspaper systems must be extremely easy to operate.

With the requirements clearly defined and a market aggressively seeking solutions, the path is open for software developers to build database marketing systems that are specialized for newspapers. In fact, at least three such systems have been introduced. One, Pro*Filer (Newspaper Marketing Solutions Inc., 415-721-2975) was reviewed in last month’s column. Here are two more.

VisionShift Database Marketing (Collier-Jackson/VisionShift, 813-872-9990) was originally introduced in 1992 by Collier-Jackson, a major provider of newspaper subscription systems. Although the eleven existing installations are all at newspapers using other Collier-Jackson products, the system can accept input from any source.

VisionShift uses the Sybase relational database running on a Unix server. Users run on a DOS PC with a graphical interface written in the JYACC JAM client/server development tool. This requires a fairly powerful PC: eight to 16 MB of RAM and over 200 MB of hard drive. By September, Collier-Jackson expects to replace the JAM front end with a version built in Microsoft Access and to support Microsoft NT as a server. Most of the processing is written in the C programming language.

The system has an exceptionally flexible data structure. Information is held in about 30 tables, with separate entries for physical address, consumer customers, business customers, individuals within a customer, subscriptions, promotions and transactions. A customer or individual can be linked to several different addresses, and an address can be linked to several customers. While there is a core of fixed fields for each data level, the system also allows users to add as many other fields as required. These fields appear automatically on selection screens.

Data is loaded into the system through import routines that can either match on a specific key, such as an account code, or on name and address. The system does not perform address standardization or postal coding, on the assumption that data will be coming from subscription files or other systems where this has already been done. The matching routines themselves look primarily for exact matches on user-specified fields, although the user can also define a near-match and see those records on an exception report.

One the initial database is built, the system would typically be refreshed daily with current subscription transaction information. This might take twenty or thirty minutes for a newspaper with 200,000 subscribers. A major import–say, appending ten demographic items based on an address match–runs at about 20,000 records per hour on a small Unix server. To support purchased demographic data and lists provided by local advertisers, the system can enforce expiration dates for individual imported data items.

Selections in the system are made with a particularly easy screen that lets the user check off the type of data to use, the specific data element and then the actual values to include. The price of this simplicity is that the interface does not support complex selections such as calculations or subqueries. Nor does it allow true Nth or random selections, test/control splits, or multiple segments selected as part of the same query. Properly trained users could overcome some of these limits by typing queries directly in Structured Query Language (SQL), however.

In addition to its query interface, the system has several other features that make things convenient. A “zoom” function allows the user to view selected records after a query is executed, which is a handy way to check that the right records were chosen. The system automatically updates each record’s promotion history record at the time of selection and will store queries for reuse. Users can search for existing queries based on their contents–say, finding all queries that involve a particular promotion code or data element.

There is also an unusually sophisticated facility to manage multi-step campaigns. Users can define a campaign as a sequence of marketing “events” with specific qualifications for each event and then assign customers to a particular campaign. The system then periodically checks customer records to determine which events they are currently eligible for. Since eligibility may depend on transactions that occur after the campaign has begun, the system has great flexibility in responding to customer actions. It can also limit the number of campaigns assigned to any one customer.

VisionShift lets users schedule repetitive processes other than campaigns, including batch jobs with several related tasks. A batch job can be written to pause for user input at the start, perhaps specifying a particular sales territory to cover in a report. Lengthy jobs can run in background while the user continues to perform other tasks on the system.

VisionShift comes with about 40 standard reports to support its regular operations and provide marketing information such as retention statistics. Users are expected to rely on third-party tools such as Microsoft Access for additional reporting needs and for other tasks such as statistical modeling, graphics, form letters and telemarketing. The system can provide ASCII and DBASE data extracts in user-defined formats, and comes with prebuilt formats for mailing labels, mail merge, MapInfo and telemarketing. Collier-Jackson is working with a sales automation vendor to add a module to support advertising sales operations.

Pricing is based on the Sunday circulation of the purchasing newspaper. Small papers would pay about $20,000 including installation in the first year, and 15% of the initial price in later years for maintenance. A million circulation newspaper might pay $200,000 to start.

Newspaper Database Marketing System (Consumer Marketing Systems, 414-798-1036) is a new product, first installed in April, but follows a previous newspaper system released in 1992 and installed at 14 sites. The system is written with the Enfin client/server development tool and Smalltalk programming language, which give it great flexibility: Windows or OS/2 workstations; Windows, OS/2 or Unix servers; and multiple relational databases. The initial installation uses Oracle. Like other client/server applications, it requires substantial desktop hardware: at least 12 MB of RAM and 300 MB of free disk.

The system is designed to run with minimum customization. The data structure is essentially fixed, with household and individual-level tables that can be changed only to the extent allowed by eight user-defined fields at each level. The system does not distinguish between physical address and customer household, and does not treat businesses differently from consumers. But it does support the maintenance of advertiser or other outside lists, by appending up to fourteen data items to each individual record for each outside list and placing controls on the use of this data. The system can also track usage of imported data. Data from an unlimited number of lists, each with its own set of items, can be linked to each customer.

External data is added to the system by a name and address comparison process that rejects all but exact matches. Users are expected to review exceptions manually and either change them to match an existing record or reject them. The system assumes that postal standardization and other preprocessing are done before data is loaded. Internal data can be matched by account number or other exact key.

The system maintains separate tables for subscriptions, transactions, promotions and other types of information. Internal transactions would typically be appended daily, in a process that runs overnight.

Queries in the system are generated through a point-and-shoot interface that makes extensive use of check boxes and buttons to guide unsophisticated users. It still manages to handle complex tasks such as frequency counts and subqueries, but cannot embed calculations within a query. Users must work within these limits, since they are not allowed to write SQL directly.

The system can select only one file segment at a time, although several existing segments could be processed in a single batch job. Users can define the size of a control group to be randomly selected from within a segment, and will see the test and control automatically compared in standard response analysis reports. The system lets the user define any type of transaction as a “response”. Selections can be limited to one name per household if desired.

The system’s batch processing capabilities allow users to submit jobs for immediate or deferred execution, and some clever programming allows jobs to use idle machines throughout the network–permitting use of dedicated servers or overnight processing on desktop machines when their owners are not present. But batch jobs cannot pause for input of parameters at run time.

Reporting in the system is limited to six standard reports and an ad hoc report writer that provides selected fields from specified records. More advanced reporting would require third-party tools that read the underlying relational database directly or work with ASCII extracts. So would graphics, mapping, form letters, telemarketing and any calculations. The vendor is working on a separate system to help ad sales people identify prospects and plan sales activities.

Pricing of the system is still being determined.