Inevitably, this begs the question: should you employ your existing DWH as a customer data platform (CDP)? After all, when you re-use an existing component in your stack, you can save resources and avoid new risks.

But the story isn’t so simple, and multiple potential design patterns await. Ultimately, there’s a case for and against using your DWH as a CDP. Let’s dig deeper.

DWH as a CDP may not be right for you

There are several inherent problems with using a DWH as a CDP. The first is obvious: not all organizations have a DWH in place. Sometimes, an enterprise DWH team does not have the time or resources to support customer-centered use cases. Other enterprises effectively deploy a CDP as a quasi-data warehouse. (Not all CDPs can do this, but you get the point.)

Let’s say you have most or all your customer data in a DWH. The problem for many, if not most, enterprises is that the data isn’t accessible in a marketer-friendly way. Typically, an enterprise DWH is constructed to support analytics use cases, not activation use cases. This affects how the data is labeled, managed, related and governed internally. 

Recall that a DWH is essentially for storage and computing, which means data is stored in database tables with column names as attributes. You then write complex SQL statements to access that data. It’s unrealistic for your marketers to remember table and column names before they can create segments for activation. Or in other words, DWHs typically don’t support marketer self-service as most CDPs do. 

This also touches on a broader structural issue. DWHs aren’t typically designed to support real-time marketing use cases that many CDPs target. It can perform quick calculations, and you can schedule ingestion and processing to transpire at frequent intervals, but it is still not real-time. Similarly, with some exceptions, a DWH doesn’t want to act off raw data, whereas marketers often want to employ raw data (typically events) to trigger certain activations.

Finally, remember that data and the ability to access it don’t maketh a CDP. Most CDPs offer some subset of additional capabilities you won’t find in a DWH, such as:

• Event subsystem with triggering.
• Anonymous identity resolution.
• Marketer-friendly interface for segmentation.
• Segment activation profiles with connectors.
• Potentially testing, personalization and recommendation services.

A DWH alone will not provide these capabilities, so you will need to source these elsewhere. Of course, DWH vendors have sizable partner marketplaces. You can find many alternatives, but they’re not native and will require integration and support effort. 

Not surprisingly, then, there’s a lot of chatter about “composable CDPs” and the potential role of a DWH in that context. I’ve argued previously that composability is a spectrum, and you start losing benefits beyond a certain point. 

Having issued all these caveats, a DWH can play a role as part of a customer data stack, including:

• Doing away with a CDP by activating directly from the DWH. 
• Using the DWH as a quasi-CDP with a reverse ETL platform.
• Coexisting with a CDP.

Let’s look at these three design patterns.

1. Connecting marketing platforms directly to your DWH

This is perhaps the most extreme case I critiqued above, but some enterprises have made this work, especially in the pre-CDP era and platforms (like Snowflake with its broad ecosystem) are looking to try to solve this.

The idea here is that your engagement platform directly connects to push-pull data with a DWH. Many mature email and marketing automation platforms are natively wired to do this, albeit typically via batch push. Your marketers then use the messaging platform to create segments and send messages to those segments in the case of outbound marketing.

Imagine you had another marketing or engagement platform, a personalized website or ecommerce platform. Again you draw data from DWH, then employ the web application platform to create another set of segments for more targeted engagement.

Do you see the problem yet? There are two sets of segmentation interfaces already. What happens if you had 10 marketing platforms? 20? You will keep creating segments everywhere, so your omnichannel promise disappears. 

Finally, what if you had to add another marketing platform that did not support direct ingestion from a DWH?

2. Employ DWH with reverse-ETL tools

This approach solves several problems with the first pattern above. Notably, it allows (in theory) a non-DWH specialist to create universal segments virtually atop the DWH and activate multiple platforms. With transformation and a better connector framework, you can apply different label mappings and marketer-friendly data structures to different endpoints.

