Here we are at the last and most important part of the blog "All About Analytics" which is about implementing and migrating s-code.js file provided by Adobe Analytics to AppMeasurement.js file which is the newer version of the sitecatalyst code and is much faster in handling operations than the earlier one.
Before we start of with actual migration code , if you want to read more about the Adobe Analytics and how is it different from Google Analytics . I would recommend you to read this first. Also if you are unfamiliar with the concept of SiteCatalyst "Traffic"/"Conversion" variables (building blocks of analytics) then you should head first to this page for some useful information
Let’s start by addressing a question :
Why should we migrate ?
The Answer to this question is very simple and relies upon keeping the tracking code and functionality up to date with the evolving market and technology. We need accurate results at much faster rates. Adobe claims that the new AppMeasurement code is 10 times faster than the s_code.
Before we get our hands dirty with migration, lets understand that most of the plugins are developed by Adobe Consultant and they are responsible for migrating the plugin code. The Plugin migration is not yet complete and you can follow the migration status on Adobe Analytics plugin support .
If you navigate to above link , you will notice that some of the links are directly accessible and some are not.
For ex. You want to implement Channel Manager plugin to your AppMeasurement code. Even though the status of the plugin is tested and migrated, You could do that only by connecting with Adobe Consultant. DO NOT include the channel manager old plugin code to the new File.
Also there are few plugins that are not accessible but the migrated code of that plugin is available in some or the other way like in community discussions or in issue queues. I came across one use case where I had to dig-in to get the plugin working and I found the working plugin code in one of the community discussions on Adobe docs.
Also while migrating the code, you might have to test your migration and see the results. To do so, you can setup a chrome plugin named “Adobe Analytics debugger” , which will report the test suite results in the browser console.
Moving on,
I will consider a small example of a code written in s_code.js file and convert that to AppMeasurement.js code , so in the end what you will have is the migrated version of the s_code file which is faster that the previous one.
Download the AppMeasurement JS New code from the code manager. The content of the directory looks as follows:
The first basic step is to move all code that appears before the DO NOT ALTER ANYTHING BELOW THIS LINE section in s_code.js to the beginning of AppMeasurement.js.
The second step of migration is to change the line no. 6 and 7 :
Old Method :
New Method :
Notice the to instantiate “s” object, the code is different for the new AppMeasurement js file. The old Code still works though. Because all your page code is also compatible with the new library, the migration can be entirely handled via a change to the s_code.js file.
Next up is the download link tracking and other tracking information :
You can safely copy paste this code to your AppMeasurement js file, this works with AppMeasurement as well.
Also remember that we talked about download link tracking and file download tracking configurations in Google Analytics . Here in siteCatalyst you don’t get this configuration option in the module config page but you can alter and add this as per your requirement to the AppMeasurement js file.
Next is to migrate the getQueryParameter plugin which returns the value of a specified query string parameter, if found in the current page URL. Because important data (such as campaign tracking codes, internal search keywords, etc.) is available in the query string on a page, getQueryParam is helps capture the data into Analytics variables. :
If you are using the s.getQueryParameter :
Then , update this to :
Now, we will migrate the code for getTimeParting plugin, which populates reports with hour of day, day of week, and weekend and weekday values.
As of now in the s_code.js file we have time parting code for populating props and eVars as follows:
Copy paste this code exactly how it is, to AppMeasurment js file.
Now the plugin code in s_code.js file is as follows :
To UPDATE this and migrate to AppMeasurement
Navigate to AppMeasurement Plugin Support
Notice that the plugin is migrated and tested and is also accessible.
Click on the link and navigate to https://marketing.adobe.com/resources/help/en_US/sc/implement/getTimeParting.html
Scroll to the bottom of the page and you will see the updated and migrated plugin code as follows :
Copy paste this code below the plugins section of AppMeasurement.js file.
Now test this file for the above code on your local , by installing “Adobe Analytics Debugger Chrome Plugin”, you will see that this code is now working and eVar24-26 and prop22-24 are populated with time parting values.
That is how a plugin code is migrated from s_code to AppMeasurement js. Look if the code requires the plugin, Check on plugin support document to see if the updated plugin code is available. If yes, then Copy paste that plugin code below “Plugins” section if AppMeasurment.js file. And write the required code for populating variables.
Updated Media Module Integration :
The media module code for s_code js file is as follows :
Now to migrate this to AppMeasurement.
Remember the contents of the AppMeasurement directory , it contains a file named as “AppMeasurement_Module_Media.js” . Copy the JS code written in this file and paste it below the “MODULES” section of the new AppMeasurement.js file
Which will now look as follows :
Do not forget to set s.loadModule(“Media”) = true; , to enable media tracking. Now copy paste the media tracking code to AppMeasurement js file , and notice the results being reported in the Adobe analytics debugger chrome plugin.
So, in the end what you now have is the new AppMeasurement.js file.
What do we know and what have we learned?
Migrating from s_code to AppMeasurement is not a tough Job , all you have to do is,
Check what you want to track and see if it requires the plugin.
Check if the required plugin is migrated or not
If Yes, copy the migrated plugin code below PLUGIN section
Write the required code to populate tracking variables
Check the results on report suits or on console.
One thing that we still need to keep in mind is that, the migration process is still not yet completed. The plugins are being migrated. Which means that AppMeasurement may not provide you the full fledged tracking functionality which your enterprise might require. In that case you have to go with the older version. With this we have come to an end of understanding and implementing analytics on a website and throughout our journey we have seen considerable differences between the two. The choice of the product solely depends upon the resources that you have and the business requirement. One thing that is the core of both the Analytics is the “Javascript”, we can imagine Javascript as the engine of analytics and is responsible for tracking all user activities. What is more important for a developer is to figure out how the product is built. May be tomorrow we can come up with a better product with a bunch of new features!! :)
Comments