Basic Tracking – Remix (contains DTM)

~ Jan Exner

In March 2013, I wrote an article on Basic Tracking, showing you the minimal set of code on a page that is needed for tracking the page in Adobe Analytics.

We’re in 2015, now, we have DTM, so it is time for a refresh.

This article will give you the minimal setup needed for tracking a page using DTM and Analytics.

There are two parts here: some Javascript on your page, plus a bit of setup to be done in DTM. Your friendly marketer might be doing the latter, but I guess the task might just as well fall into your lap.

You’ll notice that compared to the really quite basic steps in the old posting, this one seems like a lot more work. Consider it the equivalent of writing stuff yourself versus using a framework: the initial effort is higher, but above a certain level of complexity, you’ll get paid back later in the project.

Or: frameworks rarely make sense if all you want is a “Hello World!”, which is really what basic tracking is.

Basic Tracking

For tracking to work, you have to include DTM into your pages. It is technically relatively easy to do, because all you need are two lines of code, one in the <head> of the page, the other right before the </body> tag.

This goes into the <head>:

<script src="//assets.adobedtm.com/xyz/satelliteLib-abc.js"></script>

Note: yours will have some hex numbers in place of the “xyz” & “abc”, 40 characters each.

And this goes before the </body> tag:

<script type="text/javascript">_satellite.pageBottom();</script>

You can get this code from DTM itself, from the “Embed” tab in your Web Property. Or maybe your friendly marketer or a consultant will send them to you.

To keep in line with the other posting, I want to state here that while this is viable, you can improve it quite a lot. We’ll get to that later.

Basic Configuration

In DTM, the minimal configuration includes:

  • creating a Web Property
  • adding and configuring the Adobe Analytics Tool
  • adding and configuring a Page Load Rule

The Web Property serves as the space that manages what you deploy on the pages as well as the users able to do so.

Within the Web Property, “Tools” encapsulate the functionality of some Javascript-based solutions. Today, there are 5 tools available: Adobe Analytics, Adobe Target, Adobe Audience Manager, Marketing Cloud ID Service, Google Analytics, and Google Universal Analytics.

[Screenshot]
Adding a Tool
As with most Tag Management Systems, you can deploy pretty much anything that uses HTML and/or Javascript using DTM. The Tools are just pre-packaged to make it easier to do so.

Remember all those postings talking about how to do unspeakable things with Page Load Rules and Event-based Rules? Those rules are where you configure what exactly it is the Tools should do.

To put that together: the minimum viable configuration of DTM includes one Web Property and at least one rule. For our purposes (Analytics), it also includes one Tool, Adobe Analytics, and one Data Element.

If you’re confused about the configuration of the Adobe Analytics Tool, I’d suggest you keep it simple.

For now, all I want to tell you is that you have to set the report suite ID in the Tool:

[Screenshot]
Setting the Report Suite ID
DTM can log into the Marketing Cloud or Analytics and pull available report suite IDs for you, or you can just manually type them.

[Screenshot]
Setting the Report Suite ID manually
This is the equivalent of setting the old s_account variable in your s_code.js or AppMeasurement.js file.

Data Element & Page Load Rule

Next 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 name.

In DTM, the facility that creates and let’s you use values is called Data Element.

You’ll find them under “Rules”.

[Screenshot]
How to find Data Elements
Go ahead and create one. If you’re good, you’ll already have the name of the page on your pages, in your data layer, of course.

If that’s so, then your “Page Name” Data Element can be as simple as this:

[Screenshot]
Simple Page Name Data Element
Chances are that you haven’t. Chances are you will somehow determine the name of the page based on the URL or some other data embedded into the page. Chances are you’ll use Javascript to do so.

In that case, you’d set the type to “Custom Script” and put some code into DTM that magically computes a page name.

[Screenshot]
Custom Page Name Data Element
Next thing is our Page Load Rule.

Click on “Page Load Rules” on the left hand side, then create one.

Call it anything you like, “Normal Page Load Rule” works well.

Within the PLR, all we need to do is add some instructions to the “Adobe Analytics” part of the rule, such as setting the page name.

[Screenshot]
Normal Page Load Rule
And that’s it, almost.

Note that when you look at the list of your Rules later, you can quickly see which Tools a Rule is using.

[Screenshot]
View of the Rules with Tools
All 4 PLRs in the screenshot use the Analytics Tool. The first two PLRs also have custom tags. None of the 4 PLRs uses Target or GA.

Publish

Now that you have created the Web Property, Tool, Data Element, and PLR, you should head over to your site and test them.

But wait! Nothing is happening!

Well, for now everything we did is pending. It has to be approved, then published.

But: you can test it right now, using Chrome or Firefox, and the famous Switch plugin.

Set the plugin to “Staging”, and off you go.

[Screenshot]
Switch Plugin, Staging and Debug
I switched staging and debug on here, which means DTM will execute non-approved things (in my browser!), and it will be pretty verbose in the Console.

Once you have tested and are happy, it’s time to approve and publish what you built.

[Screenshot]
Approvals in DTM
Then, head to the “Overview” tab and press the “Publish Queue” button, which will lead you to this screen where you can publish your changes so they go live (meaning the setup will be applied for all users of the site).

[Screenshot]
Find the Publish Queue
[Screenshot]
Publish in DTM
We have now configured tracking equivalent to what I called “(Better) Minimal Code” in the old posting.

We can obviously do a lot better!

Data!

Analytics is all about detecting important actions and segmenting your audiences. For that, you need to a) detect actions (d’uh) and b) collect data that allows your friendly marketer to create segments.

Where does that data come from?

Well, some of it comes from the browser, some comes from the context (e.g. geo-location based on the visitor’s IP address). Most of it, though, should come from your site!

And how does it get transferred from your site into Analytics? You know me, so you know the answer: a CEDDL-compatible data layer would be awesome!

But DTM itself helps as well. Since the idea is that not-so-technical people use and administer Rules, Data Elements are supposed to allow for easy access to data.

How the Data Element gets the data is up to the definition of the DE, so it is entirely possible to create a configuration that makes your friendly marketer happy without having any data layer, much less a CEDDL-compatible one.

In real life, sites don’t yet have proper data layers, so Data Elements are a much welcome addition to our tool box. I suggest you help your friendly marketer, maybe by building DEs for her, or maybe by building your site in a way that makes it easy for her to make DEs herself (think IDs on HTML elements and such).

The more relevant data she has in DEs, the more she can use in the Rules she builds and ultimately in her analysis.

Published by Jan Exner

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.