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").

3 Answers 3


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.

  • Thank you for your answer. This question originates from an authoring team eager to use the personalization tools Sitecore has to offer that is struggling with what you can do versus what you should do. I'm trying to advise them from a place where 'DIY' lightweight personalization should be done when it can improve the user's experience, without "over personalizing" a component/page within an inch of its life.
    – Jim P.
    Commented Nov 9, 2018 at 22:23
  • @JimP. I think you'll find that you hit the point of "over personalizing" far before you hit the point of a big performance hit. Depending on how things are written, I've seen solutions where people can vary the load time by a couple hundred ms without noticing. So I think you would be able to get personalization rules to the point of having a crazy personalization UI before you really notice the performance Commented Nov 9, 2018 at 23:28

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?

  • Thank you for this answer, but maybe I should clarify. I'm trying to learn what the limits are in regards to a "Development free" solution, as in something that a marketing team/author can accomplish using just basic personalization of a single component.
    – Jim P.
    Commented Nov 9, 2018 at 20:13
  • As I wrote in my answer: "it depends". What kind of answer you expect? 100? 1000? 1 million? If you double CPU of your server, the answer won't be correct anymore...
    – Marek Musielak
    Commented Nov 9, 2018 at 20:25
  • Something along the lines of "Page load times will increase by 10 seconds or more after applying 'x or greater number' of personalization rules to a single component.
    – Jim P.
    Commented Nov 9, 2018 at 20:37
  • I'm sorry but it's not possible to give you an answer like that. Impact on the page load time will be different for every server, for every component and for every personalization rule.
    – Marek Musielak
    Commented Nov 9, 2018 at 20:52

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.