Thursday, 4 September 2014

SiteCatalyst - Configuration Variables

Aug 20th 2014, Noon (Indian Standard Time)

I am preparing for the SiteCatalyst Implementation certification. Don't know yet how much will it help my profile, but since I have started it, I will finish it. 

So, there is a Curriculum for the examination which can be downloaded at - SCImplementationExamGuide

I have recently completed my processing rules certification, I have a score of 100% in that, but after appearing through that one, I am taking this one a bit more seriously.

I have completed the topics till Conversion variables, Features and Functions and today I am beginning with the Configuration Variables.

So, first of all what are Configuration Variables. Lets Google - SiteCatalyst Configration Variables

Webmetric.org  has provided a pretty exhaustive content. Much appreciated. Usually, there is just copy paste from SiteCatalyst PDFs. But, this one is helpful. 

Another good content can be found at AnalyticCafe

So, one general understanding after skimming through the content is that the Configuration Variables are the fundamental setting for the Analytics JavaScritpt Library. In most cases you will not change them at a page level (Exceptions- Link tracking ). Secondly, they don't directly collect data but rather affect data collection. You will not find a report for report suite IDs or currencies by default in SiteCatalyst.

Lets have a look at the list of Configuration Variable
  1. s.account
  2. currencyCode
  3. charSet
  4. trackDownloadLinks
  5. trackExternalLinks
  6. trackInlineStats
  7. linkDownloadFileTypes
  8. linkInternalFilters
  9. linkExternalFilters
  10. linkLeaveQueryString
  11. linkTrackVars
  12. linkTrackEvents
  13. cookieDomainPeriod
  14. fpCookieDomainPeriod
  15. doPlugins
  16. usePlugins
  17. dynamicAccountSelection
  18. dynamicAccountMatch
  19. dynamicAccountList
So, that brings the total to 19 configuration variables over which we have control. 

Tomorrow I will tick them off one by one from this list.

Ok, Aug 21st - Time flies!

So, its 10.35 AM, I am back from gym and now its time for some Analytics Heavy lifting. I start my daily learning with some blogs. I alternately read Google Analytics and SiteCatalyst. Today its Google Analytics,
So lets see what Justin Cutroni has for us today.

I read Advanced Content Tracking with Universal Analytics. Go check it out. He has written a JavaScript to track events for how is content being read by readers on a site. Pretty Sweet and simple. I also need to learn how to write such codes.

Now, coming back to Configuration Variables - 

1.s.account
The report suite is the most fundamental level of classification you apply on analytics data. Each report suite has a Unique ID. The s.account is nothing but a way tell Analytics data collection server about the Report suite to which the data is to be sent and we do that through the unique ID. Please keep in mind the report suite name is different from report suite ID. The scope of report suite name is only till your account and the scope of report suite ID expands till Adobe Data collection servers. 

For a single suite tagging, here is an example -

s.account = "AwesomeAnalytics"

For multi suite tagging use a comma separator - 

s.account = "AwesomeAnalytics,SuperAwesomeAnalytics"

Other things to keep in mind -
  • Each ID has a total length of only 40 bytes
  • Don't use space while declaring the multiple IDs
  • Unique ID should contain only alphanumeric characters, the only exception being hyphen "-"
Well, that's pretty much it about the s_account, lets look at the next variable - currencyCode

Now, this is one variable which should be ideally set in the s_code. Why I am saying this? Coz its non persistent, so you gotta send this information with every image request. Now, in most cases the currency of the website is kinda constant and even if it changes you can write a small code with certain if else statements and allot the currency accordingly. Thus, try declare in the s_code itself.

But, yes, why it is used. It is basically used to facilitate currency conversions. If you were not aware then SiteCatalyst offers a base currency for each report suite which can be different from the currency at which the item is sold on the website. Now, the currencies are different hence the revenue should also be different. That is we need something to facilitate conversions. currencyCode does just that. Example - 

You are having a global website, but you have your head office at US. So, to track your performance you will prefer the reports in US dollars. But across the world you are not selling in dollars. So, lets suppose you are making sales in Japan. So, on the japanese website, you will set s.currencyCode = "YEN" and you can have the base currency of your report suite as Dollars. Now, SiteCatalyst will automatically convert the revenue from Yen to Dollars in your reports. That's really sweet.

Few things to keep in mind -

There are certain currencies like Swedish Krona that don't use period "." but use comma "," in there currency. But periods and commas have different meaning to SiteCatalyst. So, only use periods and not commas while feeding revenue data to any variable.

The default value for this is USD. If you require any conversion, you can simply ignore this
The debugger parameter is CC

Ok, the next one - charSet

