Help I cant personalise on the Referrer

I love it when I get on the tools and start to dig my teeth into an issue. The latest project I have been on has given me opportunities to do this, as you might have noticed from the little wave of blogs over the last few weeks, and this week is no exception.
One of the Content Authors wanted to personalise on the Referrer so was adding a rule found under the visit rules tag, the issue was that it was not working.
I started by looking at the Condition definition found at:
/sitecore/system/Settings/Rules/Definitions/Elements/Visit/Referrer

new was to crack open dotPeek, and what? Why is there no namespaces?

At first I thought the Assembly was corrupt, so check it out the Sitecore.ExperienceAnalytics
from a fresh download,and same thing, no implementations?
So turns out that this function was removed in Sitecore 9 because of the introduction of new segmentation rules.
Have a look at this Sitecore StackExchange question and answer where there is correspondence with Sitecore Support on this issue.
To solve this issue I turned to, as always, dotPeek, and have a look at the implementation that existed in Sitecore 8 and create my own condition.
public class ReferrerCondition<T> : StringOperatorCondition<T> where T : RuleContext
{
public string Referrer { get; set; }
protected override bool Execute(T ruleContext)
{
Assert.ArgumentNotNull(ruleContext, nameof(ruleContext));
Assert.IsNotNull(Tracker.Current, "Tracker.Current is not initialized");
Assert.IsNotNull(Tracker.Current.Session, "Tracker.Current.Session is not initialized");
Assert.IsNotNull(Tracker.Current.Session.Interaction, "Tracker.Current.Session.Interaction is not initialized");
var referrer = Tracker.Current.Session.Interaction.Referrer;
if (string.IsNullOrEmpty(referrer) || string.IsNullOrEmpty(Referrer))
return false;
return Compare(referrer, Referrer);
}
}
John West has a blog post on how to create and use rule elements for different scenarios for the Rules Engine, its a bit old and some of the links no longer work, because of this I am going to walk through the steps I took.
To allow this condition to be available in the Rules Engine you first need to deploy the above code, for the case of this blog lets imagine that this will be found in the Gravypower.Analytics.Rules.Conditions namespace in the Gravypower.Analytics Assembly.
Next in the content editor navigate to:
/sitecore/system/Settings/Rules/Definitions/Elements
Create a new Element Folder
, in the case of this example I will call it Gravypowers Elements
, right click this new folder and add a new Condition call Referrer, populating the Text
and the Type
fields.
I just copied the Text
from the Text
on the /sitecore/system/Settings/Rules/Definitions/Elements/Visit/Referrer
item.
where the referrer [operatorid,StringOperator,,compares to] [Referrer,,,specific value]

The above does not make the newly created condition available for use by default for personalisation, there is a bit more required to allow this.
Create a new tag
Add a new tag to the /sitecore/system/Settings/Rules/Definitions/Tags
I have called it Gravypower
. Tags are used to relate rule elements to usage.

Associate the new tag to the new Condition Element
With the above Gravypower
Tag created we need to associate Referrer Condition
to it, head back to Elements Folder
:
/sitecore/system/Settings/Rules/Definitions/Elements/Gravypowers Elements
Select the Tags Definition
called Default

Add the Tag
that was created above, in this example Gravypower
.

Allow new Rule Element to be used in the Rules Builder
In the case I was working with I wanted it to be used to personalise what renderings were added to a page, this is achieved by associating the new tag with a Rules Context Folder
, in my use case the Conditional Renderings
Folder.

Select the Default Tags Definition
and add Gravypower
across.

Apply the Rule for Personalisation
Go to the rendering you wish to personalise and you now can add the new condition that was created.


One last note, if you want to use the Referrer Condition for reporting its probable better to take a look at segmentation.