Reading time: 8 min read
Choosing the Right Personalization Method in Sitecore XM Cloud
Navigating between CDP & Personalize vs. Pages Personalize vs. in-code tailored digital experiences.
Start typing to search...
Providing generic digital experiences is no longer sufficient in the hyperconnected world of today. Consumers desire and expect individualized experiences that are catered to their own requirements, tastes, and habits. Personalization has gone from being a "nice-to-have" to becoming a necessity for any company hoping to increase conversions and create enduring relationships.
At the forefront of this development is Sitecore, which provides a set of tools to assist businesses in providing these customized experiences. However, the sheer variety of possibilities, like Sitecore CDP and Personalize, Sitecore Pages Personalize, and even the possibility of in-code personalization, can occasionally cause confusion. When is the right time to take advantage of a customer data platform's extensive capabilities? When is the website's built-in personalization enough? And is custom code still the solution in some situations?
It's important to have a basic idea of what we mean by "personalization" in the context of a digital experience platform before delving into the intricacies of each Sitecore product. Fundamentally, personalization is the process of providing each user with experiences, offers, and information that are specifically catered to their individual traits, habits, and interests. Personalization, as opposed to a "one-size-fits-all" strategy, seeks to make each encounter feel contemporary and relevant in order to promote deeper involvement and eventually achieve the intended business goals.
So what does this look like in Sitecore XM Cloud with a Next.js front-end application or site? It could mean any or all of the following examples:
There are a few cases where it’s certainly going to be easier to use Sitecore Personalize. Let’s go over them first.
While the desire to use something as awesome as Sitecore Personalize is, and it is pretty amazing, there are some strong arguments for when that awesomeness might not be justified.
Just like Sitecore CDP & Personalize, Sitecore Pages Personalize has its fair share of reasons for when it’s the right choice, just like when it’s the wrong choice. Let’s take a look at both now.
More often than not, the reasons not to use Sitecore Pages Personalize aren’t because you can do it via code, it’s more likely because what or how you’re trying to personalize is more complex than what’s available. For example:
The first two are easily encountered most often and really that’s when you’ll need a tool or tools like Sitecore CDP and Personalize. Pages Personalize just won’t cut it.
When I say, “in-code” personalization, I’m literally talking about something that is entirely developed within the front-end application or website. In all likelihood, this means you’re heavily relying on capturing user interaction and storing that information in local storage or a cookie of sorts.
There really are few reasons to resort to in-code personalization. Especially when you have, at minimum Sitecore Pages Personalization. That said, there may be the odd case where it makes sense.
There are easily more negatives than positives here, let’s have a look at a few.
It’s entirely feasible you can perform a personalization using a combination of the above methods. However, you likely would only utilize a combination of In-Code and Sitecore Personalize or In-Code and Sitecore Pages Personalize. While you can indeed combine functionality between Sitecore Personalize and Sitecore Pages Personalize, depending on what you’re after could require considerable effort and one would have to consider ROI and reusability.
I thought what better way to help sort out perhaps any remaining confusion would be to walk through a couple of examples.
It may not be a typical example, but I feel it’s a good one as I think the natural assumption that just because we may be working with data for a user coming from an external API might be to resort immediately to Sitecore CDP & Personalize. We already know that Sitecore Pages Personalization is out, given that it doesn’t have at close proximity, access to make the decisions on what page variant or component variant through A/B testing to use.
The fact that we have data coming from a single API, we already know that the In-Code option is thoroughly capable of achieving the desired result. It will have the closest access to the information at hand.
The question ultimately becomes the most important is, what is the information that we are going to show the user based upon the Personalization decision? Subsequent questions being:
If we want to restrict access to XM Cloud Pages to those responsible for authoring content and only those that author content, the decision is determined by the data coming from the API, and not a subsequent decision thereafter, then having a custom component that takes the information from XM Cloud, and determines the appropriate values to show is an appropriate one. We wouldn’t require Personalize or Pages Personalize to make that personalization.
If the content restriction is still important but the decision on what to show depended on a combination of the API response and their activities on the site, then controlling that personalization response inside of Personalize would have been best.
It can be difficult to pick the right approach in all cases. You may find one solution does not fit all and then you may have to make accommodations or suggestions to your client on how to adapt solutions. You may also be forced into a solution that may not align. Hopefully, in cases like those, you’re now armed with a cohesive approach that will support development and client goals.