Here’s how it works. Reverse ETL platforms pull data from the DWH and send it to marketing platforms after any transformation. You can perform multiple transformations and send that data to several destinations simultaneously. You can even automate it and have exports run regularly at a predefined schedule.

But a copy of that data (or a subset of it) is actually copied over to target platforms, so you really don’t have just a single copy of data. Since the reverse-ETL platform does not have a copy of data, your required segments or audiences are always generated at query time (typically in batches). Then you export them over to destinations.

This is not a suitable approach if you want to have real-time triggers or always-on campaigns based on events. Sure, you can automate your exports at high frequency, but that’s not real-time. As you increase your export frequency, your costs will exponentially increase.

Also, while reverse-ETL tools provide a segmentation interface, they tend to be more technical and DataOps-focused rather than MOps-focused. Before declaring this a “business-friendly” solution suitable for marketer self-service, you must test it carefully.

3. DWH co-exists with CDP

Your enterprise DWH serves as a customer data infrastructure layer that supplies data to your CDP (among other endpoints). Many, if not most, CDPs now offer some capabilities to sync from DWH platforms, notably Snowflake.

There are variations in how these CDPs can co-exist with DWH. Most CDPs sync and duplicate data into their repository, whereas others (including reverse-ETL vendors) don’t make a copy. However, there could be trade-offs you need to consider before finalizing what works for you.

In general, we tend to see larger enterprises preferring this design pattern, albeit with wide variance around where such critical services as customer identity resolution ultimately reside. 

Dig deeper: Where should a CDP fit in your martech stack?

Wrap-up

DWH platforms play increasingly essential roles in martech stacks. However, you continue to have multiple architectural choices about which services you render within your data ecosystem.

I think it’s premature to rule out CDPs in your future. Each pattern has its trade-offs to keep in mind while evaluating your options. 

The post Should you use your data warehouse as your CDP? appeared first on MarTech.

At Real Story Group, we’ve seen three broad approaches, including variants of each:

• Licensing a CDP from your anchor martech suite.
• Deploying a best-of-breed CDP.
• Using components to build requisite CDP functionality. (I explored the third approach in an earlier article, but I’ll expand further here.) 

Of course, these are not mutually exclusive. In some cases, an enterprise will want to take a hybrid approach. Nevertheless, they provide a useful contrast, so let’s dig deeper.

Approach 1: CDP from an anchor suite

Many suite vendors — SAP, Adobe, Oracle, Salesforce and Microsoft — sell broad marketing suites supported (to varying degrees) by an optional CDP they fervently wish you to license. 

On the buyer’s side, I understand the temptation. Why not try to simplify the choice? Some consultants and analysts push this approach, too.

Our research suggests otherwise, and we have seen many poor-fitting solutions based on a casual CDP selection. Here are a few possible reasons.

• Recall that major martech vendors have mostly cobbled together their suites via acquisition. Thus, the genesis and evolution of their CDP offerings are foremost to integrate all those acquired products. 
• These vendors have in some cases a questionable track record of sustaining a positive relationship with your martech team.
• These CDPs tend to remain comparatively immature.

There’s no harm in considering a suite vendor’s CDP add-on. But make sure you select it on its merit and not because it comes from an incumbent supplier. 

Dig deeper: Customer data platform (CDP) buyer’s guide

Approach 2: Deploy a best-of-breed CDP

There are dozens of specialized CDPs in the marketplace. CDPs can provide a wide range of functionality, and consequently, the market is wide, fragmented, and characterized by many different approaches to feature sets and architectures. 

So there’s a good chance you can find the right-fit packaged solution, which is always a boon. Do remember, though, that even with a best-of-breed CDP, someone will likely have to perform a lot of development and integration work. 

Approach 3: Assemble components

Instead of using a packaged CDP, you “compose” your CDP using other components. Most enterprises already have some sort of data warehouse (DWH) and/or data lake. So instead of copying that data over from a DWH into a CDP, why not use your DWH as your CDP?

