Sitecore Personalize with Sitecore XM

If you have been working with Sitecore XP for a while you are familiar with xDB and how you use it for tracking and personalization. With Sitecore embracing a flexible and decentralized model, it seems that XP and xDB are on their way out in favor of Sitecore’s brand new CDP and Personalize products. These products are standalone products that can work with any platform not just Sitecore, and not just web!

The Content Problem

On paper this new platform sounds great, especially if you ever had problems with xDB, needed to rebuild it or troubleshoot it. But looking at all the documentation and examples the personalized content lives in Personalize. You have to “hard code” different variants of html and the is code to replace the html of your site with the variant you created in Personalize. The problem is obvious: now I have to manage content in the CMS and in Personalize.

The Personalize API Approach

One of the solutions the common solutions that I found is by using the Personalize API. The idea of this approach is you first create a decision model in Personalize. The decision model returns who the user is based on the logic we define in the decision model.

In our backend code we call the Personalize API with the identifier to get the result from the decision model. Now that we know who the user is we can set the rendering’s datasource accordingly to some internal logic. This is a great blog post describing this

One issue with this approach is it creates a heavy dependency between Sitecore and Personalize. In order to make this flexible, a heavy integration layer will need to be engineered in order to make this approach flexible.

External Data System Approach

Another promising solution that I have been exploring is by using External Data System in our decision models. In this method, we can manage our personalized content in Sitecore and feed it to Personalize decision models to decide which data to present. We then pass that data from the decision model to the variant that was set up in Personalize to be fed back into our website.

To set this up first we need to set up a connection. This can be done by going to Developer Center -> Connections. You then create a new connection to your Sitecore. Experience Edge with GraphQL is probably the best way to connect to Sitecore, but you can also expose the CM and use the content API, or even create your own API layer. Once this is set up you are free to use it in your decision models!

The downside to this approach is that if your data changes, you will need to update your decision model logic. Also, your HTML and CSS for your variants will need to live in Personalize. This might not be an issue with simple components, but for more complex ones it might become cumbersome.

Final Thoughts

I believe that the external data approach is what is going to win out in the end. It seems to fit Sitecore’s composable model better than the API approach. In future blog posts I plan to detail the full implementation of the External Data System approach, and detail the pros and cons as well as limitations I hit. Stay Tuned!

Leave a Comment