0 More Details on Enpocket

I had a brief but enlightening chat last week with Mike Baker, CEO of Enpocket. Mike clarified that Enpocket is as marketing services agency, which means its software is only used for its own services clients. He also said that Enpocket does indeed offer interactive messaging capabilities like voting, polling, surveys, coupons, store finders and such, even though its Web site may not highlight the fact. Mike called such services “table stakes” for companies who want to compete in this field, which is why they’re barely worth mentioning. (I’ve corrected my April 3 post on mobile marketing systems to reflect this.)

But our conversation did confirm that the primary focus at Enpocket is on advertising, rather than messaging. According to Mike, three things make them unique:

- multimodal transmission, which includes ads via SMS (text messages), MMS (multi-media messages), and insertion into other applications such as games, downloads, and video.

- a database marketing focus, using customer profiling to target ads. These profiles include previous transactions known to the cellular carriers, as well as demographics and other behaviors.

- propensity scores that identify the most appropriate offers for each customer. These are updated daily and made available to the ad server, which uses them to select content.

0 Beware Distributed Analytics (You Read It Here First)

What might be called the “standard model” of business intelligence systems boils down to this: many operational sources feed data into a central repository which in turn supports analytical, reporting and operational systems. A refinement of the model divides the central repository into a data warehouse structured for analysis and an operational data store used for immediate access. (Come to think of it, I don’t see the term “operational data store” used much anymore—have I just stopped looking or did I miss the memo that renamed it?)

No one has been attacking this model directly (unless I’ve missed yet another memo), but it does seem to be under some strain. Specifically, much more analytical power is being built into the operational systems themselves, reducing the apparent need for centralized, external business intelligence functions. Examples abound:

