allBlogsList

Creating Rules for Personalization in Sitecore 7

Recently I had a client who was new to Sitecore come to me with a question. They had a 3rd party ad service that would insert all kinds of information into the URL, query stings mostly. With this information, different content would be served up to better target the user. In their legacy system, the flow would be something like this: A developer maintained the relationship for all the “if query string A has this value and query string B has this value show this content” in an XML file. Any time the sales people wanted to change any of the conditions, they would create a ticket, have the developer get to it in the next sprint, and it would be included in the next release. They wanted to know if there was a better way.

Thanks to Sitecore, I looked like a hero. No longer would sales people be a slave to the developer’s timeline, with a little bit of customization, the sales team could make these changes themselves.

But enough with the back-story, lets get into how to accomplish this. The example I am going to cover is how to read values form a query string.

If you don’t already have a Sitecore Ext folder or Project, create one. Within this, create a folder called Rules.

Add a class called QueryStringCondition

In this class, all we need is to get the name of the query sting and the expected value that the Content Editor is looking for. Once we verify that we have these values, compare them to the QueryString and the value in the URL and return a bool. Here is an example of what my code looks like:

    public class QueryStringCondition<T> : StringOperatorCondition<T> where T : RuleContext
    {
        private string _queryStringName;
        private string _value;

        public string QueryStringName
        {
            get { return _queryStringName; }
            set { _queryStringName = value; }
        }

        public string Value
        {
            get { return _value; }
            set { _value = value; }
        }
        protected override bool Execute(T ruleContext)
        {
            Assert.ArgumentNotNull(ruleContext, "ruleContext");
            if (string.IsNullOrEmpty(QueryStringName) || string.IsNullOrEmpty(Value))
                return false;

            string qsValue = WebUtil.GetQueryString(QueryStringName, "");

            if (qsValue == Value)
                return true;

            return false;

        }
    }

Once this is compiled and published, we need to tell Sitecore that this rule exists and make it editable to the Content Editor.

In Sitecore, browse to /sitecore/system/Settings/Rules/Definitions/Elements. Here, you’ll see a list of all the conditions and rules that come shipped form Sitecore. To make things easier for the Content Editor and to keep my custom stuff clear of the Sitecore stuff (important when it comes to upgrades), I like to create my own Element Folder (I find it works better to duplicate one that already exist and rename it). When creating a new Element Folder be sure and give it a meaningful name to the Content Editor.

Once that’s done, insert a new Condition. Within this Condition, there are two fields we care about.

Text: Where the query string [QueryStringName,,,name] equals [Value,,,value]

The text is what the Content Editor will see when they go to create the rule. Within the brackets, for this example, we care only about the first and last placeholders. The first is the name of the string within your code and the last is the display name the Content Editor will see as a placeholder.

Side note: Using the other placeholders, you can set a Datasource location to populate a list for a Content Editor. Sitecore is looking for the list type, location (parent id), and search location. In your code, you will see the Sitecore item Id of the value the Content Editor selects. Here is an example of what the Text field would look like in this scenario: When language is [Language,Tree,root={14998F10-FD95-48BE-8161-E560B55F3F40}&setRootAsSearchRoot=true,language]

Type: ProjectName.SitecoreExtensions.Rules.QueryStringCondition, ProjectName

The type is simply pointing to the .dll that contains the code that we wrote above that handles the condition.

That should be it… If you go to the presentation settings of an item and click on personalization, you should see a new grouping of rules containing the Query String rule. If you run in to any problems, you can hook up the debugger to your class and see where it fails. If it doesn’t find your class, double check you’re the value you inputted into the Type field when creating the Condition.

This is an example on how to read query strings to personalize content. With your imagination you can use Personalization to do a lot of awesome stuff. Also, keep in mind Sitecore ships with a lot of rules setup for you out of the box, make sure Sitecore doesn’t already have something before you start building your own rules.