This one is only to be used when you are going to feed in data to variables which is having non ASCII characters. Here is a link to the ASCII table - I AM ASCII TABLE.So, just cross check what you are feeding to the variables.

SiteCatalyst uses two character sets - UTF-8 and ISO-8859-1

This one plays a very crucial role for tagging international websites whose character set is beyond the standard ASCII characters.

The charSet declaration is used by Analytics servers to convert the incoming data in UTF-8

The value in s.charSet should match the value of charSet declared in Meta tag or http header. 

As we know that the reports in SiteCatalyst can be populated in multiple languages. When we chose any non English language, then SiteCatalyst uses UTF-8 encoding.


Each Analytics variable has a defined length limit expressed in bytes.For standard report suites, each character is represented by a single byte; therefore, a variable with a limit of 100 bytes also has a limit of 100 characters. However, multi-byte report suites store data as UTF-8, which expresses each character with one to four bytes of data.This action effectively limits some variables to as little as 25 characters with languages such as Japanese and Chinese that commonly use between two and four bytes per character

The JS file must define the charSet variable . (All page views and traffic are assumed to be standard 7-bit ASCII unless otherwise specified.) Setting the charSet variable , tells the Analytics engine what language should be translated into UTF-8. Some language identifiers used in meta-tags or JavaScript variables do not match up with the Analytics conversion filter .

I will take ahead from here tomorrow.


Okay Aug, 22nd 11.17 Am


The only thing I believe that matters most to become successful is consistency. 


First, time for some blog read. SiteCatalyst today. 


I found this post by Adam Greco really Awesome -


http://adam.webanalyticsdemystified.com/2010/05/17/crm-integration-2-passing-crm-data-to-web-analytics/


Aug 24th, 6.30 PM, Sunday


I have been a bit pressed with time for the last two days. Actually was pressed only on Friday,


yesterday I did not do anything that productive except the gym. It was weekend so i could train 

guilt free. By the time i left the gym last night, i was so tired i could sleep in the gym it self :P 

Anyway the next configuration variable - trackDownloadLinks


This is one is pretty simple and sweet. It does two things -

1. As the name suggests, provides the provision to track download links

2. Affects the clickMap data for the downloadable links

The implementation is pretty simple. Its value is either true or false -


s.trackDownloadLinks = true

I wonder why would anyone keep it false. So, if its set to true anytime someone clicks on a downloadable link, the data is sent to Analytics engine. What data? The name of the link and the click instance.

When its combined with the clickMap. The data will be shown along with the page on which the link was clicked. If you set this variable to false, clickMap data will be affected.

That's pretty much it about this one. So, the next one - trackExternalLinks

I will not spend much time on it. Its pretty straight forward. If its set to true it tracks clicks on external links else it does not. All links whose domain does not match with the one you define in are external links. This one also affects the clickMap data.

So, the next - trackInlineStats

this one is important. Again this only has the value as either true or false. If it is set to true then only the clickMap data is recorded otherwise not. It populates the clickMap reports

Next - linkDownloadFileTypes

This one works in tandem with trackDownloadLinks. It is simply a comma separated list of extensions for various file types that exist on your site. If a particular extension is not part of this link, the corresponding downloadable file will not get tracked for Analytics.Thing to keep in mind is that Analytics can track only left clicks downloads and not the right click save as downloads, as left click is under the scope of browser and right click and save as is beyond the scope of browser and under the scope of operating system. Example -

s.linkDownloadFileTypes="exe,zip,wav,mp3,mov,mpg,avi,wmv,doc,pdf,xls,xml"

Tomorrow I will start from linkInternalFilters

Ok, its August 25th, 10:30 AM

As usual I will start my day with some blog read. Google Analytics today. Here I come Mr. Cutroni

I read - http://cutroni.com/blog/2014/01/09/set-google-analytics-content-grouping/

Good as usual

Now, the next variable - linkInternalFilters

This variable is used in conjunction with trackExternalLinks. When we define linkInternalFilters we basically tell SiteCatalyst or the Analytics engine about what are the links or domains that we don't want to be tracked as external links or in other words you are telling the Analytics engine that these are my internal links. So, you also need to specify the domain on which the ananlytics is getting implemented. Lets look at an example -

s.trackExternalLinks=true
s.linkInternalFilters="javascript:,example.com,example1.com,exampleAffiliate.com"

In the above example i have told the Analytics engine that dude links to example.com, example1.com and exampleAffiliate.com should not be considered as external.

Again, notice this I am not using any spaces in the syntax.

Cool, lets move ahead - linkExternalFilters

