Customer Experience Matrix

ParAccel Toots Its Horn and Revs Its Database Engine

2009-07-09T14:42:00.019-04:00

Summary: Over the past year, columnar analytical database vendor ParAccel has methodically proven its claims about speed, scalability and easy deployment. Now it's looking to grow fast.

When I first wrote about analytical database vendor ParAccel in a February 2008 post, it was one of several barely distinguishable vendors offering massively parallel, SQL-compatible columnar databases. Their main claim to fame was a record-setting performance on the TPC-H benchmark, but even the significance of that was unclear since few vendors bother with the TPC process.

Since then, ParAccel has delivered an impressive string of accomplishments, including deals with demanding customers (Merkle, PriceChopper, Autometrics, TRX) and an important alliance with EMC to create a “scalable analytic appliance”. To top it off, they recently announced their 2.0 release, a new TPC-H record, and $22 million Series C funding. (Full disclosure: they also hired me to write a white paper.)

Of all these, perhaps the most significant news is that the new TPC-H benchmark comes at the 30 terabyte level.* ParAccel’s previous TPC-H championships were at the 100 GB to 1 TB levels.

The change reflects a general growth in the scale of systems supported by MPP columnar databases. ParAccel reports its largest production installation holds 18 TB of compressed data, which probably translates to something more than 50 TB of input. Segment-leader Vertica reports several production installations larger than 100 TB. Neither had more than 10 TB in production a year ago.

These figures still don’t put the columnar systems in the same ballpark as the petabyte-scale database appliances like Netezza, Greenplum and Aster Data, but they do open up some major new possibilities. In case you’re wondering, ParAccel’s TPC-H results were seven times faster and had 16 times better price / performance than the previous record, held by Oracle.

But pure scalability isn’t the key selling point for ParAccel. More than anything, the company stresses its ability to handle complex queries without specialized data schemas or indexes. This means that existing data structures can be loaded as is and queried immediately. The net result is a much faster “time to answer” than competitive systems, which do tailor schemas and/or indexes to specific questions. It also means that new queries can be answered immediately, without waiting for schema modifications or new indexes.

The 2.0 release extends these advantages with a new query optimizer that handles very complex joins and correlated subqueries; parallel data loading (nearly 9 TB per hour in the TPC-H benchmark) and User Defined Functions; enhanced compression; and “blended scans” that avoid Storage Area Network (SAN) controller bottlenecks by loading SAN data onto compute nodes and querying them directly. It also adds some special features such as Oracle SQL support and column encryption for financial data. Another set of enhancements are designed to provide enterprise-class reliability, availability and manageability, such as back-up and failover. Several of these features are already in production, although the official 2.0 release date is August.

The new release and added funding mark a transition of ParAccel from quiet introduction to full-throated selling. Over the past year, the company has carefully limited its participation in Proof of Concept (POC) competitions, the key selection tool in this segment. This gave it time to refine its POC processes, add system features, and build initial client references. It says it can now complete a typical POC in three days, often leaving while other vendors are still getting started. The company is now ramping up its lead generation and inside sales operations, aiming to grow quickly beyond its dozen-plus existing installations. (To provide some context: Vertica reports more than 100 clients.) We'll see what comes next.

