Database marketing is based on sending messages to known individuals.  This has always been in sharp contrast to conventional mass media, such as television and print advertising, where the marketer did not know exactly whom they were reaching.

But the introduction of online marketing has blurred this distinction.  Online marketers often know a great deal about the people they interact with, even when they don’t know their actual name and address.  This means that they can gather, analyze and react to data in ways similar to database marketers.  But without personal identifiers, online marketers cannot integrate this data into the individual profiles that are the heart of a conventional marketing database.

One result has been a surprising separation between online and database marketers.  Even though both rely heavily on technology and apply disciplined analytical approaches, each has developed its own universe of service and software vendors.  Database marketers rely on marketing services agencies and marketing automation systems whose core competency is building and managing customer databases.  Online marketers rely on search marketing, Web analytics and Web site development vendors who are skilled at attracting traffic and tailoring Web treatments to visitor behaviors.

Email and ecommerce are exceptions: online activities dominated by database marketing vendors and techniques.  But they merely prove the rule, since both face situations where personal identities are known and it’s possible to build a conventional marketing database.

Another result has been continued fragmentation among online marketing subspecialties.  Search engine optimization, paid search marketing, site personalization, Web display ads, mobile marketing, downloadable applications and social media are usually managed separately, even though they rely in part on traffic statistics from same Web analytics systems.

Some fragmentation is inevitable.  New varieties of online marketing appear so quickly that marketers must rely on internal or external specialists for quick deployment.  But this fragmentation, as well as the separation from conventional database marketing, imposes extra costs and prevents consistent treatments for individual customers.

Of course, if it were easy to integrate online with offline data, the database marketers would have been doing it all along.  Social media can help by providing an additional source of personal identifiers that can link individuals across sources.  But what’s really needed is a change in attitude: one that recognizes it’s worth centralizing information even when it cannot be tied to a specific individual.

This is a radical switch for database marketers who have spent their careers looking for better ways to identify individuals.  But they (and the rest of us) need to adjust to a concept of “semi-anonymous” marketing, which means being able to reach individuals who share certain characteristics even if you don’t know who they are.

To bring home the importance of this concept, let’s look at the types of information available in online marketing channels.

- cookies are the primary means of tagging individuals who visit a Web site.  By itself, a cookie only identifies a computer, but it can be linked to additional information that’s either observed (e.g. pages visited) or provided by the visitor (e.g. registration).  This data can be stored within the cookie or, preferably, in a database linked to the cookie ID.  This means you can use a cookie to, say, show an ad with a discount coupon to someone who previously discarded a shopping cart, even if you don’t know who that person is.  In other words, even anonymous cookies let you put people into identifiable marketing segments and send them appropriate messages.

- IP address (showing where a user has connected to the Internet) and other information provided with each Web visit (browser type, operating system, etc.) can sometimes act as a proxy identifier for individuals, since many systems keep their IP address over time.  However, this is controversial in privacy circles and not wholly reliable.  Yet even discarding this approach, IP address can often be traced to a corporate account owner (this works for business computers, not for home computers which typically connect through an IP address registered to a phone company or other Internet service provider).  And nearly all IP addresses can be mapped to a geographic location, which in turn can be linked to geo-demographic databases such as Nielsen PRIZM clusters.  Again, this information can be used to target messages to unidentified individuals.

- mobile phone location is known to the phone network operator, although how much they share with marketers depends on privacy and commercial considerations.  It’s certainly possible to target messages to people within a certain geographic area, either in network-based advertising or through user-downloaded apps.  More advanced but still semi-anonymous applications, such as targeting based on whether someone is outside of their usual territory, are possible but demand more data retention.

- social media support many kinds of marketing, including advertising based on member profiles and groups, direct messages where a prior relationship exists, monitoring public activities by usernames, and linking usernames to email and other personal identity information.  The opportunities depend on the particular medium and the operator’s terms of service, but the general point is it’s worth building a history that may later become useful even if you can’t market to it directly today.

As marketers centralize their online information, technical demands will increase.  Marketing databases not only become much larger, but they will hold more kinds of information, much of it less structured than the traditional customer and transaction records.  There will be increased opportunities to use sophisticated matching techniques to associate specific individuals with semi-anonymous information, although this can raise privacy concerns.

But even if an addressable individual is never identified, marketers will gain by integrating information across channels at the level of the semi-anonymous segments themselves.  This will allow them to identify similarities in interests and behaviors, which in turn will lead to coordinated messages and clearer understanding of results.   The ultimate impact will be to help unify the marketing departments themselves, ending the fragmentation that detracts from business performance.

*                            *                           *

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.

Over the past two decades, marketers have driven towards one clear goal: learn more about your customers so you can present the right offer to the right person at the right time.  Companies have gathered data from more sources, analyzed it in more detail, and built more elaborate campaigns tailored to more precisely defined segments.  But the fundamental premise has remained the same: marketers initiate the campaigns and hope that customers react.

That model no longer applies.

Today, customers are taking control of the relationship.  They block inbound marketing messages and instead reach out for information when they want it.  And when they do seek information, they’re more likely to trust external sources, including social media such as Facebook, YouTube, Twitter and blogs, than the company itself.

As if that weren’t challenge enough, marketers must also adjust to changes in the communication channels.  Mobile devices literally add a new dimension (location) to customer interactions – if marketers can figure out how to take advantage.  Online channels offer a tantalizing glimpse of endlessly detailed consumer data – if marketers can penetrate technical and legal barriers to identifying who is doing what.

No one is more aware of these changes than the marketing automation vendors.  But companies like Unica, SAS , Teradata, Aprimo and Oracle/Siebel originally engineered their systems for traditional outbound marketing.  All have added some support for real time interaction management, but their recent enhancements have largely been aimed at improving the efficiency of outbound campaigns.  Common improvements have focused on campaign optimization, marketing resource management, performance measurement, improved interfaces, and closer integration among separately-developed components.