Of course, a DWH is not a CDP, so this approach requires other components to build a CDP-like layer. At the very minimum, you’d need a reverse-ETL tool to pull data out of your DWH and then push it to activation channels.

But that’s not sufficient. You’d also need components for other capabilities that a CDP provides: 

• Data ingestion.
• Identity resolution.
• Data quality management.
• Marketer-friendly segmentation.
• Triggers.
• Activation
• And, potentially, orchestration. 

Now, you may not need all these, so you can pick and choose to build exactly what you need. Remember that, to some degree, you are building software here. What’s interesting for the developer may prove sub-optimal for the business stakeholder.

Some proponents of this CDP-by-assembly have gone to the extent of claiming that CDPs are dead and that this approach is all you need. I disagree. There is a time and place for all three approaches.

Composability as a spectrum

By nature, modern martech stacks are “composable.” I believe that the three approaches above really represent a spectrum of composability. As you move from “suite bolt-ons” to “packaged best-of-breed” to “componentized” (and maybe even beyond to complete DIY), the granularity of composability increases.

Initially, as the granularity increases, you get more in terms of functionality and capabilities. But a further increase in composability only brings diminishing returns in terms of out-of-the-box functionality, albeit with a more purpose-built solution.

What are the trade-offs?

There is no “one size fits all” in this marketplace, and there are always trade-offs. 

Componentization allows you to build a more purpose-built solution that may better fit your current needs while potentially quicker to get started.

That said, as your needs evolve or new requirements are added, you will likely need additional components and invest more time and resources to build something that is probably available as out-of-the-box in a best-of-breed tool. Consequently, as your requirements and components expand, the complexity of the stack will also increase. 

How should you decide?

The figure below provides a framework for deciding which approach is more suitable for you. It describes various trade-offs and how each of these approaches can impact your stack complexity, fit to purpose, range of functionality, total cost of ownership and ease of implementation. 

You can see each of the approaches has its pros and cons. A best-of-breed CDP provides support for a broad range of use cases and allows you to scale up to add support for additional use cases gradually. 

The “componentized” approach allows you to build something specific to your current requirement. It may be easy to start with (“We can get your data from Snowflake and send it to your email platform in 5 minutes”). But as your requirements become more sophisticated, you need more piece parts, making your stack even more complex.

So again, there are no pat answers here.

The post Where should a CDP fit in your martech stack? appeared first on MarTech.

Is there a single right approach? I don’t think so, but the details matter here.  So let’s dig in.

Build vs. buy

Traditionally, two main approaches for obtaining enterprise functionality have been:

1. Buying an off-the-shelf package and then customizing it for specific needs.
2. Building a platform in-house, specifically for your requirements, sometimes via packaged piece parts.

Both approaches have valid rationales, and over the past two decades as an industry analyst, I’ve seen this choice emerge in pretty much all technology marketplaces. However, the boundaries between build and buy in CDPs can become fuzzier.

Part of the challenge is that packaged CDPs can vary substantially in scope. Some have great vertical depth, reaching back into the enterprise to perform upstream data processing or extending forward to the engagement tier to provide real-time interaction. Some packaged CDPs offer lateral services around orchestration, campaign management and even outbound messaging.

So before deciding on the right approach, it is important to answer what a CDP will do specifically for your enterprise.

What does a CDP do (for you)?

The model shows different stages in a data life cycle, regardless of specific technology platform. Your customer data probably goes through all these stages:

1. You need to obtain data from various online and offline data sources before you can do anything with it. Therefore, you need some mechanism to ingest data, clean it, perform some transformations and aggregation, and ensure quality.
2. Once the data is collected or ingested from different sources, you need to tie it to user profiles. That includes activities such as identity resolution and profile unification. You also enrich your profiles with additional data while ensuring data governance and compliance.

