The limitations of ‘real-time’ CDP use cases

Just because a CDP can do some things in real time doesn’t mean it will be able to do everything you want to do in real time.

Customer data platforms (CDPs) can consolidate data across an enterprise to create a single view of the customer. That single view can empower marketers to do many things, including real-time updates and activations. 

But “real-time” execution is tricky and depends on many factors. Just because a CDP can do some things in real time doesn’t mean it will be able to do everything you want to do in real time. Here are some limitations in the context of a few “real-time” use cases. 

Personalization 

The “single view of the customer” created with a CDP allows a marketer to have all the available data about a customer to empower appropriate activations. Many of those involve different types of personalization. 

Dynamic content personalization enables a website or app to customize what is displayed to a user based on past interactions, browsing history, membership in certain segments, or purchasing behavior. Part of developing a successful program is determining how “real time” the data can be and how important immediacy is to the use case. 

Customizing content recommendations based on in-session browsing history differs from content recommendations based on membership in a group, like “people who have read articles about bicycles.” 

• In the first case, the CDP has to have immediate access to in-session browsing data and be able to update profiles and segments quickly. 
  
• In the second case, it might not matter if the data is from (September 28, 2023) or even last month. 

Dynamic email personalization extends that concept to the creation of an outbound email message. Different applications might be more or less time-dependent. A weekly email that includes excerpts of the five top stories in a user’s favorite category doesn’t have the same immediacy as a customized confirmation email after a purchase, which might need an updated link to track a package, an estimated delivery date, or some other “right now” data from a fulfillment house. 

If you want to send such “real-time” email confirmations, ask yourself:

• Does the CDP have real-time access to shipping and fulfillment information? 
  
• How often is it updated? 
  
• Does the relevant data have to be transformed before being loaded into a customer profile? 

Location-based personalization is useful for brick-and-mortar stores. A restaurant or bar might want to extend special offers to people in the neighborhood, and a big box store might want to display different information for people in the store (such as aisle and bin locations). In each case, the question is what information is required to fulfill the use case and whether that information is available to the CDP in real time. 

Let’s take the first case as an example. Assume I have an app for my favorite restaurant, and I have enabled location services in that app. If that information is available in real time to the CDP, the CDP could orchestrate a campaign to send a notification to the app with an appropriate marketing message. If I’m a sushi fan, it might tell me about the day’s specials. 

Many things are possible, but implementation depends on how frequently the data is updated and how quickly the activation can be orchestrated. 

Ecommerce 

Many real-time use cases involve online stores. Sometimes, the store software can orchestrate these use cases without the help of a CDP. But in others, the use case requires access to the more extensive customer information in the single customer record of the CDP. 

As with the examples above, functionality in the CDP depends on how frequently that information is updated and available to be used. There are several things to consider here. Just because you have a data connection doesn’t mean you have up-to-date data. 

Data might be batched overnight or updated hourly throughout the day. One system might make a call to another to retrieve a particular bit of information. The type and timeliness of the data transfer might vary from connection to connection. 

And that’s not the only limitation. Sometimes data has to be processed before it’s loaded, and profiles and segments might not update immediately in any case. (Check out David Chan’s great article on that subject.)

Here’s a good illustration of the challenges with this type of use case. 

Inventory management is crucial to a business that sells physical products. You don’t want to sell a widget if you don’t have any of them in stock. So, the first requirement is to have a real-time connection with the fulfillment software. But that’s not enough. 

You need to know if the fulfillment software is updated in real time. What if you take orders on the phone, in the mail, and in your e-store? Does the inventory management system have all the data up-to-the-minute?  

Usually, you can inject a fudge factor into these sorts of calculations. For example, a product is “out of stock” if the inventory management system reports fewer than 10 items are available. But the important point is that you have to follow the data through the chain. It doesn’t matter if the CDP continually pings the fulfillment software and has constant, continuous updates if it is the latter that’s not updated in real time.

Fraud detection 

Credit card companies monitor many types of fraud, which protects your ecommerce operations. But credit card fraud isn’t the only fraud. 

Account takeover fraud might happen when an unauthorized user obtains login credentials. A CDP can track this by noticing if a login occurs on a different device or from a strange location. This use case requires prompt action. It might involve sending a text or an email to the account holder to verify the login. 

If the CDP is not managing logins, this use case requires real-time access to the system that is managing them. 

Password sharing is a common problem for subscription services. A CDP can be useful in detecting this activity by monitoring simultaneous logins, login locations and devices. Once again, if the CDP is not managing logins, it needs access to the system that does — although, in this case, it might not have to be in real time. 

Third-party data 

Sometimes, a company might want to enrich web visitor information with data from a third-party provider. For example, some services can determine if a visitor’s request comes from inside a company’s intranet. That can be very useful in determining what kinds of information or offers to present to the visitor. 

However, it’s not always possible to do this in one browser session because competing processes are running simultaneously. Ideally, it would happen like this, in this order. 

• An HTTP request is made to the server. 
  
• A plugin makes a call to gather the third-party data. 
  
• The third-party data is ingested into the CDP. 
  
• The CDP runs the appropriate process to adjust the display on the page. 
  
• The web server loads the page with the correct information. 

Unfortunately, you can’t guarantee that things will happen in this order. For example, the plugin might make the call to get the third-party data while the web server is already rendering the page. In such cases, it’s often wise to do your customizations on the second page view. 

Conclusion 

It’s impossible to cover all the examples where a CDP might want to process data in real time. Still, I hope these examples have pointed out some potential barriers to successful “real-time” implementation. Remember: 

• Connections to back-end data are not always in real time. 
  
• The back-end data itself might not be updated in real time. 
  
• Data ingested into the CDP might need to be transformed before it’s loaded.
  
• Segments and profiles might not be updated immediately. 

Use cases need to be designed with all these limitations in mind. 

The post The limitations of ‘real-time’ CDP use cases appeared first on MarTech.

(10)