Smaller and newer vendors, particularly those serving online and business-to-business marketers, have been somewhat more nimble.  Yet no vendor can move too far until marketers know which features they need.  The best practices in this new marketing world have not yet emerged.

But even though the application details are still vague, we can already outline the foundations needed to support them.  From an IT perspective, this is enough to begin work on the capabilities that marketing will tell you tomorrow they needed yesterday.

- data.  Marketers will want much more information.  Traditional marketing databases hold basic profile information (address, demographics, etc.), transaction history (purchases and possibly other interactions such as payments and service requests), and promotions sent.  These might be supplemented with derived information such as model scores and segment codes.  Future marketers will want to a consolidated timeline of every Web page view, every social media comment, and every location the customer has visited.  They’ll also import more external data, such as competitive advertising that customers were exposed to, relationships within social networks, and behaviors of similar individuals who are tracked in research panels.  This implies storing huge volumes of data – the Web details alone could be an order of magnitude larger than today’s typical marketing systems.  The systems will also need to recognize the same person across different channels and to update and access information during real time interactions.  Real-time and near-real-time updates alone require fundamental changes in how marketing databases are designed and managed.

- analytics.  Much data is more useful when it’s been summarized and classified.  For example, the business rules that will help to drive many interactions require records to be clustered into manageable numbers of categories: otherwise, the rules themselves get too complex to manage.  Pre-processing will also be essential for quick response.  The analytics themselves must execute more efficiently, so that scores and segment codes can be updated as soon as new data becomes available, models are revised as behaviors shift and the environment changes, and optimal allocations are recalculated in response to new conditions.  Greater use of analytics also means that analytical processing must become more automated, with human experts shifting from hands-on model building to deeper innovation and monitoring the quality of the automated systems’ output.

- execution.  Speed will dominate the requirements for marketing execution.  Insights from analytical systems must be immediately translated into marketing decisions and then transmitted to operational systems that are managing the actual interactions.  Even outbound campaigns will be triggered by customer activities rather than marketer-determined schedules.  The systems will also need continuous automated processes to test alternative treatments, deploy the winners and monitor the long-term results.  Major new marketing programs will still be designed by humans, but they will need tools that make it vastly easier than today to build, deploy and measure complex treatment strategies.  Ultimately, marketers will manage a self-optimizing environment that looks beyond individual interactions to allocate corporate resources across all customer-facing investments.  For example, the system might decide each morning whether it should schedule more customer service agents for the afternoon shift or invest the money in another round of keyword advertisements – taking into account both long-term return on investment and real-world constraints such as cash flow, profits and quarterly revenue targets.

Such intense dependence on technology poses many dangers and requires substantial organizational change.  But companies that overcome these barriers will flourish in the new marketing environment – and gain a substantial edge over companies that do not.

*                            *                           *

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.

Business intelligence software has evolved to fit an environment dominated by relational databases. This mostly meant overcoming the inherent inefficiencies of executing analytical queries against normalized data models, typically by reorganizing the data into star schemas, cubes, indexes or other specialized structures. Sometimes the restructured data itself resides in a relational database and sometimes it doesn’t.

Because so many enterprises have invested heavily in these business intelligence applications, new database products must be compatible with them. But products built specifically for analytical use (ParAccel, Vertica, Netezza, Sybase IQ, etc.) often don’t face the constraints that the BI applications were designed to overcome. Attaching one of those engines to standard BI software is like towing a farm wage with a dump truck: you get better performance but are not taking full advantage of the technology.

So let’s do a little thought experiment and imagine a BI system designed with analytical databases in mind. Probably the most important feature of these databases is that they are relatively insensitive to data structure. (Caveat: each product is different; some are more sensitive to structure than others.) In many cases this means the system can efficiently execute queries against data in its original table structure, without the denormalization, indexing and aggregation used by conventional BI tools. This offers tremendous savings in time and effort, since much of the work in conventional BI systems is designing and populating these alternative structures. What’s worse, at least from an end-user viewpoint, this restructuring must be done by technical specialists. This means that any project must go through a time-consuming cycle of specification, development, review and modification as users struggle to understand their needs and the technicians struggle to understand the users.

But just because the analytical systems can query complex data structures, it doesn’t follow that end-users can understand those structures. Only a sadist would copy hundreds of database tables from an enterprise system and ask an end-user to query them directly. To take advantage of the analytical databases, a BI system needs a metadata layer to present the underlying tables in a way that makes sense to non-specialists. Indeed, one of the best reasons to retain existing BI software is that at least some of the products already contain extensive facilities to decouple the underlying physical data structure from the structures that are presented to users. To the extent that existing BI systems are not dependent on particular physical structures, they can provide excellent models for features that make end-users more productive.

One area where existing BI systems won’t provide much help is allowing end-users to connect to new data sources. In the current systems, this is a task for technicians, so the interfaces are designed with technical users in mind. But a major advantage of the new databases is how easily they can integrate new data with existing tables. A BI system designed to take advantage of this would allow end-users to do it for themselves. This implies easy features to physically load the data, explore it, define relationships between tables, and set rules for how key values are matched.

Data exploration is a particularly important opportunity, because the analytical databases let end users examine the new inputs immediately. This means users can quickly judge the data in each field, uncovering good and bad surprises that might otherwise remain hidden until weeks of technical effort had been invested in deploying them. A BI interface has to support this by providing appropriate data profiling and analysis tools. It must also support the next step, relationship definition, by making it simple to define trial matches between different tables and see how closely they correspond.

Value matching is particularly important as systems incorporate increasingly heterogeneous data sources. Exact matches between two columns are easy, but something as simple as a customer number stored as a numeric field in one system and a text field in another can cause trouble with conventional databases. Alternative date formats are another trivial difference that can still be difficult to overcome. Fuzzy matches, such as variant forms of names and addresses, are much more challenging but very important as users incorporate a wider range of inputs. In the conventional BI world, removing these discrepancies was another task handled by the technical experts as they set up the database. If the technical experts themselves are removed from the process, this matching must be handled automatically by the database or the BI system, or end-users must have tools to manage it for themselves.