In a larger organization, these two initial phases typically transpire within part of a broader enterprise data “fabric” or “mesh.” The typical enterprise already possesses data management tooling to handle these services – like data lakes, warehouses, ETL tools, quality and governance, etc. – and applies them to customer data. However, as we’ll see below, many packaged CDP tools also provide some of these services. In any case, enterprise IT and Data teams become important stakeholders in these first two stages.

• The next stage is where you use all this cleaned-up, aggregated, unified profile data for your business objectives. For example, now that you have profiles or 360-degree views of your users or customers, you can segment them based on different attributes. You can slice and dice the profiles, create cohorts, group similar data, create audiences and so forth – and then, critically, activate that data through various channels.
• This stage is the last mile where you engage with your customers via ecommerce, email, web, mobile, chat or other channels, using personalized content and product recommendations.

You see considerably higher marketing and customer experience teams’ involvement in these latter two stages.

In theory, all these services can be potentially addressed by a CDP. You will often find CDP vendors boasting they can perform all these stages equally well.

In practice, though, we see several variations of this model. See, for example, the different scopes for Company A, B and C in the diagram. Rarely do large, complex enterprises deploy a single platform for all these stages. There are at least two reasons for that:

1. As you can see, the overall potential functionality is quite broad, and large enterprises already have existing initiatives outside of CDP for several of the stages (or functionalities within those stages) identified above. These functionalities often include data pipeline management, machine learning ops, and identity resolution, to name just a few.
2. Despite what vendors claim, the truth is they are never equally good at all these stages. They can usually do only one or two of these stages well.

Therefore, where a CDP fits in your martech stack could differ from where it fits for another company. This then affects any build versus buy decision since the question initially becomes: build or buy precisely what? Even if you license an off-the-shelf CDP for some functionality within the model above, you will likely build extensions for missing capabilities.

So the first lesson: you will likely do some build and some buy, regardless of the overall strategy. The question then becomes: in what proportions?

Assembling from piece parts

One approach potentially open to you is assembling components to build CDP capabilities instead of developing from scratch or buying a more wide-ranging, general-purpose CDP off-the-shelf.

This approach has some appeal because you may already possess some powerful data management capabilities as part of your broader customer data fabric.

You can also license specific products for these different functionalities. Several vendors offer components for such functionality. For example:

• Data ingestion: There are specialized data ingestion vendors and modules from CDP vendors themselves. Vendors such as Stitch (acquired by Talend), Snowplow, Fivetran, Matillion and others provide modules for data ingestion, data pipeline management, transformations and other relevant functionality.
• ETL and ELT: Many vendors target Extract-Transform-Load (ETL), Extract-Load-Transform (ELT) and Reverse-ETL/ELT for different types of transformations that you can do with your raw data. Examples of vendors in this category are Hevo Data, Hightouch, DBT and Census.
• Data warehouses and Data Lakes: Several data warehouses and data lakes, including Snowflake, Google and others, include data management and processing functionality. Many packaged CDP architectures already assume that source data will come from this environment.
• “Virtual” CDPs: Some vendors, such as Aqfer, Rudderstack, and some other players, offer some services for cobbling together a CDP with a decoupled data layer.
• Identity Resolution: Several vendors target identity resolution. Many CDPs have now given up their own identity resolution efforts, and are instead of partnering with vendors such as Neustar, Infutor,  LiveRamp, and others.
• Engagement: The marketplace for engagement-oriented products remains quite vibrant. You can find many point solutions that target journey orchestration, campaign management, personalization, recommendations and other engagement use cases. Several packaged CDPs are also strong in this area.

This isn’t an exhaustive list of services, and you can find many other specialized vendors (e.g., those providing governance solutions). The key point is that it is possible to assemble these services to have a composable data ecosystem instead of doing everything using a single CDP.

Dig deeper: Deep changes in the CDP space

What you might miss

