Sitecore Sunday Pt 3: Conditional (Rules Based) Goal Registration

Goals in Sitecore allow us to register the fact that a site visitor has performed a specific action on the site and more importantly that that action has engagement value associated with it. Actions can vary but typically fall into one of two buckets, significant page views (end of conversion funnel pages) and on-page events (interacting with a map, playing a video etc.). For more on the importance of engagement value as a metric take a look at this guide by Sitecore's SBOS (Sitecore Business Optimisation Services) team.

This post tackles more advanced scenarios where a certain pre-condition must be satisfied before considering a page view or on-page event as legitimate engagement, to put it another way, we want to qualify the action before registering the conversion. The example I will use is site search related but the concept and approach can easily be extended to cover other scenarios. The scenario is this, we want to register the 'Site Search Page View' goal when a visitor views a search results page but not when the user subsequently pages through the search results as this is considered an extension of behavior but ultimately part of the original conversion.

The 'Site Search Page View' goal looks like this.

On inspection we can see that the goal has a rules field. This field however does not represent a pre-condition that must be true before the goal is registered, it allows us to trigger further actions after the goal is registered if the conditions of the rules field are true. This could have some interesting uses but doesn't solve the problem we are trying to solve here.

The solution to our problem once again lies in the processItem pipeline, defined in Sitecore.Analytics.config.

This is an extremely useful pipeline, which I also make use of in the post Sitecore Sunday Pt 2: Programmtic Profile Association. When goals are associated with page items in the traditional way (select the page and select Analyze > Goals), this information is stored in the pages __Tracking field as xml, just as associated profiles are.

The CollectParameters processor checks for the existence of the __Tracking field on the context item (or the context items template standard values) and if it is not null adds the tracking field to the TrackingParameters property of the ProcessItemArgs passed into Process method of the processor (a bit of a mouthful yes).

The RegisterPageEvents processor further down in the pipeline uses the TrackingParameters property to collect up all the goals associated with the current context (request) and registers them against the current page on the Interaction (session) object of the current contacts xDb record.

The trick now is to add additional tracking fields to the TrackingParameters property if certain conditions are true. To do this we will add an additional processor to the pipeline after the CollectParameters processor (to preserve standard functionality) and we'll call it CollectConditionalParameters.

The code in this processor looks like this:

To summarise before going into more detail:

1. A collection of conditional goals is retrieved from a repository (obvious I know, detail to follow).
2. For each conditional goal that is considered a match for the current context (based on its rules), add the tracking field on the conditional goal to the TrackingParameters property, which will be used later on in the pipeline by the RegisterPageEvents processor

The conditional goals repository gets a collection of items (separate from the goal items in the Marketing Control Panel and scoped to specific sites to support multi-tenancy) based on the 'Conditional Goal' template. This template has three fields:

1. Applies to Templates
2. Rules
3. Attributes To Register

The applies to templates field allows the author to select which page templates the goal applies to or if it applies to any page type, can be left blank. The rules field allows the author to set the condition(s) that must be satisfied for the goal to be registered. You're probably thinking 'The rules engine has conditions for the template that the context item is based on, why do we need the applies to templates field?'. Whilst this is a correct assertion, traditionally goals are assigned to specific pages or templates and marketers more often than not associate specific goals with specific page types, it felt an important enough condition to pull it out and pay special attention to it.

Finally the attributes to register field is a field that uses the field type 'Tracking' and allows the author to select the specific goal that should be registered if all conditions are true.

One thing I have noticed about the tracking field is that regardless of the values selected the field always displays 'Nothing has been set', I have opened a ticket with Sitecore support, I will update this post when I get a response.

Sitecore Support Response: This is a system field, when selections are made it modifies the __Tracking field (which we know). The text 'Nothing has been set' is hard coded. Not considered a bug.

So that is really all there is to it, a simple yet powerful way to register page view goals but only when specific conditions are met, powered by the Sitecore rules engine and processed in the processItem pipeline.