Most Important Edit: Sitecore 10 has been released, which has restored functionality for in-session personalization without the tracker. The below blog posts are only applicable to Sitecore 9.1 to 9.3
Edit 1: The post has been updated with addtional screenshots, clarification on rules, and notes about XM Performance
Edit 2: Added commentary from Alexey Vaschenko regarding rules UI vs rules engine

I began working with Sitecore in the 6.x days, and one of the more compelling feature sets has been the ability to personalize content. The personalization, testing, and rules-engine features were one of the key reasons our company at the time chose Sitecore for our new patient-education portal: the ability to target content in structured areas of the page based on a visitor's behavior was a key differentiator for our team when evaluating technologies.

There's now more ways to augment experience data with data from other systems through xConnect, and in turn, customize the experience for Sitecore visitors. One thing that hadn't changed in that time was the ability to create and execute rules and basic, in-session personalization. While xDB gave us many new ways to personalize based on past visits, long-term behavoir, or data from disparate systems, any Sitecore implementation could take advantage of those in-session rules to change content based on information from the current visit.

This background is important, because the functionality changes with Sitecore 9.1. When deploying XM in 9.1, you no longer have access to personalization, testing, or many features utilizing rules -- regardless of your license or use case. If you are upgrading a solution that uses rules or personalization without DMS/xDB, you must deploy the XP product and disable the XP features after the fact.

Are You xPerienced?

Since this is going to get confusing given the similarity in naming to prior Sitecore releases, let's start the next section off with a glossary of terms we'll be using through the rest of this post:

  • The Sitecore 9.1 XM distribution (What XM stands for in this release is unclear, as the prior name has been co-opted for something else -- see below) is a new deployment package that removes all personalization, analytics, and xDB features from the product distribution. The assemblies, configurations, database items, and more that support those features are gone. In exchange, the 9.1 XM release spins up faster, deploys faster, and runs leaner than its XP sibling.

This release is functionaly different than any previous version of Sitecore XM -- which was historically the same Sitecore as XP, just configured out of the box to not provision or use any xDB functionality. Sitecore XM 9.1 cannot run rules, in-session personalization, or content testing. It is missing the code to be able to perform these features. It is best to think of Sitecore XM 9.1 as a whole new product, not a direct upgrade from XM prior.

Edit 2: Alexey Vaschenko adds the following comments in the post below (lightly edited for clarity -- see full comments below the post):

...Rules engine presents in XM, you still can evaluate your rules and it is fully functional. Device Detection and GeoIP is there as well. Personalization dialog is not there. That means you can't quickly setup in session personalization, but you can do that with code. ... Sitecore 9.1 XM CAN run rules. The Rule Engine is there. Rules-based insert options will be executed. Any other functionality or customization based on running rules WILL BE WORKING

I haven't tested this, but I have no reason to not believe Alexey to be correct. If you're using roles in places like insert options, or your custom code, there's no reason those features won't work in 9.1 XM. The remaining portions of this blog still stand: the out of the box rules are not deployed, and there is no interface for you to set up personalization via the UI based on the rules (as shown below). You should test your solution to see if any use of rules or the engine you're using in your code work as intended in 9.1 XM, or deploy 9.1 XP in CMS-Only Mode if your content authors are creating and managing these customizations instead of developers.

  • Experience Platform, also known as XP, as of 9.1, is the full distribution package of Sitecore with all assemblies, configurations, and more present. When deploying XP, it also deploys all xConnect roles and databases. From a feature-completeness standpoint, XP 9.1 has all the capabilities present in prior XM and XP releases. Additionaly, the XP release can be configured in a CMS-Only mode (also confusingly named Experience Management) that allows for use of rules in determining presentation, in-session personalization, and basic content testing without xDB.

DeviceEditor
Left: Device Editor viewing renderings on the Sample Page template in XM. Right: The same in XP running in CMS-Only mode.

Confused? That's understandable, since the Experience Management/XM term is severly overloaded. In short:

  • Sitecore XM Prior to 9.1: Content management, with in-session personalization, all out-of-the-box rules, and basic campaigns. No historical personalization (no xDB), and no analytics features.
  • Sitecore XM 9.1: Content management only: no personalization, rules, campaigns, xDB, or analytics features.
  • Sitecore XP 9.1: Sitecore with all features available to be used, including all analytics features, xConnect, and xDB.
  • Sitecore XP 9.1 configured in CMS-Only mode: (AKA -- Experience Management Mode). Similar to Sitecore XM prior to 9.1. Still deploys all XP resources and roles, but can be configured to not use them.

Here's a somewhat handy (yet still confusing) chart to help you plan an upgrade:

WhatXM4

Where do we go... Where do we go now?

In short, if you're a new Sitecore customer, and you've purchased an XM license and will not be using any rules or personalization in your implementation, you should deploy the XM WDP's either on-prem, in Azure via ARM templates, or the Marketplace XM Deployment. You'll get the same Sitecore content management experience, with all of the performance improvements in the XM release for 9.1.

That's a very qualified recommendation, however. If you're going to want to use those features, it's probably best to deploy the XP WDP's instead, and configure it to disable XP functionality and perform in CMS-Only mode. While it will be a hassle to reconfigure your instances and delete the XP resources if you're not planning on using them, it will give you more leeway in functionality going forward. Otherwise, if you're going to want to use those features in the future, you're looking at a redeploy of XP and configuring down.

If you're upgrading to Sitecore 9.1 from a previous version, you'll need to identify if you're using any of the following features in your solution, since they will not be available to you if you move to 9.1's XM package:

  • In-session personalization
  • Custom or out of the box rules via the personalization UI.
  • Geolocation This is incorrect, GeoIP is present in the XM distribution.
  • Campaigns and Campaign Creator

In addition, the following features are unavailable in the XM/CMS Only mode, and require XP be deployed with xDB enabled:

  • Content Testing
  • Any Analytics features (Experience Analytics, Profile, and Explorer)
  • FXM
  • EXM
  • List Manager
  • Marketing Automation (the replacement for Engagement Plans)

In my next post, I'll be talking about alternative strategies for deploying XP without all of the additional resources in Azure.