I know you’re all work­ing hard, but it’s time to take a quick break and lighten up.  Last year, we sent our core ana­lyt­ics JavaScript file off to boot camp and it’s returned faster, lighter, and more pow­er­ful.  The updated core file was released as part of the May main­te­nance release (5.23.2013) along with a re-vamped code man­ager page.

The new ver­sion is light & fast enough to be used with mobile sites AND robust enough to be used on the full desk­top web, allow­ing you to lever­age a sin­gle JS file across all web mea­sure­ment envi­ron­ments.  There are also a num­ber of pow­er­ful new capa­bil­i­ties in the new JS file which I’ll walk you through in detail; but first, let’s hit the highlights:

  • Smaller: 22k uncom­pressed & 8k gzipped (H.26 code is 33k uncom­pressed & 13k gzipped)
  • Faster: 3-7x faster than the H.25 code
  • Native Util­i­ties: new native util­i­ties pro­vide product-level sup­port for sev­eral com­mon plu­gin use cases (get­query­param, linkhan­dler, cookie han­dling, url encoding)
  • Mod­ules: updated Inte­grate and Media Mod­ules avail­able from code manager
  • Head Tag Deploy­ments: deploy­ing s_code and page code inside the <head> tags is fully supported

A Quick Word About Performance

Before you run off and set up a per­for­mance test to see if the improve­ments are really as good as we say they are, the image below shows the results of our QA test­ing using JSLit­mus.  You can also look at a test our lead devel­oper set up on jsPerf: JS App­Mea­sure­ment jsPerf Test.  Of course you are wel­come to set up your own tests but your mileage will vary (espe­cially if you don’t set up the test prop­erly as hap­pened ear­lier today with an “early adopter”).


While the new JS file will dra­mat­i­cally improve your efforts to unify web ana­lyt­ics deploy­ments and increase the sophis­ti­ca­tion of your mobile imple­men­ta­tions, there are two lim­i­ta­tions you should be aware of:

  1. The new JS file doesn’t cur­rently sup­port Tag­Man­ager. We’ll be adding sup­port for Tag­Man­ager later this summer.
  2. The new JS file doesn’t sup­port all Con­sult­ing Plu­g­ins.  A par­tial list of sup­ported and non-supported plu­g­ins may be found here:  App­Mea­sure­ment Plug-in Sup­port. If you’ll be migrat­ing an exist­ing imple­men­ta­tion to the new JS file, you will need to remove or update any plu­g­ins that aren’t sup­ported. Con­sult­ing is cur­rently work­ing to test and upgrade (where nec­es­sary) com­monly used plu­g­ins, and the plu­gin sup­port doc­u­men­ta­tion above will be reg­u­larly updated with these changes.

Ok, now we’ve got that out of the way, let’s walk through a sim­ple deploy­ment and review two of the new util­i­ties in more detail.

Step 1: Down­load the new JS file from the code manager

You’ve prob­a­bly noticed we revamped the code man­ager page.  The new page has links to all the cur­rent ana­lyt­ics mea­sure­ment libraries (includ­ing mobile apps) along with links to mea­sure­ment doc­u­men­ta­tion and ver­sion history.


Step 2: Con­fig­ure Above-the-Line Code

Once you’ve down­loaded the core JS file from the code man­ager, you’ll need to add the con­fig­u­ra­tion set­tings to the top of the file.  When com­plete, your code will look some­thing like the image below.  You’ll notice the way the instance is instan­ti­ated (top two lines of code) is slightly dif­fer­ent from the old method—be sure to use this new approach if you’re migrat­ing to the new library.


Step 3: Con­fig­ure Plugins

If you’re doing a first-time deploy­ment, this is where you’ll add plu­gin and util­ity func­tions to enhance the data col­lected by the core JS file.  If you’re migrat­ing to the new ver­sion of JS, here’s where you’ll need to do a thor­ough review on the plu­g­ins you are migrat­ing to ensure every plu­gin is work­ing as expected.  You may wish to work with Adobe Con­sult­ing Ser­vices if you have a com­plex plu­gin setup.

Step 4: Con­fig­ure Utilities

We’ve added sev­eral util­i­ties to cover a few com­mon plu­gin use cases.  If you’re using get­query­param, linkhan­dler, url encod­ing, or set­ting cook­ies in your core JS file, you should replace the old func­tions with the new core util­i­ties.  Please note the get­Query­Param plu­gin is not com­pat­i­ble with the new ver­sion of JS.  You will need to ensure you replace the plu­gin with the utility—I’ll show you how to do that next.


Let’s assume for a minute you have a cam­paign that points peo­ple to your web­site.  The link appends the query string “cid=springpromo” in the url and you are cur­rently pass­ing “spring­promo” into the cam­paign vari­able via the get­Query­Param plu­gin.  The fol­low­ing code demon­strates how you would migrate this functionality.

Old Code

