0 New Webinars and White Paper

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.

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

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.

0 Demand Generation Implementation Survey - Background Results

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

0 Demand Generation Implementation -- Take My Survey, Please!

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

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

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.