- channel-specific analytical systems for Web sites and call centers (see last Thursday's post).
- more extensive business intelligence capabilities built into enterprise software systems like SAP
- rule- and model-driven interaction management components built into customer touchpoint systems
- more advanced testing functions built into operational processes (okay, we haven’t seen that one yet, but I did write about it yesterday).

Generally speaking, more analytical capability in operational systems is a Good Thing. But if these capabilities replace functions that would be otherwise provided by a centralized business intelligence system, they reduce the incremental value provided by that central system and therefore make it harder to justify. The resulting fragmentation of analytics is preferred by many departments anyway because it increases their autonomy.

This fragmentation is a Bad Thing, especially from the perspective of customer experience management. Fragmentation leads to inconsistent customer treatments and to decisions that are optimal for the specific department but not the enterprise as a whole.

The problem is that analysts, consultants, journalists and similar entertainers are always looking for new trends to champion. (Yes that includes me.) So coining a phrase like “distributed analytics” and calling it the Next Big Thing is immensely attractive. (FYI, a Google search on “distributed analytics” finds 64 hits, compared with 410,000 for “predictive analytics”. So the term is definitely available.)

We must all resist that temptation. A consolidated, centralized data view may seem old-fashioned, but it is still necessary. (Whether the data must be physically consolidated is quite another story—there’s nothing wrong with federated approaches.) By all means, analytical capabilities should be extended throughout the organization. But everyone should be working with the same, comprehensive information so their independent decisions still reflect the corporate perspective.

0 Operational Systems Should Be Designed with Testing in Mind

A direct marketing client pointed out to me recently that it can be very difficult to set up tests in operational systems.

There is no small irony in this. Direct marketers have always prided themselves on their ability to test what they do, in pointed contrast to the barely measurable results of conventional media. But his point was well taken. Although it’s fairly easy to set up tests for direct marketing promotions, testing customer treatments delivered through operational systems such as order processing is much more difficult. Those systems are designed with the assumption that all customers are treated the same. Forcing them to treat selected customers differently can require significant contortions.

This naturally led me to wonder what an operational system would look like if it had been designed from the start with testing in mind. A bit more reflection led me to the multivariate testing systems I have been looking at recently—Optimost, Offermatica, Memetrics, SiteSpect, Vertster. These take control of all customer treatments (within a limited domain), and therefore make delivering a test message no harder or easier than delivering a default message. If we treated them as a template for generic customer treatment systems, which functions would we copy?

I see several:

- segmentation capabilities, which can select customers for particular tests (or for customized treatment in general). You might generalize this further to include business rules and statistical models that determine exactly which treatments are applied to which customers: when you think about it, segmentation is just a special type of business rule.

- customer profiles, which make available all the information needed for segmentation/rules and hold tags that identify customers already tagged for a particular test

- content management features, which make existing content available to apply in tests. Some systems provide content creation as well, although I think this is a separate specialty that should usually remain external.

- test design functions, that help users create correctly-structured tests and then link them to the segmentation rules, data profiles and content needed to execute them. These design functions also include parameters such as date ranges, preview features for checking that they are set up correctly, workflow for approvals, and similar administrative features.

- reporting and analysis, so users can easily read test results, understand their implications, and use the knowledge effectively.

I don’t mean to suggest that existing multivariate testing systems should replace operational systems. The testing systems are mostly limited to Web sites and control only a few portions of a few pages within those sites. They sit on top of general purpose Web platforms which handle many other site capabilities. Using the testing systems to control all pages on a site without an underlying platform would be difficult if not impossible, and in any case isn’t what the testing systems are designed for.

Rather, my point is that developers of operational systems should use the testing products as models for how to finely control each customer experience, whether for testing or simply to tailor treatments to individual customer needs. Starting their design from the perspective of creating a powerful testing environment should enable them to understand more clearly what is needed to build a comprehensive solution, rather than trying to bolt on particular capabilities without grasping the underlying connections.

0 Mobile Marketing Systems Can't Stand Alone For Long

My recent exploration of mobile marketing systems left me wondering whether why the enterprise marketing systems have not jumped to service this market. By “enterprise marketing” vendors, I mean Unica, SAS, Teradata, Alterian, SmartFocus and the like. Their products can already create messages in SMS and (presumably) other mobile formats. But so far as I know, they lack the advanced mobile capabilities for ad serving, voting and polling, downloads such as ring tones, and user-initiated content uploads. It probably wouldn’t be too hard to add such features through alliances or purchase of a mobile marketing specialist. No doubt this will happen: they all added email in a similar fashion when it became important.

But these vendors’ priorities have clearly been elsewhere. They have been competing based on advanced analytics including segmentation, scoring and optimization; marketing administration including budgeting, project management and content libraries; marketing performance measurement; and specialized operational features such as distributed access and lead management. What these features share is that they support activities across many channels. Providing the most advanced features in a single channel, such as mobile, has not been the vendors’ goal.

You’ll immediately recognize this as the classic strategy of integrated suite vendors seeking to overwhelm best-of-breed specialists. Over time, the integrated products tend to win, although they are always threatened by still bigger fish: in the case of the customer management vendors, these would be enterprise software vendors like Oracle, SAP, and perhaps Infor.

It’s hard to see how the mobile marketing vendors can survive once mobile marketing attracts the attention of the enterprise marketing management systems. The mobile vendors already are trespassing on enterprise marketing turf by setting up their own functions for permissions tracking, campaign definition, customer profiles, real time interactions, and content management—capabilities needed to execute mobile marketing projects, but which really should belong in an enterprise system that can share them across multiple channels. Right now, mobile marketing is new enough that the specialist vendors’ unique expertise can justify working with them independently. But this is a very temporary situation. As mobile marketing becomes more widely understood, it will be assimilated into other marketing activities and the specialized systems will vanish.

0 Skytide Simplifies Customer Experience Analysis

Last Thursday’s post made a passing reference to Skytide , a vendor which may not be familiar to many readers. Here’s a bit more information, based on conversations with the company.

Essentially, Skytide extracts and aggregates user-selected elements from large data streams, such as Web logs or call center history files. The aggregated data is stored in a multi-dimensional structure where it can be accessed by the Skytide analyst’s workbench or by third party tools through JDBC, MDX and the system’s own API.

So far this sounds like other multi-dimensional database products. What sets Skytide apart is its use of XML and the Xpath language to access the source data. This allows it to read both conventional structured databases and unstructured data. (All sources, including the structured ones, are defined to the system as XML.) It also simplifies creation of the multi-dimensional models themselves by automating chores that are otherwise done manually, such as defining the members of each dimension.

Another of Xpath’s virtues is working with relations among “sibling” records (the equivalent of rows in a conventional database), which is difficult in a set-based language like SQL. This allows Skytide to report on paths through a Web session or phone system. Xpath also lets Skytide set up overlapping access hierarchies to the stored data, which is difficult in conventional multi-dimensional systems. On a practical level, alternative hierarchies greatly speed system deployment because users need not agree on a single data structure.

With any system that works by extracting data from source systems, a key question is the time required to read and store the reformatted data. Skytide says they do this nearly as fast as the data can be read—adding just ten to twenty percent on top of the i/o time. The input need not be presorted, since the XML tags and Xpath avoid the need for any physical storage hierarchy.

Skytide was launched in 2003 and has since matured to handle huge data volumes—the largest installations scan ten terabytes of source data per day. The company has been growing slowly and quietly with limited financing, although its dozen clients include impressive names like IBM, Sun and Akamai. It is now seeking additional funding to allow faster expansion.

Skytide is ultimately a database engine, not an analytics application. But it makes assembling cross channel data easy and supports analyses that are otherwise difficult. So it could provide a valuable platform for companies seeking to improve their customer experience analysis capabilities.