We’ve all had a love/hate rela­tion­ship with our Site­Cat­a­lyst plugins. I mean, where would we be today without good ol’ s.getQueryParam or s.getTimeParting? And when you have a new track­ing para­me­ter from your marketers, who doesn’t love to get your devel­op­ers and imple­men­ta­tion consul­tants to change and test those fateful lines in the doplu­g­ins section? But it’s time to move on. Tech­nol­ogy has finally caught up to our needs. Plugins you previ­ously couldn’t have lived without are now obso­lete, since their func­tion­al­ity is built right into the Satel­lite inter­face.

I’ll admit, when Rudi Shumpert posted about how to get a Site­Cat­a­lyst Base Code (scode) into Satel­lite 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 satel­lite inter­face, but Rudi left off a pretty crit­i­cal piece- plugins! That’s where all the hard work is, anyways.” That plain little scode 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 Satel­lite were already a few steps ahead of me.

Where did all those scodes get their plugin code? Some can be found in the Site­Cat­a­lyst knowl­edge base docu­men­ta­tion, some can be found smat­tered across the web on various blogs (I can’t tell you how often I’ve referred clients to Kevin Rogers and Jason Thomp­son‘s blogs). Either way, you need someone famil­iar with the plugins, their use-cases, and their gotchas, to imple­ment them for you: the Imple­men­ta­tion Consul­tants. 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 stream­lin­ing processes, create better gover­nance and stan­dards, and helping bring in data that  can really change the way an orga­ni­za­tion does digital busi­ness.

Now that I’ve had more of a chance to work with Satel­lite, I see Rudi wasn’t wrong to omit plugins in his post: he just knows that with Satel­lite, you may simply just not need them! Take getQuery­Param for example.

Query Param Tracking – The Old Way

In the past, if I used a query string para­me­ter, such as “cid”, “cmpid”, or “source”, in my market­ing URLs to track campaigns, I’d need to include this in my scode in the sdoPlu­g­ins func­tion:


Then in my plugins section, I’d need to include the whole getQuery­Param plugin (hope­fully the most recent version, which is currently 2.3).

/* * Plugin: getQuery­Param 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℗{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” +”,’&’,‘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 devel­op­ers to test it, and/or for the next code release cycle. Not exactly the most clear-cut solu­tion for some­thing so simple, is it? In truth, this is prob­a­bly the easiest, most simple plugin you can imple­ment in your scode. And if you wanted to keep it in your scode, you still could, and manage it within Satel­lite to keep it easy to manage and control.

Query Param Tracking ‑The New Way

Now, you can accom­plish 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 vari­able :

set up campaign tracking in one click

Done! Yep, that’s it.

Additional Uses

If you need to capture differ­ent query string para­me­ters into differ­ent vari­ables – for example, an inter­nal promo­tion into ?icid – this is done with one addi­tional step: the creation of a simple data element (under “rules” then “data elements”). Give it a friendly name for the satel­lite inter­face, select “URL Para­me­ter” under type, enter the para­me­ter, and save.

Creating a data element from a query string parameter

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 Satel­lite know I am calling a data element, choose my already-created element from the list, and hit save:

Adding the data element to an eVar.

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 scode file is still that basic, plain scode straight from the admin console.

Conclusion and Next Steps

Obvi­ously this is a very simple (if very common) use case. I imple­mented both campaign and inter­nal promo­tions on my own site in under 15 minutes. I’ll be follow­ing this post by looking at other plugins that Satel­lite can free you from, includ­ing the linkhan­dler plugins, getPre­vi­ous­Pa­ge­Name, getAnd­Per­sist­Value, append­ToList, Form Analy­sis, and forceLow­er­case plugins.

Are you ready to move on? Which plugins are you ready to leave behind?