/* Plu­gin Con­fig */
func­tion s_doPlugins(s) {
/* Add calls to plu­g­ins here */
/************************** PLUGINS SECTION *************************/
/* You may insert any plu­g­ins you wish to use here.                 */
* Plu­gin: get­Query­Param 2.4
s.getQueryParam=new Function(“p”,“d”,“u”,“h”,”“
+“var s=this,v=”,i,j,t;d=d?d:”;u=u?u:(s.pageURL?s.pageURL:s.wd.loca“
+“g(i==p.length?i:i+1)}return v”);
s.p_gpv=new Function(“k”,“u”,“h”,”“
+“var s=this,v=”,q;j=h==1?’#’:’?’;i=u.indexOf(j);if(k&&i>-1){q=u.sub“
+“string(i+1);v=s.pt(q,’&’,‘p_gvf’,k)}return v”);
s.p_gvf=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.“

New Code

/* Plu­gin Con­fig */
func­tion s_doPlugins(s) {
/* Add calls to plu­g­ins here */
/************************** PLUGINS SECTION *************************/
/* You may insert any plu­g­ins you wish to use here.                 */


To pro­vide addi­tional flex­i­bil­ity with how you man­age link track­ing (set addi­tional vari­ables, over­ride link track­ing, etc.), the fol­low­ing vari­ables are pop­u­lated before the doPlu­g­ins func­tion runs: link­Type, linkName, linkURL, linkOb­ject.  Here’s a quick exam­ple of how you would use the new linkhan­dler capa­bil­ity to set a con­text vari­able with the link name.  I know this is a sim­ple exam­ple and I’m sure you’ll think of sev­eral more com­plex and use­ful things you could do.

/* Plu­gin Con­fig */
func­tion s_doPlugins(s) {
/* Add calls to plu­g­ins here */
    if(s.linkObject && s.linkType==‘e’){
/************************** PLUGINS SECTION *************************/
/* You may insert any plu­g­ins you wish to use here.                 */

More on linkObject

That was an admit­tedly sim­ple exam­ple; and, if you’re still read­ing, you deserve a bit more detail around how to best uti­lize the linkOb­ject as there are a few gotchas. If a link is coded with an onclick that sends data using s.t() or s.tl(), doPlu­g­ins will run twice: once with the orig­i­nal onclick, wherein linkOb­ject, link­Type and linkName or linkURL will be set, and these vari­ables can be used to set link­Track­Vars and other vari­ables, or abort tracking.

Then, doPlu­g­ins will run a sec­ond time, this time because of the event lis­tener attached to the body or link by the core JS file. This time, the linkOb­ject, link­Type, linkName and linkURL will be empty. If you were to set link­Type and linkName this time (for any rea­son), you would send another server call right after the first one. This would be bad. As such, it is strongly rec­om­mended that before con­sid­er­ing using linkHandler-like func­tion­al­ity, the cus­tomer check for a value of linkOb­ject like this:

       // eval­u­ate link­Type, linkName, etc.
       // walk up the DOM using linkOb­ject, look­ing for stuff
       // set vari­ables appro­pri­ately

When some­thing is clicked, the JS file eval­u­ates the clicked object to see if linkOb­ject should point to it. If it should not, it will walk up the DOM look­ing for a par­ent that matches spe­cific cri­te­ria. linkOb­ject will only point to an object when that object or a par­ent of that object:

  • Has an onclick (not an event listener)
  • Is an anchor tag with an href or an area tag with an href
  • Is a form sub­mit but­ton with a value or an input with a value
  • Is an image with a src attribute

A com­mon use case is for users to look at a DOM ele­ment to see whether it’s a child of a DIV or other ele­ment that meets some cri­te­ria, such as whether it has an ID or class that equals “top_stories” or some­thing sim­i­lar. If walk­ing up the DOM, users will cre­ate a loop look­ing at the par­entEle­ment or par­entN­ode until they are both not set or the body tag is reached. This would look some­thing like this:

    var o = linkOb­ject;
       o = o.parentElement ? o.parentElement : o.parentNode;
          if(o.id = “top_stories”){
             s.prop10=“Top Story”;
             s.linkName=“Top Sto­ries”;

 Step 5: Ver­ify New Code

Once you’ve com­pleted the changes and pushed the file to your web envi­ron­ment, you should ver­ify the file is send­ing ana­lyt­ics requests and the code ver­sion now starts with JS– in the debug­ger or packet snif­fer of your choice.


Now you’ve light­ened up, you’re wel­come to go back to what­ever you were doing.  As for the guys in the pic­ture, I’ll let you decide if they are jazzed about the new capa­bil­ity or are act­ing like the 3 wise mon­keys.

A final note on migration

If you’re ready to migrate to the new ver­sion of the JS but are cur­rently blocked by a plu­gin that isn’t cur­rently sup­ported in the new ver­sion, please bring this to the atten­tion of your con­sul­tant or account man­ager to help Con­sult­ing pri­or­i­tize plu­gin updates.


You can find full doc­u­men­ta­tion on JS App­Mea­sure­ment within the imple­men­ta­tion guide in the knowl­edge base.

Obser­va­tions or ques­tions?  Add a com­ment below.