Let’s add one more requirement. Although some analytical databases allow only a single logical data structure for each physical set of tables, most resemble SQL in letting users define table relationships within each query. Databases that allow this flexibility need interfaces that make it available to end-users, either when they are formulating queries or when they are setting up the presentation layer.

All of these features support the fundamental goal of letting end-users ask unanticipated questions without needing a technician to build a new cube, reorganize the data tables, or expose details that were lost in a previous aggregation. Today’s analytical databases make this possible, but new business intelligence systems are needed for them to deliver.

Next month’s column will look at some existing BI systems that offer these capabilities today.

******************************

Last month’s column described how business intelligence software could be adapted to take full advantage of today’s analytical databases. The premise was that current BI systems are designed to overcome weaknesses that applied to conventional relational databases but not the newer analytical engines.

It wasn’t very hard to come up with the list of features for these next-generation BI systems because they already exist. The pioneers are vendors like QlikTech, illuminate Solutions, ADVIZOR Solutions, Tableau Software, TIBCO Spotfire, Lyzasoft, smartFocus and Alterian who did not originally constrain themselves to be compatible with SQL. Instead, they developed interfaces that let them take advantage of their proprietary database engines in ways that SQL wouldn’t allow. Some of these vendors provide APIs to let external systems access their data, and some of these do support SQL queries. But SQL front-ends cannot take full advantage of their database features.

The main advantage these systems have over conventional BI software is the power they provide to business users. Adding a new source or building a new report doesn’t require a technician to modify the data structure or generate a new cube. Most of these products also provide at least some data preparation capability through a scripting language or process flow. This won’t replace the integration needed to build an enterprise data warehouse but it lets users outside of IT create applications that go well beyond simple reporting. Some technical skill is needed, but it’s on par with an Excel power user, not a database architect.

Of the systems listed above, only QlikView – with more than 11,000 installations and over $120 million revenue in 2008 – can really be considered a major force in the industry. The other products have much smaller bases, even though several have been around for more than a decade. This raises an obvious question: if the systems are really so great, then why haven’t they been more widely adopted?

One constraint is scalability. Many of these products originally ran on 32 bit architectures that limited the in-memory systems to two gigabytes of data and the disk-based systems to 2 billion rows. Load speeds were also originally measured in tens of gigabytes per hour. Those specs are more than adequate for many purposes, and probably larger than the data cubes underlying many conventional BI systems. Moreover, many of these constraints are now removed by 64 bit architectures and parallel processing. But handling the hundreds of terabytes in even a small enterprise data warehouse is still an issue. So, at best, these systems must coexist with a conventional database rather than simply replacing it.

The more important reason is probably IT department resistance. IT departments are generally conservative when it comes to unfamiliar vendors. But, beyond that, these vendors’ decision not to match SQL standards makes their databases seem dangerously isolated from the rest of the corporate infrastructure. Any data loaded into the systems can only be accessed via the vendors’ own tools or APIs, which raises a red flag for IT departments wary of reliance on a single product. In addition, the unique technology of these tools means that special training is needed to use them – an investment that IT departments seek to avoid. The small installed base of these products also means that IT can’t plan to hire experienced staff that someone else has trained already.

Of course, IT departments do sometimes embrace new technologies, particularly when they appear to solve a pressing problem for the IT department. But remember that the main advantage of these tools is that they empower business users to do more for themselves. In theory this would be an advantage to IT departments, because it would reduce their workload or let them shift resources to other tasks. But in practice, if an IT department has already invested in conventional databases and BI applications, these systems offer few new capabilities. Asked to examine the new systems, IT people often honestly shrug, “I can already do that”. Giving similar capabilities to other people doesn’t strike them as particularly important. And, no one likes to make their existing skills obsolete.

As a result, adoption of these new tools has largely been restricted to situations where IT isn’t involved or IT itself lacks an incumbent alternative. For the lower cost systems, this often means they are purchased by business departments for their own use, outside the IT budget and with minimal IT support. Another sweet spot is small to mid-size companies with few IT resources and little existing business intelligence infrastructure. On the relatively rare occasions when a large IT shop purchases one of these tools directly, it is usually because its technology solves a particular problem that has proven impermeable to conventional methods.

The SQL-compatible analytical databases avoid most of these obstacles because they mesh more easily with existing infrastructure. But, precisely because they continue to rely on conventional, IT-centric BI applications, these systems offer fewer benefits to business users than the more radical alternatives. The vendors selling these systems and the business people eager to use them share the challenge of convincing IT departments and senior management to approve them. Next month’s column will discuss approaches to help make this happen.

******************************

The story so far: analytical databases and new business intelligence interfaces deliver radical improvements in BI price, performance and ease of use. But IT departments often fail to appreciate the benefits of systems that reduce the need for skilled technical support. Far-sighted business and technology managers need ways to present the advantages of these systems more effectively.

Before going further, it’s important to be clear that IT departments are not a villain in this tale. They have sound reasons to be cautious in accepting any new technology, since they will be held responsible if it fails. Systems that promise to give more control to end-users are legitimately worrisome because end-users will make mistakes that IT professionals would avoid and may undertake projects they do not realize are beyond their true competence. IT managers worry, often correctly, that they will still be blamed for any problems that result.

Of course, IT departments make mistakes too, including some that end-users would not. This is why the groups must work together. The goal is finding the right balance of tasks for the two groups. New technologies call for an adjustment of this balance. That is precisely the challenge posed by the new analytical systems.

Enough philosophizing. Companies don’t assess technologies in terms of the proper balance between end-users and IT. Most have a much simpler approach that boils down to assessing benefits vs. costs.

