Yellow Blocks

My first look at the ‘new’ V1.0 AppMeasurement.js for Omniture – {updated}

By fraser, September 17, 2013

I’m assuming that many of you have not yet looked into implementing the ‘new’ lightweight tracking file AppMeasurement.js? (s_code.js in old money).

Supporting Omniture implementations that are a few years old can be a challenge when they have grown organically. Tracking files can appear in all sorts of locations on many different sites. Some of you will have millions, maybe billions of dollars dependent on your tracking working. It is no small decision to start updating s_code files which have seen product teams eagerly laying-on updates over the years. You might be at a stage where everything is working swimmingly? You might be too nervous to touch it as the horde of product managers will come vying for your blood! Either way, tracking waits for no man, move on we must.

So when, how and why should you move to the new-and-improved-whiter-than-white AppMeasurement.js? This is what my article looks to find out.

Like me, you probably took one look at the new obfuscated files and thought, “I’ll look at it later when I’ve run out of conspiracy theories to watch on Youtube”. Now that I’m finally convinced that the world is going to end and we’ll just end-up as robots driving Google cars — I’m happy to spend my futile existence on tracking code.

First Glance

Screen Shot 2013-09-18 at 11.08.21 AM

The downloadable zip file from Adobe Code Manager isn’t instantly a familiar format. There are a couple more files included. Let’s have a closer look.

AppMeasurement.js
AppMeasurement_Module_Media.js
AppMeasurement_Module_Integrate.js

AppMeasurement.js

This file contents will be recognisable to most of you. Instantly my thoughts are that we won’t need to edit the file as its got ‘the warning’…


/* ============== YOUR CHILDREN WILL BE UGLY AND YOUR WIFE WILL LEAVE YOU FOR A WEBTRENDS SALESMAN IF YOU EDIT ANYTHING BELOW THIS LINE ! ===============
AppMeasurement for JavaScript version: 1.1
Copyright 1996-2013 Adobe, Inc. All Rights Reserved
More info available at http://www.omniture.com
*/

AppMeasurement_Module_Media.js

I have done my fair share of Media Module implementations over the years. Some of you will have a general distain to the two words. I know many companies who have traditionally struggled with tracking media assets. Will this update see a departure from the struggle, offering a simplified media tracking solution? This file is obviously an optional include if you don’t currently use the media tracking module.

AppMeasurement_Module_Integrate.js

Lastly AppMeasurement_Module_Integrate.js. A quick scan I can see a callback in there. Maybe this is an optional asynchronous module?

Update – Now more information available now Appmeasurement_Module_Integrate.js is an integration module for Demandbase and Genesis partners. Not an asynchronous module like Google Analytics API which I first thought it could have been.

Before we get started scouring the new code it is probably wise to see what Adobe has to say about it. I know as blokes-of-the-world, (please object in comments if you are a lady) looking at instruction manuals is not the manly thing to do. In many ways, we should be thankful that Adobe are creating good documentation, as old-money-Omniture often gave detailed descriptions of “page not found” in the help section.

AppMeasurement for JavaScript

So having a quick gander at the documentation gives a few ideas on what to expect. I’ll break out the useful points.

This version drops support for the following browsers

  • IE 4 and 5
  • Opera 6 and earlier

NOOOOOOOOOOO not IE 4 & 5!! noooooooooo oo oo o

New Initialization method

s = new AppMeasurement();
s.account=”rsid”

Old Initialization method

var s_account=”rsid”
var s=s_gi(s_account)

The legacy (s_code) initialization process is still supported for backward compatibility:

With backward compatibility of the old initialization method, it would suggest there is not much point yet in updating old desktop code for a few kb saving. Mobile sites would definitely benefit for the reduced file size and generally would be easier/safer to update first (Mobile optimised sites commonly use less variables and customisations).

It would be good for any new desktop or mobile implementations to get AppMeasurement.js file. Please check that your plugins are compatible if the new desktop/mobile pages are part of a user journey that relies on plugins passing info from previous pages. Hmmm plugins you say…

