How many personalization rules are too many? At what point does page/site performance start to take a hit?

Question

A client wants to do basic personalization with a rule that changes a header image based on geolocation/zip code. They would like to try and cover as many individual zip codes as possible in a region.

Putting aside author issues around editing/entry/maintenance:

• How many zip code personalization rules are "too many" when applied to a single component?
• At what point would site/page performance start to take a hit if this was the only personalization present on the page?

Bonus question:

• How many rules are too many for a single page?

Edit: Just to clarify, this is less about "How can I solve this with a development team?" and more about "How much can a marketing team/author do with basic personalization rules (without getting a development team involved) before site/page load performance is negatively affected?".

I tried to provide an example of what I'd consider simple personalization, and in theory it can be changing content based on any status (eg. 50 rules + default for "If user is in this state, show this banner with a state flag").

Answer 1

Without having done any testing, I think that one of the important considerations here would be "what kind of personalization conditions will cause performance impacts?" The rules engine is very performant in general, so it's really the performance of the individual conditions that would matter.

Some personalization conditions would be relatively lightweight. For instance, Sitecore.Rules.Conditions.DateTimeConditions.NowCondition simply parses a DateTime string and compares it to the current datetime. Compared to the rendering of a normal page, this would have a negligible impact.

On the other hand, some of the xDB conditions would be comparatively more expensive to compute. For instance, Sitecore.Analytics.Rules.Conditions.CampaignWasTriggeredDuringPastOrCurrentInteractionCondition needs to lookup the previous interactions (which is, then, cached) and then evaluate if any of them had a specific campaign triggered. This could cause an xConnect or Mongo call depending on the situation, which could add milliseconds to the request. Still likely low compared to a full request, but the right combination of these could be bad.

Additionally, some custom conditions may be more or less performant, so those should be taken into consideration as well.

My recommendation is that if this is a concern, read through the common conditions and produce a spreadsheet for your editors of the likely performance impact of each one based on what each one has to do. Then, you could produce some recommendations for them, such as "only use up to 5 of these conditions but you can have as many of these conditions as you like.

---

As an aside, with regards to your point around zip code rules, the postal code rule in Sitecore does a string comparison on the Sitecore.Analytics.Tracker.Current.Session.Interaction.GeoData.PostalCode property. If you only care about zip codes, I would write a custom Sitecore.Rules.Conditions.IntegerComparisonCondition which parses the postal code property and does an integer comparison. This way you could compare to blocks of zip codes instead of individual ones, potentially reducing the number of comparisons to a reasonable amount.

Answer 2

In my opinion, the only answer to your question is "it depends".

It depends on many factors:

• what is the acceptable page generation time
• how many visits your site has
• how many servers you have
• can you cache some parts of your pages
• how fast your servers are
• how fast you can get the client zip code
• and many many more.

Maybe instead of creating personalization condition for every single zip code, select default header as a datasource, and as the child items create personalized header datasources using chosen zip code as the item name. And then in your component code check if datasource has a child with the name equal to user zip code, use that child content instead of the default datasource content?

Answer 3

Nothing significant from a performance perspective. But there are other issues.

I wouldn't worry about this from a performance perspective. While there is a certain overhead on the Rules Engine I would not consider it significant enough to have any real performance impact for up to a good chunk of conditions. That said, there are a few things to consider:

• Sitecore Geolocation isn't really city/zip-code accurate, depending on what country you're in. See this table here.
• And this Sitecore KB article: Sitecore IP Geolocation Service accuracy
• A (very simple) custom condition could make your editors lives a lot easier. Something like if media library/city/images has an image named [zipcode], apply it to header. A couple of lines of code, and your client would have a much easier means of maintaining the images required. Performance would be a definite non-issue.

That said; precision of the Geo provider will be your number one concern that will need to be discussed before even moving ahead.