Generic Digital Experiences Are No Longer Enough
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?
Understanding the Personalization Stack
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:
- Displaying distinct hero graphics to returning consumers and new visitors.
- Displaying product suggestions derived from previous browsing or buying trends.
- Showcasing marketing or material tailored to a particular place.
- Modifying calls to action or navigation according to a user's known interests.
- Coordinating whole consumer experiences via email, the web, and additional channels.
Let’s Examine Sitecore CDP & Personalize
When to Use Sitecore CDP & Personalize
There are a few cases where it’s certainly going to be easier to use Sitecore Personalize. Let’s go over them first.
- Cross-Channel Personalization: When it's necessary to combine client data from several digital touchpoints (website, mobile app, email, call-centre, in-store, etc.) and personalize experiences across them.
- Deep Customer Understanding: When you need to integrate data from several systems (CRM, ERP, marketing automation, POS, etc.) to provide a thorough, real-time, 360-degree perspective of your customer. Sitecore CDP is a platform for customer data. The key here is various systems.
- Complex Audience Building and Segmentation: When your personalization tactics call for dynamic, detailed segments based on prior interactions across channels, behaviour, preferences, and even anticipated future behaviour.
- Journey Orchestration: When you wish to plan intricate, multi-step consumer journeys over several channels, based on real-time behaviour, to initiate particular experiences or actions.
When Not to Use Sitecore Personalize?
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.
- Simple, website-only personalization needs. Maybe you just need a different banner here or there, or unique “welcome back” type messaging.
- Limited budget and resources for implementation and ongoing management.
- When you don't require cross-channel data unification. If all you have is a website, it might not be necessary.
Let’s Examine Sitecore Pages Personalize (Formerly Sitecore Experience Platform / XP Personalization)
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.
When to Use Sitecore Pages Personalize
- Personalization of Content and Components: Perfect for tailoring individual content elements, pages, or complete layouts according to the actions of website visitors within the Sitecore instance.
- Rule-Based Customization: Primarily controlled by preset rules based on visitor characteristics (e.g., location, device, source of referral, previous visits, and goals accomplished inside the website). The complete list of rules are below:
- Time: certain periods of the day when the page is seen.
- Date: the precise days of the week, month, or dates when a user sees the page.
- Device: the kind of device (such as a tablet, smartphone, or desktop computer) and operating system (such as iOS or Android) that was used to view your website.
- Geography: the nation, area, or state in which the user is currently located.
- Visit: the number of times a person has visited your website in the past, or the pages they have viewed previously or during their visit. For instance, the condition of "new or returning visitor" might determine whether a user has visited the website before and display the component or content accordingly.
- User interaction: if the user is a new or returning user, or whether the referrer or UTM directed them to the customized page.
- Point of sale: One or more of your websites that have been unified under a single site identity have been accessed by your audience.
When to Not Use Sitecore Pages Personalize
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:
- When real cross-channel personalization is required, for as when email personalization requires integration with CRM data.
- When you need to unify data from external systems in real time and in depth.
- When predictive personalization requires sophisticated machine learning.
- When planning intricate, multi-channel client interactions.
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.
Let’s Explore In-Code Personalization
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.
When to Use In-Code Personalization
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.
- Extremely Specific, Niche Scenarios: When the logic for personalization is highly distinctive, customized, and doesn't easily fit into the other tools' rule-based or AI-driven functionalities.
- Proprietary system data: If you need to customize depending on information from an internal, highly specialized system that is difficult to integrate with a CDP or conventional Sitecore analytics.
- Basic developer-driven A/B testing: For developers who do not want to use the Sitecore UI and wish to quickly implement basic A/B tests.
When Not to Use In-Code Personalization
There are easily more negatives than positives here, let’s have a look at a few.
- Scalability & Maintainability: As personalization tactics expand, in-code personalization soon becomes cumbersome, challenging to scale, and a headache to maintain.
- Marketer Empowerment: When it comes to testing, upgrades, and modifications, marketers are completely dependent on developers and lose control.
- Loss of Analytics & Insights: Sitecore analytics finds it challenging to monitor and report on the efficacy of personalization logic since it is hidden in code.
- Duplication of Effort: Having to reinvent the wheel when Sitecore has powerful, unconventional personalization tools.
- Debugging Challenges: It can be considerably more difficult to identify problems.
Combining Personalization Methods
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.
Identifying the Best Approach Using An Example
I thought what better way to help sort out perhaps any remaining confusion would be to walk through a couple of examples.
Data from API for Logged-In User Determines Result of Personalization
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:
- Are we displaying content that comes from an API? Or that comes from within Sitecore XM Cloud or Content Hub or some other outside system?
- Do those that manage the content displayed according to a personalization decision, have access to the system where that information is stored?
- How often does the information change?
- Is the content controlled media, text or a combination of both?
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.
Choosing the Right Approach
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.