In the case of business intelligence systems, the benefits are often somewhat vague – things like “better decisions” – and particularly difficult to quantify in advance. When the question is one BI technology vs. another, companies can easily assume that the outputs, and therefore the benefits, will be the same regardless of which technology is chosen. Even though they may recognize this is not completely true, it’s a helpful simplifying assumption because it lets them focus solely on comparing the costs of the competing solutions.

One approach to promoting the new analytical systems, therefore, is showing that they have a substantially lower total cost of ownership (TCO).

As with any TCO calculation, the trick is in knowing which elements to include. The main benefit of TCO is that it helps buyers look beyond the out-of-pocket investment – typically the license fee in the case of software – to include the cost of services and on-going support. But this definition itself is still too narrow, because it doesn’t capture the time end-users spend working with the system. One of the main benefits of the new analytical technologies is giving end-users a greater ability to do things for themselves. Although this might seem to increase the amount of time they spend, in practice it eliminates the effort devoted to explaining their needs to technical specialists, reviewing what those specialists produce, and then often revising the requirements based on the results. The result may well be a net decrease in the time that business people spend to complete a given project.

There is also an intangible, but quite real, benefit from letting business people work directly with the data. Doing this provides an opportunity to gain insights that they miss if they only review the results of someone else’s labor. Even though the value may be hard to calculate, it’s intuitively clear that an hour spent analyzing data is a more valuable use of a business analysts’ time than an hour spent explaining his specifications to IT.

In fact, it’s possible to argue that a business analyst generates value only while doing analysis and generates cost while doing anything else. By this logic, a system that lets analysts spend more time on analysis and less on meetings simultaneously increases value and reduces cost. However, that’s a rather extreme position related to the analytical systems because much of the new “analysis” time is really spent doing system development. Still, most analysts would probably feel working through development issues is still more productive, in terms of learning new information, than writing up specs and explaining them.

Finally, although it should be obvious that shifting work from IT to business users will reduce IT costs, a conventional TCO analysis may not show this. It’s quite easy, and in many ways only fair, to prepare an “apples to apples” comparison that assumes IT will continue to provide the services it does today. But an experienced BI specialist can often perform a given task almost as quickly with the existing systems as with the new ones. Comparing those two times ignores the fact that with the new system the task would be performed by a business user instead.

In short, to properly capture the benefits of the new analytical systems, traditional TCO analysis must be extended to include the costs of end-user time and to capture the shift in labor to end-users from IT.

Conventional TCO analyses also ignore the cost of waiting for an answer. In cases like inventory and price optimization, the company can calculate the precise penalty for every second of delay. Most BI applications are less time-sensitive, but there is still a real difference between getting an answer today and getting that same answer one month from now. Next month’s column will look at ways to factor this time element into the system evaluation.

******************************

Last month’s column described how total cost of ownership (TCO) analyses must be expanded to properly capture the savings of new analytical technologies. It’s tempting to measure cost alone because quantifying the value from competing BI solutions is so difficult. But value is too important to ignore completely. Even if you can’t measure it directly, it’s worth finding an indirect approach.

One method is to consider time: even if we don’t know what an answer is worth, we are pretty certain its value is higher if we get it sooner. Phrases like “time to answer” or “time to insight” to clarify that they represent an end-to-end measure rather than individual components such as response time.

This is important for the new technologies because many of their advantages come from eliminating non-computer tasks such as design time or meetings. These are not captured in traditional benchmarks or processing specifications. Traditional analyses also often ignore the time spent waiting for technical staff to deliver a solution or the delays from several rounds of rework as users react to initial results. A good “time to result” analysis might provide two broad measures:

- time to first query. This measures elapsed time from the decision to use a technology to when the system can process its first query. It include contract negotiation, hardware acquisition, software installation, database design, data loading and indexing, front-end tool integration, and training for both technical and business staff. Although it may seem odd to include something as non-technical as contract talks, bear in mind that some cloud-based solutions can literally reduce these from months to minutes. That is a difference worth capturing.

- time to answer. This measures the time to complete an actual BI project, including problem specification, data preparation, result analysis, and subsequent rounds of revisions.

Both of these analyses would include conventional measures of labor hours and machine processing time. But they also incorporate the waiting times – for hardware, training, meetings, approvals, and fitting tasks into a busy schedule – that are often ignored but determine when a project is really completed.

Like any benchmark, each “time to result” analysis must be tailored to a company’s specific situation. Analysts will need to define scenarios with the particular data sources, staff skills, and questions involved. One practical way to develop these scenarios is to build a narrative based on previous projects, starting with the original specifications and tracking how these evolved. This narrative can then be converted into specific tasks, such as adding new sources, refreshing existing data, redesigning queries, and creating new reports. Wait times in particular are difficult to assess, because they depend on the priority assigned to any one project. But records of past service levels should provide an estimate of what can be expected on average.

The “time to result” analysis must also distinguish set-up tasks from repetitions. Hardware for a new system is only ordered once, while data will probably be refreshed at regular intervals. The theoretical ideal would be to simulate a year’s worth of projects, taking into account the frequency of different tasks as well as the time for each task. In practice, few companies are likely to be so thorough. But they should still keep these distinctions at least informally in mind.

Set-up tasks also highlight the difficulty of comparing incumbent technologies with new solutions. The first project with a new technology will incur training costs and delays, while doing the project with an existing technology will not. This is a real difference, so it’s wrong to simply ignore the benefits of using existing resources. But it’s also only a one-time cost, which can legitimately be amortized over several years of projects. Again, this requires envisioning a project portfolio of some sort so you can estimate how many projects to include.

Note that set-up costs can sometimes work in favor of a new technology. If the company has steadily expanding or rapidly fluctuating needs, then a technology that makes it easy to add new capacity or train new users will eventually be more economical than an existing technology that is harder to expand. Cloud-based systems, with their low set-up costs and brief waiting periods, are the extreme example of how set-up costs can provide an advantage over the incumbent.

