Cross-post: I originally published this on SearchDiscovery’s blog in February 2013.
We’ve all had a love/hate relationship with our SiteCatalyst plugins. I mean, where would we be today without good ol’ s.getQueryParam or s.getTimeParting? And when you have a new tracking parameter from your marketers, who doesn’t love to get your developers and implementation consultants to change and test those fateful lines in the doplugins section? But it’s time to move on. Technology has finally caught up to our needs. Plugins you previously couldn’t have lived without are now obsolete, since their functionality is built right into the Satellite interface.
I’ll admit, when Rudi Shumpert posted about how to get a SiteCatalyst Base Code (scode) into Satellite before I started working here, I thought “well, it will be nice to be able to manage/make changes to the scode right within the satellite interface, but Rudi left off a pretty critical piece- plugins! That’s where all the hard work is, anyways.” That plain little s_code you get from the admin console doesn’t include any plugins- yet somehow pretty much every scode on the web includes lines and lines of plugin code. You can’t live without them! Or at least, you couldn’t in the past. But Rudi and Satellite were already a few steps ahead of me.
Where did all those s_codes get their plugin code? Some can be found in the SiteCatalyst knowledge base documentation, some can be found smattered across the web on various blogs (I can’t tell you how often I’ve referred clients toKevin Rogers and Jason Thompson‘s blogs). Either way, you need someone familiar with the plugins, their use-cases, and their gotchas, to implement them for you: the Implementation Consultants. As someone who has made a living for 6 years as an scode jockey, I can tell you that while there is always plenty of s_code work to keep an IC busy, we’d much rather focus our efforts on streamlining processes, create better governance and standards, and helping bring in data that can really change the way an organization does digital business.
Now that I’ve had more of a chance to work with Satellite, I see Rudi wasn’t wrong to omit plugins in his post: he just knows that with Satellite, you may simply just not need them! Take getQueryParam for example.
Query Param Tracking – The Old Way
In the past, if I used a query string parameter, such as “cid”, “cmpid”, or “source”, in my marketing URLs to track campaigns, I’d need to include this in my scode in the sdoPlugins function:
s.campaign=s.getQueryParam('cid');
Then in my plugins section, I’d need to include the whole getQueryParam plugin (hopefully the most recent version, which is currently 2.3).
/* * Plugin: getQueryParam 2.3 */ s.getQueryParam=new Function("p","d","u","" +"var s=this,v='',i,t;d=d?d:'';u=u?u:(s.pageURL?s.pageURL:s.wd.locati" +"on);if(u'f')u=s.gtfs().location;while(p){i=p.indexOf(',');i=i<0?p" +".length:i;t=s.pgpv(p.substring(0,i),u+'');if(t){t=t.indexOf('#')>-" +"1?t.substring(0,t.indexOf('#')):t;}if(t)v+=v?d+t:t;p=p.substring(i=" +"=p.length?i:i+1)}return v"); s.pgpv=new Function("k","u","" +"var s=this,v='',i=u.indexOf('?'),q;if(k&&i>-1){q=u.substring(i+1);v" +"=s.pt(q,'&','pgvf',k)}return v"); s.pgvf=new Function("t","k","" +"if(t){var s=this,i=t.indexOf('='),p=i<0?t:t.substring(0,i),v=i<0?'T" +"rue':t.substring(i+1);if(p.toLowerCase()k.toLowerCase())return s." +"epa(v)}return ''");
Now you’d wait for developers to test it, and/or for the next code release cycle. Not exactly the most clear-cut solution for something so simple, is it? In truth, this is probably the easiest, most simple plugin you can implement in your s_code. And if you wanted to keep it in your s_code, you still could, and manage it within Satellite to keep it easy to manage and control.
Query Param Tracking -The New Way
Now, you can accomplish the exact same purpose with a few keystrokes and a mouse click. In either your page rules (to apply to only a subset of pages) or your overall tool settings (to apply site-wide), you’ll find the campaign variable :
Done! Yep, that’s it.
Additional Uses
If you need to capture different query string parameters into different variables – for example, an internal promotion into ?icid – this is done with one additional step: the creation of a simple data element (under “rules” then “data elements”). Give it a friendly name for the satellite interface, select “URL Parameter” under type, enter the parameter, and save.
All that’s left to be done is to call that data element in the eVar itself. This can be done site wide (in your tool settings) or for a specific page or subset of pages- either way, the set up is the same and very simple. I set the eVar number, type “%” to let Satellite know I am calling a data element, choose my already-created element from the list, and hit save:
I save my rule or my settings, test it, and publish it- a process that could be completed in as few as 5 minutes. Done. No code touched. The s_code file is still that basic, plain s_code straight from the admin console.
Conclusion and Next Steps
Obviously this is a very simple (if very common) use case. I implemented both campaign and internal promotions on my own site in under 15 minutes. I’ll be following this post by looking at other plugins that Satellite can free you from, including the linkhandler plugins, getPreviousPageName, getAndPersistValue, appendToList, Form Analysis, and forceLowercase plugins.
Are you ready to move on? Which plugins are you ready to leave behind?