This one is used when you are very particular about the exit links you want to track. In other words there are only certain exit links you want to track and not all exit links. So, using this configuration variable you provide that list of exit links to be tracked to the analytics engine. For example, I have many exit links on my site but I want to track only BadaBoom.com

s.trackExternalLinks=true //yep bro track 'em
s.linkInternalLinks="javascript:,example.com"
s.linkExternalLinks="BadaBoom.com"

Now, what we have done is that we have provided two filters to the Analytics engine. One tells what are my internal links. This will filter out all the links that I don't consider my internal links. Next I put a filter around the external links for the links I want to be tracked. The rest of the external links won't be displayed in the exit links report. If you don't want the second filter simply leave it blank-

s.linkExternalFilter=""

Now, the next one - linkLeaveQueryString. By the way we are half way done :)

I find the name of this dude very complex - It says leave Query String, but if you set it to true, it does not leave query string. So, to deal with this one - tell it what you don't want and it will give you what you want. Another thing all the configuration variables that have "link" in them will affect ummm.. yeah.. the link tracking. So, while tracking the links do you want to consider the Query String parameters or you don't want? Just remember example.com and example.com?query=badaboom are essentially the same pages but when you set s.linkLeaveQueryString = true, this will track both links as separate and different. So, if you want only those links that lead to example.com irrespective of whether it was example.com?query=Badaboom or example.com?query=BadaBadaBoom set s.linkLeaveQueryString= false.

So, next one - linkTrackVars

This one is very very very important as any goof up with this will drastically affect your server calls and data being captured by other variables. So, lets dance.

This one is used to send data on exit, download and custom links. Its very dumb and freaks out it no instructions are given to it. You have to tell it what are the custom variables to which the data needs to be sent upon the click events. If you don't tell it, its panics and resends data for all the variables who have a value at the time of a click to the analytics engine and hence duplicates the data for the other report causing erroneous inflation. So, never leave this one blank. I repeat never leave this one blank!

in the Analytics s_code define it as none -

s.linkTrackVars=none

Ideally, this should be recorded in the onClick events. example -

<a href="index.html" onClick="
var s=s_gi('rsid');
s.linkTrackVars='prop1,prop2,events';
s.linkTrackEvents='event1';
s.prop1='Custom Property of Link';
s.events='event1';
s.tl(this,'o','Link Name');
">My Page
The above example i copied from the SiteCatalyst Implementation guide. In this example we are doing a custom link tracking.the var s = s_gi('rsid') is providing the report suite Id which is rsid in this case.We want to send data to prop1, prop2 and event1 on click of this link
s.tl() is used for custom link tracking
Please take notice we don't provide value to linkTrackVars as s.prop1 or s.prop2 or s.events.We simply write prop1,prop2,events. Again, no commas. For tracking events we use linkTrackEvents which I will be covering next.Ok, so tomorrow I will take from linkTrackEvents. I want to you to smile right now. May the rest of your day be super amazing. Cheers!

August 26th, 12:07 pm, yes got a bit delayed today. Was working up for my other project -

livAwesome, its a self-help project I am working upon. You can check that out.

Ok, lets start with a blog. SiteCatalyst today.


Nice, so the next vatiable - linkTrackEvents


So, whenever you are doing a custom tagging for a link, and on specific onClick events you want to fire apart from prop and eVar an event as well, linkTrackEvents is used over there. While defining this event you first need to include "events" notice the "s" in linkTrackVars and in the following statement specify the name of the event you will be using in linkTrackEvents.Again, you will not be specifying the values as s.event1 or s.event2, you will simply write event1,event2,event3....
The declaration of event in s.events=eventX is still required. Please refer the to the example above for better clarity.

Ok, now lets look at the next one - cookieDomainPeriod


Any mistakes with this one can screw up your data, particularly around the count of unique 
visitors. Let me explain what it does. The setting on this variable directly affects the acceptance/rejection and functionality between the browser and Analytics cookie.
If you find the understanding of this variable difficult then don't take alot of load. Simply put the number of periods in your DOMAIN as the input to this variable. Put only the number of periods in Domain and NOT THE SUBDOMAIN.

By, default the value of this variable is 2. 


If your domain is AwesomeAnalytics.com then the cookie domain period is 2 
if it is AwesomeAnalytics.co.in then the cookie domain period is 3.
Now, if the page is having URL www.badaboom.AwesomeAnalytics.com then still the cookie domain period is 2 and not three because we are providing the name of domain and not the subdomain.

But, what happens if my cookieDomainPeriod is 2 but my domain has three periods. For 

example, AwesomeAnalytics.co.in. In this case the s_code will attempt to set a cookie for co.in domain and not AwesomeAnalytics.co.in. Now, since co.in is not a valid domain, the browser will get pissed off and ask the s_code to bugger off and reject the cookies, this will terribly affect the count of unique visitors and functionality of many of the plugins.

