(Too) Minimal Code
The very minimum are 4 lines of code, like so:
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.
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:
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.
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