Does xConnect/xDB need to be fully enabled and working for rendering personalization rules to work?

Question

I'm looking at an XP implementation that uses personalization rules to hide/show renderings based on a set of custom defined rules (sources 1, 2). For example:

• Rule: Is user of X type?
• Action: Run code to inspect user cookie and return true/false
• Outcome: Hide or show the component based on result of above rule

Our custom rules aren't doing anything fancy; they are independent of xConnect/xDB.

The problem is that when xConnect is unavailable or experiences errors (ex. certificate issues), or when tracking is disabled, the personalization rules appear to stop working, and renderings fall back to their default display settings. I can reliably replicate this by disabling xDB on my local.

The best documentation I found is here (9.3) (10.3). Notably, it breaks down which rules are available to XM vs XP. It also shows all of the personalization conditions.

This topic describes the personalization conditions that are available by default in the Sitecore Experience Platform (XP) and indicates which conditions are available in Sitecore Experience Manager (XM or XP with the xDB disabled).

This seems to imply that as far as personalization conditions are concerned, if xDB is disabled, an XP implementation essentially becomes an XM implementation.

Further,

While you can use many conditions from the Rule Set Editor to personalize content when using XM, there are some conditions that are only available when you run xDB and the full XP.

This makes sense. And the doc breaks that down very well. It also specifically mentions 2 rules that are relevant to this question:

• xDB is enabled
• Tracking is enabled

Both XM and XP can use the conditions above for personalization, which implies that xDB and tracking are not required to be enabled for component personalization to work, but that's not the behavior I am seeing.

What the documents don't specifically call out is custom code-driven conditions, although it could be this:

Is the behavior I'm seeing normal? Beyond having an XM/XP license, what prerequisites are required to personalize the presentation of a component with custom conditions / rules?

Answer 1

To answer your initial question: No - xConnect/xDB does not need to be fully enabled for rendering personalization rules to work.

To confirm this I did the following.

Applied this patch file:

<configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
  <sitecore>
    <settings>
        <setting name="Xdb.Enabled" value="false" />
        <setting name="Xdb.Tracking.Enabled" value="false" />
    </settings>
  </sitecore>
</configuration>

Created a custom condition that always returns true:

public class AlwaysReturnTrueCondition<T> : WhenCondition<T> where T : RuleContext
{
    protected override bool Execute(T ruleContext)
    {
        return true;
    }
}

Then added a rule to a rendering to hide if the above rule returns true (default is show). In the above situation, with xDB and tracking disabled, the rule worked and hid the rendering.

I believe the issue you are facing, is that you are trying to evaluate if a user is of Type X. To do that I assume you are using the standard SC_ANALYTICS_GLOBAL_COOOKIE cookie. This cookie would not be present if tracking has been disabled.

Please see here:

Used by the tracker to identify a returning contact. Only issued if tracking is enabled.

On this reference: https://doc.sitecore.com/xp/en/developers/93/platform-administration-and-architecture/cookies-used-by-sitecore.html

Answer 2

Dean is correct when saying:

xConnect/xDB does not need to be fully enabled for rendering personalization rules to work

However, there is a major caveat which was revealed after additional testing. If you have xDB enabled in your settings but your xDB sites are inaccessible or experiencing any kind of major issue related to SSL/TLS (which is a common issue), this WILL cause unexpected behavior. Regular personalization rules are not supposed to depend on xDB (which is implied by Sitecore's docs), but there certainly does seem to be a dependency somewhere.