Another example you have a subdomain badaboom.AwesomeAnalytics.com. Here the 
CookieDomainPeriod is 2 and you give the value three. The analytics will assume that the domain is badaboom.AwesomeAnalytics.com and not AwesomeAnalytics.com. Now, if you have another subdomain NotBadaBoom.AwesomeAnalytics.com. This will be separate 
website altogether, so would be AwesomeAnalytics.com. So, this will affect the functionality of cookies and also in linkInternalFilters you have the name of your domain and not the subdomain, things will get screwed up.

One more thing - enter the values a string that is 2 is "2"


If its still not clear just set the value to number of periods in your domain please.


Now, next fpCookieDomainPeriod. 

The fp stands for first party. This is used by Analytics to set up first party cookies OTHER 
THAN visitor Id cookie (s_vi) that is it does not control s_vi. The visitor click map cookie -s_sq and cookie checker -s_cc, plus cookies set up by a few plugins like getValOnce are affected by this variable.

Again simply put the number of periods in your domain into this period. 


Tomorrow, I will take it up from dPlugins. Cheers!


August 28th, if you did not notice, i did not blog yesterday, was really busy with some other work. Its been two days I have not been to gym.

Ok, so getting down to business - doPlugins


So you might be aware that there are various plugins that you can use to enhance the 
functionality of your Analytics implementation. To use plugins apart from adding the plugin code to the Appmeasurement.js library or the s_code, You need to configure three other variables -

usePlugins


doPlugins

s_doPlugins function

First, set s.usePlugins=true


second, define the s_doPlugins function third, feed to output of s_doPlugins function to s.doPlugins variable -

Example, we want to feed a default value to prop1 by using some plugin. Add this code to s_code -
usePlugins=true
function s_doPlugins(s){
s.prop1="Plugin output"
}
s.doPlugins=s_doplugins

Just a piece of information - When visitor comes to your website, then the Javascript files get cached to the visitors browser. The Analytics is driven by that cached version only, till it gets updated. So, if you have made any updates in your Appmeasurement library or s_code and the change is not getting reflected that is because the visitor's browser is using the cached version. This can happen to you also during testing. You might have made the correct update, but it won't get reflected because your browser is not deploying the latest library. So, its a good practice to clear your cache before testing any updates.

September 3rd. Blogging after let me count - 5 days! I went home actually and post my return I have not been able to manage my time well. But, anyway the essence lies in moving forward.*Fingers popping*

Just three left - dynamicAccountSelection, dynamicAccountMatch and dynamicAccountList. All three are used in conjunction with each other. As their name suggests, they are used to dynamically select the report suite to which the data is to be sent.

Lets start with dynamicAccountSelectio. The input is just true or false. If want dynamic selection, simply set it to true.

Now, dynamicAccountList. In the syntax of dynamicAccountList we specify two things. One, the report suite Ids and two, the URLs.

We basically tell the Javascript to select particular report suite IDs based on the URL of the webpage. So, lets have a look at the syntax.

s.dynamicAccountList="reportsuiteId1,reportsuiteId4=AwesomeAnalytics.com;reportsuiteId5,reportsuiteId3=BadaBoom.com"

Key characters to keep in mind here are comma, semi colon and equal to. Look at the way I have put them here. I so wish SiteCatalyst had been consistent with it. like for products, different product declarations are separated by comma and individual properties by semi colon. Here the case is opposite. So, keep these things in mind.

Now, dynamicAccountMatch. This is kinda complex for people who are not that geeky. So, you first enable dynamicAccountSelection, then you provide the criteria in the dynamicAccountList and then, you tell the Javascript where to implement this criteria, and this is done through dynamicAccountMatch.

The value you feed to dynamicAccountMatch are DOM objects on which you want to apply the criteria mentioned in dynamicAccountList. Following are the DOM objects to which you can apply dynamicAccountSelection -

window.locatio.host - to apply it to domain, this is also by default
window.location.pathname - to apply it to the path in the URL
( window.location.search?window.location.search:"?") - to apply it on a Query string
window.location.host+window.location.pathname - Host name and Path
window.location.pathname+(window.location.search?window.location.search:"?") - Path + Query String
window.location.href - Entire URL

Keep in mind dynamic Account selection is not supported by the latest Appmeasurement for Javascript.

And Voila! we are done! So, how many days it took me? 15 days! jeez. But, the point is this blog now exists in this world and we both learned something. Consistency matters.

Please give me a feedback if you have some time.

Till then, Happy Analytics!

Cheers!







2 comments: