Like many people in the marketing technology industry, I was tickled in 2011 when Gartner predicted that CMOs would soon have bigger tech budgets than CIOs, and even more tickled when Gartner said in 2016 that it had happened. But my recent pondering of the relationship of marketing and IT departments had me rethinking the question. On an anecdotal level, I’ve never seen or heard of a company where the marketing technology group was anywhere near the size of the IT department. And from a revenue perspective, there’s no way that marketing technology companies make up half the total revenue of the software industry.
But just as I was working myself up for some back-of-the-envelope calculations, the good people at International Data Corporation (IDC) announced a report with authoritative figures on the topic. Actually, the study estimates spending on 20 technologies and 12 corporate functional areas across 16 enterprise industries in eight regions and 53 countries, comparing the amounts funded by IT departments and by business departments. They haven’t published the figures for marketing in particular but did graciously provide them to me with permission to reprint them here. Without further ado, they are:
As you see, marketing technology expenses for 2016 are estimated at $82.3 billion, which is just 6.7% of the $1,235.3 billion for all categories. Slightly more than half of the marketing spend is business-funded, which presumably means it’s spent by CMOs. But that wasn't what Gartner had in mind: they were definitely comparing corporate IT budgets against marketing IT budgets.
I understand Gartner's logic but I find the IDC figures more plausible. One reference point is the known revenues of martech vendors. Adobe, which may well be the largest, just reported $1.6 billion in 2016 revenue for its marketing cloud (apparently including analytics and advertising products). Even if there are ten other vendors as large as Adobe, the top ten would have just a 20% share of the $82 billion. It’s hard to imagine the market is really that fragmented, even allowing for expenses that are unrelated to software.
Another reason I prefer the IDC figures is that surveys consistently show that marketing technology is far down the priority list of IT managers. That wouldn’t be the case if martech spend were equal to all other tech spending combined. Indeed, one of the main reasons that marketers have been eager to take control of their technology has been the neglect, benign or otherwise, shown by corporate IT.
So let's assume the IDC figures are much closer to correct. Does it matter? I'd answer it does because understanding the real relationship between martech and other systems is important. Marketers need to recognize that their systems are a small part of a big picture and can’t work independently of the rest of the company. Yes, marketers should control their internal systems. But the IDC figures show that sales and customer service spend more on tech than marketing. So, when it comes to customer-facing systems, marketers shouldn’t expect other departments to simply adopt marketing systems as a new core.
More likely, all departments will need to coordinate their existing systems with a shared, enterprise-level resource. This suggests that the common core / edge model of marketing systems needs to modified to distinguish an enterprise-wide core from a marketing department core. In some ways, this isn't a huge change because marketers have always co-existed with enterprise-core systems such as human resources and accounting. But marketers are much more likely to want control of customer-related systems like the Web site and Customer Data Platform. In this model, those are also part of the enterprise core.
Of course, having enterprise core systems leads right back to having the IT department manage those systems and ensure that departmental systems are compatible. IT departments are not necessarily eager to take this on. They have their hands full with things like security, cloud migration, and digital transformation. Nor are enterprise IT teams usually experts at the finer points of customer data management. They’ll certainly need help from marketing and other customer-facing tech teams. But, ultimately, managing the customer experience is a job for the whole enterprise, and enterprise IT is the logical team to manage enterprise-wide technology.
Wednesday, March 29, 2017
Thursday, March 23, 2017
Wondering How Customer Data Platforms Relate to Other Marketing Systems? Here's a Picture
I was asked the other day about the distinction between Customer Data Platforms and Journey Orchestration Engines. My immediate answer was “Some CDPs are JOEs and some JOEs are CDPs. A CDP is a JOE if has journey orchestration. A JOE is a CDP if its data is accessible to other systems. Think Venn diagram with two intersecting circles.” It's not clear the answer helped, but it did get me thinking about clarifying with a Venn diagram. The diagram I originally had in mind was this one, showing that CDPs unify customer data and make it available, while JOEs unify customer data and select messages. Systems that do all three are both a CDP and a JOE.
On reflection, that’s not the right way to draw a Venn diagram. Each circle should represent one set of traits. So the picture should really look like this:
That's fine, but it seems odd that “unify customer data” has no system associated with it. Is there a type of system that just unifies customer data without making it accessible or selecting messages? Come to think of it, there is. Systems that just do customer matching used to be called Customer Data Integration but I don’t hear that much any more. Sometimes people talk about Identity Resolution but mostly it seems that Customer Data Integration has been absorbed by the larger category of Master Data Management (MDM) systems, which integrate all kinds of data. So let’s add MDM as the label for that.
But why stop there? Let's see how other systems would fit into the diagram. First to come to mind was marketing automation platforms (MAPs), which also select messages (like a JOE) but don’t build a unified customer database or offer open data access. The diagram with MAPs included looks like this:
Hmm, what about CRM? In many ways its out there with MAP: another system that selects messages but doesn’t build a unified database. So we need to introduce a new split, of marketer-controlled vs. sales controlled. I'll give control a different color for clarity. Apologies to CRM people that your circle is so tiny; I'm not suggesting anything about the importance of your systems.
Still thinking about control, Data Management Platforms (DMPs) look a lot like Marketing Automation Platforms: they’re marketer-controlled systems that select messages (sort of) but don’t unify data from all sources or provide open access. So unless we want to further subdivide the marketer controlled space, they share the same location as MAPs.
I've summarized this information in a table below. Still confused? We just posted a answers to Frequently Asked CDP Questions on the CDP Institute blog. Maybe that will help.
Thursday, March 16, 2017
Is MarTech Too Important To Leave To The Marketers?
I’m still pondering the relationship between marketing and IT: what it is, will be, and should be. A few new ingredients have kept the pot boiling:
- a chat with Abhi Yadav, founder of Zylotech, a MIT-bred, artificial intelligence-driven Customer Data Platform and message selection engine. Those roots made it seem a likely candidate for IT-driven purchases, but Yadav told me his primary buyers are marketing operations staff. In fact, he hasn’t even run into those marketing technology managers everyone (including me) keeps talking about. On reflection, it makes sense that marketers would be the buyers since Zylotech includes analytical and message selection features only used in marketing. A system that only did data unification would appeal more to IT as a shared resource. Still, Yaday's comments are one point for the marketer-control team.
- a survey from the Association of National Advertisers that found marketers who control their technology strategy, vendors, and enterprise standards are more likely to have a strong return on martech investment. (The study is only available to ANA members but they gave permission to publish the table below. You can see a public infographic here). That’s two points for Team MarTech.
- a study by IT staffing and services provider TEKsystems that found senior marketers with more advanced strategy were more likely to control their own technology. The difference wasn’t terribly pronounced but it’s still the same pattern. MarTech is now ahead 3-0. (I was actually more impressed that 65% of departments with no strategy were in charge. Yikes!)
So far, the game’s a blow out. Marketing is usually in charge of its technology and does better when it is. A doubter might question if marketers really make better choices or are just happier when they’re in control. I do suspect that IT people would be less confident that marketers are making optimal decisions. Still, there’s no real reason to doubt that marketers are the best judges of what they need.
But the game’s not over. Let's call in a recent Ad Week article about global tech consultancies buying marketing agencies. The article cites Accenture, Deloitte, IBM, KPMG, McKinsey and PricewaterhouseCoopers and notes that each already has huge agency operations. To the extent that these firms are working with marketing departments, it’s still more evidence of marketing being in charge. But the real story, at least as I read it, is these firms are getting involved because they see a need to integrate marketing technology with over-all corporate technology, just as marketing strategy needs to support corporate strategy.
“The consultants’ bread and butter has traditionally been large IT and business-transformation projects,” says Julie Langley, a partner at fundraising, merger and acquisitions advisor Results International, in the article. “But, increasingly, these types of projects have ‘customer experience’ at their center.”
To me, this is the key. As every aspect of customer experience becomes technology-driven, technology must be integrated across the corporation to deliver a satisfactory experience. Marketing may be the captain, but it’s still part of a larger team. If marketing can be a true team player, it gets to call the plays. But if marketing is selfish, then a coach needs to step in for the good of the whole.
I’ll spare you the extended sports analogy. In concrete terms, if marketing picks systems that only meet marketing needs, then the integrated customer experience will suffer. Worse still, some new tech-driven offerings may be impossible. This could be fatal if other, nimbler competitors deliver them instead. Tech-based disruption is a real threat in many industries. Companies can’t just hope that each department working on its own will yield an optimal solution for the business as a whole. In fact, they can be quite sure it won't.
That’s why I’m not convinced by surveys showing marketers are happier or get better return on investment when they control their own technology. It’s possible for that to be true and for the corporate to miss larger opportunities that require cooperation across departments. If marketing can take that broader perspective, there’s no problem. If it can’t, IT or another department with enterprise-wide perspective will need to enter the game.
- a chat with Abhi Yadav, founder of Zylotech, a MIT-bred, artificial intelligence-driven Customer Data Platform and message selection engine. Those roots made it seem a likely candidate for IT-driven purchases, but Yadav told me his primary buyers are marketing operations staff. In fact, he hasn’t even run into those marketing technology managers everyone (including me) keeps talking about. On reflection, it makes sense that marketers would be the buyers since Zylotech includes analytical and message selection features only used in marketing. A system that only did data unification would appeal more to IT as a shared resource. Still, Yaday's comments are one point for the marketer-control team.
- a survey from the Association of National Advertisers that found marketers who control their technology strategy, vendors, and enterprise standards are more likely to have a strong return on martech investment. (The study is only available to ANA members but they gave permission to publish the table below. You can see a public infographic here). That’s two points for Team MarTech.
- a study by IT staffing and services provider TEKsystems that found senior marketers with more advanced strategy were more likely to control their own technology. The difference wasn’t terribly pronounced but it’s still the same pattern. MarTech is now ahead 3-0. (I was actually more impressed that 65% of departments with no strategy were in charge. Yikes!)
So far, the game’s a blow out. Marketing is usually in charge of its technology and does better when it is. A doubter might question if marketers really make better choices or are just happier when they’re in control. I do suspect that IT people would be less confident that marketers are making optimal decisions. Still, there’s no real reason to doubt that marketers are the best judges of what they need.
But the game’s not over. Let's call in a recent Ad Week article about global tech consultancies buying marketing agencies. The article cites Accenture, Deloitte, IBM, KPMG, McKinsey and PricewaterhouseCoopers and notes that each already has huge agency operations. To the extent that these firms are working with marketing departments, it’s still more evidence of marketing being in charge. But the real story, at least as I read it, is these firms are getting involved because they see a need to integrate marketing technology with over-all corporate technology, just as marketing strategy needs to support corporate strategy.
“The consultants’ bread and butter has traditionally been large IT and business-transformation projects,” says Julie Langley, a partner at fundraising, merger and acquisitions advisor Results International, in the article. “But, increasingly, these types of projects have ‘customer experience’ at their center.”
To me, this is the key. As every aspect of customer experience becomes technology-driven, technology must be integrated across the corporation to deliver a satisfactory experience. Marketing may be the captain, but it’s still part of a larger team. If marketing can be a true team player, it gets to call the plays. But if marketing is selfish, then a coach needs to step in for the good of the whole.
I’ll spare you the extended sports analogy. In concrete terms, if marketing picks systems that only meet marketing needs, then the integrated customer experience will suffer. Worse still, some new tech-driven offerings may be impossible. This could be fatal if other, nimbler competitors deliver them instead. Tech-based disruption is a real threat in many industries. Companies can’t just hope that each department working on its own will yield an optimal solution for the business as a whole. In fact, they can be quite sure it won't.
That’s why I’m not convinced by surveys showing marketers are happier or get better return on investment when they control their own technology. It’s possible for that to be true and for the corporate to miss larger opportunities that require cooperation across departments. If marketing can take that broader perspective, there’s no problem. If it can’t, IT or another department with enterprise-wide perspective will need to enter the game.
Tuesday, March 14, 2017
CrossEngage Orchestrates Customer Journeys Using Events
It feels like forever since I first wrote about Journey Orchestration Engines (JOEs), although it is just one year. Orchestration was already a hot term when I started, so I take neither credit nor blame for its continued popularity. I will say that I’ve now seen enough orchestration systems to start making subtle distinctions among them.
Subtle distinctions are needed because the systems are basically similar. They all ingest data from multiple sources; convert it into unified customer profiles; apply rules and analytics to find the best message for each customer in each situation; and, send those messages to external systems for delivery. Unified customer profiles make these products look like Customer Data Platforms. JOEs that expose their profiles for external access really are CDPs; JOEs that keep the profiles for their own use, are not. In theory, a JOE could connect to an external customer database rather than building its own, but I haven’t seen that configuration in practice.
The main ways that JOEs differ include:
CrossEngage treats most data as either a customer attribute or event, using big data technologies that store inputs and to allow data access with minimal schema design. The system also stores some information that’s neither attribute nor event, such as products and locations. The vendor maps new sources into the system and can define logic to create custom events. (A self-service event builder is planned by July.) Customer data from different sources is stitched together using deterministic matching only (that is, CrossEngage will only connect different identifiers to the same person if an external source provides the relationship).
A dashboard lets users see Web site events as they stream into the system. Users can apply filters to see only certain events. Campaigns also make heavy use of events, referencing them as entry and exclusion conditions, in combination with user-defined segments; as campaign goals (which may be one or several events); and, as campaign steps (each step being a different event). Event definitions can reference other events and can include brain-bending logic such as checking whether a second train fare request specified the same departure city as the first request and happened within ten minutes. In that example, the first request would be first event in the campaign. This is tremendously powerful and, as the vendor points out with some understatement, poses a substantial technical challenge to do in real time.
Each event in a campaign can be assigned a message, which will be delivered by an external system such as an email vendor. CrossEngage can map its data to delivery systems so they can use the data in their own message templates. Alternatively, messages can be created in CrossEngage’s own templates, which can include conditional scripts for dynamic content generation. The system has external integrations for email, direct mail, mobile push, text messages, and Facebook Customer Audiences, with more on the way. It has its own connectors for Web site and Web browser messages, Web hooks, and file extracts. Users can also attach discount coupons to messages.
Campaigns can be assigned frequency caps that limit the number of messages each person receives in different time periods (per minute, per hour, per day, per week, or per month). Caps are defined separately for each campaign. Another set of caps applies across all campaigns on a per channel basis. Campaigns that generate transactional messages can be exempted from the frequency caps to ensure their messages are always sent. People can also be excluded from campaigns based on whether they were recently in that same campaign or a different one.
CrossEngage also has user journeys, which involve a set of related events. Journeys can exist within a campaign or be used outside a campaign to analyze customer behavior. If you’re keeping track, this is a different use of the term “journey” from the one I described earlier.
This is a pretty mature set of features, especially for such a young system. But nuances also include noticing what CrossEngage doesn’t do. There is no machine learning to recommend the right campaign, right message, or right message timing, although the system does support a/b tests. There’s also no visual flow chart to lay out campaigns. This is a choice made by CrossEngage based on its designers’ previous experience that flow charts quickly become too complicated to be understood or maintained over time.
Speaking of nuance, CrossEngage also has a mature approach to user rights management, allowing administrators to specify which users can perform which actions on each object. Team-based rights are on the roadmap.
CrossEngage currently has about fifteen major clients, spread across travel, ecommerce, fashion, dataing, and other industries. Pricing is based on the number of events tracked in the system, not the number of messages sent. It starts as low as $2,500 per month although average client pays about twice that.
Subtle distinctions are needed because the systems are basically similar. They all ingest data from multiple sources; convert it into unified customer profiles; apply rules and analytics to find the best message for each customer in each situation; and, send those messages to external systems for delivery. Unified customer profiles make these products look like Customer Data Platforms. JOEs that expose their profiles for external access really are CDPs; JOEs that keep the profiles for their own use, are not. In theory, a JOE could connect to an external customer database rather than building its own, but I haven’t seen that configuration in practice.
The main ways that JOEs differ include:
- Channel scope. Some systems are largely limited to online interactions, while others are built to combine online and offline channels. Some systems that look like JOEs work with only Web or email. But orchestration pretty much implies multiple channels so I’d probably exclude those from the JOE tribe.
- Decision methods. JOEs can work with conventional, rule-driven campaign structures or use automated techniques to customize the path followed by each customer. There’s also considerable variation in exactly what gets automated: some automate campaign assignments but use static content; some automatically run a/b tests and pick the winners; some automatically create customer segments that receive different content; some use machine learning to dynamically generate custom content.
- Journey framework. My original definition of JOE was quite rigorous: journey orchestration meant all campaigns were defined relative to a master model of the customer journey. This really means that stages in the journey are “states” that customers flow between, and campaigns are chosen in part based on each customer’s current state. I still think of JOEs that way and definitely see some systems organized along those lines. But when you start looking at some of the more automated decision methods, it’s harder to apply concepts of fixed states or journey flows. So I still check whether a system has a journey framework but don’t necessarily require a JOE to use it. I realize this means you could have a journey orchestration system without journeys. If that’s the silliest thing you’ve been asked to accept recently, you haven’t been watching the news.
CrossEngage treats most data as either a customer attribute or event, using big data technologies that store inputs and to allow data access with minimal schema design. The system also stores some information that’s neither attribute nor event, such as products and locations. The vendor maps new sources into the system and can define logic to create custom events. (A self-service event builder is planned by July.) Customer data from different sources is stitched together using deterministic matching only (that is, CrossEngage will only connect different identifiers to the same person if an external source provides the relationship).
A dashboard lets users see Web site events as they stream into the system. Users can apply filters to see only certain events. Campaigns also make heavy use of events, referencing them as entry and exclusion conditions, in combination with user-defined segments; as campaign goals (which may be one or several events); and, as campaign steps (each step being a different event). Event definitions can reference other events and can include brain-bending logic such as checking whether a second train fare request specified the same departure city as the first request and happened within ten minutes. In that example, the first request would be first event in the campaign. This is tremendously powerful and, as the vendor points out with some understatement, poses a substantial technical challenge to do in real time.
Each event in a campaign can be assigned a message, which will be delivered by an external system such as an email vendor. CrossEngage can map its data to delivery systems so they can use the data in their own message templates. Alternatively, messages can be created in CrossEngage’s own templates, which can include conditional scripts for dynamic content generation. The system has external integrations for email, direct mail, mobile push, text messages, and Facebook Customer Audiences, with more on the way. It has its own connectors for Web site and Web browser messages, Web hooks, and file extracts. Users can also attach discount coupons to messages.
Campaigns can be assigned frequency caps that limit the number of messages each person receives in different time periods (per minute, per hour, per day, per week, or per month). Caps are defined separately for each campaign. Another set of caps applies across all campaigns on a per channel basis. Campaigns that generate transactional messages can be exempted from the frequency caps to ensure their messages are always sent. People can also be excluded from campaigns based on whether they were recently in that same campaign or a different one.
CrossEngage also has user journeys, which involve a set of related events. Journeys can exist within a campaign or be used outside a campaign to analyze customer behavior. If you’re keeping track, this is a different use of the term “journey” from the one I described earlier.
This is a pretty mature set of features, especially for such a young system. But nuances also include noticing what CrossEngage doesn’t do. There is no machine learning to recommend the right campaign, right message, or right message timing, although the system does support a/b tests. There’s also no visual flow chart to lay out campaigns. This is a choice made by CrossEngage based on its designers’ previous experience that flow charts quickly become too complicated to be understood or maintained over time.
Speaking of nuance, CrossEngage also has a mature approach to user rights management, allowing administrators to specify which users can perform which actions on each object. Team-based rights are on the roadmap.
CrossEngage currently has about fifteen major clients, spread across travel, ecommerce, fashion, dataing, and other industries. Pricing is based on the number of events tracked in the system, not the number of messages sent. It starts as low as $2,500 per month although average client pays about twice that.
Monday, March 13, 2017
Forecast: Self-Assembling Application Bundles Will Manage Customer Experience
I recently described a Deloitte paper on technology trends, focusing on their descriptions of IT management methods. The paper also covered broader trends including:
Juniper's term is "digital cohesion", which they desfine as "an era in which multiple applications self-assemble to provide autonomous and predictive services that continually adapt to personal behaviors.” It somewhat resembles the ideas I offered in this post about RoseColoredGlasses.me and further elaborated here. I guess that’s why I like it.
Beyond having excellent taste to agree me, Juniper fills in quite a few details about how this will happen. Key points include:
I’m also sure you see how this relates to ideas that neither vendor mentioned directly, such as the increasing value of rich customer data, importance of accurate identity resolution, role of brands in creating trust, and natural tendency of consumers to do everything through a single mega-service.
Of course, there’s no guarantee this vision will come to pass. But it’s an interesting working hypothesis to shape your thinking. More than anything else, it should help you look beyond optimizing your current stack to ensure that you’ll be able to adapt if radical changes are needed.
- Unstructured data, which they saw as a potentially bottomless source of insight. What’s interesting is they didn’t suggest many operational uses for it. By contrast, traditional corporate data management is almost exclusively about business operations.
- Machine intelligence, which they described as broader than artificial intelligence. They saw deployment moving from offering insights, to interacting with people, to acting autonomously. They also described it as controlling internal business processes as well as customer interactions. That's not the way marketers tend to think but they're right: the bulk of company processes are not customer-facing.
- Mixed reality, which is a combination of virtual reality, augmented reality, and Internet of Things. They focused less on game-like immersive experiences than on new types of interfaces, such as gesture- and voice-based, and on remote experiences such as collaborative work. They also listed some requirements that aren't usually part of this discussion, including machines that can understand human expressions and emotions and security to ensure hackers don’t falsify identities or inject harmful elements into the remote experience (such as, telling you to make a repair incorrectly).
- Blockchain, which they presented as mostly in terms of easing security issues by verifying identities and allowing for selective sharing of information.
Juniper's term is "digital cohesion", which they desfine as "an era in which multiple applications self-assemble to provide autonomous and predictive services that continually adapt to personal behaviors.” It somewhat resembles the ideas I offered in this post about RoseColoredGlasses.me and further elaborated here. I guess that’s why I like it.
Beyond having excellent taste to agree me, Juniper fills in quite a few details about how this will happen. Key points include:
- Disruptive competitors can use high speed networks, local sensor data, and centralized cloud processing to offer new services with compelling economics (e.g. Airbnb vs. Hilton).
- Smartphones provide pre-built mass distribution, removing a traditional barrier to entry by disruptive competitors.
- Consumers are increasingly open to trying new things, having been trained to do so and seen benefits from previous new things.
- Natural interfaces will eliminate learning curves as systems adopt to users rather than the other way around, removing another barrier to adoption.
- Autonomous services will self-initiate based on observing past behavior and current context. Users won't need to purposely select them. More barriers down.
- Services will be bundled into mega-services, simplifying user choice.
- Open APIs and interoperability will make it easy to add new services to the bundles. This is a key enabling technology.
- Better security and trust are essential for users to grant device access and share information with new services.
- Business relationships need to be worked out between the individual services and the mega-bundles.
I’m also sure you see how this relates to ideas that neither vendor mentioned directly, such as the increasing value of rich customer data, importance of accurate identity resolution, role of brands in creating trust, and natural tendency of consumers to do everything through a single mega-service.
Of course, there’s no guarantee this vision will come to pass. But it’s an interesting working hypothesis to shape your thinking. More than anything else, it should help you look beyond optimizing your current stack to ensure that you’ll be able to adapt if radical changes are needed.
Sunday, March 12, 2017
Should Customer Data Platforms Be "Marketer-Controlled"?
Thomas Wieberneit argues in a thoughtful blog post that companies need one platform for consolidated customer data, but that Customer Data Platform isn’t it because the CDP is “marketer-controlled” by definition, and thus doesn’t support other departments.
This hits a nerve. Many of the CDP vendors have told me their systems are used outside of marketing. Just last week, RedPoint unveiled a “Customer Engagement Hub”* that it defines as extending beyond marketing to all customer touchpoints. When I was recently writing a paper for B2B CDP CaliberMind, they listed sales and customer success teams along with marketing as likely buyers of their product.
As these examples suggest, CDP technology can support all customer-facing departments. It’s true that different departmental applications will probably need the CDP data to be presented slightly differently. But applications within marketing also need different formats, and it’s already standard for CDPs to reformat their data for access by external systems. So there’s no technical reason to limit CDPs to marketing.
Indeed, as I argued in my last blog post, the era of isolated marketing technology systems may be coming to an end as companies return to centralized systems to ensure a seamlessly integrated customer experience. In this world, the CDP is a shared enterprise asset, and, as such, clearly not something that marketers build and control for themselves.
So what’s holding me back from changing the definition? Three things:
I’m tempted to offer something truly lame, like “Enterprise CDP” as an alternative to plain or Departmental CDP. It might come to that, or I might ultimately just drop “marketer-controlled” without replacing it. After all, if enterprise systems really do become flexible enough to meet departmental needs in a way that past enterprise data warehouse projects did not, then the distinction will no longer matter.
Bottom line: I’ll leave “marketer-controlled” in place for now but suspect its days are numbered.
________________________________________________________________
*CEH is a Gartner term, which they define as “an architectural framework that ties multiple systems together to optimally engage the customer. A CEH allows personalized, contextual customer engagement, whether through a human, artificial agent, or sensors, across all interaction channels. It reaches and connects all departments, allowing, for example, the synchronization of marketing, sales and customer service processes.” As the term “hub” implies, this definition doesn’t specify creation of a persistent database, something I believe is required to build an effective customer profile. Come to think of it, I'm not sure that "architectural framework" is a system at all.
This hits a nerve. Many of the CDP vendors have told me their systems are used outside of marketing. Just last week, RedPoint unveiled a “Customer Engagement Hub”* that it defines as extending beyond marketing to all customer touchpoints. When I was recently writing a paper for B2B CDP CaliberMind, they listed sales and customer success teams along with marketing as likely buyers of their product.
As these examples suggest, CDP technology can support all customer-facing departments. It’s true that different departmental applications will probably need the CDP data to be presented slightly differently. But applications within marketing also need different formats, and it’s already standard for CDPs to reformat their data for access by external systems. So there’s no technical reason to limit CDPs to marketing.
Indeed, as I argued in my last blog post, the era of isolated marketing technology systems may be coming to an end as companies return to centralized systems to ensure a seamlessly integrated customer experience. In this world, the CDP is a shared enterprise asset, and, as such, clearly not something that marketers build and control for themselves.
So what’s holding me back from changing the definition? Three things:
- History. The fact is that CDPs evolved from systems that were built specifically for marketing. This matters because it means marketing needs drove their design. CDPs built to support sales or customer success teams would probably look a bit different, even if they used the same underlying technology. To give a concrete example, systems built for customer success don’t need to advanced identity resolution because almost all the data they care about arrives with a customer ID attached. I know that history by itself isn’t a good reason to retain the marketer-centric definition of CDP since CDPs have outgrown their origins. But it doesn’t hurt to have something remind users outside of marketing that they should look closely at whether any particular CDP can fully support their needs.
- User control. The primary reason the CDP definition includes “marketer-controlled” is to distinguish CDPs from enterprise data warehouse (or data lake) projects run by corporate IT. That matters because such projects were historically multi-year undertakings that often failed altogether or required so many compromises among enterprise stakeholders that they didn’t meet all of marketing’s particular needs. Moreover, once built, such systems were slow and costly to update, so they didn’t adapt quickly to marketers’ fast-changing environment. This responsiveness is really the biggest change that CDPs introduced into the world of customer data management. As I noted earlier, department-controlled systems may soon be lost in a new round of centralization. In theory, these new central systems will be vastly more responsive to user needs than the old central systems. But if I were a marketer, I’d be reluctant to give up my own systems until the new ones had proven their agility in practice.
- Departmental buyers. Whatever the long-term future of centralization, CDPs today are almost always bought by departments. Even when corporate IT groups are managing the process, they are generally reacting to requests from departmental users rather than executing an enterprise master plan of their own. And when you start looking at which departments are making these purchases, marketing is by far the leader. It’s true that other departments often find uses for a CDP once it’s deployed. Whether marketers really share control of their CDPs when this happens or simply treat other users as guests, I can’t say. From a seller’s standpoint, I can certainly see companies offering their technology in packages aimed at enterprise buyers, which is exactly what RedPoint just did. But abandoning the large marketing-department segment for the nascent enterprise-buyer segment doesn’t sound like a good idea.
I’m tempted to offer something truly lame, like “Enterprise CDP” as an alternative to plain or Departmental CDP. It might come to that, or I might ultimately just drop “marketer-controlled” without replacing it. After all, if enterprise systems really do become flexible enough to meet departmental needs in a way that past enterprise data warehouse projects did not, then the distinction will no longer matter.
Bottom line: I’ll leave “marketer-controlled” in place for now but suspect its days are numbered.
________________________________________________________________
*CEH is a Gartner term, which they define as “an architectural framework that ties multiple systems together to optimally engage the customer. A CEH allows personalized, contextual customer engagement, whether through a human, artificial agent, or sensors, across all interaction channels. It reaches and connects all departments, allowing, for example, the synchronization of marketing, sales and customer service processes.” As the term “hub” implies, this definition doesn’t specify creation of a persistent database, something I believe is required to build an effective customer profile. Come to think of it, I'm not sure that "architectural framework" is a system at all.
Saturday, March 11, 2017
Corporate IT Will Regain Control Over Marketing Technology (And That's Okay)
One of my favorite factoids comes from a Computerworld survey in which IT managers placed marketing technologies at 20th of 28 items on their priority list. This either shows that martech managers are less important than they think or explains why martech managers are needed in the first place. Maybe both.
But the disconnect between corporate IT and marketing technologists could be more than simply amusing. A recent Deloitte study described IT trends that seem incompatible with common martech strategies. If that’s really the case, martech may end up isolated from other company systems – or, more likely, huge investments in martech may ultimately be scrapped once it becomes essential to pull marketing back into the corporate IT fold.
What are these worrisome trends? One was positioning of IT as an innovation driver; another was a loosely-coupled technical architecture of standards-based components; a third was replacing individual applications with enterprise-wide services. Each is problematic for a different reason:
Rather, what’s happening here is a good-faith effort by IT managers to help their company and its customers. (The word “customer” occurs 139 times in the paper.) Indeed, the paper proposes that technical innovations can lead to entirely new business models. Many of those models will surely integrate marketing functions as part of the whole. The paper also lists opportunities such as using machine intelligence to run systems more smoothly and more flexibly than human operators. Those would benefit marketing systems as much as any others, putting the burden on marketing to justify keeping its system separate.
There may be something oxymoronic about “tightly-integrated, loosely-coupled systems”. But that’s exactly what’s being proposed and it actually makes a great deal of sense. Perhaps the trend of marketing taking control of its own systems has run its course and the pendulum is now swinging back to centralization. If so, marketers, marketing technologists, and martech vendors need to ensure their systems meet the new requirements for loosely coupled integration. In fact, they should do this gladly, because the new integrations promise grand new benefits for companies and their customers.
But the disconnect between corporate IT and marketing technologists could be more than simply amusing. A recent Deloitte study described IT trends that seem incompatible with common martech strategies. If that’s really the case, martech may end up isolated from other company systems – or, more likely, huge investments in martech may ultimately be scrapped once it becomes essential to pull marketing back into the corporate IT fold.
What are these worrisome trends? One was positioning of IT as an innovation driver; another was a loosely-coupled technical architecture of standards-based components; a third was replacing individual applications with enterprise-wide services. Each is problematic for a different reason:
- IT as an innovation driver suggests that IT should take a larger role in marketing technology than it plays when marketing runs its own systems. It probably also implies innovations that cross departmental boundaries, again reducing the independence of marketing technologists.
- a loosely-coupled architecture implies that marketing systems will conform to corporate standards to ensure interoperability. This also reduces marketing autonomy. More concretely, it conflicts with the internally-integrated marketing clouds and customer engagement platforms that some marketing departments have purchased to reduce complexity.
- enterprise-wide services suggest that marketing would be expected to use the corporate solutions rather than its own systems. This goes beyond setting standards for marketing systems to actually dictating at least some components of the marketing stack.
Rather, what’s happening here is a good-faith effort by IT managers to help their company and its customers. (The word “customer” occurs 139 times in the paper.) Indeed, the paper proposes that technical innovations can lead to entirely new business models. Many of those models will surely integrate marketing functions as part of the whole. The paper also lists opportunities such as using machine intelligence to run systems more smoothly and more flexibly than human operators. Those would benefit marketing systems as much as any others, putting the burden on marketing to justify keeping its system separate.
There may be something oxymoronic about “tightly-integrated, loosely-coupled systems”. But that’s exactly what’s being proposed and it actually makes a great deal of sense. Perhaps the trend of marketing taking control of its own systems has run its course and the pendulum is now swinging back to centralization. If so, marketers, marketing technologists, and martech vendors need to ensure their systems meet the new requirements for loosely coupled integration. In fact, they should do this gladly, because the new integrations promise grand new benefits for companies and their customers.
Friday, March 03, 2017
CaliberMind Offers B2B Orchestration with a Twist
I spent quite a bit of time debating with myself how to classify CaliberMind. But instead of presenting my conclusion and defending it, I’ll just tell you what CaliberMind does. We’ll circle back to classification at the end.
Unify B2B data. CaliberMind ingests data from Salesforce Sales cloud and Marketo, Oracle Eloqua, Salesforce Pardot, and HubSpot marketing automation systems. It reports on missing data and fills in the blanks using data from external vendors. It also uses those vendors to find identifiers belonging to the same person (such as multiple email addresses or alternative company names) and to link contact and lead records to accounts. The system can accept feeds from major advertising systems (GoogleAdwords, Bing, Facebook Ads), from Web analytics (Google Analytics, Mixpanel), and various data stores (MySQL, Amazon Redshift and S3, MongoDB, Apache Hive, etc.). CaliberMind has embedded a third-party data load and transformation tool to manage such inputs. The system stores structured data in Redshift, semi-structured data in MongoDB, and unstructured data in S3.
Report on journeys. CaliberMind system builds an account-level journey visualization that shows different types of events (outbound contacts, inbound contacts, account created, opportunity created, deal won, etc.) on parallel time lines. It imports opportunity stages or account statuses from the source systems rather than creating its own journey stages. Attribution reports show the timing of different types of contacts relative to the date of the final sale, aggregated across multiple accounts. The system doesn’t explicitly report the impact of different contacts but it does consider their effects when recommending which messages to send next.
Create personas. Users can define a list of personas and then assign them profile attributes such as job titles or company sizes. More interesting, they can also submit texts related to each persona. These might be job descriptions, advertising copy, blog posts, video transcripts, email messages, or anything else written in English. (Other languages will be added in the future.) The system uses natural language processing to analyze these and build a profile of what they have in common. This can later be used to determine how closely other texts match each persona. The system can also classify new contacts by persona, based on their profile attributes and associated texts such as content consumed or emails written. The assignments can be adjusted over time as new information becomes available.
Match content to individuals. CaliberMind also uses the texts associated with each contact to build a personal profile. Because the language processor can understand things like level of interest, buyer role, and stage in the purchasing process, it can identify new and generate alerts about important events. The system can also pick up references to other individuals and infer their own roles and interests.
Push results to other systems. CaliberMind draws on its individual-level profiles to push personality insights, engagement tips, and content recommendations to sales people. These can be loaded into the CRM database or displayed in a window on the CRM desktop. CRM users can also see the account-level journey reports and revenue summaries including forecasts. Marketing automation systems could get the same details but usually take more general information, such as persona codes used in segmentation. User-created rules can pick records meeting specified criteria and send them to different marketing automation campaigns. A Salesforce app is pending approval on the App Exchange and Salesforce single sign-on is scheduled for later this year.
Expose detailed data. CaliberMind’s own interface lets users examine the data loaded into the system. Individual-level reports can display details down to the level of single emails or Web visits. These reports are used by marketing, enablement and sales operations teams, not sales people.
These facts should give you an idea why classifying CaliberMind is such a challenge. Its two most notable features are data unification and the personas and recommendations based on natural language processing. The unification and access features make it a Customer Data Platform, while the personas and recommendations make it a Sales Enablement tool. That’s an unusual combination because the marketing and sales domains usually remain separate. You might label CaliberMind an Account Based Marketing system, which also straddles those domains. But there are so many types of ABM systems that it's not a useful classification. CaliberMind itself calls the system an orchestration engine. That's also accurate, since CaliberMind does indeed coordinate messages across channels. But orchestration is another vague term that if understates the main value of CaliberMind, which is less about coordinating messages than finding the best ones. So must best suggestion is to leave categories aside and consider CaliberMind on its own merits.
CaliberMind was released last summer and currently has eleven clients including a mix of mid-size and enterprise B2B companies. Pricing is based on number of contacts and data sources and starts at $2,000 per month.
Unify B2B data. CaliberMind ingests data from Salesforce Sales cloud and Marketo, Oracle Eloqua, Salesforce Pardot, and HubSpot marketing automation systems. It reports on missing data and fills in the blanks using data from external vendors. It also uses those vendors to find identifiers belonging to the same person (such as multiple email addresses or alternative company names) and to link contact and lead records to accounts. The system can accept feeds from major advertising systems (GoogleAdwords, Bing, Facebook Ads), from Web analytics (Google Analytics, Mixpanel), and various data stores (MySQL, Amazon Redshift and S3, MongoDB, Apache Hive, etc.). CaliberMind has embedded a third-party data load and transformation tool to manage such inputs. The system stores structured data in Redshift, semi-structured data in MongoDB, and unstructured data in S3.
Report on journeys. CaliberMind system builds an account-level journey visualization that shows different types of events (outbound contacts, inbound contacts, account created, opportunity created, deal won, etc.) on parallel time lines. It imports opportunity stages or account statuses from the source systems rather than creating its own journey stages. Attribution reports show the timing of different types of contacts relative to the date of the final sale, aggregated across multiple accounts. The system doesn’t explicitly report the impact of different contacts but it does consider their effects when recommending which messages to send next.
Create personas. Users can define a list of personas and then assign them profile attributes such as job titles or company sizes. More interesting, they can also submit texts related to each persona. These might be job descriptions, advertising copy, blog posts, video transcripts, email messages, or anything else written in English. (Other languages will be added in the future.) The system uses natural language processing to analyze these and build a profile of what they have in common. This can later be used to determine how closely other texts match each persona. The system can also classify new contacts by persona, based on their profile attributes and associated texts such as content consumed or emails written. The assignments can be adjusted over time as new information becomes available.
Match content to individuals. CaliberMind also uses the texts associated with each contact to build a personal profile. Because the language processor can understand things like level of interest, buyer role, and stage in the purchasing process, it can identify new and generate alerts about important events. The system can also pick up references to other individuals and infer their own roles and interests.
Push results to other systems. CaliberMind draws on its individual-level profiles to push personality insights, engagement tips, and content recommendations to sales people. These can be loaded into the CRM database or displayed in a window on the CRM desktop. CRM users can also see the account-level journey reports and revenue summaries including forecasts. Marketing automation systems could get the same details but usually take more general information, such as persona codes used in segmentation. User-created rules can pick records meeting specified criteria and send them to different marketing automation campaigns. A Salesforce app is pending approval on the App Exchange and Salesforce single sign-on is scheduled for later this year.
Expose detailed data. CaliberMind’s own interface lets users examine the data loaded into the system. Individual-level reports can display details down to the level of single emails or Web visits. These reports are used by marketing, enablement and sales operations teams, not sales people.
These facts should give you an idea why classifying CaliberMind is such a challenge. Its two most notable features are data unification and the personas and recommendations based on natural language processing. The unification and access features make it a Customer Data Platform, while the personas and recommendations make it a Sales Enablement tool. That’s an unusual combination because the marketing and sales domains usually remain separate. You might label CaliberMind an Account Based Marketing system, which also straddles those domains. But there are so many types of ABM systems that it's not a useful classification. CaliberMind itself calls the system an orchestration engine. That's also accurate, since CaliberMind does indeed coordinate messages across channels. But orchestration is another vague term that if understates the main value of CaliberMind, which is less about coordinating messages than finding the best ones. So must best suggestion is to leave categories aside and consider CaliberMind on its own merits.
CaliberMind was released last summer and currently has eleven clients including a mix of mid-size and enterprise B2B companies. Pricing is based on number of contacts and data sources and starts at $2,000 per month.
Subscribe to:
Posts (Atom)