SiteCatalyst Close-up:'None' is Too Many and 0 too Few:

We know that Web Analytics, regardless of the vendor solution, is never accurate. It’s about trends. However, that’s only acceptable, “all things being equal”.

But ‘None’ may point the way to know issues and “all things not being equal”.

This series on ‘None’ will highlight recognizing when ‘None’ is a problem and the hidden causes which may be bypassing developers writing SiteCatalyst code.

When ‘None’ is too many

SiteCatalyst Conversion reports (optionally) show the value ‘None’, as in the following example:

This is perfectly logical. E.g. In the case of, say, Campaigns, many visits, if not the majority, are not referred via “Campaign”. And many of those visits result in conversions and success events. In order to have proper context, ‘None’ is the most powerful value in the report. (Go tell that to the marketing manager!)

So! What’s wrong with that report? Particularly given that the code populating the report is called on every page as follows:

 

The eVar is populated at the beginning of every visit. It is configured to expire at the end of the visit. Therefore, it can never be without a value at any point during the visit. Like politicians, it’s never unavailable to take credit for success events. In the case of this eVar, no metrics should appear against ‘None’.

So in such reports, it’s clear that ‘None’ is too many.

Much ado about ‘None’

So why do they appear? And, more importantly, why should we care? Particularly given that this phenomenon, commonly seen, often has much smaller numbers, often well under the magical 10%. The numbers in the above report led to the investigation and to this series.

The problem is it isn’t “trendy”. Errors with known causes cannot form part of our trends. All things are no longer equal. If we can eliminate ~90% of such inaccuracy, the remaining discrepancies are not only smaller but also more technically acceptable.

There are at least 2 causes of this problem that one may find in one’s SiteCatalyst JavaScript code. We are testing our hypothesis that a third cause may be server latency.

Understanding SiteCatalyst Visits

To understand the problem, we need to get close-up and personal with SiteCatalyst visits. They terminate after 30 minutes of inactivity or after 12 hours of time on site.

That 30 minutes is measured from the time the last “web beacon” or image request is received by SiteCatalyst servers for each visitor, identified by s_vi, the 5-year visitor cookie. It does not use client-side cookies to help calculate visits. It also, therefore, does not use the visitor closing the browser to end the visit (which can only be done with a session cookie).

In contrast, e.g. Google Analytics, for better or worse, uses cookies to measure the 30 minute period, client-side rather than server-side and it uses a session cookie to mark the closing of the browser as the end of a visit.

Understanding eVars and s.getValOnce()

In order to get a meaningful count of Instances of an eVar’s values and provide context for the other metrics, we often need to ensure that values are only set when it first gets a value or when that value changes.

That is done using the plugin s.getValOnce(value, cookieName, days) as in the following typical snippet (using New/Repeat as an example):

 

The 2nd line means, if s.prop4 has a value, check the cookie ‘s_eVar4_nr’ and if it either doesn’t exist or stores a different value from s.prop4, then return s.prop4’s value, assign it to s.eVar4. Either way, (re-)write the value to that cookie.

This code should be running on every page. More often than not’s it’s called in doPlugins() just before each and every image request is completed and sent.

On the first page view by a returning visitor:

• s.prop4 is assigned the value ‘Repeat’.
• s.getValOnce finds no cookie so writes the value ‘Repeat’ to the cookie and returns the value
• The value is assigned to s.eVar4 which will be sent to SC
• SC counts an instance of that value. It will also attribute event1 to that value.

On the next page view:

• getValOnce() finds the value ‘Repeat’ in the cookie
• It therefore returns an empty string to s.eVar4.
• The eVar is not resent and no further instance is counted.

0 is too Few

However, the 0 used as the 3rd parameter causes the cookie to be written as a session cookie, meaning that it does not expire after a set time but when the visitor closes the browser.

Our visitor goes out to lunch without closing her browser and refreshes the page on her return 45 minutes later, the following happens on that page view:

• getValOnce() will still find the cookie with the same value (‘Repeat’)
• It will return an empty string to s.eVar4 which will not be sent to SC.
• Another event1 will still be fired.
• On SC’s servers, SC will have ended the visit 30 minutes earlier and expired eVar4.
• The new page view starts a new visit
• The new visit count and the new page view event have nothing to be attributed to and so are counted against ‘None’.

So in getValOnce(), 0 is too few.

The cookie needs a lifetime of 30 mintues, to coincide with the length of the visit. For some reason, getValOnce wants cookie lifetime expressed in days!!!, as follows:

Now, when the visitor returns and refreshes the page the following happens:

• s.getValOnce() looks for the previous value but, since the cookie expired 15 minutes earlier, it will not find one.
• It then writes the value in s.prop4 (‘Repeat’) to the cookie and returns that value assigning it to s.eVar4.
• When SC gets the image request it starts the new visit.
• SC now has the value ‘Repeat’ to attribute the visit and event1, rather than to ‘None’.

So, given that SC visits are oblivious to Browser Sessions, there are very few scenarios where s.getValOnce() should use session cookies. Making this change in your code should show a significant drop in success events and other metrics (Visits, Visitors, Revenue, etc) being attributed to None.

I would really love to hear what you find.

But Wait! There’s more!

There are 2 other issues (at least) that cause None to happen when it shouldn’t. These have to do with how doPlugins() works and our latency hypothesis.

You will have to tune in next week for that exciting episode.

You may want to follow the “Best Practice” of subscribing …