By now, you’ve probably figured out that a couple of key CDP services are missing from that list above: business-friendly segmentation and activation. These are more challenging capabilities to purchase off the shelf, and at RSG, when we’ve seen home-grown CDPs, typically, the enterprise will build these business-user interfaces from scratch. When we hear enterprise developers arguing, “let’s just employ our data warehouse as the data layer instead of a CDP,” this is typically where they are headed.

I would caution you about this approach, though, because custom segmentation and activation tooling could prove fragile, and advanced UX design is a big part of what you pay for in a CDP (though to be sure: not all CDPs are equally good at this).

What you should do

Recognize that your CDP effort will undoubtedly include some measures of both build and buy. It’s just a question of proportion and location. Even if you license a packaged CDP – and there are good reasons to do so – you will need ample development work to stitch it into the rest of your customer data fabric, let alone your front-line engagement systems.

The jury remains out on a single best approach for this, but design patterns are emerging. Consult this briefing for more details.

In the meantime, as you look to build your customer data management muscles over the next year, keep your data scientists close but your developers even closer.

The post The Real Story on MarTech: Should you build or buy a customer data platform? appeared first on MarTech.

Scenario analysis

While you should always consider product functionality and vendor predilections, the most important key to comparing technologies lies in how well they fit your particular business use cases, what Real Story Group calls “scenarios.” In our experience, scenario analysis provides the most efficient shortcut for finding the best-fitting solutions and architectures.

Explicitly or not, different personalization technology platforms target different use cases. This is usually because they were often created for addressing a specific need. Over time, they may have broadened their scope but initial roots remain visible — and typically decisive.

In this case, several personalization platforms started as simpler services for providing A/B testing. Some others started their journey offering website personalization and have broadened from there, though typically the newer services remain less rich.

Understanding the business scenarios that fit better or worse for the different platforms enables you to see deeper into their relative strengths, weaknesses, and architectural compatibility for your particular circumstances. Therefore, RSG has identified four common scenarios against which personalization platform vendors can be judged.

Before we get into details of each, some important considerations to keep in mind:

• These scenarios are abstractions. In practice, your own efforts here are likely to represent variants or a hybrid combination of scenarios. The cases overlap somewhat, but they are useful for understanding what types of products tend to work better for different types of projects;
• RSG uses these as model scenarios for evaluating vendors, including personalization platforms. However, in your own tech selection efforts, you should specify your own unique use cases against which to test vendors;
• The scenarios in the figure roughly form a maturity spectrum from left to right. As you move across that spectrum, you will need more preparedness in terms of capabilities required as well as a deeper understanding of how to deploy personalization services strategically. But as you mature, you can use these scenarios to reinforce each other; e.g., using Testing & Optimization to inform Ecommerce Recommendations.

Now let’s dive in on each.

Scenario 1: Experimentation

Experimenting with logic, content, design, and other elements is an almost universal requirement, and increasingly begs omnichannel capabilities. This is a scenario that most personalization vendors support. In fact, several personalization tools, including Optimizely and Adobe Target, started life with this scenario.

Common capabilities are:

1. A/B Testing, or more advanced A/B/..N testing: This compares two or more versions of content to see which works better for specific goals;
2. Multivariate testing: As the name suggests, it compares multiple variables, so you can compare combinations of different elements that can include not just variations of content elements (e.g., headline) but also variations of design elements (e.g., image or call to action); and
3. Optimizations based on test results.

Most tools now support machine language-based mechanisms to carry out splits, tests and optimizations. Where they differ — substantially — is in their omnichannel capabilities, e.g., the ability to stripe a single test across multiple different customer touchpoints. 

Scenario 2: Web Personalization

As the name suggests, this scenario targets web sites and applications; i.e., deploying personalized content or services on one of your own digital properties. Like testing, it can be based on behavioral and contextual signals, but increasingly enterprises are trying to leverage first-party profile data.

This sort of inbound personalization isn’t new, and some of you have been fiddling with rules engines for as long as two decades. Today, rules-based techniques are slowly giving way to Machine Learning-based algorithms, often based on session behavior rather than customer profile. RSG has found that enterprise experience with these techniques remains mixed, however.

