Endress Analytics has a great video about tracking manifest for Adobe Analytics aka SiteCatalyst. Kevin Rogers has also good blog post why you need to have tracking file for your analytics implementation. It’s official name is Adobe Solution Design Requirements (SDR), but I like to simplify and use the name “tagging map”. This blog post focus also on Adobe Analytics but you can do this kind of tagging map for any other analytics tool as well.

What is this tagging map exactly?

It’s a document (Excel, Word, whatever…) where you write all the details of your analytics implementation. I’ll do this every time because at the same time that is also document for our scrum team (coders) how they have to implement the tags to our sites. Our (my employer) sites are so complicated from the technical perspective that it would be stupid for me to try implement all the codes by myself, and if that would happen I’m sure I would do something wrong. At least, it wouldn’t be very effective and I should focus on my real job which is analyzing the data. Although, I admit that it’s a useful thing to now little bit how the codes are implemented so you can make the tagging map easy as possible for the coders and for smaller sites I have implemented codes too (sometimes with the help of dynamic tag management aka Adobe DTM).

Why do we need tagging map?

For smaller sites you don’t need one and you can get all the data needed just by copy & paste the default analytics code. Tagging maps are needed especially for big sites that use Adobe Analytics and include lots of dynamic content and/or user generated actions (forms, buttons, internal search, logged-in status etc). With default analytics code you can’t save this kind of data and you need to do custom tags for these. You can also do changes to your default data with custom tags, e.g. change page names to more user-friendly.

Do it once and forget it. No, update!

Every time you make a change to your implementation, update the change to your tagging map also. If you add new custom tag (prop, eVar, event) to the site, add it also to your tagging map. Your tagging map is your tagging bible! Of course you can debug your current site and even look directly from the admin console what you have enabled and implemented, but what happens when something has gone wrong on the site? What happens if the client/coder says that they have implemented everything correctly but you don’t see the data needed? No need to worry, the answer can be found on the tagging map. It’s important that there is a single source of truth for analytics implementation = Tagging map!

What is the best format for tagging map?

There isn’t one and right answer to this. I have done about 50 different tagging maps and none of them are exactly the same, but the basic structure is the same. When I started to do these maps I used to add every code for every single page and custom tags. Nowadays, I have tried to be me more effective and made only one code example for every same kind of custom tags. For example if you have contact form on 20 different pages then I would do my guide for tagging like this “send the information X to SiteCatalyst every time contact form is sent”.

Here is my latest format for Adobe Analytics

Yes, just an example so you get the idea. You might get a feeling that there is so much to do but actually there isn’t, because you can copy the format to any other report suite´s tagging map. It also helps if you have same kind of sites then you can try to use same props, eVars and events. And usually custom tags (form submission etc.) use pretty much the same code with the help of S object.

Name of the document

Year-Month-Day_YOURDOMAIN_SiteCatalyst_Tagging_Map.xlsx

Always make a new copy and update the date when you make changes to the document.

Tab #1  for tags

On the “code” section is the real guide for tagging and you need to open that cell to see the full code. I can give two small examples how I write these:

Please execute the following SiteCatalyst tracking code if the login fails on the URL X:

if (s) {
s.linkTrackVars=’prop9,events’;
s.prop9=s.pageName;
s.linkTrackEvents=’event43′;
s.events=’event43′;
s.tl(true,’o’,’invalid_login’);
}

Please implement the following tracking parameters within the SiteCatalyst tag on the search result page URL X:

s.pageName=”search_result_companies”;
s.channel=”companies”;
s.eVar1=”<search term>”;
s.eVar3=”<number of results>”;
s.eVar25=”search_result_companies_<page number>”;
s.eVar30=”<user status>”;
s.eVar36=”<number of results displayed>”;
s.events=”event1, <,no_results_event>”;

Notes:
<search term> = search term that the user typed.
<number of results> = the accurate number of search results returned. If no results were found -> “0”.
<page number> = the page number of the search results page. For example, “1” for the first page. If the user clicks to “see more results”, the page number must be incremented.
<user status> = either “yes” or “no”, depending on whether the user is logged-in to the website.
<,no_results_event> = if no search results were found, “event2” should be appended to s.events.

Tab #2 for props & eVars

Many times it’s useful to know what kind of “features” admin has enabled to these variables and that’s why I add information directly to the name of the variable, for example the number of the variable and does it have any special features e.g. “OV” = Original Value, “Never” = Never Expire

Tab #3 for events

Same here. Add special information directly to the name of the variable because it affects the way Web Analyst analyzes the data, e.g. “OPV” means event is launched only once per visit and this is crucial information.

Tab #4 for mind map (Optional)

Sometimes I do one more tab just for me, and there I can write my special notes what I still need to tag for the site and/or what specialities this site includes etc. Yes, some kind of “mind map” for the web analyst.

Please comment and/or share your ideas for tagging maps. Thanks.