The s_code.js file – Plugins

This article is part of the mini series about the s_code.js file. You can find the other articles here:

• Overview
• Configuration section
• The s.doPlugin() callback method
• Plugins (this article)
• Core Javascript code

Plugins

Yesterday we mentioned that you can do a lot of things in the s.doPlugins() method, which often means less code on the pages and therefore easier maintenance.

To help with that practice as well as to add interesting functionality, Adobe Consulting have over time written a whole family of code called “plugins”.

Plugins are little bits of Javascript code that are placed into the s_code.js file. They can subsequently be used inside the s.doPlugins() method to assign variables to your liking.

A couple of examples:

• The s.getQueryParam plugin is used to read query parameters in the URL and return their value.
• Using the s.getValOnce plugin, you can make sure a value is only sent once. We call that “de-duplication”.
• The s.getTimeParting plugin returns time of day and day of week.
• To track visits over time, we can use the s.getVisitNum and the s.getDaysSinceLastVisit plugin.
• We can track activities across visits using the s.crossVisitiParticipation plugin.
• The s.getPercentPageViewed plugin helps figure out whether and how far down visitors scroll on the site.

Let’s look at some of those in more detail.

s.getVisitNum & s.getDaysSinceLastVisit

The s.getVisitNum plugin returns a number that represents how many visits the visitor has had on the site, while s.getDaysSinceLastVisit returns the time since the last visit.

	s.eVar35 = s.getVisitNum('m');
	s.eVar36 = s.getDaysSinceLastVisit('s_lv');

For a visitor who comes to the sie for the first time ever, s.getVisitNum will return 1. If they come back a second time some other day, the plugin returns 2, and so on. The s.getDaysSinceLastVisit plugin will return whether the last visit was less than 1 day ago, less then 7 days, more than 7 days or more than 30 days ago.

The reports you get out of this are relatively useless without classifications. We’ll explain those in the article about SAINT. Once they are classified, though, they can be really powerful!

Your marketer ideally wants visitors to come back to the site often and frequently, no matter what the purpose of the site may be. Using the visit number and days since last visit, we can segment returning visitors into 4 “quadrants”:

1. Visited few times, low frequency
2. Visited few times, high frequency
3. Visited often, low frequency
4. Visited often, high frequency

Analysing the “visited often, high frequency” quadrant might give us an understanding of what these people do. And we could from there figure out how to get some ofther visitors into that quadrant as well, i.e. turn them into more valuable visitors.

The ‘m’ parameter in the s.getVisitNum('m') call stands for ‘monthly’ and tells the plugin to reset the count at the beginning of a new month. Other possible values are ‘d’ (daily), ‘w’ (weekly), or any number which the plugin will read as a number of days.

The related s.getNewRepeat plugin has less functionality than s.getVisitNum and we therefore never use it.

s.getPreviousValue

This plugin is used to store a value for later use and at the same time retrieve the last value stored. It is slightly non-intuitive to use, so let’s look at an example:

	var test1 = s.getPreviousValue('foo','gpv_test');
	var test2 = s.getPreviousValue('bar','gpv_test');

At this point, test1 will contain whatever value had been stored in the “gpv_test” cookie originally, the cookie will now contain “bar” and test2 will contain “foo”.

You would usually call s.getPreviousValue on every page of your site, not twice on the same. One common use case is to store the page name, like so:

	var s.prop4=s.getPreviousValue(s.pageName,'gpv_page');

We’ll get back to the use case around this.

We deliberately did not want to explain s.getQueryParam in too much detail, even though it is the most used of all the plugins by far. There’ll be a separate article when the time comes.

Cookies

Most of the plugins use cookies to store state. Especially those that work across visits (like s.getVisitNum, s.getDaysSinceLastVisit or s.crossVisitParticipation) are obviously relying on people to not delete their cookies!

The bad thing is that cookies are not as reliable as they used to be. People are getting increasingly aware of their ability to delete them. The good thing as that all cookies set by plugins are set through Javascript and are therefore by design 1^st-party cookies, which means even Safari and Firefox 22+ accept them.

As a rule of thumb, cookie acceptance and deletion rate these days are still ok in the sense that the reports based on the plugins allow marketers to draw valid conclusions.

Notes

While some plugins come for free and can be found in the Knowledge Base, others are implemented by Adobe Consulting only. Yet others are written by 3^rd parties.

For two good examples, you might want to visit Kevin Rogers or Jason Thompson. Both are active on twitter as well (@vabeachkevin & @usujason). Talking about twitter, you can and probably should follow the “#measure” hash tag.

Once you start thinking about plugins and the s.doPlugins() method in general, you’ll quickly get to tag management. Tag management systems offer similar capabilities and much more.

We just mention this because it is the logical next step once you get more savvy and your marketing department gets more demanding.

For a different view on plugins, and without wanting to endorse any particular 3^rd-party tool, let me point you towards Jennifer Kunz’s article “Breaking up with SiteCatalyst Plugins“.

The same can be done with pretty much any tag management system on the market.