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.
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.
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
This goes into the
Note: yours will have some hex numbers in place of the “xyz” & “abc”, 40 characters each.
And this goes before the
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.
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.
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:
DTM can log into the Marketing Cloud or Analytics and pull available report suite IDs for you, or you can just manually type them.
This is the equivalent of setting the old
s_account variable in your
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”.
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:
In that case, you’d set the type to “Custom Script” and put some code into DTM that magically computes a page name.
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.
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.
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.
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.
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.
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).
We have now configured tracking equivalent to what I called “(Better) Minimal Code” in the old posting.
We can obviously do a lot better!
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.