Scenario 3: Outbound Personalization

This scenario caters to personalizing messages, mostly via email but also via text and in-app messaging.

Personalization here allows you to tailor message content to segments or individuals, and perhaps trigger messages based on behavior or events, as well as testing/optimizing outbound communications as you would inbound web experiences.

Some personalization platforms integrate with email marketing platforms. However, the sophistication of integration varies. A few platforms provide advanced capabilities for email templates and email content on their own. In other cases, the email marketing vendor itself may provide channel-specific personalization services.

Scenario 4: Ecommerce Recommendations

Online retail and ecommerce more generally is a special use case for personalization. Since it promises a direct impact — increased sales — vendors have focused on advanced capabilities here.

Key functionality might include product recommendations, cross- and up-sells, cart-related triggers and more. Several personalization solutions provide specific point solutions for ecommerce, whereas others integrate with ecommerce platforms. 

Machine Learning-based recommendations can also play an important role here in selecting the right audiences, or an optimal set of products, bundles, offers, and so forth.

Dig deeper: The first two parts of this three part series

What you should do

Scenarios offer the most useful initial approach for contrasting key strengths and weaknesses of different personalization platforms. There are at least two ways you can use these scenarios for your benefit.

First, scenarios can help you clarify architectures. In part 1 of this series, we addressed an important question: Where should personalization reside in your omnichannel martech stack? Business use cases should weigh heavily here. For example, if you’re really keen on just website personalization (second scenario) and nothing else, then channel-based personalization embedded into your WCM may not be a bad option to consider. But if you wanted to support all these scenarios, you probably need a dedicated Personalization Engine.

Secondly, once you’ve decided where it should reside, you can use scenarios to select the right products for your needs. At RSG, we use scenarios customized to your specific needs to generate custom vendor quadrants suitable for your requirements. You should follow a similar approach. Let me know if we can help.

The post Universal scenarios: The key to comparing personalization technologies appeared first on MarTech.

Unified customer data as table stakes

For successful personalization, you will need other enablers and indeed some prerequisites. Of the latter, unified customer data should become your first priority. And this means first grappling with the full lifecycle of customer data, which has at least five phases:

1. Data Ingestion: You have to first ingest all kinds of data from zero-, 1st-, 2nd- and 3rd-party data sources. This data can be batch or real-time, may come in different formats and via diverse ingestion mechanisms — but not matter what, first you have to successfully source it.
2. Data and Profile Management: Once you collect and ingest data from different sources, the next step takes it through basic management tasks  such as cleansing, de-duping, normalizing and so forth. Once normalized you need processes to stitch data together into unified user profiles. Without this, how are you going to know that M. Kelley and Masha Kelley are (or are not) the same person? 
3. Segmentation: Once you have unified profiles of all your prospects and customers, you can then segment them based on different attributes. The resulting segments and audiences provide the foundation for customizing different experiences for different groups.
4. Analytics: These segments then form the basis for analytics and insights. You can run simple analytics, or you can run more sophisticated models, including predictive analytics via advanced machine learning techniques.
5. Personalization: The final step in this data lifecycle is activation, or putting all this data and these segments to work. That means acting on your data to address experience personalization, product recommendations, or related use cases.

There may be more stages depending on your situation, and the sequencing might vary. Moreover, the scope of a customer data platform (CDP) may vary across this lifecycle. To learn more about different architectural models for addressing customer data management, check out this recorded briefing.

Other prerequisites

Meanwhile, your personalization strategy will require several adjacent capabilities to work on that data. We’ve already covered customer identification, across channels and transactions, and over time. From there you need to:

1. Decide what to present to customers, and when, based on context, behaviors, profiles, and preferences across channels and devices;
2. Manage assets that underpin personalized experiences across multiple channels. Think content items, offers, news, discounts, and other assets; and
3. Analyze the effectiveness of your work, to keep improving the relevance of your offerings

