Basic Tracking

Most web analytics data is gathered within browsers using Javascript. There’s other ways, but we’ll get to that later.So how do you track a web page?

(Too) Minimal Code

The very minimum are 4 lines of code, like so:

<script type="text/javascript" src="/include/s_code.js"></script>
<script type="text/javascript">
s.t();
</script>

The first line loads the s_code.js file which contains three important pieces (we’ll go into that later).

For now, suffice to say that it defines the s.t() method which is called in the third line. The s.t() method is what actually triggers the tracking of the page.

The 4 lines above work, but they won’t produce good reports. One crucial bit is missing, the s.pageName variable.

Content in Adobe Analytics is identified not by the URL but by the s.pageName. If you’re not sending anything in that variable, the system will revert to using the URL, but your reports will look like this:

Can anybody tell me which page “site.com/?id=987654321” refers to? Unlikely.

So let’s improve our code!

(Better) Minimal Code

Let’s add one line to turn it into something usable.

<script type="text/javascript" src="/include/s_code.js"></script>
<script type="text/javascript">
 s.pageName="Testpage";
 s.t();
</script>

So what do you put into the s.pageName variable on a given page?

The answer to that depends on your site, your marketers and possibly your CMS. In general, the name should follow the “three Cs”: context, concise, complete.

My suggestion would be to run it by the marketer. The ultimate test is to fake a report with a couple of names, show it to them and see whether based on the name they know whcih page you are talking about. If they do: good name!

What do you get?

With the minimal code you will get a bunch of built-in reports along with all the traffic metrics: Page Views, Visits, Visitors. You also get pathing reports like “Next Page Flow” and even geo segmentation if that’s enabled for the report suite.

This is the level of tracking that most people will easily understand: you can look at trends (did we have more or less traffic? From more or less Visits or Visitors?) and rank your pages (“Oh, the campaign landing page really took off this month! See, it passed the home page in popularity!”) as well as find out where your visitors went after the landing page.

Minimal Useful Code

I will come back to the subject traffic metrics at some point, let me just say for now that I think web analytics should go a lot further than Page Views. Minimal code will get you minimal results.

The next step is to track “micro conversions” on the site, i.e. activities done by the visitors which we (the marketer) deem important. That could be buying something, looking at a product, downloading a white paper, signing up for a newsletter or searching.

Most sites do not just exist in a void. They have a specific purpose. Micro conversions are like little steps on the way there and tracking them allows us to see how far visitors go down the path to conversion.

Adobe Analytics has space for up to 100 micro conversions in the s.events variable. The events are called “event1” to “event100”. Your marketer (or an Adobe consultant) will define which one is which. They might give you a “Solution Design Reference” or “Tech Spec” document that includes the mappings.

So let’s look at an example.

Our site contains a blog and our marketing department wants to get a more detailed look at article consumption. The “Tech Spec” tells you that “event21” should be “Blog Article Views”.

The code on the article about “Basic Tagging”, which is the 2nd blog article on the site, might look like this:

<script type="text/javascript" src="/include/s_code.js"></script>
<script type="text/javascript">
 s.pageName="Blog:b2:Basic Tagging";
 s.events="event1,event21";
 s.t();
</script>

We added two events here: event1 (“Page Views (custom)”) and event21 (“Blog Article Views”). The “Blog Article Views” metric is already a step forward because in a lot of cases it will be more relevant than “Page Views”.

We have also entered the world of conversion metrics and variables, which we’ll explain later.

For now, our marketers will be able to analyse their campaigns based on “Blog Article Views” rather then “Click-throughs”, which is a huge step.

What next?

We shall go into more advanced tracking in due time so let me just drop a couple of concepts here that I’ll explain later.

We can add “plugins” to the s_code.js file. Those plugins can capture data independently of page code (i.e. on every page on the site). Good examples would be: capture campaign tracking codes, visit number, time of day, days since last visit, marketing channel and much more.

Once we talked about SAINT and classifications, you’ll see how classifying some of the data can produce much better reports. We’ll essentially add meta data to our reports to make them ore readable or to aggregate data.

That’s it for now, really.

Apart from the s.pageName variable, everything so far can easily be done in the template if your CMS works with templates. That makes your job a lot easier

25 thoughts on “Basic Tracking

  1. Pingback: The s_code.js File – Overview | Web Analytics for Developers

  2. Pingback: The s_code.js file – Core Javascript Code | Web Analytics for Developers

  3. Pingback: “Variables” | Web Analytics for Developers

  4. Pingback: Modifying Data Server-Side | Web Analytics for Developers

  5. Pingback: Data Warehouse & Data Feeds | Web Analytics for Developers

  6. Pingback: Tracking Mobile Apps | Web Analytics for Developers

  7. Pingback: The Thank You Page – Tracking Purchases | Web Analytics for Developers

  8. Pingback: Tracking Links & Actions | Web Analytics for Developers

  9. Pingback: App Tracking – Part II | Web Analytics for Developers

  10. Pingback: Tracking Apps vs Web Pages | Web Analytics for Developers

  11. Pingback: Tracking w/o Javascript | Web Analytics for Developers

  12. Pingback: Redirect Tracking | Web Analytics for Developers

  13. Pingback: How Do I – Track Page Load | Web Analytics for Developers

  14. Pingback: Ode to Charles & Map Local | Web Analytics for Developers

  15. Pingback: 2 Good Reasons to use Context Data | Web Analytics for Developers

  16. Pingback: A Short History of Processing a Hit | Web Analytics for Developers

  17. Pingback: Poll – Mobile Analytics Mini-Series? | Web Analytics for Developers

  18. Pingback: Analysing Mobile Apps – Tagging | Web Analytics for Developers

  19. Pingback: Getting into Analytics in 1 Hour | Web Analytics for Developers

  20. Pingback: Page Views | Web Analytics for Developers

  21. Pingback: Data Elements vs Data Layer | Web Analytics for Developers

  22. Pingback: Basic Tracking – Remix (contains DTM) | Web Analytics for Developers

  23. Pingback: Quick tip – setting products or listX in DTM | Web Analytics for Developers

  24. Pingback: Everything but the TMS | Web Analytics for Developers

  25. Pingback: Quick tip: Tracking Server & SSL – Web Analytics for Developers

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