How Do I – Track Page Load

Let’s begin our irregular series of articles explaining how to do things with a simple one: how do I track page loads?

KPI(s)

The underlying questions your friendly marketer is asking include:

  • How many Visits and Visitors do I get (to a certain part of my site)?
  • What are the most popular pages on our site?
  • Where do people go after they landed on a specific landing page?
  • At what stage of the checkout process do people drop off?
  • Does anyone ever look at our Italian pages?
  • Do people read news and sports articles in one visit?

A long list of questions, possibly never ending. Your friendly marketer will ask these questions. You may work with an analytics team that tries to answer some of them and come up with even more. (Note: if they do not come up with more interesting questions, they are missing out!)

But don’t despair!

All of the above can be answered if you only track the pages of your site when they load.

Now you’ll need to track some more than s.pageName to be able to answer non-trivial questions, but there are only three basic techniques for how you track them:

  1. Use Javascript (the default)
  2. Track without Javascript
  3. Track server-side

Let’s look at the pros and cons of each of these techniques.

Javascript (the default)

The normal way to track page load is to use Javascript. (That actually goes for most if not all analytics solutions!)

As described in the article on basic tracking, you have to do three things: a) load the s_code.js file, b) assign “variables”, c) send it all off using the s.t() method.

What are the advantages and disadvantages of tracking like this?

Good:

  • Tracked in browser — catches reloads, not thrown by caches or when people load saved pages. In other words: Rather than looking at what your server delivers, you can see what people consume.
  • Captures some automatic data like OS, browser type, screen sizes. This is mostly technical information.
  • Plugins — you can use the library of available plugins as well as write your own. Makes the live of an implementer so much easier.
  • State — you can use cookies to store state in the browser. Allows you to determine things like “time since last visit”. As unreliable as cookies are, they are still the only way to do this.

Not so good:

  • Tracked in browser — your tracking depends on how well Javascript executes on the combination of your site and the visitors browser. An infinite number of possible failures means your tracking will never be 100% accurate. Plus the fact that data transport over the Internet is never 100% perfect either. This makes comparisons with back end systems difficult (think “orders do not match”).
  • Size — Javascript code on your site adds to its size, makes page load times longer.
  • Doesn’t track devices that don’t support Javascript. Ok, that is not really an issue anymore.

Tracking w/o Javascript

We just wrote about tracking without Javascript, so we won’t repeat it here. Let’s jump straight into the advantages and issues.

Good:

  • Tracked in browser — everything said above applies here as well. You are tracking where it matters.
  • No Javascript — you track everyone and everything, no matter what their device is capable of.
  • Size — no libraries to load, no big scripts, just an <img> tag with a URL. Loads nice and fast.

Not so good:

  • Tracked in browser — everything said above applies here as well. You’ll never get 100% accurate data.
  • No Javascript — you track everyone and everything, no matter what their device is capable of. That includes bots and crawlers. (But you can filter them in SC15.)
  • No plugins — no libraries to load, no big scripts, and no plugins! You’ll have to code all fancy tracking yourself. Using one of the server-side AppMeasurement libraries can alleviate that pain a little bit.

You could argue that Redirect tracking falls into this category and I would agree. The pros and cons above apply to Redirect tracking, plus you can track things with it that you otherwise could not.

Server-side Tracking

You can send data into Adobe Analytics via the “Data Insertion API”. You basically send tracking calls to a URL as you would normally, but you send them from your server rather than the browser.

See the online documentation for an introduction. We will also pick up this topic at some stage.

Good:

  • Accuracy — because your server sends the tracking, you can get very close to the numbers in your transactional back-end systems. It is not uncommen to get to an error < .5% using this method. The business users love that!
  • Stealth — can track things without your visitors seeing it.

Not so good:

  • Stealth — can track things without your visitors seeing it. Yes, I think that is not a good thing. Be transparent, your customers want you to be!
  • Plugins — you’ll have to rewrite any plugins that you’d want to use.
  • Some things can not be tracked — things like “how far did people scroll down the page?” or “which form field was the last they filled before they walked away?” or even “how far into the video did they stop watching?” just can’t be done without access to the browser.
  • Cookies / State — you can’t track anything that depends on cookies only. If you want to handle state, you will have to build it on your server.

Notes

Some (a few) people use hybrid tracking: Javascript for normal pages, server-side for anything transactional, like purchases. They basically get all the goodness of Javascript plus the accuracy of server-side where it matters.

The overwhelming majority uses Javascript-based tracking, mostly with a <noscript> tag containing a non-customized <img> tag.

An additional consideration: Javascript-based tracking is already the most flexible option, but if you use a tag management system, you get even more flexibility!

Firstly, you are reducing the dependency between site functionality and web analytics. Release cycles won’t get in the way as much and marketers will be happier.

Secondly, you can use the functionality provided by your TMS to add very powerful customizations to your tracking.

The technical limitations of cookies are an issue, of course, as are the feelings people have about them. But there is nothing else out there, currently, so we still use them as far as we can.

So, how should you track a page?

  • Use Javascript-based tracking. It’s not a coincidence that this is the standard.
  • If you need accuracy better than 5%, your only realistic option is to use server-side tracking. I would suggest you go for the hybrid approach here and only track the really important bits server-side.

And that’s it. Unless someone comes up with a really good use case for tracking without Javascript, of course.

About

German expat living in Switzerland (formerly UK and France). Consultant and member of the Multi-Solutions Group at Adobe, working with the Digital Marketing Suite. Father of 4 girls.

Posted in Javascript, Page Code, Plugins, Principles, Tips
2 comments on “How Do I – Track Page Load
  1. […] we need a Data Element for the page name. Adobe Analytics identifies what it tracks by the s.pageName “variable”, so we better give everything we track a page […]

    Like

  2. […] I might have a standard PLR that fires on every single page of my site. This rule might use the URL of the current page to compute some kind of page name. This page name is then written into s.pageName. […]

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Enter your email address to follow this blog and receive notifications of new posts by email.

Join 1,398 other followers

%d bloggers like this: