Over the past few months, I have shared a couple of blogs exploring embedded personalization in Sitecore XM Cloud:
- Personalization in Sitecore XM Cloud: What’s New, What’s Different, and What It’s Built On! – where I introduced the out-of-the-box personalization capabilities in XM Cloud.
- Getting Started with Personalization in Sitecore XM Cloud: Enable, Extend, and Execute – where I walked through how to set up personalization and begin using it effectively.
While XM Cloud embedded personalization (found within Pages) offers an excellent, out-of-the-box solution for common personalization needs, it has a key limitation: it restricts you to a predefined set of marketer-friendly conditions. This streamlined, page-variant-based approach is quick to implement for scenarios like localizing content by geography or targeting new vs. returning visitors, making it a great starting point for content authors.
The Need for a Deeper Personalization Engine
But here’s the limitation: XM Cloud is built for speed, scalability, and a smooth content authoring experience. It doesn’t let you create custom conditions inside Pages. In legacy Sitecore XP, developers could extend the rule engine with custom C# code. In XM Cloud, the design is different. For any personalization logic beyond basic, marketer-friendly, out-of-the-box rules (like device type or referrer), Sitecore directs you to its dedicated, cloud-native platform – Sitecore Personalize.
This is where the world of digital experience often demands logic that goes beyond these basic audience segments. When you need to personalize based on proprietary business rules, custom data streams, or complex, multi-touchpoint journeys, the embedded tools won’t suffice.
This is where Sitecore Personalize becomes essential. Personalize is a standalone, cloud-native personalization and decisioning engine built to handle advanced scenarios.
Sitecore Personalize: The Technical Extension
Personalize acts as the key to unlocking limitless personalization power within your XM Cloud solution.
- Custom Conditions: The most critical technical feature is the ability to define developer-written custom conditions. These conditions are authored in JavaScript within Personalize, built once by a developer, and then exposed to marketers for endless reuse within the XM Cloud Pages audience builder. This allows you to create highly tailored audience rules based on any data you can pipe into the platform.
- Advanced Decisioning and Experimentation: Personalize is API-first, supporting complex decision models, A/B testing, and multi-variant experiments that can go far beyond simple page variants. It includes dedicated dashboards and robust analytics for measuring the performance of these sophisticated experiences.
- Cross-Channel Orchestration: Personalize is designed to be truly cross-channel. Its capabilities extend beyond just the website, enabling you to orchestrate consistent, personalized experiences across email, mobile apps, and other API-driven touchpoints—leveraging a unified profile of the customer.
In short, Personalize extends XM Cloud’s personalization boundaries, making it possible to design highly tailored user journeys without being locked into out-of-the-box conditions.
This blog is the next step in the series: a developer-friendly deep dive into how Personalize works with XM Cloud.
XM Cloud and Personalize Integration
The seamless delivery of personalized content relies on a robust technical connection between your XM Cloud content management environment and the Sitecore Personalize decision engine. This part often feels like “black box magic,” so let’s clarify the two key phases: initial provisioning and run-time execution.
Provisioning & Tenant Setup
When an organization purchases a Sitecore Personalize license, the initial setup is managed by Sitecore Professional Services or your dedicated implementation partner. This process ensures the two separate cloud products are securely linked.
The typical process involves:
- Tenant Mapping: Establishing a clear connection between your environments (e.g., XM Cloud Dev/Test connecting to a Non-Production Personalize tenant, and XM Cloud Production connecting to a Production Personalize tenant). This separation is crucial for ensuring you don’t mix test audiences and conditions with real production traffic.
- Portal Access: You’ll receive invites to both the Sitecore Cloud Portal and the Personalize portal.
- Site Identifier Configuration: A Site Identifier must be created and mapped within XM Cloud. This is a critical technical step that tells Personalize exactly which rendering host (your website) it’s communicating with.
Important: Don’t be surprised if you don’t see your new custom condition in XM Cloud Pages right away—always first check that the site identifier is configured correctly and that the tenant setup is complete. Once this is wired, your XM Cloud Pages environment can successfully surface custom conditions and experiences created in Personalize.
Runtime Architecture: How the Two Talk at Request Time
Once environments are provisioned, your XM Cloud rendering host (typically a Next.js application) needs to fetch the correct personalization decision for every page request.
The Sitecore Cloud SDK is the exclusive and recommended method for integrating personalization and A/B/n testing within JSS SDK Next.js applications hosted on XM Cloud. This is designed to leverage Next.js Middleware and server-side rendering (SSR) for optimal performance. But let us take a look at both the SDKs that can be used to integrate with Personalize:
| Evaluation Method | Description | Key SDK | Use Case & Impact |
|---|---|---|---|
| Server-Side (SSR / Edge) | The Next.js rendering host calls Personalize at render-time (before the HTML is sent to the browser). | Cloud SDK | Recommended for XM Cloud. Ensures the variant is chosen before the page is delivered, eliminating the dreaded "flicker" of default content. Optimal for consistency and SEO. |
| Client-Side (Browser) | The page loads first, then Personalize (via an SDK snippet) evaluates and applies the winning variant in the user's browser. | Engage SDK | Simpler for non-XM Cloud or highly component-specific scenarios. However, this approach can cause a flash of default content before the personalized swap occurs. |
Personalization Data Flow Summary (SSR/Edge)
The personalization flow for a dynamic (SSR/Edge) page is a server-side handshake orchestrated by the Next.js Middleware and the Cloud SDK:
- Initial Check (JSS/Next.js Experience Edge): The Next.js Middleware first queries Experience Edge to verify if any personalization variants exist for the page.
- Decisioning Call (JSS/Next.js Personalize): If variants are found, the Middleware uses the Cloud SDK to send the visitor’s context to Sitecore Personalize.
- Variant ID Returned (Personalize JSS/Next.js): Personalize evaluates all rules and returns the winning Variant ID (or the default ID) based on the evaluated rules.
- Content Fetch (JSS/Next.js Experience Edge): The rendering host then makes a second request to Experience Edge, fetching the specific content layout matching the winning Variant ID.
- Final Delivery: The fully personalized HTML is rendered on the server and delivered to the visitor, ensuring a flicker-free experience.
Static Site Generation (SSG) Personalization Flow
The personalization process for pages built with SSG differs slightly from SSR to gain performance benefits by leveraging pre-generated HTML:
- Initial Request: When a visitor requests an SSG page, the Next.js application receives the standard HTTP request details (cookies, headers).
- Pre-Render Check: The Personalize middleware first checks its cache to see if static HTML variants have already been pre-rendered for this page.If a static variant is found, the middleware skips the initial API query to Experience Edge, speeding up the process. If no static variants are found, the process falls back to the standard SSR flow to dynamically fetch personalized variants from the CMS/Edge.
- Audience Decision: Assuming variants exist, the middleware sends a request to the Personalize (via the Cloud SDK) to identify which audience the current visitor belongs to.
- Delivery:
- If the visitor matches an audience and that variant was already pre-generated, the middleware simply returns the cached static HTML for the personalized variant immediately.
- If the visitor matches an audience but the static variant has not yet been built, the Next.js application generates the page variant HTML on the fly and then caches that output to serve as a static asset for all future visitors belonging to that same audience.
- If the visitor does not match any defined audience, the generic default static HTML page is returned.
This method allows high-traffic personalized pages to benefit from the speed of static hosting after the first request generates the variant HTML.
Wrapping Up
Bringing Sitecore XM Cloud and Sitecore Personalize together creates a powerful framework for delivering experiences that adapt in real time. While XM Cloud manages structured content and headless delivery, Personalize adds a decisioning layer that evaluates context, behaviors, and data signals to tailor each interaction.
This integration not only extends the personalization capabilities of XM Cloud beyond static rules but also enables continuous testing, optimization, and experimentation. For teams building modern digital experiences, this approach provides the agility to serve relevant, data-driven content at scale – while maintaining the flexibility of a cloud-native, headless architecture.
In my next blog, I’ll walk through creating custom conditions in Sitecore Personalize, so you can define personalization logic that truly aligns with the unique business needs.
