Comparing Personalization Options for Sitecore Personalize when Building with Sitecore

Hello friends, welcome back. This is my second blog post in a week, all in preparation for my SUGCON Europe presentation. I've put together a curated list of blogs related to my topic on behavioral personalization. This is the final blog post in the series, where I share some recent internal discussions. I plan to discuss this further on the developer portal. The question arose: What is the recommended approach for implementing personalization on XM Cloud? However, I believe this advice may also be beneficial to users on XP, XM, and even those using other CMSs.

Using XP/XM

With a Sitecore XP/XM implementation you’ll use a standalone tenant of Personalize (and possibly an add-on of CDP if you have more extensive data collection needs). You’ll really have two options for implementation of personalization (but keep in mind that this could also apply to experimentation as well). First you could opt to probably take one of the easiest approaches, which is to use the Engage SDK and enable Web Experiences. This is relatively straightforward, and just requires an additional setting to be configured when you initialize the Engage SDK. Below is an example of this:

1import { createContext, useContext, useState, useEffect, useCallback } from "react";
2import { init } from "@sitecore/engage";
3
4const EngageContext = createContext();
5
6function EngageProvider({ children }) {
7  const [engage, setEngage] = useState({});
8
9  const loadEngage = useCallback(async () => {
10    const engage = await init({
11      clientKey: "<client_key_PLACEHOLDER>",
12      targetURL: "<stream_api_target_endpoint_PLACEHOLDER>",
13      pointOfSale: "<point_of_sale_PLACEHOLDER>",
14      cookieDomain: "<cookie_domain_PLACEHOLDER>",
15      cookieExpiryDays: 365,
16      forceServerCookieMode: false,
17      webPersonalization: true
18    });
19
20    setEngage(engage);
21  }, []);
22
23  useEffect(() => {
24    loadEngage();
25  }, [loadEngage]);
26
27  return <EngageContext.Provider value={engage}>{children}</EngageContext.Provider>;
28}
29
30function useEngage() {
31  const engage = useContext(EngageContext);
32  return engage;
33}
34
35export { EngageProvider, useEngage };

So in the above code, when you load the engage SDK, you just need to add a property for webPersonalization: true and you should be all set. Another caveat, is that you should ensure you are using the latest version of the Engage SDK. Once you have those two things, make sure you aren’t seeing any console logs in your console, and then you should be all set. With Web Experiences all of the configuration of the personalizations including the styling of the personalization components themselves would be done from Sitecore Personalize.

There may be instances where you want to limit the control of your marketing team or when your development team prefers to use modern development techniques. These techniques can include source control, versioning, and code governance to manage changes to personalized code. In such cases, a Full Stack Interactive Experience is likely your best option. However, it is more complicated to implement. Each component in XP needs abstraction logic to call into Personalize for decision-making. Alternatively, you could implement an XP rule that returns a true or false value or an object that matches your needs for a specific Experience ID, eliminating further configuration changes. This will be discussed in a future blog post. But note, this approach likely leans towards a non-headless approach. As suggested, it requires review, and a simple proof of concept should be created to verify its compatibility with XP and its potential for use with XM Cloud.

As an XP customer, your two options are the Full Stack Interactive Experience or implementing Web Experiences. You should carefully consider these options. The more logical choice may be the Full Stack Interactive Experience, with the caveat that if you need a quick solution for your marketers, Web Experiences might be the right approach.

It's worth noting that you could implement both. However, in my opinion, Web Experiences can be somewhat risky in the corporate realm. They are a great way for small businesses to decrease time to market, but they may cause unexpected glitches in the frontend application, possibly due to CSS injections from the Web Experiences implementation.

Even if you don't want your teams to use Web Experiences, you might still want to enable them in the Engage SDK, as this also enables the debug tool.

Using XM Cloud

Really the implementation of XM Cloud is similar to the considerations for XP/XM, however a few additional discussion points as of the time of this writing. First you could opt to use the Cloud SDK over the Engage SDK. But as of this writing, the Cloud SDK does not allow you to enable the Web Experiences. This shouldn’t be a problem if you are predominantly using the Full Stack Interactive Experience, but it’s something to keep in mind. I haven’t tried, but I would also assume if you are using 21.6+ (where the Cloud SDK was first introduced), you could back track and switch to using the Engage SDK, but there could be some issues and you would likely cause issues for future compatibility upgrades with JSS. There has been commitment of adding support for Web Experiences in the Cloud SDK, but I do not have a timing on that.

If you are using an older version of JSS with support still for the Engage SDK, then you could still use both Web Experiences and Full Stack Interactive Experiences.

Before we delve into the configurations necessary to enable the Web Experience feature in the Engage SDK, let's discuss an additional option available for XM Cloud customers. If you're using the basic XM Cloud version, it includes Embedded Personalize, a stripped-down version of the fully licensed Personalize product. With this combination, you gain limited personalization capabilities through a new feature in XM Cloud Pages. Sitecore has introduced a method for achieving page-level personalization through Audience capabilities. These allow you to define rules that segment your audience, enabling them to see a personalized version of the page.

The XM Cloud Pages interface introduces unique methods for personalization, creating notable differences from the XP/XM approach. In XP and to an extent in XM, personalization is managed through a rules engine. In contrast, XM Cloud uses pages, and the only way to set new rules for pages is through Conditions, which we'll discuss further. This difference affects how personalization is achieved in XP versus XM Cloud. If you were to create a personalization rule for a Full Stack Interactive Experience in XP, it would likely not work in XM Cloud. Despite these differences, the recommendation to consider using a Full Stack Interactive Experience in XP remains valid for XM Cloud.

Anything else

For anyone else, the approaches will be similar to XP/XM, given that you don't have access to the XM Cloud Pages interface. Your only options are to create a Full Stack Interactive Experience or a Web Experience. The choice between these two depends on your use case and eliminates the need to handle the inherent quirks of Sitecore's rendering engine. If your CMS doesn't have a rendering engine, you'll likely choose the appropriate preference based on your organization's needs.

Since you are not operating within the Sitecore realm, you will also need to use the Engage SDK. This tool supports triggering flows for personalization via the Full Stack Interactive Experience. To use it, initialize the Engage SDK and trigger a call flow. For more details, refer to the Engage SDK documentation: https://doc.sitecore.com/personalize/en/developers/api/engage-personalize.html.

1const flowData = {
2    channel: "WEB",
3    currency: "EUR",
4    pointOfSale: "myretailsite/ireland",
5    friendlyId: "running_shoes_popup_02",
6    // guest identifier:
7    email: "jane.doe@myretailsite.com"
8}
9
10engage.personalize(flowData);

Since you are not working with the XP/XM rendering engine, you should apply your full-stack experiences directly within the code you are implementing.