A holistic technology strategy

So as you can see, in terms of technology, these prerequisites map to specific technology components or layers. I won’t label this a “stack,” per se, but it’s a collection of services you need to mature and integrate as part of a holistic technology strategy to become truly effective. Let’s review the main pieces. 

1. Uniquely Identify Customers <-> Customer Data Platform: Uniquely identifying your customers requires consolidating data from various sources, resolving identities and associating disparate transactions to unified user profiles. This roughly maps to Customer Data Platforms and —as discussed earlier — other components in your customer data fabric, such as underlying data warehouses and lakes.
2. Decide When/What to Present <-> Decisioning Services: The ability to create and manage rules or other decision logic, such as sending a particular message at a particular journey point, or showing a specific offer based on session context. Journey Orchestration and Customer Journey Management platforms can begin to enable this sort of decisioning, even if both market segments remain somewhat immature. 
3. Manage Assets <-> Content Platform: Manage and distribute content and digital assets such as micro-content, images, offers, campaign content, and other types of content fragments. Omnichannel Content Platforms and (in a more limited way) Digital Asset Management systems can help you do this.
4. Analyze the Effectiveness <-> Analytics Ecosystem: Note the plural; you may need several types of platforms to glean the right insights and build more meaningful models, including potentially predictive ones.
5. Give Them What Is Relevant <-> Personalization Service: Finally, taking the required relevant action will require you to be able to offer relevant content and experiences, as well as product recommendations.

Think of the these components as distinct services, though not always marketplaces, since some packaged platforms will cover more than one service. For example, it might be possible for your CDP to also provide light personalization or orchestration capabilities.  But regardless of whether you deploy one or multiple platforms, they remain distinct services, and you’ll need both a business and technology strategy around each.

The other concept that’s implied here is that you can (and should) abstract these capabilities from your engagement tier so that you can run them as omnichannel services. This becomes particularly important with respect to your personalization strategies, where customers quite naturally assume you will address their specific needs across all touchpoints, and not, for example, send them an offer in email that your website doesn’t recognize.

Personalization components as part of your larger omnichannel stack. Source: RSG

What you should do

Personalization in an omnichannel world is no longer a single module you can drop into a customer experience environment. Moreover, you can’t just license a personalization platform and hope it will magically improve your customer experience. Your personalization strategies will require several adjacent capabilities beyond simple targeting logic, especially those that relate to granular management of data and content.

Therefore, when considering personalization initiatives, you should take a holistic view and remember that several technology components need to work with each other as part of a coherent stack.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps enterprises make better marketing technology stack and platform selection decisions.

The post The Real Story on MarTech: A holistic personalization technology strategy appeared first on MarTech.

• Greater attention to test and optimization leading to demands for more “always-on” personalization programs;
• Better access to customer data and segments, opening up possibilities for more targeted experiences in any digital setting;
• Emergence of AI and ML-based approaches for automating personalization logic; and
• Heightened customer expectations for relevancy, leavened by experience with major consumer platforms like Netflix.

However, martech leaders today still struggle to implement personalization, even those at big companies with ample resources.  And those who have gotten smarter about targeting people in individual channels must now confront the challenge of coherent personalization across an ever-growing set of channels.

This raises the first question to answer in my three-part series of articles on Personalization at Scale: Where should personalization reside in an omnichannel martech stack?

A legacy of silos

For the past two decades, that question went mostly unasked.  Personalization just emerged as a possibility within distinct silos.  Let’s dig a bit into the history here.

A modern martech stack consists of channels at the top, where you interact with prospects and customers. You then have interaction and delivery environments as well as engagement platforms underneath. During the 2000s and 2010s, this drove vendors at every level to build out personalization services within their discrete platforms, including:

