2008 Nov 01

Demand Generation System Requirements

Demand Generation System Requirements
David M. Raab
DM Review
November 2008

Demand generation systems—products to attract and nurture leads before they are turned over to the sales department—are probably the fastest growing type of marketing software.  This means there is a good chance you will be asked to help select such a system in the near future.  If that happens, what’s the best way to proceed?

First, recognize that many demand generation products are offered on a “software as a service” basis.  This means you won’t be installing, managing, upgrading or customizing the software, so you can skip many of the usual technical considerations.  Of course, you’ll still need to assess security, reliability and scalability.  You may even add some new technical issues, such as integrating with the system as a Web service or via its Application Program Interface.  And there are always business issues including vendor stability, pricing, contract terms, implementation and support.

But mostly you will focus on user requirements.  This can be exceptionally difficult for demand generation systems because they are new to an organization.  Without previous experience, users find it hard to define their needs.

One thing you don’t want to do is just pick the system with the most features.  Features you don’t need add complexity without increasing value.

A better approach is to steal a page from the developers’ book and define business use cases.  Most demand generation systems are used for a few common applications.  It’s easy enough to list these and have your users pick the ones that are most important.  The requirements for these applications are the requirements for your system.

Here is a set of demand generation applications for your marketers to consider.

- Lead generation campaigns.  These campaigns attract new names to your prospect database and reactivate old ones.  They send messages through list-based promotions such as email, direct mail and telephone calls, and anonymous media such as print and Web advertising, search engine listings, and trade shows.  Responses are captured and reacted to appropriately.

Functional requirements for lead generation include campaign setup with costs and tracking codes; list segmentation and selection; creation and delivery of email, direct mail, and telemarketing scripts; landing pages and surveys to capture responses; auto-reply mechanisms to react to inquiries; and reporting on results, including sales data from CRM or accounting systems.

Specific requirements depend on your business.  If your marketers execute many programs simultaneously or produce localized versions, they’ll need features to share standardized content.  If they offer many different products or gather detailed prospect information, look for ability to tailor messages by list segment.  If they work in channels beyond email and Web pages, the system must support these.  If they import leads and sales data from external sources, they need customer data integration and extensible data models.  Demand generation products vary greatly in all of these areas.

- Lead nurturing.  This is maintaining continuous contact with leads until they are ready to buy.  It involves sending messages to inform leads about the company, and gathering information about the leads so you can understand them better.  Functional requirements include multi-step, cross-channel campaign flows; visitor identification through cookies, URL strings and IP look-up; offer selection based on lead attributes and observed behavior; generation of email and newsletters; response capture via surveys and landing pages; and results measurement.  Because lead nurturing programs seek to enrich existing relationships, capturing detailed data is especially important.  So is the ability to use this data in complex program flows, offer selection logic and message personalization rules.  Many lead nurturing programs also need a continuous supply of content to keep the messages fresh, which implies requirements to manage content libraries and RSS feeds.  Companies vary greatly in how sophisticated they need their lead nurturing programs to be.  In general, companies with many products or complex sales cycles will want more advanced lead nurturing capabilities.

- Lead scoring and distribution.  This manages the actual transfer of leads to sales.  Key functions include gathering data through surveys, data enhancement and activity tracking; lead scoring calculations to identify when the leads are ready to send; lead assignment rules to determine which salesperson should receive the lead; and CRM system integration to make the actual transfer, synchronize marketing and CRM data, and coordinate future contacts.  Demand generation systems vary widely in all these areas.  In particular, don’t assume a system can meet your needs if you must: integrate with a CRM system other than Salesforce.com; assign leads within the demand generation system rather than relying on the CRM system; use a Web services interface to interrogate external sources such as D&B or Jigsaw; or perform sophisticated lead scoring calculations.  Also look closely if your salespeople expect true real-time integration, such as alerts when a prospect visits the Web site or requests a chat.

The list of common demand generation applications also includes marketing performance measurement, managing events such as Webinars, and coordination of local marketing efforts.  Each has specific requirements that you can identify by working with your marketers to define the necessary process and data flows.  Once you’ve done this, it’s easy enough to look for the required capabilities in the systems you evaluate.  The trick is making sure the requirements are based on specific business needs: it’s the only way to get the system that’s right for you.

*                            *                           *

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.