Of the two measures proposed above, “time to first query” applies more to database engines and “time to answer” applies more to BI applications. Even though the new analytical database engines are broadly similar in using columnar data structures on “shared nothing” parallel hardware, there are still substantial differences in how they deal with database design, compression, indexing, incremental updates, new data sources and other tasks. These can impact both the processing and waiting components of “time to first query”. The impact of these differences also varies greatly depending on the volumes and complexity of the data being processed.

“Time to answer” is generally more sensitive to the amount of work that end-users can perform for themselves. This depends primarily on the interface built into the BI application. Today, the most user-empowering interfaces are attached to the non-SQL analytical databases like QlikView, iLuminate, and ADVIZOR. But as BI systems take advantage of the flexibility provided by the SQL-based analytical engines, time to answer will be an increasingly important measure for those databases as well.

Summary

This series started with a simple question: what would business intelligence applications look like if they weren’t designed around the constraints of conventional relational databases? We’ve seen that the systems would be much easier and cheaper to operate and that they would make end-users more productive because they could do much more for themselves. We also described some existing systems that match this description and looked at some of the obstacles faced by advocates trying to get them adopted. Finally, we suggested how two evaluation methods – expanded Total Cost of Ownership and new “time to result” measures – can highlight the new systems’ advantages.

That’s a lot of ground to cover, but consider the topic: reinvention of business intelligence as we know it. Companies must make many changes to adapt to the new technologies but the results – a huge improvement in the value delivered by business intelligence systems and a huge reduction in cost – is well worth the effort.

*      *      *

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.

Back in February, this column asked “Does On-Demand Business Intelligence Make Sense?” and answered a tentative “Yes”.    The gist of the argument was that the major obstacle to BI success is the skilled labor needed to build the systems, and on-demand vendors can reduce this through strategies including automation, end-user-driven interfaces, advanced database engines, and pre-built solutions to specialized problems.

True as this may be, it is coming at the issue backwards.  On-demand BI should not be a solution in search of a problem.  The real goal is to identify situations where on-demand BI is a better choice than conventional solutions.  In other words, the right question is not whether on-demand BI makes sense, but when.

The general answer is that on-demand BI is the right choice when it meets two conditions.  First, it must solve problems that conventional solutions cannot.  Second, it must not face insurmountable new problems created by the on-demand model itself.

Regarding the first condition, we’ve already identified the required amount of skilled labor as the major problem faced by conventional BI solutions.  But labor isn’t the only potential roadblock.  A project might cost more than it’s worth, take longer than the time available, or require more hardware than the company can immediately deploy.  On-demand solutions generally offer advantages in these areas, so projects that face these issues are good candidates for an on-demand approach.

The second condition addresses on-demand weaknesses.  Common objections to on-demand systems include: the perceived security risk of moving data off-premise; difficulties if close integration is required with other company systems; the cost of outages if the on-demand system goes down or you can’t connect to it; the risk of becoming dependent on a system you don’t control; and the impossibility of enhancing or customizing the application if it doesn’t meet your present or future needs.

This is where picking the right application and the right on-demand vendor become more important.  Let’s start with security.  Most on-demand vendors meet high security standards because their customers demand it.  Still, particular applications or data sets may require even tighter security than a particular vendor can provide.  This might limit your choice of on-demand vendors to those who can prove they meet that standard, force you to load only less-sensitive data, or prevent you from using any on-demand system at all.

Similar considerations apply to the other issues.  Tight integration between an on-demand system and other systems is much easier than it used to be, because some on-demand vendors have provided APIs or otherwise engineered their systems to permit it.  But the details vary from vendor to vendor.  On-demand BI systems in particular are generally not built with real-time external integration in mind.  Nor, for that matter, do most BI applications require it.  You have to look carefully at what you need and what the systems you’re considering can do.

The cost of outages also relates primarily to applications that are closely coupled to other company systems.  For example, a BI system that made real-time credit decisions about new orders could cause major problems if it were unavailable even for a few minutes.  But most BI systems are used for statistical analysis rather than operational transactions.  Although you might be able to find an on-demand BI vendor who could guarantee to meet stringent availability standards, an application that required extreme reliability would probably be a poor choice for on-demand.

Vendor dependency is an issue with any externally-owned system, not just on-demand.  For that matter, reliance on internally-built systems also raises dependence issues.  But on-demand does compound the usual risks of vendor lock-in (unreasonable price increases, unresponsive service, deterioration in quality) with concerns that the system could become unavailable if the company went out of business or its system crashed.  Again, most BI applications are not mission-critical in the short term, so the worst-case scenario – permanent loss of access – is usually an acceptable risk.  Where continued access is truly essential, you may be able to negotiate appropriate back-up arrangements as part of the on-demand agreement.

The final issue is inability to enhance or customize the system.  Unlike the previous concerns, this applies to BI applications in particular.  While requirements for operational applications are usually well known and fairly stable, BI requirements are often poorly understood until users can load and analyze their data.  In addition, the requirements change frequently as new projects and questions arise.   This means that a BI system selected with a particular task in mind may not meet future needs.  The solution lies primarily in the vendor choice, and in particular in matching the vendor’s approach (automation, simple interface, flexible database, predefined solutions) to your situation.  For example, if you expect to work with many large files, a BI solution built around a flexible, scalable database is most likely to accommodate future needs even if you can’t define them precisely.  But if your major constraint is a lack of skilled staff, a highly automated system may be your best bet.

In the end, on-demand systems cannot solve every BI problem.  Some BI projects are best built in-house with conventional technology, and others should be outsourced completely.  You must assess the requirements for each project and match it against the alternatives to select the most suitable approach for every case.

*                            *                           *

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.

