Search
Close this search box.

Easier implementations: contextData

Implementing SiteCatalyst can be a lengthy process at the best of times, and development teams are often pushed to the limits. Context data comes to the rescue! Find out how to include variables in your code that allow more sophisticated tracking and make for a smoother implementation process.

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.

The content and advice contained in this post may be out of date. Last updated on January 16, 2014.

Contact us

to discuss a range of services and support to suit your business needs and goals.

* Required field

Latest Blog Posts

Need Some Help?

We can work onsite or remotely with you and your team to provide capacity uplift or ongoing support as you need.

Need additional MarTech resources to supplement your team for special projects or to provide given expertise?

Data quality and integrity is key to any data strategy. We undertake audits and health checks that can give you peace of mind.

If you know your data could be working harder, but you’re not sure where to start, we can help.

We can help you build dynamic dashboards based on important metrics to fully inform the business.

Is it a CDP or a DMP that is right for your organisation? Let us help you work through the pros and cons.

Let us show you how to bring your online and offline data together to create a best picture of your customers.

Free assessments

Martech Talks: The End Of Cookies

This webinar was recorded in May 2024.

Note that the information contained in this presentation should not be taken as legal advice. Digital Balance and its partners recommend that you undertake your own legal investigation.

Martech Talks: The Four Stages Of Attribution Excellence

This webinar was recorded in April 2024.

Download the full 2024 Digital Experience Benchmarks report from Contentsquare.

Note that the information contained in this presentation should not be taken as legal advice. Digital Balance and its partners recommend that you undertake your own legal investigation.

Martech Talks: The Four Stages Of Attribution Excellence

This webinar was recorded in October 2023.

Note that the information contained in this presentation should not be taken as legal advice. Digital Balance and its partners recommend that you undertake your own legal investigation.

Martech Talks: Privacy and Data Governance

This webinar was recorded in August 2023.

Note that the information contained in this presentation should not be taken as legal advice. Digital Balance and its partners recommend that you undertake your own legal investigation.

Martech Talks: Privacy Changes and Data Security

This webinar was recorded in July 2023.

 

Note that the information contained in this presentation should not be taken as legal advice. Digital Balance and its partners recommend that you undertake your own legal investigation.