2008 Oct 01

How to Judge a Columnar Database, Revisited

How to Judge a Columnar Database, Revisited
David M. Raab
DM Review
October 2008
.

Last December, this column ran a piece on “How to Judge a Columnar Database.” When someone quoted it to me recently, I realized it had already become outdated. The reason is that a new generation of vendors, including Vertica, ParAccel, Calpont, and InfoBright, has joined older columnar systems from Sybase IQ, Alterian, SmartFocus, Kx Systems, and 1010Data.

In general, the new systems assign dedicated disk drives to each processor (“shared-nothing”) while the older systems apply multiple processors to a shared storage pool. Each approach has its own strengths and weaknesses, which introduces some new differences to consider. In addition, the broader adoption of multiple processors and 64-bit memory removes some of the performance constraints that impacted earlier systems.

Let’s first revisit the original list of items to see which are still relevant. Then we’ll add a few new ones.

- load time, incremental loads, and data compression. These all reflect the need for a columnar database to restructure data originally stored in another format. They can be critical bottlenecks at large data volumes, and older systems varied widely in their performance. As a result, these were probably the most important considerations when comparing older columnar systems.

Today, multiple processors, larger memory space and more scalable disk storage have greatly improved load and compression rates in nearly all columnar systems. Substantial differences still exist, but performance of even the slower systems is likely to be adequate. As a frame of reference, leading columnar databases several years ago loaded around 10 gigabytes per hour, while today’s best products load 150 to 200 gigabytes per hour. Many can reach whatever load rates are needed by simply adding more processors. Additional processing power also allows greater compression of stored data, since systems can decompress it more quickly after it is read from disk. (Decompression is not always needed: many operations run on the compressed data directly.)

Bottom line: you still need to consider load and compression performance, particularly if you’re dealing with terabytes of data (and aren’t we all?) or need quick incremental updates. But these issues no longer head the list.

- structural limitations: some early columnar databases imposed significant constraints on data structure, such as requiring that all tables use the same primary key. These crude limitations are largely gone. However, some of the newer systems do have more subtle limits, such as performing better on star schemas than normalized architectures. If you expect to use a star schema anyway, you probably won’t have a problem with any modern columnar system. But if you use other structures, check carefully how well a given product will perform on them.

- access techniques: while many early columnar systems were not SQL-compatible, all of today’s products all offer some level of SQL access. (Some still offer their own language for functions that SQL handles poorly, such as time series analysis.) Still, there are many levels of SQL compatibility. You’ll want to dig into the details for each system, particularly if you want to reuse existing SQL queries or SQL-based reporting tools.

- performance: this is one issue that hasn’t changed. Columnar databases are all fast, but performance on particular tasks can vary substantially from system to system. Performance may also depend on system configuration, so it is especially difficult to test. But performance is probably why you’re considering a columnar system in the first place, so you’ll certainly want to be sure you know what you’re getting.

- scalability: any columnar database you’re likely to consider will handle a couple terabytes of data. But not all are proven at the fifty or hundred terabyte level. In addition, some systems are significantly better than others at handling mixed query types and large numbers of simultaneous users. If you have needs like these, make sure your chosen vendor has similar installations in production, or that they can demonstrate the necessary performance in a realistic test.

So much for the old issues. None has vanished but the frame of reference has shifted for many. In addition, here are some new considerations:

- fault tolerance: many of the newer systems store data redundantly, either within or across nodes. This is done largely for performance purposes, but can have side benefits of easy—possibly even interruption-free—recovery from hardware failures. Many columnar databases are used for analytical work where some downtime is acceptable. But if it matters for you, be aware that products differ substantially in this area.

- data types: columnar databases have traditionally analyzed conventional structured data. But a few also support XML, text analysis and even binary objects. As with fault tolerance, you may not need this, but should know that it’s available if you do.

- database administration: one of the traditional benefits of columnar databases was their simplicity. Basically users dumped in the data and the system organized it for them. It’s still possible to work this way, but many systems now provide options such as multiple index types or sort sequences. This lets users tune the system to their requirements, but also means database administrators must make the right decisions. It’s still true that any columnar system should be easier to manage for a given analytical application than a relational database. But you’ll want to assess the differences in administrative workload among the columnar products themselves.

* * *

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.