Marketing systems were early adopters of analytical database engines.  This was purely from necessity: list segmentation and analysis were the core application of most marketing systems, and standard relational databases require much tuning and considerable hardware to handle them effectively.  Since marketers rarely had the technology budget to pay for this, they were forced to seek the lower-cost alternatives provided by specialized databases, typically using columnar structures.  Corporate IT departments were rarely enthusiastic about these non-standard systems, but, since marketing was usually a low priority, IT found it easier to let the marketers buy what they wanted and take responsibility for the consequences than to step in and do the work themselves.  No one was quite happy, but an uneasy truce prevailed and everyone got their work done.

Today, specialized analytical databases are a hot fashion in corporate IT.  These include not just columnar structures but also in-memory and shared-nothing parallel processing systems.
So you’d think that marketing systems using of those databases would be the center of attention.

Not necessarily.  It’s true that big marketing systems with big analytical databases are more common than ever, and that IT is more comfortable with them.  But the classic list segmentation and selection functions are less important because today’s marketing is increasingly focused on managing real-time interactions with individuals.  Those interactions largely require conventional transaction processing technology.  As a result, the analytical databases are receding to the role of supporting systems that prepare and stage data for front-line interactions.  The really interesting business and technical challenges are making the front-line systems work better.

The implications of this run deep.  For marketers, it means the traditional divide between marketing and sales is now much less distinct.  Customers and prospects all interact with the same company systems (Web sites, call centers, email, etc.) and external social networks.  To ensure that each visitor is handled correctly, marketing (responsible for prospects) and sales (responsible for customers) must jointly define the business rules and treatments.  This is much more cooperation than those groups are used to.

The change also calls into question the fundamental architecture that has kept marketing databases separate from sales and customer service systems.  Even though Customer Relationship Management (CRM) vendors have long claimed to integrate all three, a look under the hood has usually found that sales and service ran on a transaction-oriented database while marketing ran on a separate, analytical database.  This was partly due to the technical requirements of marketing queries, which made the analytical data structure more effective.  But the separation between sales and marketing activities meant there was no particular penalty for running fundamentally independent systems.  Companies needed just a bit of data synchronization, which might be done in real time but could often run nightly without causing serious problems.

The equation changes drastically when marketing and sales do need to integrate.  Now the advantages of a separate, analytically-structured marketing database must be weighed against the significant impediments to sales and marketing coordination that database creates.  This gives companies more reason to consider alternatives.

The simplest approach is to just get rid of the separate analytical database altogether.  This is increasingly viable because today’s relational databases and hardware can more easily support transactional and analytical processing.  The very largest marketing databases will probably still run on separate analytical systems, but companies with smaller files will increasingly be able to get adequate performance for marketing applications from their transactional databases.  Even if this requires a bit of tweaking to add some extra indexes or summary tables, the overhead will usually cost less than maintaining a truly separate marketing database.

Another option is to keep the analytical database but shrink its role.  Under this scenario, the analytical database is truly used for analytics – that is, research and reporting – while the quasi-operational tasks such as list selection migrate to the transactional system.  This is arguably a more logical structure anyway: since some of the tasks were assigned to the analytical database because it was the only system the marketers had available, not because they required an analytical structure.  For example, many analytical systems work best with batch updates, but have been forced to take real-time updates so that marketers can work with current data.

The fundamental point to remember is that whatever happens to the analytical database, marketing will do an increasing portion of its work on the transactional systems.  That’s the inevitable result of managing individual interactions at touchpoints such as the Web site.  In theory, marketing systems could evolve to include their own transactional components.  But that makes little sense when most companies already have these in the sales and service components of their CRM systems.  It’s more likely that the long-standing promises of CRM systems to encompass marketing will finally be fulfilled, and separate marketing systems, like separate analytical databases, will play a smaller, more specialized role.

*                            *                           *

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.

Social media in all its forms—blogs, social networks, forums, file sharing, Wikis, and the rest—continues to evolve at a head spinning pace. But for marketers and IT departments, it has already moved past “my cat is cute” to become a can’t-ignore business tool.

Yet “can’t ignore” isn’t the same as “can manage”.  There are literally thousands of software applications to help you monitor and interact with social media.   Picking your tools is a major project in itself.

To bring some order to this process, first step back and define your objectives.  Common social media applications include:

- gathering market intelligence about attitudes towards your company and competitors
- executing campaigns for outbound marketing, publicity and community development
- identifying potential customers based on their published comments
- connecting with people through common acquaintances and recommendations
- tracking behaviors and attitudes of sales prospects and customers
- measuring campaign results (including, of course, the results of social media campaigns)
- providing support and responding to complaints in public or private

Many of these applications share some requirements, although the mix is different for each.  Here is a brief list of primary requirements by application:

- gather market intelligence: keyword alerts to identify references to the company or product; sentiment measurement to understand the nature of the references; external site traffic and link measurement to measure influence; trend reporting and analysis

- execute campaigns: content creation and posting; external traffic and link measurement; search engine optimization and paid advertising to build traffic to your own sites; platforms to build and manage your own communities

- identify potential customers: keyword alerts, social network research to profile  individuals

- connect with people: personal network and reputation development; social network research

- track behaviors: social network research, Web site visits and behaviors; behavior-based alerts

- measure results: traditional Web analytics (traffic sources and volumes); keyword alerts; sentiment measurement; search volume and destinations; link tracking; content rating on sites like Technorati and Digg; track use of company-generated content

- support and complaints: keyword alerts, sentiment measurement, social network research, external traffic and link measurement

There are dozens and sometimes hundreds of tools to address each requirement.  Social media themselves are a great place to identify the candidates, since expert bloggers often post information on products within a given specialty, and community members are usually eager to share their own experience.  Many of these people can also be hired as consultants—something that can be well worth the investment.

