Tracking w/o Javascript

Almost all web analytics tools these days are tracking using Javascript in the browser, see the post about Basic Tracking.

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.

I would like to introduce one way that is very seldomly spoken about even though it is present on a lot of sites: tracking without Javascript.

No Javascript?

Yup, no Javascript.

Why?

Well, if you rely on Javascript for tracking, you end up tracking only those devices that actually support Javascript and the visitors who haven’t disabled it.

A couple of years ago, mobile devices would mostly not support Javascript!

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).

Back in the days, Javascript was an add-on that some web designers would put onto their sites for added effects. Noone used it for real functionality.

Today, the landscape looks totally different. Virtually all devices on the Internet do support Javascript. As a result, it is used on a lot of sites, and it is used to add to the user experience. Some sites don’t even work without it. And users are less likely to switch it off, as well.

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:

  1. data transported over the net
  2. browser rendering / script execution

Tracking without Javascript greatly reduces both, and it can therefore make sense even today.

To be honest, you might get away with switching to the latest Javascript AppMeasurement library, which is a lot smaller and faster than H code. See the blog article Faster Analytics Javascript written by my colleague Ed Hewett.

Any Disadvantages?

There is one catch, and it might be a big one for you: a lot of crawlers and bots on the Internet do not execute Javascript. Meaning: if you track using Javascript only, you automatically exclude these and they won’t pollute your data.

If, however, you track without Javascript, you will see everything that bots and crawlers do on your site in your data. That is unless you switch on bot filtering and reporting.

The second disadvantage is that if you do not use Javascript, you will need to find alternative ways to

  1. populate all your page-level variables, pageName being the most important one, and
  2. set variables that would usually be set within the doPlugins method in the s_code.js file.

And you have to do these two server-side, of course, because you do not use Javascript.

How?

Let’s take a step back and see how we can track without Javascript.

The Javascript code on each page of your site includes 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.

Now s.t() calls 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.

So in order to track without using Javascript, all you have to do is build the URL for that tracking call yourself! Use an <img> tag to send it off and you’re done.

I have tried to explain what the URL looks like in the articles about debugging here, here, here, here & especially here.

There is more documentation in the help section: Implementing Analytics without Javascript.

<noscript>

Even though tracking without Javascript is really not mentioned very often, a surprisingly big proportion of sites uses it!

Just look for the <noscript> tag on your own site!

The reason is that it was until very recently recommended to have non-Javascript tracking deployed in parallel so that you would track all those devices that couldn’t handle Javascript.

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.

Help?

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!

Rather than writing your own code to create the tracking URL, those libraries allow you to instantiate an “s object” and assign the usual “variables” almost as you would for a Javascript implementation.

[Screenshot]
Server-Side AppMeasurement Libraries (PHP & Java)
Example:

// 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();

The 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

Good question! How will the system handle cookies and visitor identification without Javascript?

Short answer: as usual.

This question mainly comes from people who have used Google Analytics. GA sets all of its cookies using Javascript. That has one big advantage: those cookies are always 1st-party Cookies and they are therefore accepted by pretty much all browsers and visitors.

But the flip side is that if you track without Javascript, this method would not work.

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.

All of this does not rely on Javascript (except one of the fallbacks), so tracking without Javascript makes no difference.

(Can I please ask you to quickly vote in the poll? Do we provide relevant content? Thank you!)

5 thoughts on “Tracking w/o Javascript

  1. Hi Jan,
    do you know since when virtually all devices on the Internet support Javascript?
    I am gathering some information regarding mobile web implementation…

    Thanks and regards,
    Stef

    Like

    1. Hi Stef,

      I don’t, no.

      I would look at the ascend of iOS and Android, because I think the “fully featured smart phone” sector has been driven by them. But it is notoriously hard to find hard facts about anything on the Internet. Too diverse a landscape for anyone to be sure.

      Cheers,
      Jan

      Like

  2. I want to use Java library to track server side, but some event (sent to adobe server) does not correspond to a page load, does user agent suffice to populate device , device type, browser report? Can I overrride server IP address to populate connection type report?

    Like

    1. Hi Giuseppe,

      Server-side tracking is an article in itself, I guess.

      To answer your first question: yes, User-Agent is enough for those. Overwriting the IP (with the IP of the browser accessing the site) would give you geo segmentation.

      Maybe it would also help with connection type, but I frankly never look at that report. Can’t see the benefit.

      Like

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.