Tested Plugins

Adobe says: The following plug-ins were tested and verified as compatible:

  • appendList
  • crossVisitParticipation
  • userAgentManager
  • getTimeParting
  • join
  • split
  • getDaysSinceLastVisit
  • getNewRepeat
  • getTimeToComplete

Untested Plugins

Adobe says: The following plugins should continue to work since the underlying functionality is still supported, but they have not been tested and verified as compatible. You should test these plug-ins in your development environment before migration.

  • getActionDepth
  • getAndPersistValue
  • getCookiesAccepted
  • getValOnce

Unsupported Plugins

Adobe says: These plugins are not supported and no longer function due to their use of functionality that no longer exists in the new AppMeasurement for JavaScript library.

  • manageVars
  • callBack
  • channelExtract
  • channelManager
  • detectRIA
  • deviceOrientationChanges
  • DynamicObjectIDs
  • Form Analysis
  • getPageName
  • manageQueryParam
  • Cookie Combining Utility
  • HTML5Storage

RIP Plugins

Many of you will have ditched lots of these plugins a while ago, especially in Europe when the stricter privacy laws came about. I think if updating to AppMeasurement.js, it would be a good time to review your plugins and have spring clean.

The most common ‘plugins’ that we use are now described as ‘utilities’. These are:

  • Util.cookieRead
  • Util.cookieWrite
  • Util.getQueryParam

You can cover 90% of the above plugin functionality with these methods (and a little javascript skill) so it’s not by chance that Adobe has made these part of the standard code. Nice.

Clearing Variables

A new method for clearing variables has also been provided. This should also help with keeping things tidy. Time to remove those for loops eh!

The method to use is s.clearVars();

  • props
  • eVars
  • hier
  • list
  • events
  • eventList
  • products
  • productsList
  • channel
  • purchaseID
  • transactionID
  • state
  • zip
  • campaign

Let’s have a butchers at the code

Screen Shot 2013-09-18 at 7.03.52 PM

So doing a side by side comparison of the obfuscated code you can see a big reduction in lines.

File Rows Size
Version H26.1 Obfuscated code 169 33KB
AppMeasurement.js 50 24KB
Version H26.1 Media Module Plugin 51 10KB
AppMeasurement_Module_Media.js 15 7KB
AppMeasurement_Module_Integrate.js 4 2KB
File Total Rows Total Size
Version H26.1 220 43KB
AppMeasurement 69 33KB

Thoughts & Summary

Adobe seem to have introduced some good house keeping here. They have looked at what is redundant from the aged s_code.js and started trimming the fat. Instead if reinventing the wheel, the removal of many of the unused plugins has given a good saving in file size. The main saving comes with /** TOUCH THIS AND DIE CODE **/ being 10KB smaller. The refactoring of the code will no doubt enable quicker execution (it’s too late in the evening for me to bother testing). Adobe probably is confident it runs faster having released the getLoadTime plugin on 15 August, 2013. :)

KB saving aside, you’re still going to have to copy your do_plugins() and s.methods() to the top of AppMeasurement.js file. If you have loads of poorly written loops and statements here, that 10KB saving will probably be of little significance. If you are looking to add AppMeasurement.js code to the head and compress with your other JS scripts, you can now do that without issue. There is change in the way the media module is implemented, just a reduction in the module code. The survey module is no longer supported.

In summary, I wouldn’t sweat-it running to complete the update for existing sites. If you use a lot of plugins and have no requirement to move execution to the header then it would be more hassle than it’s worth. New sites and applications will definitely benefit from the lighter footprint. It is not a big departure from the s_code we know and love but on the surface seems to be a good optimisation.

I will be implementing this code soon so will post some details on steps to implement and results in a future post.

targetier has specialised in Adobe Omniture implementation for the past 8 years. Please feel free to get in touch if you are in need of consultancy services

What do you think?

Leave a Reply

Your email address will not be published. Required fields are marked *