But before you jump into the details of individual products, you’ll want to define a strategy.  Almost every company today has several social media applications on its agenda, so you’ll want to inventory the projects to see which requirements are shared.  Ideally you’ll then select a company standard tool for each requirement.  The reason is less to save on software costs than to avoid supporting more than one platform.  Even if each department runs the tool independently, a shared standard will let them compare notes and help each other out.

Your strategy should also consider the need to integrate the different products, in reports if not actual operation.  Most Web-oriented systems are designed to be open, which in practical terms translates to Application Program Interfaces (APIs) that allow external access to their data and functions.  But the scope and efficiency of those APIs varies widely because vendors must balance openness against external demands on shared servers and the never-quite-dead goal of customer lock-in.  So there’s no avoiding the need to define the required points of integration and to assess carefully whether proposed systems can support them.

Another part of your strategy must estimate the value expected from each application and from meeting individual requirements.  This allows you to add the different supporting systems in the sequence that makes the most sense from both business and technical perspectives.  These choices are essential in the current economy, where every penny and every moment must be spent as productively as possible.

Your strategy must also set standards for vendor stability.  This is especially challenging for social media tools, which are often cobbled together by tiny start-ups.  The good news is that switching to a new system is often inexpensive, even counting the cost of staff time and business interruption.  So unless a particular function is truly mission critical, you can usually take a chance on a great product from a shaky vendor.  In reality, most of your initial social media projects are experimental, so learning quickly and cheaply is more important than finding a system you’ll be able to keep for years.  Much of what you learn is about the underlying technologies and business applications, so that knowledge will retain its value even if you change tools..

Indeed, the most important part of your social media technology strategy has to do with people, not tools.  It’s a truism, but you really do need to train your staff to understand the business objectives of the various projects, and the functions, data and processes needed to support those objectives.  These basic principles will change much less rapidly than the technology itself, and a well-trained staff working in a sound framework will easily adjust to whatever the social media geniuses come up with next.

*                            *                           *

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.

]]> http://archive.raabassociatesinc.com/2009/04/tools-to-support-social-media-marketing/feed/ 0 http://archive.raabassociatesinc.com/2009/02/internet-data-for-marketing-measurement/ http://archive.raabassociatesinc.com/2009/02/internet-data-for-marketing-measurement/#comments Sun, 01 Feb 2009 00:30:44 +0000 http://archive.raabassociatesinc.com/?p=358 Internet Data for Marketing Measurement
David M. Raab
DM Review
February 2009

Marketers know what they spend and their companies know what gets sold. The challenge of marketing measurement is connecting the two. Which customers were touched by which marketing programs? How did those programs affect behavior? What non-marketing factors contributed to the final result? This data has often been missing.

Today, the Internet can fill in many of these gaps. Marketers can directly measure the Web traffic generated by online and offline campaigns. They can count search queries and blog mentions to see what’s on consumers’ minds. They can capture attitudes based on message contents, measure engagement by willingness to download content, and identify influential voices based on their audience. More prosaically, online surveys can assess consumer reactions to campaigns and make appropriate changes. In a growing number of cases, they can relate individuals’ Internet experience to their actual purchases, providing the final link in the chain between marketing efforts and sales results.

Taking advantage of this data poses new challenges. Here are some issues and solutions to consider.

- changing data sources. Two years ago, few people had heard of Twitter. Today, many companies are obligated to monitor it on a regular basis. The measurement challenge is not simply that new channels keep appearing, but that you may need to start tracking one literally overnight. Imagine, for example, that you are featured in the next popular YouTube video or a prominent social network discussion. Or, that marketing asks you track downloads of that new widget they released yesterday without telling you. Coping with these demands requires very flexible, Web-friendly data integration tools that can adapt to new sources with minimal effort. It also requires analytical databases and reporting tools that can incorporate the new data without major projects to redesign data models, reload old data, or rebuild standard queries and reports.

- high data volumes. Internet sources can generate massive data streams, particularly when individual data is involved. Your reporting system must be able to load and store large volumes, including sudden spikes to many times the size of base levels. You may also need automated tools to scan and summarize incoming data and to issue alerts about specified conditions. All this has to happen without degrading performance or losing downtime for database reorganizations.

- ambiguous data. A few Web sources are nicely structured: perhaps your marketing department takes well organized surveys. But most Web data is fundamentally anarchic, involving not simply free text, but free text that’s misspelled, unpunctuated, in several languages, and filled with ever-morphing abbreviations, slang and emoticons. indeed. Now add in audio, video, maps, graphics and other formats that not text-based at all. You’ll need powerful data quality tools that can identify unfamiliar elements and resolve them automatically when possible. You also need tools to interpret and classify the these contents so you can manage them without paying someone to read every word, listen to every podcast, or look at every picture.

- new attributes. New media contain new types of data such as social media rankings, connections within a network, paths through a Web site, links to a Web page, and numbers of subscribers to a blog. Your systems must capture and interpret this information, monitor changes over time, and build it into meaningful reports. This will require sophisticated data parsing, queries, trending, and calculations.

- identity resolution. Internet identities have less to do with name and mailing address than network nodes, cookie IDs, user names, biometrics, and self-identifying devices such as smart cards, cell phones, electronic license plates. Within legal and ethnical privacy limits, you’ll want to link these to gain a comprehensive picture of customer media consumption, behaviors and purchases. The sheer variety of potential identifiers will require radical changes to identity resolution techniques. Clever algorithms to find similarities in text strings will not longer suffice.

- mashups. The best way to make sense of Web data may be to view several sources in combination. Many Web products expose their data through APIs designed to make this possible. Your marketing reporting systems will need to take advantage of these capabilities. In some cases, one of the Web systems themselves may provide a platform to mash together several types of information.

- data exploration. To handle an endless stream of new and shifting data sources, your marketing measurement system must give users tools to explore each source and uncover significant relationships among them. This implies a heavy dose of ad hoc inquiry, data mining and visualization capabilities, all designed for relatively non-technical users: that is, marketing analysts, if not necessarily the senior marketing managers themselves. (As someone put it, the users drive a Honda, not the Lexus.)

