1995 Aug 01
More on Interactive Marketing
David M. Raab
DM News
August, 1995

The April 17 and May 15 editions of this column dealt with CD-ROM catalogs and direct response TV, the two most concrete implementations so far of the much-anticipated “interactive marketing”. Each column left out an important system in its category. Here are the omissions.

CatalogBuilder (Digital Delivery, 617-275-3830) was introduced in 1994 as a product aimed at “electronic commerce” rather than just building CD-ROM-based catalogs. The difference is that the product also includes a modem-based ordering mechanism, the encryption necessary for secure on-line transactions, and the ability to link to both the buyer’s and seller’s existing computer systems for order authorization and processing, respectively. In fact, one of the system’s most intriguing applications, still in the planning stage, is a “reverse catalog” that includes entries for all of one firm’s authorized vendors and is used to simplify and centralize that firm’s purchasing operation. In this system, orders are “placed” with the firm’s internal purchasing system, which checks authorization, assigns Purchase Order numbers, and then sends the actual transactions to the vendors over a standard Electronic Data Interchange (EDI) network.

The system’s five existing implementations are more conventional electronic catalogs, produced by a single vendor and distributed to customers and prospects. Four are from suppliers of industrial electronic components, although one holds encrypted computer software that is copied directly from the CD-ROM once the buyer has made a payment and received the proper code in return.

But even the vendor-built systems depart from the standard electronic catalog model, which mimics a paper-based catalog by placing items on “pages” and using page-related access mechanisms such as table of contents, index, page-turning “browsers”, page tagging, and so on. Instead, CatalogBuilder’s standard interface assumes that customers will locate items through simple or complex searches of the built-in product database. These searches can be as simple as listing all products from a particular manufacturer, or involve complex logical conditions defined through a point-and-shoot query builder. The available variables depend on the type of product–clothing might use size, color, and style, while computer software might use operating system, application and memory requirements–and are defined for each product type when the catalog is set up. A single catalog can mix several product types, and still offer only the search variables relevant to the type of product that was initially selected.

The system creates internal tables of product attributes once a catalog is built, so that searches typically take just two or three seconds.

Once a small list of potential products is identified, CatalogBuilder allows the user to see additional detail about each item. Text can be stored directly in the system, or it can be linked to any external program with graphic, audio, video or other types of information. Products can be selected by clicking on a button or dragging the object to an “order pad” and specifying a quantity. The system can remind the user of related items that must be purchased along with a selected product, such as a cable to go with a printer. A special facility for software vendors can report on the hardware being used to run the system, to determine whether the buyer’s computer is compatible with software products included in an order.

The system keeps a running total of the cost of the current order, and can calculate sales tax if the user enters a rate. Developers could embed a Zip-based sales tax table or call out to third-party tax calculation software, and will soon have the option to include shipping cost calculations as well. The system stores a list of bill-to and ship-to addresses for previous orders by each user, and lets the user select an existing set or enter new addresses for the current order.

Once the user is ready, the system’s built-in communications software can dial the vendor’s computer to place the order, using the sophisticated RSA private key encryption scheme to protect confidentiality. (The system does not require passwords from individual users for access, although this could be built in.) Interfaces could be built to link directly to the vendor’s order entry system to actually check available inventory, authorize credit and enter the order. But this raises security and other issues, so current CatalogBuilder installations simply post the orders onto a computer bulletin board and let the vendor enter them separately. The system could also send the orders by fax or EDI, generate printed copies, or create a transaction file to load into another system. A copy of each order is also retained within the system on the buyer’s hard drive.

When the user connects with the vendor’s system, CatalogBuilder can also automatically download new prices. These are stored on the user’s hard drive rather than the original CD-ROM. New products are generally not downloaded in this way, because they reside on the CD. Unlike some other CD catalog systems, CatalogBuilder does not provide for e-mail messages as part of its linkage. Nor do current versions broadcast special offers or other marketing messages to users, although this could be added.

Particularly intriguing, the system can also report at the time of connection on the user’s behavior during the previous session, showing which products and features were looked at and how much time was spent. Although this might be used to build profiles of individual users, the intent is to provide more general marketing intelligence similar to conventional catalog research on how people are using the system, which items are most popular, which are being looked at but not purchased, and so on.

CatalogBuilder systems are created with Digital Delivery’s own software, which includes the user interface, search engine, order generator, modem access, and encryption. The system uses the Raima database engine. Developers use standard multi-media tools to create the system contents, and can add custom features by writing them in languages such as Visual Basic or C++ and calling the system’s Applications Programming Interface (API). The current system runs on Microsoft Windows with standard hardware: earlier versions had been ported to MacIntosh and Unix, but demand never materialized. Companies wishing to build their own catalog can purchase development tools for $20,000 for one user and $10,000 for additional users, or have Digital Delivery build the system for them. Copies of the viewer software (for end-users) cost from $2.00 to $.05 depending on volume, up to $20,000 for unlimited copies.

