With Adobe Analytics, you have a couple of other possibilities to get data into the system. My colleague Brent Dykes has written a blog article on How to Get Data In and Out of SiteCatalyst – Part I, which lists the most important ones.
Some other devices also used to be flaky at best: gaming consoles for example or custom-built touch screen devices that you sometimes find in stores or shopping centres (“malls” for you in the USA).
But one reason still remains: size.
If you want your pages to render fast (see Ilya Grigorik’s video “Breaking the 1000ms barrier”), you have good reason to strip every component of your site down to the minimum.
From our point of view — reducing the impact of web analytics tagging — there are two aspects:
- data transported over the net
- browser rendering / script execution
- populate all your page-level variables,
pageNamebeing the most important one, and
- set variables that would usually be set within the
doPluginsmethod in the
s_code.js file which will define the “s object” and a couple of methods in it. Your code then assigns variables and finally calls
s.t() to trigger the tracking of the page.
doPlugins which might populate more variables. It then builds a tracking call, which really is just an HTTP GET request to Adobe Analytics data collection servers.
Just look for the <noscript> tag on your own site!
Adobe consultants have at some point stopped sending out code snippets that included the <noscript> part, but it is still around on a lot of web site.
Unfortunately, practically nobody customizes the tag! Which means that it will track, but it will not even assign a
pageName and your friendly marketer will therefore see URLs in some of the reports, which will likely puzzle him.
Here’s my advice: either you use the <noscript> part properly, or you remove it.
For those of you who run sites on PHP or Java EE, Adobe has tracking libraries that handle the creation of the URL for you!
// Instantiate instance AppMeasurement s = new AppMeasurement(request, response); // Setup application config variables s.account = "my_rsid"; // Set Variables s.pageName = "Some Page Name"; s.prop1 = null; //clears any previously set value for prop1 s.prop4 = "Blog"; s.track();
s.track() method is interesting.
In it’s “normal” form, it creates the <img> tag with the tracking URL. The browser, trying to load the image, will therefore contact the Adobe data collection servers and transmit tracking information.
But you can flip a switch in the Java AppMeasurement and instruct it to send the tracking directly, server to server!
If you set
s.sendFromServer = true;, the call to
s.track() will actually send off the tracking right then and there, straight from your server to Adobe’s.
Cookies & Visitors
Short answer: as usual.
Adobe Analytics handles cookies differently, and you can follow the process in a debugger:
On the first tracking call ever, the system will notice that there is no
s_vi cookie in the HTTP Headers. It will therefore reply to the browser with a HTTP Status 302, a redirect. On that response, it will add the
s_vi cookie with a random visitor ID, and it will add a parameter to the URL that tells it “I have tried setting a cookie”.
Now the browser will just go and request the new URL. If setting the cookie was successful, every tracking call from now on will contain the
s_vi cookie with the visitor ID which allows the system to tie those hits together.
If the browser does not set the cookie, the second tracking call will not contain the cookie but it will have the additional parameter. So the system will basically not try setting a cookie again and instead use a fallback mechanism.
(Can I please ask you to quickly vote in the poll? Do we provide relevant content? Thank you!)