- data distribution. Different Web data is relevant to different users. Customer support will be interested in complaints, sales will be interested in product questions, and product design will want to see feature requests. Even within marketing, your product managers, promotion managers, publicity managers, Web managers and others will want different items at different intervals and levels of detail. The marketing measurement system must make it easy for analysts to publish a useful piece of information, for users to share comments on the findings, and for users to subscribe to reports they find relevant.

These challenges won’t be all met by any one product. But every partial solution fills in a piece of the puzzle. Over time, marketers will gain an ever-clearer picture of how their efforts contribute to business results.

* * *

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.

Last month’s column discussed how to identify the system functions you need in a demand generation system.  But functions are only one piece of the puzzle, and many vendors argue that their real advantage actually lies elsewhere, in superior “ease of use”.  How do you measure that one?

This is a serious challenge.  Functionality is relatively straightforward: either a system has a particular capability or it doesn’t.  But “ease of use” is more subtle.  Formal, objective measurement is difficult and expensive, so most people end up relying on subjective assessments instead.  And even subjective assessments are hard to organize.

To make any sense at all of the topic, we need to take a couple steps back.  First, “ease of use” is one component of a larger and ultimately more important concept of “usability”.  This is defined in different terms but generally includes ease of use, ease of learning, and functionality.  Second, both ease of use and usability are highly contextual: they can only be measured for specific tasks for specific users in specific circumstances.  This makes perfect sense if you think about it for a moment: a system may be quite easy to use for one task, yet very difficult for another.  But it means that a single “usability score” makes much less sense than a single “functionality score” (not that functionality scores make much sense to begin with—the point of last month’s column was to measure only the functions that matter to you).

The good news is that accepting the contextual nature of usability is the first step towards a reasonable way to measure it.  Specifically, it hints that you should start by defining the contexts you need to consider.  Then you can actually assess usability within those contexts.

We’ve already listed three broad types of contexts: tasks, users and circumstances.

- The tasks you need to consider are essentially the same ones identified in the use cases that drive your functional requirements.  Usability analysis does add one new dimension to these: measuring the effort to do a task the first time compared with the effort to do it repetitively.  The difference is set-up effort, which applies to the first iteration only.  This turns out to be a significant differentiator among demand generation systems, since some are optimized for simple, one-off campaigns (not much set-up but little reuse) while others are best at creating many variations within a fixed theme.

- Users, of course, come in many varieties.  Some dimensions to consider are: experience with the system; frequency of system use; skill sets (marketing, analysts, technologists, etc.); and system access (end-users vs. administrators).  You will first identify the characteristics of your users, recognizing that you will probably have several sets of users who fall into different groups.  Then, determine which types of users will perform which tasks, bearing in mind that some tasks may be shared across different groups.    For example, administrators who are technically skilled and frequent users may set up program templates that are then completed by infrequent end-users who are primarily marketers.

- Circumstances vary as well: will your users be focused solely on the demand generation system or will they be in chaotic environment with many distractions?  Will they be under extreme time pressure or be able to plan ahead?  Is there some leeway for error or must everything be perfect the first time out, perhaps for regulatory reasons?  The answers bear on system attributes such as display style, alert functions, error checking capabilities, approval workflows, versioning, and security.  Again, different tasks will likely be performed in different circumstances.

Once you’re worked through these issues, your original task list will now be extended to include information on which types of users will perform each task, and in what kinds of circumstances.  This allows you to assess the usability of each task against the right criteria.

This still hasn’t answered the question of how to do the assessment itself.  In an ideal world, and sometimes in the real world when the stakes are high enough, you would install a test version of the software, train the appropriate users, and let them work with it.  But most evaluation projects don’t have the time or resources to make such an investment.  Yet even if you’re limited to what can be accomplished in a couple of vendor demonstration sessions, you can ensure that you are looking at usability in the right context.  Here are some specific suggestions:

- have the vendor demonstrate tasks that would be performed by expert users.  This assumes that the vendor’s demonstrator, either a salesperson or engineer, is herself likely to be an expert.  The demonstrator will surely make things look easy—but your own experts will eventually learn the same tricks, so that’s okay.

- have the vendor show you how to perform tasks that would performed by casual users.  That is, you should operate the system rather than watch.  If you are already an expert, it might be better to have a typical end-user at the controls instead.  The goal is to see how well someone unfamiliar with the system can work with it, at least for tasks likely to be done by such users.

- look for features relevant to the appropriate user groups.  Expert users can invest the time to learn system shortcuts, set up reusable templates, and make correct choices in unstructured environments.  Casual users rely more the intuitive choice being the right choice, expect more guidance and error-checking, and may prefer graphical interfaces.  Casual users may also need to rely on templates and other components produced by the experts.

- when different kinds of users will share the system, look for options to tailor the interface to individual needs.  These include capabilities to turn help messages off and on, to limit the capabilities offered to casual users, and to present predefined workflows.

Be sure to prepare a specific list of these items in advance of the demonstration itself, so you know exactly what to look for and have a place to record your observations.  The more structured your process, the more you’ll be able to cover and the more clear you’ll be on what you actually saw.

Finally, remember to look beyond the demonstration itself.  Reference clients are a particularly important source of insight.  Anybody the vendor recommends is almost certain to be happy (although slip-ups are more common than you might think), but you still need to assess whether the reference context (tasks, users and circumstances) is similar to your context.  If the vendor can’t connect you with someone similar, you’ll have to work harder to assess the product directly.  You can also look at other elements of the customer experience, such as training, support and user forums.  These have the advantage of being objectively measurable, but bear in mind that they often have more to do with the size and maturity of the vendor than the quality of the product itself.

*                            *                           *

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.

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.