MediaLink for Windows (NextGen Systems, formerly Media Solutions; 610-354-8700) provides direct response television advertisers with a system to plan, execute and evaluate their media purchases. Introduced in late 1994, the system has been sold to eleven U.S. firms, mostly large infomercial producers and agencies. It is written with the PowerBuilder client/server development tool to run with Microsoft Windows workstations and any standard relational database. Initial implementations use Watcom SQL, and an Oracle version is now being prepared.

MediaLink is targeted at larger, sophisticated direct response marketers. For example, it supports international operations through a country table with information about local currency, taxes, exchange rate, and default operational vendors for fulfillment, customer service, answering service, call overflow, dubbing and credit card processing.

Information from this table is drawn as a default into the setup of specific offers, which can have customized profit and loss calculations using different currencies for each line item–perhaps because orders from Germany are fulfilled out of the Netherlands with a product purchased in Taiwan. The system will automatically convert each line into a common currency before making summary calculations. It will also allow the user to enter alternate “what if” assumptions in a separate column, without altering the original values.

This degree of sophistication is made possible–and practical–through use of many related database tables. In addition to countries, the system has administrative tables for vendors (split into subcategories), employees, stations, markets, program types, dayparts, and standard letters. Information about products is stored in campaign, offer and item tables; telephone numbers and traffic information are related to specific offers; and the system handles long-form, short-form and several types of Per Inquiry (PI) media purchases. Higher level tables provide default values and option lists for more detailed tables, speeding data entry and reducing errors.

Once the basic administrative information has been entered, most work in the system is done at the campaign and media levels. Campaigns are roughly analogous to product lines; each holds items and offers and well as a set of profit and loss assumptions including allowable media cost ratios, inquiry conversion rates, and seasonal response adjustments. For each item, which can be either an individual Stock Keeping Unit (SKU) or several SKUs sold as a bundle, the system stores information including type, shipping weight, price, shipping and handling charge, order quantity, number of payments, and shipping cycle (for continuities). Offers are based on the existing list of items, but can override the default price and shipping values. Offers also include information about the actual advertisement length, first and last air date, allowable media cost, lists of vendors (based on defaults from the country table), profit and loss assumptions (based on defaults from the campaign level), and telephone numbers used for responses.

Media schedules relate specific offers to individual stations. The system allows the user to enter the cost of each buy, with different screens for long form (e.g., half hour), short form (e.g. 60 second) or Per Inquiry purchases. PI buys can be made on a fixed dollar or percentage basis, and the system can calculate separate payments to a client, station and buyer. The system will not allow different PI dollar payments depending on the exact items purchased, however. Nor does it store “gross” or “rate card” costs on media buys, although it stores commission when appropriate so “gross” can be calculated if desired.

Several other media buying features are very impressive, however. One is a function to assess the desirability of a particular purchase, by finding up to ten comparable past purchases and estimating the probability that the new purchase will yield acceptable results. Another automatically checks whether a tape with the appropriate commercial is present or scheduled to be shipped to the station, and creates a “to do” list entry for the traffic department if needed. A third uses a custom table built by NextGen to ensure that the same telephone number is not assigned to geographically adjacent stations, making it easier to attribute orders to the correct stations when responses are received.

These orders can be entered into the system manually, on a screen that mimics the format of fax reports typically received from telephone order taking services, or by electronic files from these services. The import routine automatically creates copies of the downloaded files, checks for valid entries, and flags any problem records. It will allocate orders to specific stations when possible, and lets users manually allocate the balance by graphically “dragging” individual orders onto the desired line of an on-screen media schedule.

MediaLink’s standard reports will probably serve the needs of most users. The system does not have an integrated report writer, although any third party SQL-based product would work with the underlying files.

The only major function not available in the system is integrated accounting. NextGen found that larger firms wanted it this way, because they would rather use their existing accounting systems for all transactions. So MediaLink simply exports information on payments as they become due and leaves it to the user’s own accounting system to cut the actual checks or generate client invoices.

Pricing on MediaLink reflects the system’s high-level target market. A base installation costs $24,000 for six users and includes two or three days of on-site training. After the first year, telephone support and software maintenance costs 15% of the original license.

* * *
David M. Raab is a Principal at Raab Associates Inc., a consultancy specializing in marketing technology and analytics. He can be reached at draab@raabassociates.com.

Leave a Reply

You must be logged in to post a comment.