Boy, does size ever matter – particularly oversize – and, in this post, that’s all that matters, so we won’t be discussing purpose or technique.
Seriously, this post categorizes SiteCatalyst variables based their length, syntax and other restrictions, to focus on tracking rather than reporting.
Categories of SiteCatalyst Variables
The SiteCatalyst Implementation Manual is ok as a reference work but it is far more instructive to look at SC Variables and their restrictions within a categorisation. Here is one way to categorise them:
‘Internal’ Variables
SC collects data ‘behind the scenes’ populating its own variables. Examples include ‘g’ (page URL),’bh’ (browserHeight), ‘k’ (cookiesEnabled), ‘s’ (resolution), ‘t’ (timestamp) etc.
Since they are set automatically by SC, as required, their restrictions are of little further interest here, save that we can use them to populate props and eVars.
Free-form Text Variables
- This categorizes the majority of the SC variables used in our SC coding.
- These include:
- s.pageName,
- s.channel,
- s.server,
- s.prop1 thru s.prop50
- s.campaign,
- s.eVar1 thru s.eVar50
- Traffic free-form variables are limited to 100 bytes in length.
- Conversion free-form variables are limited to 255 bytes in length.
- Their only other restriction is against containing Illegal Characters (see below):
Structured Text Variables
Such variables either have a length limit of 255 bytes or are unlimited (which, on such subjects means no practical limit). They also may have size limits of 255 bytes or other specific limits for individual segments of data. These include:
- s.hierN
- values delimited by a delimiter (typically a : or 😉 configured in the report suite by ClientCare upon request.
- each element and the entire string each have a 255 byte limit.
- s.events
- comma delimited list (no spaces)
- length is unlimited
- each segment has no particular length limit, but that’s irrelevant since each segment must contain a valid event name such as ‘event80’ or ‘purchase’
- each event in the segment (except purchase) may have a serializing identifier (e.g. ‘event80:a8dke8tm5jk9’ or ‘event80:12345’) which may be alphanumeric and may not exceed 20 characters.
- s.products
- length is unlimited as is the length of each segment
- however, the length of each Product or Category value within each segment is limited to 100 bytes
- wins the ‘Most Complex Variable Syntax’ award like Canada playing ice hockey against South Africa!
- The syntax of s.products is documented well in the Implementation manuals and does not need improvement here.
Almost free-form text
- These have no specific syntax requirements(e.g. not comma delimited)
- Similar to g, SC’s internal variable containing the URL of the page.
- The only one in this category is s.referrer which should contain a validly formatted and encoded URL
- Limited to 255 characters.
JavaScript-only Variables:
- Their values are not sent to SC servers and therefore have no data storage or other server-based limitations
- They have no SC length restrictions.
- They are only used by the s_code as configuration variables to determine what data to send.
- However, they may have syntax and/or value type restrictions in that sum must be numeric or Boolean
- Syntax restrictions typically refer to them being comma delimited lists (cdl) without spaces , e.g.:
- s.dynamicAccountSelection (cdl)
- s.linkDownloadFileTypes (cdl)
- s.linkTrackVars and s.linkTrackEvents (cdl or “None”)
Value Type
SC variables are not strongly typed but some expect certain types of values like logical or numeric
Although some such variables are sent to SC, the majority are not. So, I’m dealing with this type of restriction within the JS-only category:
- s.linkExternalFilters: ‘true’ or ‘false’
- s.usePlugins: ‘true’ or ‘false’ or ” or not used at all.
- s.doPlugins: one of the most unusual variables set by the implementation programmer. It is typically assigned the value s_doPlugins, where s_doPlugins is of the data type ‘function’ (ok, it’s a pointer to a function). It tells SC what function to execute just before it sends data off to SC servers using either s.t() or s.tl();
Some cross-categorised Variables
These defy categorization. They are limited by the actual values they must store and/or by their structure. They are better regarded as exceptions.
- s.cookieLifetime
- A weird one since it can be assigned either a specific string (“NONE”, “SESSION”, “”) or an integer (seconds)
- Also weird because it is both vital to JS configuration variable and is sent to SC.
- s.currencyCode: may only be assigned one of the 3-char ISO codes (e.g. ‘USD’, ‘CAD’, ‘EUR’. ‘AUD’ etc) as listed in Multi-Currency.pdf
- s.dc (data center): assigned a value identifying the address of the SC data centre to which your data is to be sent. e.g. 112, the default if s.dc is blank.
- s.charSet: one of the valid ISO character set codes listed in SC’s Multi-byte Character Sets documentation. It is not required if you use ASCI characters with codes less than 128.
- s.pageType: either “errorPage” on Error 404 pages or “”.
- s_account:
- comma delimited list (no spaces) of report suite id’s to which data is being directed.
- each report suite id is limited to 40 bytes.
- although s_account has no practical limit, if there are more than 20 report suites there is either a serious report suite design flaw or SC want you to use a VISTA to despatch server calls to the report suites.
- must be declared before the s object instantiated. That is, before the call to s=s_gi(s_account) near the top of s_code.js or before s_code.js loaded. As such it is not an s.<variable> at all.
Illegal Characters
The following characters may not be contained in any of your variables
- Tab (ASCII 9 or 0x09)
- Carriage return(ASCII 10 or 0x0D)
- Newline (ASCII 13 or 0x0A)
- ASCII characters with codes above 127 (except in the case of properly configured report suites supporting multi-byte character sets in sync with your s.charSet value)
- HTML tags (e.g. <b></b> or ™)
To avoid them, use JavaScript’s escape() function to URLencode them, although they may be encoded before leaving the visitor’s browser.
The real problem here is that they will consume additional bytes. E.g. a single space will become 3 characters when changed to %20 and an & 5 characters when becoming &
The Size that Really Matters
At the end of the day, one cannot send unlimited amounts of data to SC, even if all the above restrictions have been obeyed.
With 50 props (100 chars each), 50 eVars (250 chars each), products, 80 events (out of the box), etc, the total size of the image request to SC may easily exceed what visitors’ browsers can handle.
Fortunately for us, me in particular, Jason Thompson just posted an excellent article on the Adobe Site Catalyst Developer Connection at https://developer.omniture.com/node/5723 dealing with this very issue.
For reasons Jason explains, your image requests should not exceed 2083 bytes and he gives you a small little tool to measure them – just copy the following code in your address bar:
<![CDATA
]>
Jason also provides a great diagnostic solution to report pages with image requests that exceed or are at risk generating image requests that are too large.
Reduce your Size in 7 days or your Money Back
When your image requests are too big, its often caused by having lengthy values, like URLs and page names, being copied to multiple variables. To reduce the size of your image requests, SC provides a syntax called Dynamic Variables that allows one to do what comes naturally in many programming languages:
Instead of:
use:
When the SC server evaluates s.prop1 and sees its value begins with D=, it evaluates the expression and assigns the value of pageName to s.prop1.
This code does not have to be retrofitted into every page or even some pages. Rather, pick out the worst culprits and reassign them in do_Plugins().
The topic is discussed in the Implementation Manual (search it for s.dynamicVariablePrefix) and in Article ID 10099, 10142 and 10297
Looking Forward …
We look forward to bringing you more SiteCatalyst Close-ups and your feedback and suggestions will go far in driving and inspiring more posts. Some already in process include closer looks at Page Naming strategies and much ado about ‘None’.
The posts may not be regular, so the “best practice” is to subscribe