Saturday, July 25, 2020

Don't Misuse Proof of Concept in System Selection

Call me a cock-eyed optimist, but marketers may actually be getting better at buying software. Our research has long shown that the most satisfied buyers base their selection on features, not cost or ease of use. But feature lists alone are never enough: even if buyers had the knowledge and patience to precisely define their actual requirements, no set of checkboxes could capture the nuance of what it’s actually like to use a piece of software for a specific task. This is why experts like Tony Byrne at Real Story Group argue instead for defining key use cases (a.k.a. user stories) and having vendors demonstrate those. (If you really want to be trendy, you can call this a Clayton Christensen-style “job to be done”.)

In fact, use cases have become something of an obsession in their own right. This is partly because they are a way of getting concrete answers about the value of a system: when someone asks, “What’s the use case for system X”, they’re really asking, “How will I benefit from buying it?” That’s quite different from the classic definition of a use case as a series of steps to achieve a task. It’s this traditional definition that matters when you apply use cases to system selection, since you want the use case to specify the features to be demonstrated. You can download the CDP Institute’s use case template here.

But I suspect the real reason use cases have become so popular is that they offer a shortcut past the swamp of defining comprehensive system requirements. Buyers in general, and marketers in particular, lack the time and resources to create complete requirements lists based on their actual needs (although they're perfectly capable of copying huge, generic lists that apply to no one).  Many buyers are convinced it’s not necessary and perhaps not even possible to build meaningful requirements lists: they point to the old-school “waterfall” approach used in systems design, which routinely takes too long and produces unsatisfactory results. Instead, buyers correctly see use cases as part of an agile methodology that evolves a solution by solving a sequence of concrete, near-term objectives.

Of course, any agile expert will freely admit that chasing random enhancements is not enough.  There also needs to be an underlying framework to ensure the product can mature without extensive rework. The same applies to software selection: a collection of use cases will not necessarily test all the features you’ll ultimately need. There’s an unstated but, I think, implicit assumption that use cases are a type of sampling technique: that is, a system that meets the requirements of the selected use cases will also meet other, untested requirements.   It’s a dangerous assumption. (To be clear: a system that can’t support the selected use cases is proven inadequate. So sample use cases do provide a valuable screening function.)

Consciously or subconsciously, smart buyers know that sample use cases are not enough. This may be why I’ve recently noticed a sharp rise in the use of proof of concept (POC) tests. Those go beyond watching a demonstration of selected use cases to actually instal a trial version of a system and seeihow it runs. This is more work than use case demonstrations but gives much more complete information.

Proof of concept engagements used to be fairly rare. Only big companies could afford to run them because they cost quite a bit in both cash (most vendors required some payment) and staff time (to set up and evaluate the results). Even big companies would deploy POCs only to resolve specific uncertainties that couldn’t be settled without a live deployment.

The barriers to POCs have fallen dramatically with cloud systems and Software-as-a-Service. Today, buyers can often set up a test system with a just a few mouse clicks (although it may take several days of preparation before those clicks will work). As a result, POCs are now so common that they can almost be considered a standard part of the buying process.

Like the broader application of use cases, having more POCs is generally a good thing. But, also like use cases, POCs can be applied incorrectly.

In particular, I’ve recently seen several situations where POCs were used as an alternative to basic information gathering. The most frightening was a company that told me they had selected half a dozen wildly different systems and were going to do a POC with each of them to figure out what kind of system they really needed.

The grimace they didn’t see when I heard this is why I keep my camera off during Zoom meetings. Even if the vendors do the POCs for free, this is still a major commitment of staff time that won’t actually answer the question. At best, they’ll learn about the scope of the different products. But that won’t tell them what scope is right for them.

Anther company told me they ran five different POCs, taking more than six months to complete the process, only to later discover that they couldn’t load the data sources they expected (but hadn’t included in their POCs). Yet another company let their technical staff manage a POC and declare it successful, only later to learn the system had been configured in a way that didn’t meet actual user needs.

You’re probably noticing a dreary theme here: there’s no shortcut for defining your requirements. You’re right about that, and you’re also right that I’m not much fun at parties. As to POCs, they do have an important role but it’s the same one they played when they were harder to do: they resolve uncertainties that can’t be resolved any other way.

For Customer Data Platforms, the most common uncertainty is probably the ability to integrate different data sources.  Technical nuances and data quality are almost impossible to assess without actually trying to load each system.  Since these issues have more to do with the data source than the CDP, this type of POC is more about CDP feasibility in general than CDP system selection. That means you can probably defer your POC until you’ve narrowed your selection to one or two options – something that will reduce the total effort, encourage the vendor to learn more about your situation, and help you to learn about the system you’re most likely to use.

The situation may be different with other types of software. For example, you might to test q wide variety of predictive modeling systems if the key uncertainty is how well their models will perform. That’s closer to the classic multi-vendor “bake-off”.  But beware of such situations: the more products you test, the less likely your staff is to learn each product well.

With a predictive modeling tool, it’s obvious that user skill can have a major impact on results. With other tools, the impact of user training on outcomes may not be obvious. But users who are assessing system power or usability may still misjudge a product if they haven’t invested enough time in learning it.  Training wheels are good for beginners but get in the way of an expert. Remember that your users will soon be experts, so don’t judge a system by the quality of its training wheels.

This brings us back to my original claim.  Are marketers really getting better at buying software?  I’ll stand by that and point to broader use of tools like use cases and proof of concepts as evidence. But I’ll repeat my caution that use cases and POCs must be used to develop and supplement requirements, not to replace them. Otherwise they become an alternate route to poor decisions rather than
guideposts on the road to success.

Monday, April 27, 2020

Here's a Game about Building Your Martech Stack

TL;DR: you can play the game here.

I’ve recently been running workshops to help companies plan deployment of their Customer Data Platforms. Much of the discussion revolves around defining use cases and, in particular, deciding which to deliver first. This requires balancing the desire to include many data sources in the first release of the system against the desire to deliver value quickly. The challenge is to find an optimal deployment sequence that starts with the minimum number of sources needed for an important use case and then incrementally adds new sources that support new use cases. I’ve always found that an intriguing problem although I’ll admit few others have shared my fascination.

As coronavirus forces most marketers to work from home, I’ve also been pondering ways to deliver information that are more engaging than traditional Webinars and, ahem, blog posts. The explosion of interest in games in particular seems to offer an opportunity for creative solutions.

So it was fairly natural to conceive of a game that addresses the deployment sequence puzzle. The problem seems like a good candidate: governed by a few simple dynamics that become interestingly complex when they interact. The core dynamic is that one new data source may support new multiple use cases, while different combinations of sources support different use cases. This means you could calculate the impact of different sequences to compare their value.

Of course, some use cases are worth more than others and some sources cost more to integrate than others; you also have to consider the availability of the CDP itself, of central analytical and campaign systems, and of delivery system that can use the outputs. But for game purposes, you could simplify matters to assume that each system costs the same and each use case has the same value. This still leaves in place the core dynamic of balancing the cost of adding one system with the value of enabling multiple use cases with that system.

To make things even more interesting and realistic, you could add the fact that some use cases are possible with a few systems but become more valuable as new systems come online.  It might be that their data adds value – say, by making predictions more accurate – or because they enable delivery of messages in more channels.

In the end, then, you end up with a matrix that crosses a list of systems (data sources, CDPs, analytics, campaigns management, and delivery systems) against a list of use cases. Each cell in the matrix indicates whether a particular system is essential or optional for a particular use case. Value for any given period would include: the one-time cost of adding a new system; the recurring cost of operating active systems, and the value generated by each active use case.  That use case value would include a base value earned by running the use case plus incremental value from each optional system. Using red to indicate required systems and grey to indicate optional systems, the matrix looks like this:

The game play would then be to select system one at a time, calculate the value generated as the period revenue, and then repeat until you run out of systems to add.  Sometimes you’d select systems because they made a new use case possible, sometimes you’d select because they added optional value to already-active use cases, and sometimes you’d select a system to make possible more use cases in the future. Fun!

I then showed this to a professional game designer, whose response was “you may have found the least fun form factor imaginable: the giant data-filled spreadsheet. I'm kind of impressed.”

Ouch, but he had a point. I personally found the game to be playable using a computer to do the calculations but others also found it impenetrable. A version using physical playing cards was clearly impossible.

So, after much pondering, I came up with a vastly simplified version that collapsed the 19 systems in the original model into three categories, and only required each use case to have a specified number of systems in each category. I did keep the distinction between required and optional systems, since that has a major impact on the effectiveness of different solutions. I also simplified the value calculations by removing system cost, since that would be the same across all solutions so long as you add one system per period.

The result was a much simpler matrix, with just six columns (required and optional counts for each of the three system types) and the same number of rows per use case (22 in the example). I built this into a spreadsheet that does the scoring calculations and stores results for each period, so the only decision players need to make in any turn is which of the three system types to select. Even my game designer grudgingly allowed that it “made sense pretty quickly” and was “kinda fun”. That’s about all the enthusiasm I can hope for, I suspect.

I’ve put a working version of this in a Google spreadsheet that you can access here.

Go ahead and give it a play – it just takes a few minutes to complete once you grasp how it works (put a ‘1’ in the column for each period to select the class of system to add during that period). Most of the spreadsheet is write-protected but there’s a leaderboard if you can beat my high score of 1,655.

Needless to say, I’m interested in feedback. You can reach me through LinkedIn here.
Although this started as a CDP planning exercise, it’s really a martech stack building game, something I think we can all agree the world desperately needs right now. I also have worked out a physical card game version that would have a number of additional features to make games more interesting and last longer. Who wants to play?

Thursday, April 02, 2020

A Dozen Market Research Studies on COVID-19 Business Impact

This sums it up.  From Bank of America via Twitter but I can't find a link to the original.
As marketers finish their initial emergency adjustments to coronavirus lockdowns, they are starting to think about longer-term plans. While the shape of things to come is impossible to guess, reporting on industry changes has become a marketing trend of its own. Here are a dozen-plus studies I’ve seen in the past week, most of which are on-going.

Retail Behavior Data

Adobe this week launched their Digital Economy Index, a long-term project that gained unexpected immediate relevance. The index draws on trillions of Web visits tracked by Adobe systems to construct a digital consumer shopping basket tracking a mix of products including apparel, electronics, home and garden, computers, groceries, and more. The headline finding of the initial report would have been a continuing drop in prices driven by electronics, but this was overshadowed by short-term changes including a 225% increase in ecommerce from March 1-11 to March 13-15. Online groceries, cold medications, fitness equipment and computers surged, as did preordering for in-store pickup. Extreme growth was concentrated in hard-hit areas including California, New Hampshire and Oregon.

Customer Data Platform vendor Amperity reported a less rosy result in its COVID-19 Retail Monitor, which draws data from Amperity’s retail clients. They report that total retail demand fell by 86% by the end of March and even online revenue is down 73%.  Food and health products fell after an initial stock-up surge in mid-March.

Retail foot traffic tracker has packaged its in-store data in a COVID-19 Retail Impact tracker, which not surprisingly shows an end to traffic at shuttered entertainment and clothing outlets, near-total drop at restaurants, and mixed results for grocery stores and pharmacies. Results are reported by day by brand, if you really want to wallow in the gruesome details.

Grocery merchandising experts Symphony RetailAI have also launched a COVID-19 Insights Hub, which reports snippets of information with explanations. These range from obvious (consumers are accepting more product substitutions in the face of stock-outs) to intriguing (canned goods sales rose twice as much in the U.S. than in Europe because of smaller families and less storage space).

Retail Behavior Surveys

Showing just how quickly the world changed, retail consumer research platform First Insight found that the impact of coronavirus on U.S. shopping behavior doubled between surveys on February 28 survey and March 17. In the later survey, 49% of consumers said they were buying less in-store and 34% were shopping more online. Women and baby boomers went from changing their behavior slightly less than average in the first survey to changing slightly more than average in the second.

Ecommerce platform Yotpo ran its own survey on March 17, reaching 2,000 consumers across the U.S., Canada, and United Kingdom. They found consumers evenly split between expecting to spend more or less over-all, with a just 32% expecting to shift purchases online. Food, healthcare, and, yes, toilet paper were high on their shopping lists.

The situation was clearer by the end of March, when Retail Systems Research surveyed 1,200 American consumers for Yottaa. By this time, 90% were hesitant to shop in-store, 94% expected online shopping will be important during the crisis, and their top concerns were unavailable inventory, no free shipping, and slow websites. (Really, no free shipping?) More surprising but prescient, given Amazon's labor troubles: just 42% felt confident that Amazon could get their online orders delivered on time.

Media Consumption

Nobody wins any prizes for figuring out that Web traffic went up when people were locked down. But digital analytics vendor Contentsquare did provide a detailed analysis of which kinds of Web sites attracted more traffic (supermarkets, media, telecom, and tech retail) and which went down the most (luxury goods, tourism, and live entertainment) in the U.S., UK, and France. Week-by-week data since January shows a sharp rise starting March 16. Less easily predictable: supermarket and media conversion rates went down as consumers spent more time searching for something they wanted.

Media tracking company Comscore has also weighed in with an ongoing series of coronavirus analyses. Again, no surprises: streaming video, data, newscasts, and daytime TV viewing are all up. Same for Canada and India, incidentally.

You also won’t be shocked to learn that Upfluence found a 24% viewing increase in the live-streaming game platform Twitch in Europe. Consumption growth tracked national lockdowns, jumping in Italy during the week of March 8-14 and in France and Spain the week after.

Consumer review collector PowerReviews has its own data, based on 1.5 million product pages across 1,200 Web sites. Unlike Contentsquare, they found traffic was fairly flat but conversion rates jumped on March 15 and doubled by March 20. Their explanation is people were buying basic products that took less consideration.  People read many more reviews but submission levels and sentiment were stable. Reviews were shorter as consumers likely had other things on their minds.

Influencer marketing agency Izea got ahead of the game with a March 12 survey, asking social media consumers how they thought they’d behave during a lockdown. More social media consumption was one answer, with Facebook and Youtube heading the list. Izea also predicted that influencer advertising prices would fall as more influencers post more content.

Consumer Attitudes

Researching broader consumer attitudes, ITWP companies Toluna, Harris Interaction and KurunData launched a Global Barometer: Consumer Reactions to COVID-19 series covering the U.S., UK, Australia, India, and Singapore. The first wave of data was collected March 25-27.  People in the U.S. and India were generally more satisfied with how businesses had behaved and more optimistic about how quickly things would return to normal. But U.S. respondents ranked support from the national government considerable lower than anyone else.

Edelman Trust Barometer issued a ten market Special Report on COVID-19, although the data was gathered during the good old days of March 6-10. Even then, most people were following the news closely and 74% worldwide felt there was a lot of false information being spread. Major news outlets were the primary information source everywhere (64%) but the U.S. government was by far less relied upon (25%) than anywhere else (31% to 63%). Interesting, people put more faith in their employers than anyone except health authorities. They also expected business to protect their workers and local communities.

Kantar Media has yet another COVID-19 Barometer, although they reserve nearly all results for paying clients. The findings they did publish echo the others: more online media consumption, low trust in government, and expectation that employers will look after their employees. Kantar says that just 8% of consumers expect brands to stop advertising but 77% want advertising to show how brands are being helpful, 75% think brands should avoid exploiting coronavirus and (only?) 40% feel brands should avoid “humorous tones”.

Survey company YouGov publishes a continuously-updated International COVID-19 Tracker with timelines on changing opinions in 26 countries.  Behaviors including avoiding public places and not going to work change quickly; others such as fear of catching coronavirus and wearing masks move more slowly.  Other attitudes have barely shifted, including avoiding raw meat and improving personal hygiene.  The timing of changes correlates with the situation in each country.

Job Listings

There’s also an intriguing little niche of companies offering job information. PR agency Global Results Communications just launched a COVID-19 Job Board to help people find work.  So far, it's not very impressive: as of April 1 it had under 100 random listings from Walmart to Metrolina Greenhouses to the South Carolina National Guard.

Tech salary negotiators Candor (did you know that was a business?) has a vastly more useful site, listing 2,500+ companies that are reported to be hiring, freezing hiring, rescinding offers, or laying people off. At the moment, half the companies on the list are hiring. The site offers a very interesting break-down by industry: transportation, retail, consulting, energy, and automotive are in the worst shape. Defense, productivity and education software, and communications are doing the best.

Wednesday, March 18, 2020

Balandra Orchestrates Customer Journey Without a CDP

Balandra Customer Flow Diagram
The need for a system that assembles unified, sharable customer profiles is now widely accepted. So is the label of “Customer Data Platform” to describe such systems. What people do still debate is whether a Customer Data Platform should only assemble those profiles or should also include features to “activate” them in the sense of selecting customer treatments. I personally find the discussion uninteresting since the plain reality is that some companies want activation features in their CDP and others do not.  Companies that don't want activation in their CDP may already have a separate activation system or prefer to purchase a separate one.  This means that activation is optional, and, thus, not a core CDP feature. QED.

Theory aside, it’s true that the majority of CDPs do include activation features.  This makes a stronger argument for the weaker claim that most buyers want activation features in their CDP.  But this has nothing to do with CDPs in particular: it’s just an instance of the general rule that buyers prefer integrated systems to separate components. This is known (to me, at least) as Raab's Law, stated most succinctly as "suites win".

A diehard advocate of “CDPs need activation” might question whether activation systems can truly be purchased separately. My response points to Journey Orchestration Engines (JOEs), a small but intriguing category that includes Thunderhead, Pointillist, and Kitewheel among others. These products select the best treatment for each customer in each situation and transmit their choice to delivery systems (email, Web CMS, mobile app, call center, etc.) for execution. All need customer profiles to function, but they don’t necessarily meet the RealCDP requirements for accepting data from all sources, retaining all details, storing the data internally, or sharing their profiles with others. This is because their designers’ focus is on the very different challenge of making it easy for users to define, manage, and optimize customer treatments across channels.

Meeting that challenge requires presenting customer data effectively, identifying events that might require an action, selecting the right action in the current situation, and sending that action to external systems for delivery. Some tasks, such as data presentation and delivery system integration, are also found in other types of systems. The unique challenge for Journey Orchestration Engines is finding the right action while taking into account the customer’s complete situation (not just the current interaction). This requires understanding all the factors that are relevant in the current situation and choosing the best among all possible actions.

Of course, "all" is an impossibly high standard.  A more realistic goal is to understand as many factors as possible and choose among the broadest range of available actions. It’s an important distinction because the scope of available data and actions will grow over time.  This means the key capability to look for is whether a system has the flexibility to accommodate new data and actions as these become available.

This brings us to Balandra, a Madrid-based journey orchestration engine.

Balandra is designed for complex service industries such as insurance, telecommunications, and healthcare, where companies have multiple, complex operational systems. Left to run independently, these systems will each send their own messages, creating a disconnected and often inappropriate experience for each customer. Balandra intercepts these messages and replaces them with a single stream is governed by a common set of rules.

The rules themselves draw on a structure that organizes customer experience into major processes such as onboarding a new client, setting up a new service, or filing an insurance claim. Each process is assigned a combination of data, lifecycle stages, available actions, and decision rules. When an event occurs that involves the process, Balandra executes its rules to pick an action based on the customer’s data and lifecycle stage.

This may not sound especially exciting. But it’s important to contrast Balandra’s approach with conventional customer journey flows.  These follow a specified sequence of messages and events, at best with some branching to accommodate different customer behaviors as the journey progresses. But a conventional journey flow can only include a fairly low number of steps and branches before it becomes incomprehensibly complex. The rule-based approach avoids this problem by letting users  create different rules for different factors and apply them in sequence. So, you might have one rule that checks for recent customer service issues, another that checks for customer value, and another for previous purchases. Each rule would add or exclude particular messages from consideration. After all the rules had executed, a final rule would select from the pool of messages that remain available.

The advantage of this approach is that each rule executes independently, avoiding the need for a complex decision tree that specifies different treatments for different combinations of conditions. Rules can just be added or dropped into the mix knowing that they’ll apply themselves only when relevant conditions are met. For example, a rule might check for recent customer service problems and suppress new product offers within the following two weeks if one occurred. This happens (or doesn’t happen) across all interactions without explicitly building that check into each journey flow.

To be clear, Balandra isn’t the only system to take this approach. In fact, its actual rule definition and execution is done using a standard business rules engine – IBM’s Operational Decision Manager (ODM), formerly ILOG. The system does have an interface that lets non-technical users define the data associated with each process and specify connections with delivery systems. It can ingest data in real time via APIs, through event streams such as Kafka, or through batch file updates. It can support both real time interactions and batch processing for outbound campaigns.

If you’re keeping score, Balandra doesn’t qualify as a CDP because it only uploads a fraction of the data related to a customer – the interactions between customer and company systems. While this means Balandra clients might still want a separate CDP system, it also enables Balandra to use many fewer resources than a CDP would.

Balandra launched its product in 2014. It currently has four clients in production, all in Spain, and is looking distribution partners in other regions. Pricing starts around $50,000 per year and grows based on the number of customers.

Monday, March 09, 2020

Reflections on the CDP Revolution in France (and the Rest of Europe)

The CDP Institute just published a report on the CDP Industry in Europe (download here). This was based primarily on the global Industry Update released last month. This showed especially fast growth in Europe, with a year-on-year increase of 74% in the number of European vendors and 80% in European CDP employment, compared with growth outside of Europe of 38% in vendors and 59% in employment.

We spent quite a bit of time in Europe last year, so I certainly have my own ideas of the reasons behind these sharp increases. But it always seems best to get information from people who live in the region. So as part of the report we collected comments from several European CDP vendors and consultants on what they saw happening in their markets. Their complete comments are included in the report. They are largely consistent with each other, so I think it’s fair to give a summary. Here’s my interpretation:

• The European market is divided into several zones, each at a different stage of the development. The UK market is closest to the U.S. and most mature. Growth there began in 2017, paused as companies worked to meet the GDPR deadline of May 2018, and then resumed. The Netherlands and Germany are next in line, with growth taking off after mid-2018. Southern Europe, Eastern Europe and the Nordics the least mature, with limited deployment to date. Maturity can be measured by understanding of CDP, adoption levels, and the speed of sales cycles.

• Each market is served by native national vendors. These are often affiliated with marketing agencies or consultancies and usually provide a combination of data assembly and campaign management. Large U.S-based vendors have a substantial presence in the UK and Netherlands/Germany regions but little activity elsewhere. These vendors are primarily focused on data assembly. Some of the European vendors also sell throughout the UK/Netherlands/Germany markets. Few non-local vendors have much presence in Southern Europe, Eastern Europe, or the Nordic.

• France is a market of its own.  Most CDP sales in France are made by French vendors, who sell little outside of France.  U.S. and non-French European vendors do continue to try to penetrate the French market, so far with limited success.  Unlike other markets, the French vendors generally started as Data Management Platforms (DMPs) although they took a broad approach that included some CDP features from the start. They have now further evolved to towards CDP although their DMP roots still show.

• GDPR was an early impetus to CDP adoption but that momentum is now largely spent. Current interest in CDP is based on the core use cases of data unification and campaign management. In the more mature markets, where CDPs are better understood, this interest is most likely to result in buying a packaged CDP system. In the less mature markets, this interest is more likely to result in buying a solution from an agency or in building a solution in-house.

These observations largely parallel my own impressions of the region. One difference is that none of the commenters mentioned the several European CDPs that compete globally as specialists in travel, telecommunications, financial services, or retail. The reason may simply be that only one the vendors who contributed to the report is in this category.  Also, none mentioned the limited funding available to European CDP vendors, an extremely sharp contrast to heavily-funded U.S.-based firms.

There’s much more in the report, both in the vendors’ comments and in the industry data.  Again you can download it here.  Enjoy.

Thursday, February 13, 2020

Understanding Adobe Real Time CDP

Adobe fully released its Real Time Customer Data Platform last November. Although they had briefed me on it before then, it was only this week that I finally caught up with them to discuss the final product. Since this is a topic of great interest – and confusion – it’s worth sharing what I learned.

Part of the confusion has to do with Adobe’s habit of reusing product names. It’s easy to confuse the Adobe Experience Platform, the core system for collecting customer data, assembling profiles, applying machine learning, and sharing the results with services and applications, with Adobe Experience Manager, the Web content management system that is one of those applications. Similarly, Experience Platform contains a Real Time Customer Profile, which is different from the Real Time CDP, one of the services that consumes data from Experience Platform. Got that?

It also doesn’t help that Adobe describes Experience Platform and Real-Time CDP as managing unknown and known profiles for activation across all channels, without clarifying that it’s only referring to first-party data. It turns out that Audience Manager, their Data Management Platform (an “application” in their terminology), holds third party profiles that aren’t shared with Experience Platform.   Adobe nevertheless uses the term “audience activation” to describe movement of first party profiles from Experience Platform into other applications, including into Audience Manager itself.

Somebody get these people a thesaurus.

But that’s just words. What really takes explaining is that Adobe has split what it considers the functions of a CDP between the Experience Platform and the Real Time CDP itself. Specifically, they describe a CDP as doing three things:
  • ingesting customer data from all enterprise sources
  • creating persistent customer profiles used for modeling and segmentation
  • “activating” the profiles by moving them into applications
The first two functions, ingestion and profile management, are provided by Experience Platform. The third is provided by Real Time CDP.  

In other words, although Adobe’s combined stack does everything you expect from a CDP, its Real Time CDP only provides one of the three core functions. I’ll pause for a moment while you wrap your head around that.

Ready to continue? Great.  There’s nothing inherently wrong with Adobe’s approach, which is ultimately another matter of labels. In fact, I’ve recently seen several situations where the CDP is primarily an access tool that connects a master data store to marketing systems. As with Real Time CDP, the role is simply to take already-assembled data and put it in a format that’s suitable for marketers (or potentially other business users). So Adobe may be on to something.

Of course, any system that just provided data access would not be a CDP. Adobe’s combined solution does meet the CDP Institute definition of a CDP: packaged software that builds a unified, persistent customer database accessible to other systems. They might be a bit weak at the edges – I haven’t explored whether they can truly include all sources and all details within the Experience Platform database.  News that that Experience Platform excludes the third party profiles in Audience Manager does raise some questions about that. But, truth be told, quite a few CDPs have some practical limits in those areas.

You’re likely aware that some analysts and CDP vendors disagree with the CDP Institute definition, arguing a CDP should include analytics and experience orchestration. The general logic is that data is worthless unless it’s exploited, so the CDP should include features to use it. This is usually described as “activation”, a word I’m avoiding since Adobe is using it one way (to describe moving data from the CDP into application systems, with some segmentation capability but no message selection), while others often use it to include message selection, personalization, and orchestration. I personally don’t much care how anyone defines “activation” so long as they’re clear about what they mean when they use it. I happen to agree with Adobe that message selection, personalization, and orchestration aren’t essential CDP functions.  But that’s a debate for another day.

That said, it’s important to know that Real Time CDP isn’t the only Adobe service that can access the customer profiles in Experience Platform. Services including analysis, journey orchestration, and offer management provide alternative connections between Experience Platform and the applications. This is wrinkle that wouldn’t be present in a CDP that provided ingestion, profile creation, and access as part of one system. It adds complexity if one application might connect with several services. You might even worry that it recreates the crazy wall of point-to-point connections that causes people to want CDPs in the first place.  But that’s an overstatement if only four services are involved.

A more pressing concern would be how much data is actually loaded into Experience Platform. Some operational data will stay within the individual Adobe applications because no other system can use it.  Beyond that, my understanding is that Experience Platform has an extensible data model which would theoretically handle any information that users wanted it to ingest. But that could be wrong. Anyone thinking about buying the system should check that it can load the sources that matter in their situation. Remember that Experience Platform grew out of Adobe’s previous approach, which largely relied on storing identifiers within the central data store and looking up everything else in its source systems as needed. Adobe has clearly moved beyond that but some traces may linger.

Monday, February 03, 2020

Salesforce Buys Evergage But Not For CDP

The CDP Institute published its semi-annual Industry Update report today, which you download here for free. Although every word and image in the report is a jewel, there’s no question that the main story in this edition is CDP industry consolidation. Events in the past six months (stretching a bit to include early January 2020) include seven new funding rounds, three acquisitions of CDP vendors, four acquisitions by CDP vendors, and four asset sales by CDP companies.  Asset sales aside, these are all ways for companies to strengthen their business more quickly than organic growth permits.

What’s particularly intriguing is the industry position of the firms in these deals.  Using our best guess at CDP employment for each vendor, only one of the twelve vendors involved funding or either side of an acquisition is among the industry’s five largest (SessionM, bought by Mastercard). The rest all ranked within the fairly narrow band from number eight to number thirty (of 101 total). That is, they were bigger than most but not the industry's largest.  I interpret this to mean that these vendors were either adding resources for a push to reach the industry top tier or have already decided they need to be part of something else.  

Notably, the firms that engaged in asset sales were much smaller: only IgnitionOne would have fallen within the top thirty and their deal might be considered more of an acquisition, since Zeta Global is apparently still selling the product.

Careful readers will have already noticed that this chart includes one other deal: acquisition of Evergage by Salesforce, announced on Monday.  Evergage fits into the size range of the other deals and the sale can certainly be seen as an escape from the crowded campaign CDP space. But the purchase is otherwise atypical because Salesforce has stressed that they are primarily interested in Everage for real time interaction management and personalization.  Of course, Salesforce is already far along in work on its own CDP, the Customer 360 Audiences component of Customer 360 Truth, which is due for general release around June. So this deal has little to do with Evergage as a CDP.  It's about closing a gap elsewhere in the Salesforce product line, not a sudden acceleration of Salesforce’s entry into the CDP space.