2008 Sep 01

Demand Generation vs. Marketing Automation: What’s the Difference?

Demand Generation vs. Marketing Automation: What’s the Difference?
David M. Raab
DM Review
September 2008

Last month’s column described the importance of lead scoring within “demand generation” systems. But perhaps we should step back to describe those systems in general. Many people still confuse them with “marketing automation” or “campaign management” products.

It’s an easy mistake. Both sets of systems maintain a contact database used to drive outbound marketing campaigns. Both provide reporting and analysis tools to understand promotion results. Both sometimes include marketing planning, content management, and project management.

The obvious difference is that demand generation software is nearly always used by business marketers, while marketing automation and campaign management are used primarily to reach consumers. But this distinction is less useful than it seems. Many traditional marketing automation systems are also used for business marketing. And many small consumer marketers use lower-end demand generation software.

The more meaningful distinction is probably between companies that market directly to their customers and those that sell through sales people. Traditional marketing automation systems are used primarily in financial services, travel, retail and communications companies. Their campaigns sell specific products, even though the sale may be completed at a retail store, bank branch or sales agent. By contrast, demand generation systems attract and nurture leads which will be handed to sales departments when they are ready to buy. The salespeople will then identify needs, select appropriate offers, and close the deal.

Another, even simpler difference is that demand generation systems work with leads—that is, people who have not yet made their first purchase—while marketing automation systems focus on existing customers.

The fundamental distinction between nurturing leads and managing customers drives the major differences between the two sets of products. These include:

- focus on Internet behavior. Demand generation systems drive prospects to the company Web site, monitor their behavior, and infer when they are ready to buy. Most of herding is done with emails, which themselves can report whether they have been received, opened, clicked on, etc. Demand generation systems track Internet behavior in great detail because it’s one of their two main information sources. (The other is user-provided information such as surveys). By contrast, marketing automation systems work primarily with promotion and purchase histories. Non-purchase behaviors such as Web site visits are given much less weight if they are considered at all.

- integrated Web pages and analytics. Demand generation systems provide tools to build Web surveys and microsites and to capture data from these directly. This reflects their focus on online media. Marketing automation systems can sometimes build Web pages, but they largely assume this will be done externally. Similarly, they usually rely on third-party Web analytics systems to capture information about visitor behaviors.

- tracking of anonymous visitors. Tagging anonymous Web site visitors with cookies, building a history of their behavior, and later merging that history with the visitors’ identities are central features of demand generation systems. Marketing automation systems may not even track anonymous visitors, and certainly do not consider this a core capability. Have I mentioned that they are primarily interested in communicating with known customers?

- multi-step, highly reactive campaigns. Treatments within a demand generation campaign can vary quickly and significantly in response to an individual’s behavior. Marketing automation systems consider this an advanced feature that only their most sophisticated users are expected to deploy. In contrast, this is a fundamental capability for even basic demand generation products. In fact, finding ways to simplify deployment of multi-step campaigns is one of the main competitive battlegrounds in the industry.

- limited segmentation. This is the flip side of campaign complexity. Demand generation systems start with limited information about their targets, so they build campaigns that adjust treatments as information is gathered during execution. Marketing automation systems begin with a much richer customer history, so they select treatments using complex segmentations when the campaign is set up.

- lead scoring. Demand generation systems support elaborate scoring calculations to measure when a lead is ready for sales. Although marketing automation systems often support user-defined calculations and predictive modeling, they lack specialized lead-scoring functions such as depreciating the points allocated to older events or capping the points generated by a particular type of event. This is another competitive arena for demand generation vendors.

- simple database structure. Both demand generation and marketing automation systems maintain databases with information about individuals. But the base structure in demand generation systems is usually just a lead table and contact history. A modern marketing automation system nearly always includes purchases, and often additional information such as account balances and customer service interactions. The theory among demand generation vendors is that detailed information will be kept in the company’s customer management systems. However, most demand generation systems do let their clients extend the data structure through custom tables. For example, some version of purchase history is needed to measure campaign return on investment.

Many of these differences are more a matter of emphasis than fundamental technology. The products within each group also vary widely. So you still need to identify your own business requirements and assess how each system would meet them. But understanding the distinction between the two categories should make it easier to narrow in on the products best suited to your needs.

* * *

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.

Previous Entries