• Web Content & Experience Management (WCM) platforms, to personalize content-heavy website experiences; 
• Campaign Management and Outbound Marketing platforms, to personalize email and other messages;
• Ecommerce systems, to generated personalized shopping recommendations;
• CRM platforms to recommend next-best actions and conversations in a sales or support context;
• And so on…

Hence the legacy of personalization silos, with all the attendant disadvantages.  Lacking an easy way to standardize or even align those rules everywhere, your targeting logic gets trapped in individual delivery channels.  This in turn leads to incoherent and potentially frustrating customer experiences.  A customer might get an offer in an email on a product that later she can’t find in your storefront, while searching your website in vain for further information, only to be delivered a different recommendation by your WCM platform. She calls a service rep who makes yet a different recommendation. Not good.  But what are the alternative solutions?

Your options for seating personalization in your stack

There are at least three places in your stack where you can seat a personalization service. Of course, there is no single right answer, and you could mix and match different strategies for different scenarios. 

1. Personalization in channels

This entails living with the status quo described above, and trying to optimize it as much as possible. In some cases, this strategy may still work well for you. First of all, it’s the easiest and fastest way to “grow into” personalized experiences, but you may find other benefits as well.

For example, this approach offers the tightest integration within your experience layer. So in your WCM platform you can very tightly couple your personalization logic with website content variants. Where content managers double as targeting managers, this can work very well. 

The downside, as discussed above, is that you inevitably lose uniformity, consistency, or standardization across channels unless you muscle through with a lot of manual coordination, which typically isn’t sustainable.

2. Personalization as part of a data platform

The next option is to have personalization as part of an omnichannel data platform, such as a Customer Data Platform (CDP) or a Journey Orchestration Engine (JOE). 

Several CDPs and almost all JOEs provide some subset of personalization capabilities built on top of their data management capabilities or as an integral part of their orchestration capabilities. In some cases the capabilities may prove light, but you get the benefit of operating them close to the all-important customer data.  So, for example, if someone’s status changes — like a subscription expires — you can send them personalized win-back communications.  Critically, you should be able to execute this across multiple platforms, including your call center, since the personalization logic isn’t “stuck” in any one channel.

There are downsides to this approach.  Weaker integration with channels could lead to issues such as duplication of personalized content blocks. You may also encounter challenges trying to achieve bi-directional, real-time data exchange between your data layer and your engagement layer. 

3. Personalization as a dedicated service

The last option is a dedicated personalization platform as a standalone tool in your stack.  In some sense, this approach echoes the data-centric approach as it becomes a foundational service disconnected from any channel. Just remember that personalization works best when you have ready access to authoritative customer data, and so this approach does not obviate the need for unified, normalized, and accessible customer profiles.

The major benefit is that dedicated personalization engines can theoretically provide you a whole gamut of personalization capabilities – from multiple types of recommendations to testing of different types, and so on.

On the downside, RSG’s new Personalization Platform vendor evaluation research suggests that many of these solutions remain under-tested in the wider marketplace.

What you should do

As you can see, the three approaches bring their own trade-offs.  Here’s a handy summary, based on RSG’s experience working with large enterprises.

In general these alternatives represent a kind of maturity spectrum, but also potentially a journey towards a more elegant (read scalable and sustainable) architecture. 

Of course, these approaches are not mutually exclusive and we often see enterprises deploying them in combination. So for some tactical wins, you might apply channel-specific personalization, whereas in the longer term, or fpr more strategic, scalable, and omnichannel use cases, you might end up deploying a separate, dedicated platform layer.  

Finally, personalization technology does not exist in a vacuum.  For the next post in this series, I’ll look at the specific capabilities necessary to succeed with personalization at scale.

Real Story on MarTech is presented through a partnership between MarTech and Real Story Group, a vendor-agnostic research and advisory organization that helps enterprises make better marketing technology stack and platform selection decisions.

The post The Real Story on MarTech: Where should personalization reside in your new stack? appeared first on MarTech.