As a company that helps to roll out SiteCatalayst on a regular basis, we’ve found that there are a few steps that regularly hold up implementations. One of these, and probably the biggest time-devourer, is the addition of any on-page code within a site.
By on-page code I’m referring to custom pieces of javascript that are being used to describe a user’s journey. Declarations of user specific values (such as IDs or specific monetary amount related to a purchase) are the most common, but also includes more common tracking such as forms and processes.
A simplistic implementation will use something like the following:
s.eVar1 = "jcitizen100"; s.t();
This works from a basic technical perspective, but might cause problems when it comes to maintainability. Development teams may not fully comprehend why they are setting certain SiteCatalyst variables, and in our experience this has contributed to developer resistance.
Our current preference is to make us of the s.contextData variable by setting a descriptive variable like so:
[javascript]s.contextData[‘user.id’] = ‘jcitizen100’;
s.t();[/javascript]
Much more self-descriptive, and self-descriptive is good.
What is contextData?
The s.contextData variable is simply a JS object, with named properties. It is persistent for as long as the s object is available, and is a handy place to store data related to the current user’s journey.
You can assign values with the following code:
[javascript]s.contextData[variable name] = value;[/javascript]
It’s worth noting that it isn’t an array, even though the assignment code may give that impression, and as such the usual array methods such as pop() and push() aren’t available.
Why should I use it?
The primary reason we recommend using this method is that it separates the declaration of information from the execution of the actual tracking. This can help both at implementation time and during any debugging/maintenance periods. In the initial roll out, clients are able to insert code to capture any information deemed necessary into custom-named (read: meaningfully-named) context data variables. They do not need to know about eVars, props and events as the contextData variables can be translated in the s code. Result: code that client development team can understand, implement and maintain.
During the execution of the s_code, we now have a lot more flexibility in what we can do with information before assigning it an eVar, prop or event.
Detecting the presence of a contextData variable is simply a case of using the type of operator to ensure it has been set (unset variables will return “undefined”). Once detected, we can combine it with other present variables and session conditions before deciding what SiteCatalyst should actually record.
Secondly, new versions of s_code just don’t seem to like randomly created properties attached to the s object. In the past, we would create custom s properties such as s.userId, however more recent versions of the SiteCatalyst libraries will destroy a lot of these properties during the loading and initialisation of the s_code object. The contextData object is treated more carefully, and gets retained throughout these processes.
Finally, the contextData paradigm is used across non-web platforms such as when using SiteCatalyst in a mobile application. Knowing how it works makes it easier to understand the requirements of these types of implementation.
Example: Tracking multi-stage forms
Tracking user progression through forms is usually done with a combination of eVars, props and events, which can be a lot for client developers to get their head around.
To simplify their workload, we simply get them to write out 2 contextData variables on each page of the form process:
- Something to identify the current form (eg: s.contextData[“form.id”]).
- A description of the current step (eg: s.contextData[“form.step”]).
The s_code file then contains some logic, usually in the form of a switch statement, that detects the presence of these particular values and assigns relevant values to eVars, props and events.
Simple.
Keeping it simple = easier deployments for everyone
In general, I prefer to keep implementation process as simple as possible for everyone involved. Client development teams usually have a lot on their plates, and the thought of implementing analytics code across their sites doesn’t usually elicit cries of joy. Context data lets us separate the more complex aspects of SiteCatalyst from the on-page data capturing requirements, and thus provides dev teams with most minimal AND easily understood implementation instructions. It also allows us to create more sophisticated tracking logic, which results in more refined and descriptive analytics data.
Win-win.