______________
* For some serious doubt-sowing about the new benchmarks, see Daniel Abadi's post (be sure to read the comments) and ParAccel's response. What really matters, as ParAccel points out, is performance in customer POCs. The company says its performance has never been beaten, although there was one tie. (For sheer entertainment, check out the related string on Curt Monash's blog.)

Lyzasoft White Paper Looks at Coordinating Business Analysts and IT

2009-07-09T13:43:00.005-04:00

Summary: a new white paper says business analysts gather data with little help from IT. I'm not so sure, but agree that collaboration tools like Lyza Commons can help both groups cooperate.

Analytical software vendor Lyzasoft has just published a white paper by data warehouse guru Dr. Barry Devlin on how business analysts and IT can work together. (Click to download Collaborative Analytics: Sharing and Harvesting Analytic Insights across the Business.) Since I’ve spent much time pondering this very issue, I was quite curious to see his perspective.

The paper describes a fundamental contrast between a “center out” model of data usage favored by IT (carefully and centrally controlled) and an “edge based” model favored by business analysts, who act as independent data “hunter-gatherers” to combine and use data in ways that the central resources are not designed to support. Devlin's term for this is “emergent prototyping”, a trial-and-error process of reworking an analysis until it produces something useful.

He also suggests that analysts work first by themselves, and then, if they find something interesting, share it with other analysts. Only later, when something seems really important and reusable, will they try to get corporate IT to add it to the central systems.

My own mental model is slightly different. I see analysts as spending very little time gathering data. In practice, most of what they need resides in corporate systems, so analysts are largely at the mercy of IT to provide extracts of required sources. Although waiting for those extracts is probably the biggest constraint on what analysts can accomplish, they don't spend that time twiddling their thumbs. Most of their work day (apart from meetings, etc.) is spent manipulating and interpreting data, and, as Devlin suggests, discussing results with other analysts.

This difference in perspective has some impact on judging what matters in a business analysis tool. If data gathering is really important, then features for extraction and consolidation are critical. If manipulation and interpretation matter most, then features for processing and visualization are at the top of the list.

As I recall, Lyza doesn’t offer particularly advanced extraction or consolidation features (e.g. fuzzy matching), so this isn’t necessarily a topic they should stress. Lyzasoft might disagree – and I’ll gladly concede that the system allows basic joins and filters that are well beyond what you can do in Excel. Still, to my mind, the real strength of Lyza is the ability to create data process flows, which save analysts from trying to do similar work by manually modifying Excel spreadsheets. (Click to read my Lyza review.)

Either way, though, features to document and share analytical processes still matter. Those are really the focus of this white paper, which is written to support the "Lyza Commons” product. Commons lets analysts share their work, trace the origins of each shared item, and use one analysis as input to another. As the paper points out, this both fosters cooperation among analysts and makes it easier for IT to add their activities to the company’s core business intelligence systems. Both benefits should free up analysts’ time for new projects, letting them foxus on what they do best.

Demand Generation Vendor Traffic Rankings

2009-07-08T17:40:00.008-04:00

Summary: Based on Web traffic rankings, new demand generation vendors with low prices are gaining market presence. Pardot and (perhaps) Genius.com look particularly strong. But Eloqua, Silverpop and Marketo remain industry leaders.

Last November, after much consideration of alternatives, I settled on Alexa three-month Web traffic rankings as a reasonable way to measure the relative market presence of demand generation vendors. You can see that post here. I revisited that data today, adding a few new vendors and dropping some of the very minor ones. Results are in the following table.

(Note: after I posted this, it was pointed out to me that the bulk of traffic on several sites relates to customer log-ins rather than marketing prospects. For example, Alexa says that 89.4% of visitors to eloqua.com next go to now.eloqua.com, which is the customer log-in page. I don't know whether this particular nuance makes the Alexa rankings a less useful indicator of market presence, but it probably means the figures relate more to existing customers than prospects. Alexa is a crude measure for many reasons -- although I do think the rankings correlate roughly with a vendor's volume of business and marketing actvitiy, I wouldn't go much further. - David)

There are no huge surprises. The leaders among demand generation systems are still Eloqua, Silverpop and Marketo. Infusionsoft and Genius.com also rank very highly, but they serve broader markets (small business and salespeople, respectively) so a direct comparison with pure-play demand generation vendors may not be appropriate. Silverpop's figures may also be inflated by its consumer email production business.

Vendors showing significant growth (highlighted in green) are mostly new entrants with below-average prices: Pardot, OfficeAutoPilot and LoopFuse. ActiveConversion is not new but also has a low price point. The outlier here is eTrigue, a long-established player that I've never looked at in depth. Their ranking is still very low, but has increased substantially. Judging from the press releases on their Web site, this may be due to a new release last October that added Salesforce.com integration. I'll explore further when time permits.

The only vendor with a really major drop in ranking was Lead Genesys, another long-time industry participant.

As the entries in the first column indicate, I've reviewed nearly all these vendors in either this blog or the Raab Guide to Demand Generation Systems. (The links all point to blog entries.) The only important exception is LoopFuse, which I have deferred at the company's request. (How about it guys? Ready yet?) NurtureHQ doesn't quite seem to be a full-scale demand generation system, insofar as it seems to lack landing pages. But its relatively high rank still surprised me, so I'll make it a priority to learn more.

My general interpretation of these numbers is that demand generation remains a dynamic market -- new participants can still enter successfully if their product and pricing are attractive enough. This is good news for marketers, since continued competition will result in continued product improvements. Major advances are still needed in usability, particularly for complex marketing programs, and in coordination with sales systems. Vendors who can deliver on these key requirements at reasonable price points should earn their place as tomorrow's industry leaders.

reviewed in:	vendor:	Alexa rank: November 2008	Alexa rank: July 2009
blog	Infusionsoft		4,993
guide	Eloqua	20,234	10,036
guide	Silverpop / Vtrenz	29,080	28,640
guide	Marketo	68,088	51,463
blog	Genius.com		70,007
blog	Pardot	211,309	92,530
blog	OfficeAutoPilot	509,868	153,232
guide	Marketbright	167,306	180,141
blog	ActiveConversion	257,058	192,634
guide	Manticore Technology	213,546	203,501
blog	Marqui Software	211,767	265,780
guide	Market2Lead	235,244	296,914
blog	Act-On Software		344,806
	LoopFuse	734,098	353,994
	NurtureHQ		367,152
blog	Treehouse Interactive		419,315
guide	Neolane	566,977	537,863
blog	LeadLife		677,156
	eTrigue	1,510,207	728,720
	SalesFusion360		846,961
	Lead Genesys	557,199	1,015,851
blog	True Influence		1,246,454
	RightOnInteractive 5Buckets		1,342,985

LucidEra's Failure: More Evidence that Marketers Won't Pay for Measurement

2009-07-07T10:30:00.007-04:00

I’m just catching up with what happened while I was on vacation these past two weeks. One piece of news is the demise of LucidEra, which this blog profiled almost exactly one year ago. According to SearchDataManagement.com, the company said it shut down because it couldn’t raise new funds or find a buyer.

There has been some learned discussion of the causes of LucidEra’s collapse on Timo Elliot’s BI Questions Blog. Much seems to focus on the apparent operating costs. These must have been substantial, since the company raised $15.6 million in 2007 and, presumably, has since spent it all.

Still, I think the fundamental problem was a lack of customers. When I spoke with LucidEra in June 2008 they said they had about 40 paying clients. When I spoke with them again in October 2008, the number was 50 and it was still at 50 when we spoke in April 2009. In other words, LucidEra was making very few sales or, even worse, was able to make new sales but couldn’t retain its customers.

With the benefit of 20/20 hindsight, LucidEra’s strategic decision to focus on building sales analysis applications primarily for Salesforce.com was a mistake. Bear in mind that there are about 60,000 Salesforce.com customers – selling to 50 of them is less than 0.1% penetration.

I suspect LucidEra’s price point, around $3,000 per month depending on the details, was too rich for many of its prospective clients. Not that they couldn’t actually afford it – but they didn’t want to spend that much money on sales analysis.

This is not surprising. I reluctantly concluded some time ago that marketers (and presumably sales managers) are not willing to spend money on measurement systems even though they consistently say in surveys that better measurement is a high priority. For recent evidence along these lines, see the 2009 Marketing ROI and Measurements Study published by Lenskold Group and sponsored by MarketSphere, which found that “6 in 10 firms (59%) indicate having an increased demand for marketing measurements, analysis and reporting in 2009 without the budget necessary for those measurement efforts.”

Many analysts and other on-demand business intelligence vendors have been quick to assert that LucidEra’s failure does not reflect a problem with the notion of on-demand BI in general. I agree, since I see the key to LucidEra's demise as its uniquely narrow focus on sales analysis. Indeed, competitors including Birst and GoodData have leapt to offer a new home to orphaned LucidEra clients.

Still, the apparently high costs to sustain a small client base suggests the economics of this business are not as attractive as they seem. LucidEra's Darren Cunningham did tell me that their costs were particularly high because they were not a multi-tenant solution and had to manage the entire BI stack to support a single application. Presumably other on-demand BI vendors can run more cheaply. Still there does seem to be a little more reason for caution in approaching on-demand BI vendors, even though there is not (yet) any cause for alarm.

Marqui Combines Content Management and Demand Generation

2009-06-17T15:42:00.004-04:00

Summary: Marqui started as a Web content management system and then added basic demand generation. It’s a good choice for organizations that need both and don’t have very sophisticated marketing requirements.

Marqui is one of the oldest demand generation vendors, founded in 2000. But that date is a bit misleading because the company’s original product was a Web content management system (CMS). It added demand generation features later in response to client requests. Today, content management and campaign management can be purchased separately although they are tightly integrated.

The entry of CMS vendors into the demand generation market is a bit of a mini-trend right now: others following the same path include Sitecore and Lyris-owned Hot Banana. Among conventional demand generation systems, Pardot is a spin-off from CMS vendor Hannon Hill and Marketbright includes extensive CMS features. Since the CMS marketplace is now almost totally commoditized, in particular by open source products like Joomla and Drupal, it makes sense for vendors to look for an adjacent field with greater profit potential.

Whether demand generation is the right refuge is another question. Marqui’s VP Marketing Richard Sharp defines “marketing automation” as the combination of Web content management and campaign management. In this view, content management is responsible for attracting, engaging and capturing leads, while campaign management captures, nutures, and sends leads to sales. That makes a nice diagram but it ignores the reality that content management systems are generally purchased and run by IT while demand generation systems belong to marketing.

This poses a serious sales challenge. Marketing and IT have different priorities, different cultures, and are likely to be buying systems at different times. In practice, Sharp said, most of Marqui’s new clients start with CMS and add campaign management later as the need becomes more evident. He said about one-third do purchase both modules at once.

Sharp also said he is finding that control of the company Web site is generally slipping away from IT departments, especially at smaller organizations. That sounds both true (as in “factually correct”) and right (as in “the way it should be”). As the Web site becomes a more prominent source of information for prospects, it’s increasingly important for marketers to watch and optimize its operations.

Still, the technical chores of managing the Web infrastructure will always remain with IT, so there’s an on-going question of who will be responsible for what. Ultimately, it’s hard to imagine that IT won’t have the dominant voice in selecting the CMS. This will leave marketing to either use the demand generation features embedded within the chosen CMS system or to integrate a separate demand generation product.

Encroachment by CMS systems poses another strategic threat to stand-alone demand generation vendors, who (at least in my opinion) are already in danger of being absorbed into CRM suites because of the need for closer integration between sales and marketing. I see demand generation as a tasty little fish swimming among some much larger sharks. This leads to an elaborate metaphor about hiding in coral reefs, but I'll restrain myself.

Marqui has the features you’d expect given its background: strong content management and basic demand generation. To accentuate the positive, the system provides hierarchical folders for marketing assets, version tracking, expiration dates, advanced templates, and fine-grained user rights management.

It also does a good job with Web forms, allowing users to specify whether responses update the main lead profile or are stored separately. The system can send notification messages to the person who completes the form and to someone else (e.g., a marketing or sales manager). It can also direct visitors who complete a form to another Web page.

One particularly nice feature is tight integration of Marqui-generated pages with Google Website Optimizer. This makes it much easier than usual to test alternative components within landing pages and elsewhere on the site. I can’t immediately recall any other demand generation vendor offering this integration, but haven’t checked carefully.

The outbound marketing features are not as advanced but should be adequate for simple programs. Users create subscriber groups (i.e., lists) by building rules; these can incorporate behaviors, such as email responses and Web page visits, as well as attributes and form responses. Behavior definitions can be include relative time (e.g., the past three days), which is important and not always the case with other products. However, the rules cannot reference membership in other groups, which makes some things harder. Groups can be dynamic (reselected each time they are used) or static (selected once and frozen) – a common but important capability.

Emails are defined as activities within a campaign and assigned an execution schedule, email template, and target group. Campaign activities can also be Web behaviors such as clicking on a banner ad. Each activity can be assigned several Web pages to track as goals, allowing reports to show leads moving through a conversion funnel. This feature is a somewhat unusual among demand generation systems but pretty common in Web analytics.

Users can also enter the cost of each activity and combine this with expected and actual revenues for Return on Investment reports. The revenues are based on opportunity records imported from the CRM system. This is probably adequate for most uses and more than some other demand generation products offer. But Marqui doesn’t capture cost details and can only link campaigns to opportunities when opportunity is "owned" by a lead from the demand generation system. Such links are often missing, and more advanced demand generation vendors offer alternative attribution methods to compensate.

Marqui’s features for lead scoring, multi-step campaigns and CRM synchronization are similarly basic. Lead scoring is associated with individual Web forms, a somewhat unusual approach. The scoring formulas can look at a broad range of data, including activities, attributes and form replies, but cannot cap the value from a single element or automatically reduce scores over time.

Multi-step campaigns are probably the weakest of all these features. Multiple activities can be assigned to the same campaign, but are not directly linked in a sequential flow. Nor is there any visualization of the entire campaign. A new interface is planned for later this summer.

The system can exchange data with Salesforce.com, NetSuite and Microsoft CRM Dynamics, but does not allow field-by-field update rules.

Pricing also leans toward the lower end, starting around $1,000 per month for campaign management and under $2,000 per month for campaign management and CMS combined. There are some additional charges based on email volume and for template creation.

Marqui's customers tend to be smaller organizations, and are not as concentrated in technology as clients of most demand generation vendors. This also reflects its base in content management software. Companies with basic demand generation needs that also want a tightly integrated CMS will find it worth a look.

Cloud-Based QlikView Still Isn't Available as a Service

2009-06-15T21:11:00.006-04:00

Summary: Pay-as-you-go pricing would make QlikView easier to buy, but the company doesn't offer this option. To make a stronger business case for the purchase, include the value of shifting work from IT to business users, and of producing results faster.

Last week’s post about QlikView 9.0 prompted an inquiry from a manager who has been trying for a year to convince his company to consider the product. Having run into this issue many times, I easily felt his pain and we speculated a bit on what might help things along.

One obvious tactic would be to purchase QlikView on a pay-as-you-go basis, presumably cloud-based. But a quick check with QlikView confirmed that they don’t allow this and have no plans to change.

The closest they come is to let their partners offer QlikView-based applications as a service. For example, they pointed me to SportsDataHub, which lets users analyze football statistics for $40 per year. But the key point about this and similar QlikView services is that you can only access data loaded by the partner. You can't define and load your own data sources directly. At best, you might be able to create your own reports based on the loaded data. (See QlikTech Marketing SVP Anthony Deighton's comment on this post for a little more on the subject.)

I don’t understand QliiView’s reluctance to adopt a Software-as-a-Service model. It has proven viable for many other software companies, including other business intelligence vendors. To me, it seems a natural extension of the company’s “seeing is believing” sales approach as well as a good way to sidestep the barriers raised by corporate IT.

In fact, QlikView’s tremendous ease-of-use makes it an excellent fit for the SaaS model, because business users can deploy it for themselves with minimal technical support. In our conversation last week, QlikTech's Deighton said the majority of clients already implement the system without purchasing any external services. If there was ever a piece of software suited to SaaS, this is it.

Be that as it may. The lack of a proper SaaS offering left my correspondent with several avenues to pursue:

- find a QlikView partner who would build an appropriate application and sell it to him on a services basis. This doesn’t seem very plausible because he probably won’t be able to commit enough funding to make the project worthwhile for the partner. I mean, if he had that much money, he could just buy the software outright in the first place.

- use an alternative system that costs less. Yes, QlikView is unique and wonderful, but products from ADVIZOR Solutions, Lyzasoft, Tableau Software and TIBCO Spotfire offer some of the same advantages at a much lower entry price. Again, this is far from ideal, and it might not work at all because I didn’t explore precisely which aspect of QlikView my correspondent found attractive. Still, it’s better than nothing.

(Vaguely related aside: today, people often cite author Jim Collins’ phrase “good is the enemy of great” as a reason to avoid compromise. Previously, I was more likely to see Voltaire’s “the best is the enemy of the good,” which means that compromise is better than nothing. I’m sure this reversal says something important about our society, although I can’t say what. You're welcome.)

- Find a way to sell QlikView internally. Of course, my correspondent had already been trying, so his question was whether I had any new ideas for how. This actually prompted some very deep thinking over the weekend, which will show up in my Information Management magazine column over the next several months. To summarize four pages in 100 words, there are two approaches to consider:

- do a cost of ownership analysis showing the savings from letting business users perform tasks currently done by IT. Traditional cost analysis compares the time it takes IT to do the work with one tool vs. another. This hides rather than highlights the advantages of QlikView and similar products.

- do a “time to result” analysis that measures the time spent waiting for IT to deliver solutions through multiple iterations. This applies to many analytical databases, not just QlikView, because their flexibility reduces the time spent building conventional BI structures like star schemas and data cubes.

Perhaps one of these will work. I hope so, because we could all benefit from finding ways to take advantage of what new technologies like QlikView have to offer.

QlikView 9.0 Reaches for Broader Business Intelligence Market

2009-06-10T18:37:00.008-04:00

QlikTech released version 9 of its QlikView business intelligence software today. The product has been in public beta for several months, so the general features are well known to people who care about such things.

Probably the item that attracted the most advance attention is an iPhone version that supports interactive analysis; this also works for other Java Mobile clients like Blackberry. It's cool (or ‘qool’, if you must) but not so important in the grand scheme of things. More significant changes include:

- availability through the Amazon Elastic Compute Cloud (EC2), which lets companies order up a QlikView-equipped server in minutes. (Of course, they still have to purchase a QlikView license.) Users can also expand or reduce the number of servers to match fluctuating needs. Advantages including avoiding the wait for new hardware, no need to physically install a server, and the ability to meet peak demands without making a fixed investment.

- API for real-time updates of in-memory data. This is an extension of previous changes that allowed incremental batch updates and manual data entry. But it still marks a major step towards letting QlikView run time-critical applications such as stock trade analysis, pricing and inventory management. No one will be processing orders on QlikView (hmm, never say never), but the line between analytical and transaction databases just got that much thinner.

- enhanced support for enterprise-level deployments. This includes centralized control panels for multiple servers; load balancing and fail-over; better thin-client support; multi-billion-row data sets; and more efficient calculations. These are critical as QlikView moves from being a departmental solution run primarily by business analysts to a mission-critical system backed by corporate IT.

- free Personal Edition with full development capabilities. The main limit vs. the licensed version is that Personal Edition cannot read QlikView files developed on any other copy of the software, and no one else can read files that Personal Editon generates. The goal is to make it easier for users to try the system on their own – a continuation of the company's long-standing "seeing is believing" strategy.

- functional enhancements including improved visualization, search and automation functions. These are nice but none seemed especially exciting. Changes in previous recent releases, such as set analysis (simultaneously comparing two sets of selected records) were more fundamental. Remember, we're talking about version 9: the system is already quite polished.

Of all these items, the one I found most thought-provoking was the free Personal Edition, which replaces a 15-day free trial. Removing the time limit let users build QlikView into their regular work. The strategy makes sense, but it doesn’t lower the $30,000 - $50,000 investment required for the smallest licensed QlikView installation. Few analysts, who are the most likely users for Personal Edition, have the clout to sponsor so large an investment. Competing analyst tools such as LyzaSoft, ADVIZOR Solutions and Tableau can generally provide a 5-10 user departmental deployment for under $10,000. Although QlikView is vastly more powerful than the others, the lower cost will give them an initial advantage. And once they’re in place, it’s hard to get a company to switch.

On the other hand, maybe QlikView is really moving to compete with traditional business intelligence tools like Cognos, Business Objects and MicroStrategy. QikView’s entry cost is vastly lower than those products, especially once you consider the savings in labor. But most enterprises have a BI tool already in place, so it’s not a matter of comparing entry costs. Rather, the choice is entry cost for QlikView vs. incremental deployment cost on the incumbent. The labor savings with QlikView are so great that it will still be cheaper for many projects. But QlikView will remain be a tough sell because IT departments are reluctant to invest in the staff training needed to support an additional tool.

QlikView will never fully replace the traditional data warehouse and BI tools because its in-memory approach limits the size of its databases. With 64 bit systems, the product can easily handle dozens of gigabytes of data. This is quite a lot, but even the smallest enterprise data warehouses now hold multiple terabytes. QlikView works with such systems by executing SQL queries against them, pulling down limited data sets, loading these into memory, and analyzing them. That’s an excellent and perfectly viable approach, but it does rely on the warehouse being there in the first place.

None of this is to suggest that QlikView has anything but a very bright future. When I first spoke with the company in 2005, it had just reached 2,000 clients; at last count, it had over 11,000. Revenue for 2008 was $120 million and had risen 50% from the previous year. The product has finally attracted attention from analyst firms like Gartner and Aberdeen and is very well rated in Nigel Pendse’s latest BI Survey. My brief fling as a VAR ended two years ago, but I still use it personally for any non-trivial data analysis work and remain absurdly pleased with the results. I won’t say QlikView is better than sex, but its pleasures are equally difficult to describe to the uninitiated. Anyone interested in BI software who hasn’t given it a try (QlikView, not sex) should download a copy and see what they’ve been missing.

Marketo Sales Insight Expands Salesforce Access to Marketing Data

2009-06-09T12:48:00.009-04:00

Summary: Marketo's new Sales Insight ranks prospects for sales people, based on recent Web and email activities. It lets Marketo sell seats to sales departments, which could be more lucrative than selling its core demand generation system. But I expect the sales automation vendors to take the business for themselves.

Marketo today officially launched “Sales Insight”, an application that makes prospect activity history directly available to sales people from within Salesforce.com. I had a personal demonstration last week (are you impressed?), but there’s an online demo that seems to cover pretty much the whole product. Features include:

- a ranked prospect list, based on measures of interaction intensity (represented by one, two or three flames) and prospect value (up to three stars). The idea is to help the sales rep decide who to call first. Users can drill into the details of each account, including Web activities, emails and score history.

- a list of “interesting moments” for each prospect, showing activities that the company has deemed significant. The moments are set up as real time triggers within Marketo. They can be linked to a specific campaign or defined more generically (e.g., three Web site visits in two days). I found this the most interesting capability in the system, because it fills a middle ground between summarizing all activities and providing the item-by-item detail. It does depend on marketing setting up the definitions, rather than letting sales people create their own. But, then again, how many salespeople really want to do that?

- a “lead feed” feature that can send “interesting moment” alerts via RSS, SMS, email, iPhone and other mobile devices. Sales people can select the individuals and accounts to monitor and the types of activities that trigger alerts.

- an option to send emails and add prospects to Marketo campaigns.

- ability to track anonymous Web visits within the sales person’s territory, using IP lookup to identify the visiting company and location. This can be integrated with Demandbase and Jigsaw to download the names of contacts at those firms. The system can also open a window to LinkedIn to let the sales rep find network contacts of her own.

It’s irresistible to compare Sales Insight with Eloqua Prospect Profiler, launched two weeks ago (see my review), which also gives sales people access to prospect activities gathered by the marketing system. The products are designed around slightly different scenarios: while Marketo starts with a list to help the sales rep decide who to call, while Eloqua aims to help the rep understand a prospect she has already selected. Still, both systems provide views into the data and both let salespeople receive alerts about prospect activities.

There are some subtle differences. Marketo is a Force.com application that works only with Salesforce.com, while Eloqua works with several CRM products. Eloqua lets sales people define their own alerts rather than relying on marketing to predefine the “interesting moments”. Marketo lets sales reps send emails and add prospects to demand generation campaigns. Eloqua provides interesting graphs of activity trends. Marketo includes the anonymous visitor tracking.
It’s hard to say which product will be more appealing to sales people, but that probably won’t matter: any significantly attractive feature in one product will (and should) be quickly copied into the other. Competitors without any equivalent product are more at risk, but, you can bet they'll quickly add something similar if it becomes an issue.

What really matters is that these products provide an opportunity for the marketing system to integrate more deeply with sales. This is THE big industry trend right now, so much so that we’re probably due for some clever nay-saying. The attraction to vendors like Marketo and Eloqua is quite clear: they can expand the size of their installations by serving new customers within existing clients.

This could have a substantial impact on total revenues. At Marketo’s price of $49 per seat, a 20-user license would bring in another $1,000 per month. (Genius.com's Genius Pro, a somewhat similar tool that helps sales people track prospect activities, is also priced at $49 per seat.)Compare this with maybe $2,000 per client per month earned by most demand generation vendors. Figures like these radically change the economics of the demand generation business. They also explain why some vendors have been willing to sell to new clients at very low prices.

But these figures also raise the specter of sales automation vendors moving in the other direction. An average Salesforce.com seat is around $100 per month these days. From the Salesforce.com viewpoint, adding marketing automation for $1,000 to $2,000 per month per client isn't particularly exciting. But if that same application also justified another $49 for each seat, you're starting to talk real money.

Of course, this has always been the threat inherent in demand generation vendors’ symbiotic relationship with CRM in general and Salesforce.com in particular. I’m increasingly convinced that it’s just a matter of time before sales automation and demand generation / marketing automation do merge – and it will almost certainly be sales systems swallowing the marketing vendors, not the other way around.

That will put the business marketing world pretty much where consumer marketers have already landed: most companies will use the marketing features of their CRM vendors, except for a relatively small number of businesses with marketing needs so advanced that they can really need the special features of a “best of breed” system.

In support of this view, it’s worth noting that demand generation systems for small businesses already routinely include their own sales automation system. This integrated model will likely filter up into larger companies, even as CRM vendors add marketing automation features and move down from above. Vendors offering just marketing automation or just sales automation will be trapped in the middle – rarely a pleasant place for a vendor to be.

Market2Lead User Interface: Attention to Detail Pays Off

2009-06-05T11:36:00.008-04:00

Summary: Market2Lead's revised user interface has plenty of refined details. But what's most important is it offers different ways to build simple and complex campaigns. This beats even the best "one size fits all" approach.

Time flies. I saw a demonstration of Market2Lead’s new user interface last December, and they released it in February. But I’m only now getting around to writing about it.

It’s a good thing that Market2Lead moved more quickly than I did, because the new interface is a huge improvement. Their previous offering was a good example of what happens when technicians design a user interface: you get the thinnest possible skin stretched over the underlying components. It’s all perfectly logical and functional, but makes no accommodation for how users actually work.

For the redesign, Market2Lead had the good sense to bring in a usability consultant who focused them rigorously on intuitive navigation, fewer mouse clicks, presenting options only as they are needed, and accommodating both novice and expert users. The results included:

- tabs structured around user activities rather than system tables
- wizards to lead users through creating campaigns, programs and Web forms
- floating menus that show options related to the user’s current activity
- pleasant and consistent color schemes that highlight the commonly-chosen menu options
- searches entered directly into form fields and allowing advanced syntax such as lists and value ranges
- different interfaces for creating simple and complex campaign flows

These are not especially novel concepts, so what really matters is how rigorously they are executed. One objective metric is mouse clicks: Market2Lead reports these were reduced by 300%. The others are largely verifiable by sight – yep, the wizards and floating menus really exist.

But listing these items doesn’t convey their combined effect. The resulting system simply feels less stressful than the original version. Even though you may not know in advance how it works, the next step is usually clear.

The campaign interface is the acid test. Market2Lead offers either three versions, each tailored to a different level of complexity.

- The simplest are static campaigns, which use predefined flows and typically present a single marketing program. The program itself represents a single offer, but may contain a sequence of contacts such as an outbound email, landing page, and confirmation email. These elements are predefined for different program types, and users simply fill out forms to specify the details. There is no visual flow chart for the program.

Static campaigns wrap some additional rules around a program, such as which campaign the prospects should enter next. These rules can have some conditional logic, creating the equivalent of a branching workflow. But the structure of the flow is predefined for each campaign type and users cannot change it. As with programs, they use forms to fill in the details.

- A second type of campaign does allow users to build their own workflow. For these, called "workflow campaigns", Market2Lead has provided a Visio-style flow builder but kept it simple. Decisions can only have two results (true or false), branches cannot merge within the flow, and prospects always enter a new campaign at the beginning. This eliminates some options but avoids the complicated paths that can make conventional flow charts so confusing.

In fact, the drag-and-drop interface offers just five icons: send a program, make a decision, wait a specified number of days, send to another campaign, and exit. As in other systems, users can click on each icon to define its parameters. Market2Lead has posted an online demonstration.

- For really complicated projects, Market2Lead provides “adaptive” campaigns. These are designed with standard work flows, but replace the specific programs with rules that select the most appropriate program for each prospect. This allows one simple campaign to deliver different messages to different prospects simultaneously, and to deliver a sequence of messages to the same prospect over time.

Of course, the user must still define the rules used to make the program selections. But Market2Lead argues, and I agree, that this is easier than trying to build the rules within the flow chart itself. It also opens the way for increasingly sophisticated selection capabilities, such as the automated statistical approaches that I described last month.

Choosing from three different campaign types may sound confusing. It certainly will take some time for new users to learn when to select each one. But the Market2Lead interface makes the options readily apparent, which will help to some degree.

More important, each choice makes building its particular type of campaign about as easy as possible. This is a much more effective approach than trying to build a single interface that is good for everything. For marketers who execute a broad variety of campaigns, ranging from simple to complex, this will ultimately make their jobs easier.

Marketbright's Campaign Flows Work Well for Serena Software

2009-06-03T15:17:00.007-04:00

Summary: Serena Software is pleased with Marketbright's Visio-style interface for complex campaigns. The real work is in designing the campaigns, not setting them up in the software.

(Second of three posts on demand generation interfaces.)

I spoke last week with Marketbright client Michaline Todd, director of corporate marketing at Serena Software, to see how Serena likes Marketbright’s campaign interface. Marketbright uses the two-level approach that I consider an industry best practice: users can build simple linear campaigns with a wizard-driven interface, and embed these in a Visio-style flow chart to manage flows across campaigns.

The short answer is that Serena is very pleased, since the flows make it easier to enforce complex processing rules that were otherwise difficult to define and execute. The long answer adds a few shades of gray to this rosy picture, and these are worth exploring.

- Serena didn’t build the complex campaigns for themselves. The work was done by an outside agency, Maratona Marketing. The reason was not the Marketbright interface: of the six weeks it took to develop the company's first complex flow campaign, setting it up in Marketbright took twenty minutes. Maratona spent the rest of the time on business issues such as lead scoring, process flow and content creation. This reinforces the point that most companies will need help to take advantage of the new opportunities that demand generation systems present.

- Todd felt the campaign flows were “as easy as Visio”. She meant this as praise, although I suspect that many marketers don’t find Visio all that easy. In particular, Todd said the visual diagrams helped to explain the flows to marketing and sales managers who would otherwise find them hard to grasp. Todd also noted that Serena itself sells software development tools, so its staff is already very comfortable with flow charts.

- Serena is now running into conflicts when a given prospect is in more than one marketing campaign. Marketbright handles this now by limiting each prospect to one message per day, storing any additional messages, and sending them later. The vendor plans to refine this approach by letting users prioritize the campaigns so the most important messages are sent first.

Todd cited a couple other features she appreciated. These include a “flight check” of all components before the campaign is executed and an option to view results of active campaigns by clicking on icons in the flow chart. She didn’t mention some of the limits I noted in my Raab Guide analysis of Marketbright, such as a maximum of two splits leading from any decision within the flow or the inability to create random tests without SQL coding.

We did discuss testing in general. Todd said her company doesn’t run formal a/b tests although it does review the performance of different messages to see which yield higher response. She hinted that she might add testing later but was wary of creating too much complexity in the company’s first flows. Marketbright president Erik Bower reinforced this comment, suggesting that most marketers are too busy to analyze results from many tests. Instead, Marketbright plans to add “self-optimizing” capabilities similar to Google AdWords, which will let marketers load alternative versions and have the system automatically select the better-performing option over time.

We also discussed whether an automated lead nurturing campaign can build a relationship between a prospect and the sales rep whose name is on the system-generated emails. Both Todd and Maratona’s Cari Baldwin told stories about prospects who believed the emails werebeing sent personally. This is good news for companies hoping that demand generation systems can compensate for the loss of direct contact between sales people and early-stage prospects. (See my recent white paper Restoring the Balance for more on this.) But the stories also raise a note of caution: in both cases, the prospect approached the actual sales rep at a trade show, and the rep had no idea what they were talking about. Happily, both reps handled the situation well.

Silverpop Engage B2B Adds Visual Campaign Builder

2009-06-03T10:32:00.008-04:00

Summary: Silverpop Engage B2B has added an innovative visual campaign builder that supports complexity without the drawbacks of a Visio-style flow chart. Thumbs up.

(This is the first of three planned posts on updated interfaces from demand generation vendors.)

Silverpop Engage B2B (formerly Vtrenz) on Monday released its first visual campaign builder, finally matching a feature offered by nearly all its competitors. The interface takes a creative approach to the conflict between simple presentation and complex campaign flows, using what Silverpop describes as “horizontal video-production-style features” that lay out each contact stream in a separate row on the screen. Movement between streams is handled by objects that list the destinations, but don’t connect to them with lines like a conventional, Visio-style flow chart. (Click here for a video demonstration.)

Silverpop told me that they had originally planned to use a Visio-style approach but found the diagrams became unworkably complex once they expanded beyond a few branches. Since this matches my own oft-stated opinion, I readily agreed.

It also can’t have hurt that the Engage B2B was already organized around contact streams, which it calls “tracks”, and rules to direct movement between streams, which it calls “track routes”. This fits perfectly with the new interface. In fact, “track” is precisely the term that audio, video and film producers use to describe their synchronized inputs. Think “sound track” or “8 track tape”. But I digress.

The ability to explicitly direct leads from one contact stream to another is what separates the Engage B2B approach from simple linear campaign flows. In the new interface, track routes are objects within the contact stream, and can be opened to edit the decision rules that determine where the lead moves next. The stream can also contain decision objects with a single rule that is tested repeatedly during a specified evaluation period. This allows the system to wait for an event (e.g., allow one week for response to an email) and still react immediately if it happens. If the rule is not met by the end of the evaluation period, the lead can move to the end of the track, to another track within the campaign, or to another campaign.

The interface includes a variety of thoughtful details that have a major impact on usability.

- A track can include placeholder objects, letting users design a campaign before its marketing materials are ready. Since this raises its own risks, the system flags incomplete objects so users know which still need work.

- Users can hover over the list of destination tracks within a track route object and then click on a destination to move to it.

- When events are based on fixed dates, as in a Webinar promotion, the objects in the different tracks are vertically aligned by date. This makes it easier to grasp what happens when.

- Once a campaign is under way, the system displays actual metrics on the track objects (responses, leads currently in the object, leads that have passed through, etc.) so users can see the results at a glance.

- The rule definition interface offers a wide variety of pre-formatted, fill-in-the-blanks statements. This lets non-technical users build complex rules, since it spares them from learning about database details or programming syntax.

Of course, no interface is perfect. There is no visual overview of how leads move across tracks and campaigns, which can make the flow hard to grasp. Nor is there an alternative, more concise interface for simple linear campaigns. The system doesn’t seem to adapt to different user skill levels or to adjust which options are exposed, although I might have missed some of these features.

Still, the Engage B2B interface represents a much-needed fresh look at solving some of the basic issues in campaign visualization. It definitely raises the bar for the rest of the industry.

Demand Generation Vendors Offer Few Social Media Applications

2009-06-02T11:14:00.005-04:00

Summary: marketing vendors offer several types of social media applications. But none truly automates social media management, which is what's ultimately needed.

Social media is this month’s Trend of the Year. But no one knows how best to use it, which has led to a wide range of offerings under the social media label. Here’s a quick and surely incomplete run-down of those I’ve seen recently. They provide three basic functions:

- send messages via social media. Treehouse Interactive just introduced a “talk it up” feature that embeds “share this” buttons in Treehouse-generated Web pages and emails. This lets people easily send a Tweet, post to a Facebook wall or create a LinkedIn article that points to the original content. CRM vendor RightNow offers something similar under the label of Cloud Links.

- add social media data to prospect profiles. InsideView is gaining the most attention for this at the moment. It lets marketers or sales people specify companies and individuals to monitor, and then scans media including social networks (LinkedIn, Facebook), public forums (blogs, wikis, Diggs, Twitter), paid sources (D&B, Zoom, Jigsaw,) and Web pages for information about those entities. It analyzes the results to identify key events and to build consolidated profiles with its best guess at the correct current information. These can be loaded into sales and CRM systems to make them easily accessible. InsideView is already integrated with major CRM vendors and with the Marketbright demand generation system.

Broadlook offers somewhat similar functions, although it is largely limited to Internet searches to gather the data it examines. The company’s main product, Profiler, extracts names, titles, email addresses and telephone numbers from a specified Web site. It can also search other Web sites for email addresses containing the targeted domain. An enhancement released last month, Profiler X, will also incorporate data from Hoovers. Other products include Eclipse, which scans online directories that require user log-in, and Diver, which scans the results of a Google search one page at a time. Results can be imported to sales automation and CRM files to update and enhance their profiles.

Many other vendors let a user automatically jump to the LinkedIn or Jigsaw profiles of the prospect they are reviewing. Ones I know about include Pardot, LoopFuse , TrueInfluence , Salesforce.com and ACT! by Sage This is a crude sort of integration – the data is simply presented in a window on the screen, not actually loaded into the demand generation or sales automation database. But it does save a few keystrokes.

- scan for social media mentions. Specialized systems like ScoutLabs, Crimson Hexagon and BoardTracker have been available to track social media mentions for some time. Just last week, RightNow announced Cloud Monitor, which integrates such tracking with the ability to respond with its sales and customer service features. This will surely be a standard CRM feature before long, and will probably migrate to demand generation systems soon after.

All told, I'm rather disappointed at what I see in this list. InsideView and RightNow have the most important applications, but neither is a demand generation system. Treehouse Interactive is the only demand generation vendor to offer anything beyond a simple LinkedIn integration, and even Treehouse is only making it easier to use social media as a broadcast medium. No one seems to be executing meaningful dialogs through social media, even though that is marketers’ truly pressing need because doing it manually is so expensive.

Of course, this ties into the larger need for automated personalized dialogs that I have previously identified the future of demand generation. I’ve now believed this for almost two full weeks, so it must be true.

How the Buying Process Has Changed, and How It Hasn't: Notes from the Field

2009-06-01T12:02:00.005-04:00

Summary: The Internet has given more power to buyers and changed the buying process. But product and responsive salesmanship still make the difference.

The deer that ran into my car on May 21 provided still more posthumous marketing insights when the insurance company declared my car a total loss and I had to buy a new one on short notice. My latest pass through the quintessential American purchase experience confirmed one obvious truth and recalled two others that are easily forgotten.

- The obvious truth was that information, and therefore power, have shifted to buyers from sellers due to the Internet. Everyone knows this, but, for the record, I was able to do nearly all my research online and even get price quotes without setting foot in a dealer. This almost completely eliminated any personal relationship from the equation, as well as blocking traditional dealer tactics like the indirect negotiation with the sales manager.

- A less obvious truth was that, whatever the pundits say, products are not fully commoditized. My online research and preexisting preferences quickly narrowed the field to Honda and Subaru models with virtually identical specifications. The Honda has better reviews and a lower price, so I was all set to purchase it. But then I actually drove both vehicles and found I had a small but definite preference for the Subaru. Lesson learned: product really does count. This is something we all know but tend, as marketers, to disregard when we focus on decisions we control.

- The other easily-overlooked truth is that execution really matters. I put out online requests for price quotes to three Honda dealers and four Subaru dealers. I had responses with pricing from two Honda dealers in just over one hour, and from the third within three hours. In contrast, it was twenty-four hours before I got my first nebulous price from Subaru. More specifically, one Subaru dealer responded immediately but wouldn't discuss price except in person, one called me on phone even though I had requested an online reply, one responded twenty-three hours later, and one responded after four days.

In short, based on ease of doing business, Honda won hands-down. On the other hand, Subaru corporate sent me an email checking up on its dealer responses about two days after my original inquiry. So we can at least hope that Subaru dealers, as well as their cars, will eventually match the performance of Honda.

There were also clear examples of poor coordination within the dealers. The dealer that took four days to answer my email was very responsive in other channels: they published detailed prices on their Web site and gave me a price immediately over the telephone when I called. The phone and Internet prices differed slightly, but were both quite competitive. When I finally got their email, the price matched the one I had been offered on the phone. Of course, by that time I had already made my purchase and told the salesman.

The Subaru dealer who telephoned me also sent an email response three days later, but the email system was clearly unaware of our telephone interactions. That dealer proved particularly inept: they played the “let me talk to my manager” game on the phone for two days running, taking so long that I had already purchased the car elsewhere by the time they got back with a realistic quote. Ironically, I had recently purchased another vehicle from this dealer and had no particular complaints about my treatment, so the business was theirs to lose. They lost it by moving too slowly and playing old-style negotiating games.

For the enjoyment of anyone who really cares about the details, here is a log of my contacts during the buying process. Dealer names are changed to those of the Seven Dwarfs for no particular reason.

5/28
11:22 a.m. Subaru quote request via Edmunds.com to Doc, Dopey, Grumpy and Bashful
11:33 a.m. auto response – Doc Subaru
11:33 a.m. auto response – Dopey Subaru

11:37 a.m. Honda quote request via Edmunds.com to Sleepy, Sneezy and Happy
11:41 a.m. personal response – Dopey Subaru
11:46 a.m. auto response – AutoFigures.com (Honda service company)
11:46 a.m. auto response – Sleepy Honda
11:46 a.m. auto response – Sneezy Honda
11:46 a.m. auto response – Happy Honda
11:52 a.m. price – Sleepy Honda
12:00 p.m. (?) phone from Grumpy Subaru (sales manager)
12:47 price – Sneezy Honda
1:12 p.m. price details – Sneezy Honda
2:00 p.m. phone from Happy Honda (apologized; said system often doesn’t show whether requested email response)
2:20 p.m. price Happy Honda
3:00 p.m. (?) phone from Grumpy (my previous salesperson; gave him target price

3:30 – 5:00: test drove vehicles at Dopey Subaru and Happy Honda. Offered uncompetitive price from Dopey Subaru.

10:08 p.m. email w/other vehicles – Sleepy Honda

5/29
12:03 a.m. auto response – Sleepy Honda
9:50 a.m. personal response – Doc Subaru
11:26 a.m. price - Doc Subaru (details not stated – actually about $800 higher)
12:00 a,m. (?) phone from Grumpy Subaru
12:03 a.m. clarification – Sneezy Honda
12:16 a.m. details - Doc Subaru
12:41 a.m. note – Sneezy Honda
1:39 p.m. note from Doc Subaru (prices are ‘all in’)
3:00 p.m. (?) – phone price from Grumpy Subaru; told to get lower; said will talk w/manager
5:25 p.m. – price clarification from Doc Subaru

5/30
9:27 a.m. note from Sneezy Honda (can I come in?)
9:30 a.m. called Grumpy Subaru (salesperson; gave him target price)
9:30 a.m. called Bashful Subaru; got price (about $300 higher than on Web, but w/$500 gas card)
9:47 a.m. note from Sneezy Honda (thanks)
9:58 a.m. offer to negotiate price from Doc Subaru
10:43 a.m. price agreement from Doc Subaru
12:00 a.m. signed papers at Doc Subaru
12:30 p.m. phone from Grumpy Subaru w price; told had already purchased
3:00 p.m. (?) phone from Bashful Subaru; told had already purchased
4:03 p.m. email from corporate Subaru checking on dealer response

5/31
6:14 a.m. auto response from Sneezy Honda (had already informed dealer would not make purchase)

6/01
3:11 a.m. opt-out form from Autofigures.com (Honda)
3:13 a.m. auto response from Grumpy Subaru
11:03 a.m. email w/price from Bashful Subaru Internet division

New White Paper and Eloqua Prospect Profiler

2009-05-27T18:02:00.002-04:00

Eloqua yesterday announced Eloqua Prospect Profiler , which makes it easier for salespeople to review prospect behaviors that are captured by the demand generation system. In honor of the event, they sponsored a white paper by Yours Truly on the general topic of, um, why it’s important to make it easier for salespeople to review prospect behaviors that are captured by the demand generation system. The paper, Restoring the Balance: Why Marketing Holds the Key to Effective Selling in a Changed Business World, is available for free on the Raab Guide site and will eventually show up on the Eloqua site as well.

Despite its origins, the paper itself is quite generic and I think makes a valid argument: basically, that salespeople have less contact with prospects today because the prospects can gather so much information on their own. This makes it harder for salespeople to understand prospects and build relationships with them. The behavior data captured by marketing automation systems restores the balance by providing an alternate source of insights into prospect interests and intentions.

Replacing the relationship-building is more difficult, but demand generation systems can help somewhat by responding appropriately to prospect behaviors. This gives prospects a generally positive feeling towards the company even if no personal relationships are created. At a minimum, it keeps the company in the consideration set during the early stages of the buying cycle. Once the prospect has been assigned to an actual salesperson, the demand generation system can also send a stream of emails “signed” by the salesperson, building something of a one-to-one relationship. Obviously those emails must be appropriate, but this is what clever campaign design and good predictive modeling are about, per my last two posts.

Back to Eloqua Prospect Profiler. There’s nothing new about demand generation systems making prospect behavior available to sales people. Pretty much every major system on the market does this, and in roughly the same way: they pass activity headers over to the sales automation system, where they can be viewed as part of the normal interface, and let salespeople drill into details that are stored in the demand generation system itself. This may sound a bit awkward but it’s seamless from the user’s perspective, and moving all the details into the sales automation system isn’t practical.

Prospect Profiler’s claim to fame, so near as I can tell, is that it also presents summaries and trends of the prospect activity, per this very nice screenshot from Eloqua:

I don’t recall the other vendors doing that. The idea is to make it easier for the sales person to see patterns and then to drill into the details. This seems like a nice enhancement, and perhaps (I’m speculating here; Eloqua didn’t mention it) will be followed by additional of other marketing-gathered data with the salesperson’s interface. That would seem to be the general path that Eloqua and the rest of the industry are headed down, as part of the larger trend towards more closely intertwining marketing and sales activities.

If this isn't clear, think in terms of data from directories (D&B, Hoovers, OneSource), news feeds (Google Alerts, Lexis-Nexis, Reuters), social networks (Jigsaw, Linked-In), and social media (blogs, Facebook, Twitter). These are already assembled by various vendors, so all that’s needed is a relatively simple integration. The demand generation / marketing automation system is the obvious place to do this, rather than asking each sales person to do it for herself. The sales automation system could also be an option, but marketing already needs the data for its own purposes so it’s arguably a stronger contender.

Anther feature of Prospect Profiler is that salespeople can define their own rules for behavior-related alerts. Again, other demand generation systems also allow alerts, but I don't think they allow each salesperson to configure the rules for herself. It would be done by system administrators instead. But whether this is truly unique to Eloqua, I can't say.

More on the Future of Demand Generation Systems

2009-05-24T20:12:00.008-04:00

Summary: let's not forget that most companies are still not even doing simple demand generation. Systems for that might succeed even though advanced integration between sales and marketing is the long-run trend. And, my car hit a deer.

I hit a deer last Thursday while driving to Boston for the Sales 2.0 conference. I'm treating the four hour delay that followed as field research into customer relationship management, which ranged from great (the family-run auto shop that towed my car and took me in) to poor (the Enterprise car rental office that kept me waiting nearly two hours before admitting they didn’t have a vehicle available). It ended with the retired dad of the auto shop owners driving me into the next town to pick up a rental car there. The finishing touch was waving as we passed the local traffic cop, who had earlier stopped at the auto shop to chew the fat in true Mayberry RFD style. All told, my little visit to Plantsville (the actual town name) was straight from a grade B movie—city slicker makes an unplanned stop in a small town and learns about real life—except that I didn’t fall in love with a local shop girl.

The net result, beyond some new anecdotes, was that I missed much of the conference. My only extended conversation was with a sales manager who was just recognizing that cold calls were not the most efficient use of his time, and was quite excited to learn that many vendors can provide qualified lists and do the appointment setting for him. He was also starting to think that maybe the company Web site could play a role in attracting leads. In other words, he far behind the times. Yet he also appeared to be seasoned, competent and generally successful. In its own way, this conversation was as much an intrusion of the real world into my bubble as the stopover in Plantsville.

But then it was back to the bubble (so much more interesting than reality) with vendor meetings. Much of the conversation related to my blog post of the day before, which argued that self-adjusting statistical models will replace manually-generated business rules for alerts, lead scores, segmentation and message selection in demand generation systems. Discussing this idea let me to refine the presentation, which I now describe in terms of marketers catching up with changes in their role. That is, most marketers understand their job as generating leads and are just starting to implement systems to do this better. But their job today is actually to manage relationships deep into the buying process. Industry leaders have recently recognized this. The next step, which has barely begun, is for demand generation vendors to deliver solutions that support the new role. My specific argument is that self-adjusting models must replace rules because only models let the systems handle their expanded responsibilities and still be simple enough for marketers to actually use them. My broader argument is that self-adjusting models, rather than a variety of other new capabilities, will be the really important features for vendors to add.

My vendor discussions also touched on the other side of this coin, which is that demand generation systems to perform the original marketing tasks are quickly becoming commodities. Interestingly, I’ve spoken with more than one vendor who sees this as an opportunity, so long as they get to be the dominant commodity provider. Whether these vendors know how to make this happen is another question. I don't know myself, although I’m guessing the primary requirement (beyond a suitable product) is deep pockets for extensive marketing to grab share quickly.

Nor am I convinced that commoditization is a very good strategy, since even the dominant player may not make much money. But, with my little reality check still fresh in mind, I don’t want to underestimate the market for old-style demand generation systems. Perhaps a simple, low-priced system really can be a major success even though marketers will eventually need something more advanced. (Yes, the obvious strategy is to offer one product that can start simple and expand. But I’m very skeptical that this is actually possible.) It’s an interesting strategic puzzle. Fortunately for me, I don’t have to solve it. I just observe and report.

Prediction: Statistical Methods Will Replace Conventional Rules for Marketing Decisions

2009-05-20T23:38:00.007-04:00

Summary: basic demand generation features are close to a commodity. Vendors who replace conventional decision rules with automated statistical methods may gain a key competitive advantage because the automated methods produce substantially and measurably better results.

One of the most popular posts ever on this blog is Low Cost Systems for Demand Generation, which listed several options that started at under $500 per month. But it seems that nearly every day brings yet another possibility to my attention. Some really frugal alternatives include Genoo starting at $199 per month; Net-Results starting at $79 per month; and Nurture starting at $495 per month. I haven’t looked closely at any of these but they all seem to promise the core demand generation capabilities of email, landing pages, automated nurturing, lead scoring, and sales system integration.

The question this raises in my mind is where the industry goes from here. Basic demand generation is on the verge of becoming a commodity if it isn’t one already. The more sophisticated vendors will of course continue to add features, but it’s not clear that most marketers will be interested in the additional capabilities or be able to handle the added complexity. Perhaps the key competitive battleground is the ability to add that complexity without making the systems harder to use. But even though there are certainly substantial differences in usability among today’s systems, it’s hard to see why everyone won’t eventually be able to do roughly equal jobs of simplifying their interfaces.

Another possibility is that vendors will compete on their ability to help marketers use their systems – that is, by providing marketing training, usage reviews, and professional services. In other marketing automation segments, including MCIF systems and campaign management for consumer marketers, the ability to provide such services was the single most important difference between winners and losers. The same applies to CRM systems – it was Siebel’s partnerships with big system integrators that ultimately let it pull away from the pack. I do think these services will be a key success factor in the demand generation market, but there’s a big difference: because demand generation systems are offered as on-demand services rather than on-premise software, the actual deployment is much simpler. This means independent consulting firms can more easily learn to work with multiple systems. Because it’s much harder for vendors to build a loyal, locked-in base of resellers, it’s easier for new players to duplicate the service infrastructure of established competitors.

This brings us back to features. Certainly there is a list of hot items right now: Webinar integration, digital asset management, dedicated IP addresses for outbound email, APIs to post data from external forms, integration with Google Adwords, providing contact names from external databases when a visiting company is recognized by its IP address, pulling data from social networks to flesh out a prospect’s profile, and interacting through social media in addition to traditional channels.

The question is which of these features will turn out to be really essential. The only one I personally see as important to a large number of marketers in the immediate future is the Webinar integration, because Webinars are widely popular and integration makes the marketer’s life significantly easier. Everything else on that list strikes me as either of interest to a relatively small fraction of marketers or as simple enough to add that it won’t be a competitive advantage.

So is there something else that could be really important? Well, I wouldn’t ask the question if I weren’t leading up to something.

My particular insight, if it is one, is that consensus has crystallized within the past month that marketing now remains dominant much deeper into the buying cycle, and that sales and marketing must work much more closely together as a result. The idea itself isn’t new, but I suddenly see it referenced everywhere I turn. Part of the reason may be that I’m paying more attention because I wrote a paper on the topic myself (see When Best Practices Go Bad: New Rules for Sales and Marketing Management) although I’m under no illusion that my paper was anything other than one voice among many. It’s simply one of those ideas whose time has come.

As I and others have written, the immediate implication of this change is that marketing systems should provide salespeople with more information about prospect behaviors – what Steve Woods of Eloqua elegantly calls “digital body language”. This gives the salespeople insights into customer interests, replacing to some extent the information that they previously gathered for themselves when dealing with prospects directly.

But those direct interactions also built a relationship between the salesperson and the prospect. Watching their behaviors doesn’t do that. To the extent that anything does build the early relationship today, it’s the automated nurturing programs and behavior-driven responses executed by marketing systems. I don’t really believe that even the cleverest marketing systems can really replace the trust built by a good salesperson, but at least the automated programs can educate prospects and leave a positive impression about the company’s responsiveness to their needs.

I haven’t seen much written about the burden that this change places on the marketing systems. We’re not talking about some simple drip marketing to keep leads warm and educate them a bit until they move closer to their purchase. Rather, marketing must come as close as possible to simulating the interactions between a prospect and a good salesperson to build an essential relationship. This means that the marketing system has to be really smart. And I think providing this sort of intelligence might be a major competitive battleground for the vendors.

That last sentence was a bit of a leap, so let me fill in the blanks. Today’s demand generation systems are largely rule-driven when it comes to selecting prospect treatments. Whether those rules are embedded in list definitions, campaign flows or dynamic content doesn’t matter. The problem is that rules are hard to build and remain unchanged until somebody writes a new one. They’re generally based on somebody’s best guess about how the world works and they tend to be fairly simple. As a result, rule-driven systems just can’t be very smart, in the sense of reacting appropriately to subtle clues or changes in behaviors.

The limits of rule-driven systems don’t matter when there isn’t much data to work with and there aren’t many choices to make. That was arguably the case in the past when lead management systems worked with only a small amount of data from a postal reply card or brief telephone survey. But today’s demand generation systems are dealing a flood of behavioral data related to emails and Web visits. Rules can’t deal optimally with that much information. In addition, the demand generation systems have many more decisions to make, since every personalized email and Web page involves many choices for information to display. No one can create enough rules to handle all the possibilities.

Nor is the challenge limited to rules for selecting messages. Demand generation systems also use rules to decide when to alert salespeople about prospect behaviors. Lead scoring formulas are essentially rules as well. In addition to the fact that these rules are all defined manually and pretty much arbitrarily (that is, based on users’ best judgments), there is little feedback to check whether they are effective.

All of this absolutely guarantees that demand generation systems will produce suboptimal results. That would be annoying under any circumstances, but if the demand generation system takes on the primary responsibility for early relationship building, it’s more than merely annoying. It could destroy your company.

There is an alternative. Marketing systems can deploy automated statistical techniques to select messages, issue alerts and send leads to sales. Consumer marketers have used such methods for years with proven success. In addition to dealing with many more options than rules can handle, such systems can automatically learn from past results to improve their accuracy and adjust to changes in behaviors. Nicer still, marketers and salespeople can actually observe the success or failure of the decisions by watching objective criteria such as return visits and close rates. This last point is critical because it means marketers have a way to actually compare the value of decisions made by different systems. This means that vendors can meaningfully compete to offer the best decision-making capabilities, and marketers can choose the system that does a better job. And, unlike a feature that appeals to just a small fraction of marketers, better decisions are important to everyone. A system that could show it made better decisions would therefore have a very major competitive advantage.

So far, everything I’ve written here is just my private little theory. I haven’t heard any vendor, pundit or client suggest anything similar. This could well mean that I’m wrong; after all, I do like fancy automated systems with their cool bells and whistles. But I think maybe I’m right. Demand generation systems are getting more and more complicated, and something is needed to radically simply them before they collapse into chaos. Given that the stakes are nothing less than the sales process itself, allowing this to happen is unthinkable.

Eloqua Adds Free Implementation Offering

2009-05-12T09:16:00.004-04:00

On Monday, Eloqua announced a new free deployment service for its clients. This is part of a larger industry trend to offer free deployment. It follows last month’s free deployment offer from Eloqua reseller Pedowitz Group, which generated quite a bit of comment on this blog. The new service, called QuickStart, will also be delivered by Eloqua partners, giving them an opportunity to start a relationship that could lead to future paid business. Crafty.

Eloqua Senior Vice President Paul Teshima, who is in charge of post-sales support, said the new program includes system configuration, CRM data integration, setting up an email template, landing page, three-touch lead nurturing program and a lead scoring discussion. It is delivered remotely and can be completed in two days to two weeks, depending on how much time the client has available. Advance preparation involves filling out a survey and receiving (if not reading) simple documentation. Clients fill out a workbook during the sessions and are the consultant leaves behind a 90 day plan for future action.

Teshima said the new program was developed in response to customer requests for a fast way to get some immediate use from their systems. It is a subset of the company’s year-old SmartStart program, which take five days or longer but includes more extensive email set-up; data posting from an external Web form; deeper CRM integration including lead flow, activity-triggered sales alerts, lead assignment, and email opt-outs; creation of either a lead scoring or lead nurturing program; and several types of marketing assessments and planning. SmartStart involves on-site consulting and costs $3,000 to $8,000.

The difference in scope between QuickStart and SmartStart provides a useful reminder of the importance of digging into the details of vendor claims about deployment. The question isn’t whether it’s free or can be done in one day, but what’s included and how much your company must do in advance.

The reality is that a complete demand generation program is something you develop and expand over time. A good start is important but it’s only a start.

Another reality is that most companies need help with improving their programs. Teshima pointed to Eloqua's customer success managers, who meet with each client quarterly to review system usage and develop a plan for improvements. They are compensated solely on retention rates, so their focus is on making better use of existing components rather than selling new licenses.

Eloqua also has its professional services group and consulting partners to provide more hands-on assistance. Other vendors also provide such services, either with their own own staff or through partners.

My point is to recognize that you’ll very likely want to purchase such services to get the most value from your demand generation investment. If that sounds like bad news, I guess you don’t absolutely need to. And while you’re saving money on that, you can also change your car’s oil and cut your own hair to save money on mechanics and stylists.

Sarcasm aside, a few companies already have skills to deploy a demand generation system effectively, but most do not. The reason you pay money for these systems is because they’ll help you do a better job. Not investing in the training and consulting means you’ll get less value than you should. Of course, you still need to invest wisely, in the sense of getting the right training and consulting. And, yes, you can probably get some value even without outside help.

Training and consulting are ultimately business decisions about where you can spend money to get the greatest return on your investment. A small investment in using your system effectively is likely to be a wise choice.

Demand Generation Deployment Survey: Preparation Saves Two Months

2009-05-05T11:06:00.005-04:00

Summary: My survey of demand generation deployments found that some companies deploy many features immediately, while others take two or three months to reach the same stage. A fast start depends on ample preparation. A white paper on the Raab Guide site explores the results in detail.

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

I finished my detailed analysis of the demand generation deployment survey results yesterday and posted it to the resource library of the Raab Guide site. This turned out to be a major project (the analysis, not the posting) because I revisited the data from a company perspective. The analysis in my earlier blog posts looked at average deployment rates by feature, without relating those to particular companies.

As often happens, averages gave misleading results. For example, one of the original factoids that most impressed me was that 80% of features ever deployed are deployed by the second month. This seems to suggest that people deploy quickly and then are largely done. But analyzing data by company, I found a very wide divergence in behaviors: some companies deploy nearly all features immediately, while others start very slowly.

Specifically, I grouped the companies into four quartiles, ranked by the number of features they deployed during the first week. This figure itself varied hugely, from 0.6 features per company in the lowest quartile to 8.8 features/company in the highest. But what I found is the companies who start with very few features will add them steadily over time, while the ones who deploy many features immediately quickly reach the maximum. So, that average of 80% deployment by the second month really is a combination of rates ranging from 57% to 97% for the different quartiles.

table 10 [table numbers refer to tables in the paper]
% of final features deployed by time period (companies stay in original quartile over time)
quartile	first week	first month	second month	third month	later
1 (tortoise)	0.05	0.32	0.57	0.72	1.00
2	0.28	0.55	0.70	0.77	1.00
3	0.49	0.76	0.84	0.86	1.00
4 (hare)	0.68	0.93	0.97	0.97	1.00
average	0.39	0.66	0.80	0.84	1.00

In other words, we have a classic tortoise vs the hare race, with some fast starters and others moving slow but steady. Looking at the number of features per company rather than percentages, we see the tortoises (quartile 1) never quite catch up, but do greatly narrow the gap.

table 9
average features per company by quartile (companies stay in original quartile over time)
quartile	first week	first month	second month	third month	later
1 (tortoise)	0.6	3.4	6.1	7.7	10.7
2	3.0	6.0	7.7	8.3	10.9
3	5.6	8.7	9.7	9.9	11.5
4 (hare)	8.8	12.0	12.6	12.6	12.9
average	4.5	7.6	9.2	9.6	11.5

My fundamental interpretation is that the companies who deploy many features immediately have done their homework and are ready to go from day one, while those who start slowly did little advance preparation. The figures above suggest it takes the tortoises about three months to approach the initial deployment levels of the hares - so it seems this is the length of the delay from lack of preparation.

I actually tightened the analysis even more by looking separately at deployment rates for basic, advanced and optional features within each quartile. (Basic features are needed for simple email campaigns; advanced and optional features are more complex and less common. The paper describes the definitions in detail.) Looking just at the basic features, you'll see they're deployed sooner than average, and that even the tortoises finish implementing them by the second or third month. (You'll also note that, even among basic features, the tortoises never quite deploy as many as the hares.)

table E-1
cumulative features deployed by quartile (based on first period rank)
% of final features deployed by period							average features deployed
quartile	feature category	first week	first month	second month	third month	later	average features deployed
1 (tortoise)	basic	0.10	0.53	0.85	0.93	1.00	4.4
2	basic	0.52	0.79	0.88	0.90	1.00	4.7
3	basic	0.71	0.88	0.92	0.92	1.00	4.8
4 (hare)	basic	0.84	0.98	1.00	1.00	1.00	5.0
avg		0.56	0.80	0.91	0.94	1.00	4.7

The paper draws a number of other conclusions from the data and makes some helpful if generic recommendations (select the right system, prepare in advance, plan for expansion, test and measure). That's all good stuff but far from world-changing. What's really interesting is the details themselves - go ahead and dig into the paper and see what you find.

New Webinars and White Paper

2009-04-29T09:01:00.004-04:00

I have two Webinars and a newly published white paper you might find interesting:

Webinar Making the Right Start with Demand Generation, Thursday, April 30, 2:00 p.m. Eastern. This will discuss preparing for your new demand generation system, including requirements definition, vendor selection, and the initial deployment. I'll talk a bit more about results of the deployment survey. Sponsored by Marketo. Click here to register.

Webinar How to 'walk the walk' with the Sales 2.0 Approach to Aligning Sales & Marketing, Wednesday, May 13, 1:30 p.m. Eastern. This will be feature myself, Sales 2.0 guru Anneke Seley, and Genius.com CEO David Thompson in a discussion format. Sponsored by Genius.com. Click here to register.

White Paper When Best Practices Go Bad: New Rules for Sales and Marketing Management. Best practices that were valid just a few years ago are now obsolete. This paper shows why and offers some replacements. Also sponsored by Genius.com. Download here.

Demand Generation Implementation Survey: Half of Users Deploy Basic Features in One Week

2009-04-29T00:03:00.005-04:00

Summary: a small survey of demand generation users shows that more than half deployed basic demand generation features within one week, and about 75% within one month. More complicated features take longer, but in general, 80% of the features ever deployed are in place by the end of two months. This suggests that marketers are quickly gaining value from their systems, but also highlights the need for continued training to be sure they take advantage of all system capabilities.

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

Yesterday’s post described the responders to my online survey on demand generation implementation. Today we get to the main event: what people actually do.

Table 1 shows the actual responses, with the items ordered by % used (that is, how many respondents ultimately deployed a given function).

table 1
How soon after starting implementation did you first do...
first done:	first week	first month	second month	third month	later	never	total	% used
outbound email campaign	22	8	5	1	0	0	36	1.00
campaign response reporting	12	15	3	2	4	0	36	1.00
lead transfer to CRM	18	5	8	0	2	2	35	0.94
CRM integration / synchronization	23	4	2	1	3	3	36	0.92
landing page	19	9	2	0	2	4	36	0.89
lead scoring	12	7	3	0	10	4	36	.89
multi-step lead nurturing campaign	8	10	7	2	5	4	36	0.89
Web site analytics	14	7	6	2	2	4	35	0.89
Webinar campaign	5	13	5	1	6	5	35	0.86
campaign ROI reporting	7	11	3	0	8	6	35	0.83
data cleansing process	10	7	1	3	7	8	36	0.78
pay per click campaign reporting	9	5	1	2	6	12	35	0.66
Web page survey	3	6	5	1	6	15	36	0.58
email survey	2	2	6	1	7	16	34	0.53
combined	164	109	57	16	68	83	497	0.83

Looking at the table, we see:

- virtually everyone (more than 90%) does outbound email, campaign reponse reporting, lead transfer to CRM, and CRM integration. No surprises there.

- Just slightly fewer (80-90%) do landing pages, lead scoring, multi-step lead nurturing, Web site analytics, Webinars and campaign ROI reporting. I’m a bit surprised to see Webinars ranking so highly, given that support for them is rather limited in many demand generation systems. But they’re certainly a popular marketing tool, so I guess people will run them through their demand generation system regardless. The high utilization of other relatively advanced features is impressive (lead scoring, lead nurturing and ROI reporting), although perhaps to be taken with a grain of salt.

- Other features are less widely employed (53-78%), including data cleansing, pay per click (PPC) campaign reporting, and Web and email surveys. The latter three make sense: it’s hard to get PPC costs into a demand generation system, so many people probably don’t bother. Surveys are simply not that common, bearing in mind that most data is gathered through forms on landing pages. On the other hand, the relatively low utilization of data cleansing is a bit scary because I strongly suspect nearly everyone needs it. This may reflect the fairly limited data cleansing tools in most demand generation products.

So far so good. But the main purpose of the survey was to understand when and how quickly the different functions get deployed, to get a more nuanced view of the implementation process – and, in particular, see what marketers can realistically expect to accomplish in the first week.

Table 2 addresses this by calculating the cumulative fraction of responders who had deployed each function by each milestone (one week after implementation, one month, two months, etc.). The calculation excludes people who never deploy a given function, since we’re trying to understand how quickly the people who use a function deploy it.

table 2
cumulative deployment rate (base: ever deployed)
cumulative %	first week	first month	second month	third month	later	% used
landing page	0.59	0.88	0.94	0.94	1.00	0.89
outbound email campaign	0.61	0.83	0.97	1.00	1.00	1.00
CRM integration / synchronization	0.70	0.82	0.88	0.91	1.00	0.92
campaign response reporting	0.33	0.75	0.83	0.89	1.00	1.00
lead transfer to CRM	0.55	0.70	0.94	0.94	1.00	0.94
Web site analytics	0.45	0.68	0.87	0.94	1.00	0.89
multi-step lead nurturing campaign	0.25	0.56	0.78	0.84	1.00	0.89
Webinar campaign	0.17	0.60	0.77	0.80	1.00	0.86
data cleansing process	0.36	0.61	0.64	0.75	1.00	0.78
pay per click campaign reporting	0.39	0.61	0.65	0.74	1.00	0.66
campaign ROI reporting	0.24	0.62	0.72	0.72	1.00	0.83
Web page survey	0.14	0.43	0.67	0.71	1.00	0.58
lead scoring	0.38	0.59	0.69	0.69	1.00	0.89
email survey	0.11	0.22	0.56	0.61	1.00	0.53
combined	0.40	0.66	0.80	0.84	1.00	0.83

I’ve arbitrarily chosen to highlight when each function exceeds 75% utilization. This shows the relative deployment speed and presents a very interesting pattern:

- the basic demand generation activities needed for a simple email campaign (outbound email, landing pages, CRM integration and response reporting) are almost fully deployed in the first month . In fact, about half the users deploy them in the first week.

- Lead transfer to CRM doesn’t quite make the one month cut-off, but it’s also deployed by half the people in the first week, and almost everyone by the second month. Clearly moving leads to sales to a core demand generation function. The somewhat slower deployment, if it’s anything more than noisy data, might reflect the added time needed to set up a lead transfer process in cooperation with sales. You’ll note that the preceding four items were totally under marketing’s control.

- Web site analytics shows a pattern like lead transfer: nearly half the people do it immediately, but then there is a lag until it reaches nearly 90% deployment in month two. This might also reflect the need for help from the an outside department (whoever runs the company Web site). It might also reflect relatively low urgency, since other Web analytics tools are often in place. But bear in mind that detailed activity tracking of individual Web site visitors (not provided by traditional Web analytics) requires the demand generation tracking code to be installed.

- Multi-step lead nurturing and Webinar campaigns are both fairly complex projects, so it makes sense that deployment of these builds slowly and steadily through the first few months. We can probably infer that most marketers start with something simpler and then add these as they become more proficient with the systems.

- Most of the remaining items (data cleansing, PPC reporting, Web and email surveys) are relatively low priority, as reflected in their % used scores, so relatively slow deployment makes sense. The two exceptions are campaign ROI reporting and lead scoring, which have high ultimate usage rates (83% and 89%) but take a long time to reach those levels. Both are relatively complicated and require cooperation from external departments: ROI reporting needs revenue from sales and approved formulas from finance; lead scoring needs coordination with sales management. I think it’s reasonable to conclude that the importance of these items pushes marketers to deploy them, but their complexity and the need for external cooperation slows the implementation.

Is there a trend in deployment speed over time? I did some analysis of results by implementation year, and the pace does seem to be picking up. But it's a tricky analysis since more recent implementations haven't had time to deploy the longer-lead functions. I'll revisit this if time permits and let you know if I find anything.

Table 3 is similar to table 2, except that the fractions are calculated including never-deployed cases. This gives a more realistic view of the actual pace of deployment for different features. The sequencing is pretty much the same as table 2, with the notable exceptions of lead scoring and campaign ROI ranking somewhat higher.

table 3
cumulative deployment rate (including never deployed)
cumulative %	first week	first month	second month	third month	later	never
outbound email campaign	0.61	0.83	0.97	1.00	1.00	-
landing page	0.53	0.78	0.83	0.83	0.89	0.11
CRM integration / synchronization	0.64	0.75	0.81	0.83	0.92	0.08
campaign response reporting	0.33	0.75	0.83	0.89	1.00	-
lead transfer to CRM	0.51	0.66	0.89	0.89	0.94	0.06
Web site analytics	0.40	0.60	0.77	0.83	0.89	0.11
multi-step lead nurturing campaign	0.22	0.50	0.69	0.75	0.89	0.11
lead scoring	0.33	0.53	0.61	0.61	0.89	0.14
Webinar campaign	0.14	0.51	0.66	0.69	0.86	0.11
campaign ROI reporting	0.20	0.51	0.60	0.60	0.83	0.17
data cleansing process	0.28	0.47	0.50	0.58	0.78	0.22
pay per click campaign reporting	0.26	0.40	0.43	0.49	0.66	0.34
Web page survey	0.08	0.25	0.39	0.42	0.58	0.42
email survey	0.06	0.12	0.29	0.32	0.53	0.47
	0.33	0.55	0.66	0.70	0.83	0.17

Summary

Pulling back from these details, what I find really impressive is how quickly in general the features are deployed: 40% of the features ever deployed are deployed in the first week; two-thirds are deployed in the first month, and 80% by the second month. An optimist might argue that this shows marketers are quickly gaining value from their systems. A pessimist could say this shows that marketers learn a few things quickly and then stop.

The slow-but-steady deployment of complex processes like ROI reporting and lead scoring suggests that neither view is quite accurate, since marketers do add some features over time. It’s also true that this survey didn’t capture some of the more esoteric demand generation applications that marketers might add later. So it does seem there is at least some continued development after the initial implementation.

Circling back to the original question of how much marketers can expect to accomplish during the first week, the short answer is: quite a bit, actually. But it still takes a couple of months to get fully up to speed, and there is certainly a need for continued training to ensure you get the full value of any demand generation system. The job is far from done the day the implementation team walks out the door.

Demand Generation Implementation Survey - Background Results

2009-04-28T14:31:00.011-04:00

I've been having a dandy time analyzing the results of my Demand Generation Implementation Survey. Responses are still coming in but I thought I'd at least post some preliminary results to whet your appetite. Hopefully I'll be able to post a more substantive analysis tonight or tomorrow.

As of April 29, I've received 40 responses, of which I've discarded two as incomplete and two because they related to vendors I considered irrelevant (Zoho and Ad Giants PitchRocket). Obviously any survey based on 36 net responses (and self-selected at that) has little statistical value, but I still think the broad results are extremely interesting.

The survey was promoted on this blog and the Raab Guide site, but primarily via posts on Twitter. (Thanks to the many people who 'retweeted' the request). This introduces yet another source of sample bias. One measure of this is the distribution of vendors reported by the respondents, which clearly doesn't reflect the installed base of the industry. This distribution actually pleases me, since it means we have results from users of many different systems. (Obviously, however, the quantities are too small and sample bias too significant to break out results by vendor.)

nbr responses	vendor
8	Marketo
6	Eloqua
3	Genius.com
3	LoopFuse
3	Pardot
2	Market2Lead
2	Treehouse Interactive
1	eTrigue
1	Vtrenz (Silverpop)
7	No Response
36

Another intriguing bit of contextual information is the deployment date of the systems. Two respondents actually reported future dates -- I'd guess those were typos but, since responses were anonymous, I couldn't ask. There was actually another dated 6/01/2208, which I treated as 2008.

I was also curious to see the six responses for implementations during 3/09 and 4/09; obviously, these companies haven't gotten past their first or second month. Most of the answers for those entries reported features deployed within the first two months, or made the reasonable selection of 'later', so they could quite well be accurate. One repondent reported deployment on 4/24/09 (i.e., last week) but showed several features as deployed in month three. I assume represents their plans rather than reality. Fair enough.

In any case, the ten deployments in the first four months of 2009 (or 12 if you count the two future dates) and 12 in 2008 highlights the newness and fast growth of the demand generation industry. There were just five earlier deployments, including one for 1990, which is almost surely an error.

nbr responses	deployment date
1	10/09
1	8/09
3	4/09
3	3/09
1	2/09
3	1/09
12	2008
2	2007
2	2006
1	2005
1	1990
6	No Response
36

One final bit of more data, this more substantive: I asked how well their experience with deployment and their systems as a whole had met their expectations. Results strike me as extremely positive -- about two-thirds rated both experiences as better than expected, with just a bit more satisfaction with the systems than the implementation. Only a couple of responders felt things were worse than expected. Again, we have to consider sample bias. But even so, this seems to be a pretty happy set of campers.

I actually looked to see if there was any relationship between deployment year and satisfaction, and it newer customers may be a bit happier. But the numbers are very small, recency may also introduce some bias, and in any event even the earlier customers are highly satisfied. So I don't consider this more than a hint of what might be the case.

How would you rate your experience with...
%	better than expected	about as expected	worse than expected	total
system implementation	0.64	0.33	0.03	1.00
the system itself	0.67	0.28	0.06	1.00

How would you rate your experience with...
nbr responses	better than expected	about as expected	worse than expected	total
system implementation	23	12	1	36
the system itself	24	10	2	36

Demand Generation Implementation -- Take My Survey, Please!

2009-04-21T16:48:00.007-04:00

Update - 4/23/09: I have some preliminary results, but would still like more responses. Click here to take survey. One result of interest: how quickly people deploy the features they eventually use. I had expected people to start slow and add more features over time. Not so much. It seems that by the end of the first month, people have already used 2/3 of the features they will ever use. Interesting. Here is the cumulative percentage of total features deployed based on when they were first deployed:

time since system deployment	first week	first month	second month	third month	later
cumulative % of used features	38%	65%	81%	86%	100%

The recent discussion triggered by my post Pedowitz Group Offers Free Support for New Eloqua Clients raises an important question: Just how much can marketers realistically expect to accomplish during the initial stages of a demand generation system deployment?

The obvious answer is “it depends”, but that just begs the question, “Depends on what?” My own take is that the main factor is how well the marketers know what they want to do – that is, do they understand their data, know what marketing campaigns they want to set up, have the materials in hand and process flows defined, know what their scoring rules should be, etc.

In theory, those could be defined even before a marketing automation system is selected. You actually need a pretty good idea of the answers to select the right system. One might also think that most companies would already have these processes in place, even if they’re not formally defined. Yet my impression from industry vendors and consultants is that most deployments start with a fairly extended planning stage where companies either document their existing campaigns and processes or, more likely, define a large number of new ones.

This makes sense to a certain degree, since a demand generation system allows vastly more activity, specified in more detail, than was possible without one. A new system also presents an opportunity to revisit and update existing practices rather than simply reproducing them.

In any event, I’m curious about people’s actual experiences. I’ve created a little poll using SurveyMonkey – if you’ve implemented a demand generation system, please click below to fill it out. Of course, I’ll report on results when I have some. Thanks!

Click here to take survey

Lyzasoft: Independence for Analysts and Maybe Some Light on Shadow IT

2009-04-16T16:03:00.021-04:00

Long-time readers of this blog know that I have a deep fondness for QlikView as a tool that lets business analysts do work that would otherwise require IT support. QlikView has a very fast, scalable database and excellent tools to create reports and graphs. But quite a few other systems offer at least one of these.*

What really sets QlikView apart is its scripting language, which lets analysts build processing streams to combine and transform multiple data sources. Although QlikView is far from comparable with enterprise-class data integration tools like Informatica, its scripts allow sophisticated data preparation that is vastly too complex to repeat regularly in Excel. (See my post What Makes QlikTech So Good for more on this.)

Lyzasoft Lyza is the first product I’ve seen that might give QlikView a serious run for its money. Lyza doesn’t have scripts, but users can achieve similar goals by building step-by-step process flows to merge and transform multiple data sources. The flows support different kinds of joins and Excel-style formulas, including if statements and comparisons to adjacent rows. This gives Lyza enough power to do most of the manipulations an analyst would want in cleaning and extending a data set.

Lyza also has the unique and important advantage of letting users view the actual data at every step in the flow, the way they’d see rows on a spreadsheet. This makes it vastly easier to build a flow that does what you want. The flows can also produce reports, including tables and different kinds of graphs, which would typically be the final result of an analysis project.

All of that is quite impressive and makes for a beautiful demonstration. But plenty of systems can do cool things on small volumes of data – basically, they throw the data into memory and go nuts. Everything about Lyza, from its cartoonish logo to its desktop-only deployment to the online store selling at a sub-$1,000 price point, led me to expect the same. I figured this would be another nice tool for little data sets – which to me means 50,000 to 100,000 rows – and nothing more.

But it seems that’s not the case. Lyzasoft CEO Scott Davis tells me the system regularly runs data sets with tens of millions of rows and the biggest he’s used is 591 million rows and around 7.5-8 GB.

A good part of the trick is that Lyza is NOT an in-memory database. This means it’s not bound by the workstation’s memory limits. Instead, Lyza uses a columnar structure with indexes on non-numeric fields. This lets it read required data from the disk very quickly. Davis also said that in practice most users either summarize or sample very large data sets early in their data flows to get down to more manageable volumes.

Summarizing the data seems a lot like cheating when you’re talking about scalability, so that didn’t leave me very convinced. But you can download a free 30 day trial of Lyza, which let me test it myself.

Bottom line: my embarrassingly ancient desktop (2.8 GHz CPU, 2 GB RAM, Windows XP) loaded a 400 MB CSV file with about 430,000 rows in just over 6 minutes. That’s somewhat painful, but it does suggest you could load 4 GB in an hour – a practical if not exactly desirable period. The real issue is that each subsequent step could take similar amounts of time: copying my 400 MB set to a second step took a little over 2 minutes and, more worrisome, subsequent filters took the same 2 minutes even though they reduced the record count to 85,000 then 7,000 then 50. This means a complete processing flow on a large data set could run for hours.

Still, a typical real-world scenario would be to do development work on small samples, and then only run a really big flow once you knew you had it right. So even the load time for subsequent steps is not necessarily a show-stopper.

Better news is that rerunning an existing filter with slightly different criteria took just a few seconds, and even rerunning the existing flow from the start was much faster than the first time through. Users can also rerun all steps after a given point in the flow. This works because Lyza saves the intermediate data sets. It means that analysts can efficiently explore changes or extend an existing project without waiting for the entire flow to re-execute. It’s not as nice as running everything on a lightning-fast data server, but most analysts would find it gives them all the power they need.

As a point of comparison, loading that same 400 MB CSV file took almost 11 minutes with QlikView. I had forgotten how slowly QlikView loads text files, particularly on my limited CPU. On the other hand, loading a 100 MB Excel spreadsheet took about 90 seconds for Lyza vs. 13 seconds in QlikView. QlikView also compressed the 400 MB to 22 MB on disk and about 50 MB in memory, whereas Lyza more than doubled data to 960 MB of disk, due mostly to indexes. Memory consumption in Lyza rose only about 10 MB.

Of course, compression ratios for both QlikView and Lyza depend greatly on the nature of the data. This particular set had lots of blanks and Y/N fields. The result was much more compression than I usually see in QlikView and, I suspect, more expansion than usual in Lyza. In general, Lyza seems to make little use of data compression, which is usually a key advantage of columnar databases. Although this seems like a problem today, it also means there's an obvious opportunity for improvement as the system finds itself dealing with larger data sets.

What I think this boils down to is that Lyza can effectively handle multi-gigabyte data volumes on a desktop system. The only reason I’m not being more definite is I did see a lot of pauses, most accompanied by 100% CPU utilization, and occasional spikes in memory usage that I could only resolve by closing the software and, once or twice, by rebooting. This happened when I was working with small files as well as the large ones. It might have been the auto-save function, my old hardware, crowded disk drives, or Windows XP. On the other hand, Lyza is a young product (released September 2008) with only a dozen or so clients, so bugs would not be surprising. I'm certainly not ready to say Lyza doesn't have them.

Tracking down bugs will be harder because Lyza also runs on Linux and Mac systems. In fact, judging by the Mac-like interface, I suspect it wasn't developed on a Windows platform. According to Davis, performance isn’t very sensitive to adding memory beyond 1 GB, but high speed disk drives do help once you get past 10 million rows or so. The absolute limit on a 32 bit system is about 2 billion rows, a constraint related to addressable memory space (2^31 = about 2 billion) rather than anything peculiar to Lyza. Lyza can also run on 64 bit servers and is certified on Intel multi-core systems.

Enough about scalability. I haven’t done justice to Lyza’s interface, which is quite good. Most actions involve dragging objects into place, whether to add a new step to a process flow, move a field from one flow stage to the next, or drop measures and dimensions onto a report layout. Being able to see the data and reports instantly is tremendously helpful when building a complex processing flow, particularly if you’re exploring the data or trying to understand a problem at the same time. This is exactly how most analysts work.

Lyza also provides basic statistical functions including descriptive statistics, correlation and Z-test scores, a mean vs. standard deviation plot, and stepwise regression. This is nothing for SAS or SPSS to worry about; in fact, even Excel has more options. But it’s enough for most purposes. Similarly, data visualization is limited compared to a Tableau or ADVIZOR, but allows some interactive analysis and is more than adequate for day-to-day purposes.

Users can combine several reports onto a single dashboard, adding titles and effects similar to a Powerpoint slide. The report remains connected to the original workflow but doesn’t update automatically when the flow is rerun.

Intriguingly, Lyza can also display the lineage of a table or chart value. It traces the data from its source through all subsequent workflow steps, listing any transformations or selections applied along the way. Davis sees this as quickly answering the ever-popular question, “Where did that number come from?” Presumably this will leave more time to discuss American Idol.

Users can also link one workflow to another by simply dragging an object onto a new worksheet. This is a very powerful feature, since it lets users break big workflows into pieces and lets one workflow feed data into several others. The company has just taken this one step further by adding a collaboration server, Lyza Commons, that lets different users share workflows and reports. Reports show which users send and receive data from other users, as well as which data sets send and receive information from other data sets.

Those reports are more than just neat: they're documenting data flows that are otherwise lost in the “shadow IT” which exists outside of formal systems in most organizations. Combined with lineage tracing, this is where IT departments and auditors should start to find Lyza really interesting.

A future version of Commons will also let non-Lyza users view Lyza reports over the Web – further extending Lyza beyond the analyst’s personal desktop to be an enterprise resource. Add in the 64-bit capability, an API to call Lyza from other systems, and some other tricks the company isn’t ready to discuss in public, and there’s potential here to be much more than a productivity tool for analysts.

This brings us back to pricing. If you were reading closely, you noticed that little comment about Lyza being priced under $1,000. Actually there are two versions: a $199 Lyza Lite that only loads from Microsoft Excel, Access and text files, and the $899 regular version that can also connect to standard relational databases and other ODBC sources and includes the API.

This isn’t quite as cheap as it sounds because these are one year subscriptions. But even so, it is an entry cost well below the several tens of thousands of dollars you’d pay to get started with full versions of QlikView or ADVIZOR, and even a little cheaper than Tableau. The strategy of using analysts’ desktop as a beachhead is obvious, but that doesn’t make it any less effective.

So, should my friends at QlikView be worried? Not right away – QlikView is a vastly more mature product with many features and capabilities that Lyza doesn’t match, and probably can’t unless it switches to an in-memory database. But analysts are QlikView’s beachhead too, and there’s probably not enough room on their desktops for both systems. With a much lower entry price and enough scalability, data manipulation and analysis features to meet analysts’ basic needs, Lyza could be the easier one to pick. And that would make QlikView's growth much harder.

----------------------------

*ADVIZOR Solutions and Tableau Software have excellent visualization with an in-memory database, although they’re not so scalable. PivotLink, Birst and LucidEra are on-demand systems that are highly scalable, although their visualization is less sophisticated. Here are links to my reviews: ADVIZOR , Tableau, PivotLink, Birst and LucidEra.

LeadLife Mixes Advanced and Simple Features

2009-04-14T16:15:00.005-04:00

I have my little checklist of features to define whether a demand generation system is suited for simple or complex marketing programs. (You'll find most of the list in our report on Vendor Usability Scores on the Raab Guide site.) Sadly, some vendors didn't get the memo and have built products that straddle my categories.

Consider LeadLife. It offers many features that appeal to large marketing departments: fine-grained user rights management, rule-based content selection, multiple scores per lead, central processes to score leads and transfer them to sales, APIs to integrate with external Web forms, campaign cost tracking, detailed ROI reporting, and project management with tasks. But it lacks other features that are equally advanced: approval workflows, templates linked to deployed content, split tests, campaign actions to update data values, support for channels beyond email, and, most important, any way to direct leads from one campaign to another.

One way to explain this particular mix of features is to note that LeadLife’s founders previously sold sales automation software. Many of LeadLife's strengths and weaknesses are typical for sales automation systems.

Of course, Joe the Marketer won't care about my classification scheme. LeadLife president Lisa Cramer says the system is targeted at mid-size firms (which she defines as 25 or more employees), not large enterprises, and she should know. Still, it’s probably significant that “flexibility,” not simplicity, was the first term she used to describe the system. Her second term was “intuitive”, so she wasn’t saying the system is designed only for expert users. To me, those terms reflect an ambition to support more than just the simplest marketing programs.

I did in fact find the user interface in LeadLife to be particularly well designed. It follows some principles I first heard many years ago, the gist of which was to divide the screen into fixed regions that always display the same type of information (e.g., navigation folders on the left, detail data in the center) and avoid windows that pop up and disappear in random locations. Today that looks a bit old-fashioned, but it really does make things easier because users always know what to expect. On the other hand, LeadLife has inexplicably chosen a green-based color scheme that can only be described as institutional.

I’ll forgive them the color scheme because LeadLife had the good sense to agree with me on the much more important issue of flow-chart vs. step-based campaign design. LeadLife campaigns are defined strictly as a list of steps, without any branching at all – not even the if/then/else logic that some vendors embed within a single step. In fact, Cramer told me that LeadLife originally tried a flow chart approach, but discarded it because clients got lost. My point exactly.

Notwithstanding the austere simplicity of its campaign flows, LeadLife is a very powerful system. Emails, landing pages and Web surveys all support rule-driven content selection, which lets the system send different messages in different situations even without conventional branching. Rules can dynamically select survey questions, so a single survey page can ask the same visitor different questions over time. Users build emails and Web pages by positioning objects (text, data entry fields, images, etc.) in layers. This allows more flexibility than conventional methods, although it also opens new opportunities for errors. The system incorporates SpamAssassin spam scoring and is exploring how to add preview rendering for different ISPs. Marketing materials, including downloadable documents as well as emails and Web pages, can be shared across several campaigns.

The campaigns themselves can contain multiple events such as trade shows, Webinars, newsletters and surveys. Leads can be assigned to an event with a list or posted to the event from a Web form. The system keeps track of all events each lead is linked to and uses events as its primary vehicle for marketing performance measurement.

Leads can also be added to a campaign through queries against the system database. Queries can reference pretty much any data in the system, including survey responses and activity details. The query builder is quite sophisticated, allowing queries to incorporate multiple data elements and to scan for multiple values and substrings. Advanced users can view and modify the underlying SQL if they wish. The same interface is used to set up selections, campaign conditions, and lead scoring.

Once a query is created, the user can export the selected records, send them an email, or update data on their records. Queries execute continuously as data changes. This lets a campaign attached to a query react immediately as new members become qualified.

Users can combine a sequence of steps into a single campaign. Each step is either a query condition, which must be met for the lead to continue through the sequence, or an action. Conditions can also define waiting periods in multi-step campaigns. The only available actions are different types of emails. Cramer said that LeadLife originally allowed other actions, but removed these for simplicity. The company is considering adding some new actions, including one to direct leads from one campaign to another.

The system already provides an unusually rich set of administration functions. Campaign events can be assigned expenses, goals, budgets and activities such as notes, appointments, and tasks. Task attributes can include due dates, responsible individuals, billable time, and status. Access to system functions is managed by user groups, and at last count could be tailored to control 656 specific capabilities.

Lead scoring is also quite sophisticated. Users set up lead scoring rules, which run outside of campaigns but can be limited to members of a particular campaign or event. Each rule contains a query condition and number of points earned for meeting that condition. Users can also define several scores per lead and specify which score a given rule will update. The system can be set to score a rule just once, thereby capping the number of points derived from a particular type of event. Users can also define “decay” rules that reduce a lead’s total score after a specified period without activity. The system updates scores for each lead every few minutes.

Users also define one or more scoring processes, which can assign lead status (new, open, contacted, qualified, etc.) and execute actions when leads meet status and score thresholds. Actions can send the lead to the CRM system, assign the lead to an owner, and send the owner an email. LeadLife has existing integration Salesforce.com and could connect with other CRM systems via the system API. Users can define up to sixteen user-assigned fields on the lead record, plus an unlimited number of survey responses.

LeadLife provides full Web analytics, fueled by tracking codes on vendor-created and external Web pages. Campaign reports show activity counts (emails sent, opens, links clicked, etc.) and let users drill into the reports to see the individuals, and then drill further to see all activities for a selected individual. Other reports can list individuals by status, by products purchased, by contact recency, and other attributes. The system calculates ROI for each event within a campaign, drawing on the cost figures entered by the user and on revenues imported from CRM opportunity records. Revenue is attached to the earliest event associated with a lead linked to the opportunity.

Pricing is based on primarily on email volume. It starts at $500 per month for 1,500 emails and reached $1,395 for a more practical 25,000 emails. Each price includes all system features, unlimited Web volume, and five users. Additional users cost $10 to $30 per month depending on the user type. There are no additional fees for set-up, implementation or training. A quick implementation program aims at executing the client’s first campaign in three days. The company requires a one year contract but clients can leave within the first 90 days without further payment.

LeadLife was established in 2006 and released its first version in September 2008. The company now has about 20 clients.

PivotLink: Flexible On-Demand Business Intelligence

2009-04-12T15:07:00.004-04:00

I did a Webinar recently (click here for slides) about on-demand business intelligence systems, sponsored by Birst. It boiled to two key points:

- most of the work in business intelligence is in assembling the underlying database, even though the term “BI systems” often refers to the query and reporting tools (a.k.a. the “presentation layer”).

- vendor strategies to simplify BI include: using simpler interfaces, automation or pre-built solutions to make conventional technology easier; or using inherently more efficient alternative technologies such as in-memory and columnar databases.

Naturally, the full Webinar was jammed with much other wisdom (you missed Time-Traveling Elvis and the Reese’s Peanut Butter Cup Fallacy). But those two points alone provide a useful framework for considering business intelligence systems in general.

I bring this up because I’m finally writing about PivotLink, which I looked at more than a month ago. It turns out that my framework helps to put PivotLink into perspective.

Here’s the thing. PivotLink is an on-demand business intelligence product. Its most interesting technical feature is an in-memory columnar database. If you follow the industry, you know that type of database is about the geek-sexiest thing out there right now. I myself find it totally fascinating and had a grand time digging into the details.

But the rest of the world doesn’t care if it’s geek-ilicious:* they want to know how PivotLink can help them. Here’s where the framework comes in, since it clarifies what PivotLink does and doesn’t do. Or, to put that a bit more formally, it shows which elements of a complete business intelligence system PivotLink provides.

The answer to that being, PivotLink works largely at the presentation layer. It can import data from multiple sources and join tables on common keys. But it won’t do the complicated transformations and fuzzy matching needed for serious data integration. This means that PivotLink must either work with data that's already been processed into a conventional data warehouse or can be usefully analyzed in its original state.

There’s actually more of this naturally-analyzable data than you might think. Purchase transactions, a common source for PivotLink, are a good example. The obstacle to working with these has often been the size of the data sets, which meant lots of expensive hardware and lots of (how to put this delicately?) deliberately-paced IT support. These are exactly the barriers that on-demand systems overcome.

This brings us back to PivotLink's technology. In-memory, columnar databases are especially well suited for on-demand business intelligence because they compress data tightly (10% of the original volume. according to PivotLink), read only the columns required for a particular query (providing faster response) and don’t require need special schemas or preaggregated data cubes (requiring less skill to set up and modify).

But even columnar systems vary in their details. PivotLink sits towards the flexible end of the spectrum, with support for incremental updates, many-to-many table relationships, and abilities to add new columns and merge data along different query paths without reloading it. The system also allows calculations during the data load and within queries, caches data in memory and further compresses it after an initial query, and supports user- and group-level security at the row, column or individual cell levels. Not all column-based systems can say the same.

On the other hand, PivotLink does not support standard SQL queries and doesn’t run on a massively parallel (“shared nothing”) architecture. Both limits are typical of older columnar databases, a reminder that PivotLink began life in 1998 as SeaTab Software. Although shared-nothing architectures are generally more scalable, PivotLink is already running data sets with more than 10 billion rows in its current configuration. Response is very fast: according to the company, one client with several billion rows of point-of-sale data runs a nightly update and then executes a summary report in under one minute. Still, PivotLink recognizes the benefits of shared-nothing systems and plans to move to that architecture by the end of 2009.

Lack of SQL compatibility means users must rely on PivotLink’s tools for queries and reports. These let administrators import data from CSV, TXT and Excel files and map them to PivotLink tables. (The actual storage is columnar, with different compression techniques applied to different data types. But to the user, the data looks like it’s organized in tables.) The system reads the source data and makes suggestions about field types and names, which the user can accept or revise.

Users then define queries against the tables. Each query contains a selected set of columns, which are identified either as a header (i.e., dimension) or metric. When queries involve multiple tables, the user also specifies the columns to join on. Each report is written against one query.

The distinction between tables and queries is important in PivotLink, because it provides much of the system’s flexibility. The same column can be a dimension in one query and a metric in another, and the same tables can be related on different keys in different queries. All this happens without reloading the data or running any aggregations. The metadata used to build reports is defined by the associated query, not the underlying tables.

Reports are built by dragging headers and metrics into place on a grid, defining drill paths, and selecting tabular or chart formats. Reports can also rank and sort results and select the top or bottom rows for each rank. For example, a report could rank the top ten stores per region by revenue. Users can combine several reports into a dashboard.

End-users can apply filters and drill into the selected elements within a report. However, PivotLink does not apply filters for one report to the rest of the dashboard, in the way of QlikView or ADVIZOR. This feature is also on the agenda for 2009.

PivotLink clients can import data, define queries and build reports without help from the company. PivotLink said it takes a couple of days to train an administrator to load the data and build queries, a day or two to train a user to build reports and dashboards, and minutes to hours to learn to use the reports. Based on what they showed me, that sounds about right. You can also find out for yourself by signing up for a free trial.

Pricing of PivotLink is based on the size of the deployment, taking into account data volume and types of users. It starts around $3,000 per month for 50 million rows. When I spoke with the company in early March, they had about 60 clients supporting over 6,000 users, and had doubled their volume in the past year.

-----------------------------------------------------------------------------------------
* geek-alicious? is it possible to misspell a word that doesn’t exist?