Tracking Manifests

0 Share13

Tracking Manifests

One of the best things about being a consultant, in my opinion, is the fact I get to work on both a variety of projects and a variety of aspects within each project as well. I woul ...

One of the best things about being a consultant, in my opinion, is the fact I get to work on both a variety of projects and a variety of aspects within each project as well. I would be bored to death if I ever let myself become a “reporting robot.” I love it when I am able to get involved with projects right from the beginning – because if I was involved in the implementation to any degree, it makes future analysis of data a lot easier (because I know exactly how the site is tagged).

Generally I don’t do the actual implementation development, but I do work closely with the developers during the implementation. One part of this process is to create a tracking manifest for the developers. They are a great tool for communicating clearly to the developers exactly what needs to be tracked, and how.

Here’s generally how I create my manifests:

  • I look through the site’s wire-frames to determine how complex of a site it is.
  • I read through all documented business goals and KPIs to understand what the client considers to key metrics that need to be tracked.
  • I create the spreadsheet for the manifest
    • I start by just listing out every page/user interaction on the spreadsheet, and listing basics like static or dynamic tags, user authentication, user type, or any other relatively basic info I’ve gleaned from the wire-frames.
    • Then I go back through the wire-frames and manifest and start to note any custom tracking that may be required – and noting for the developers which variables should be used, breaking it down by type (traffic, conversion or event variables).
    • Finally I also make sure I put in any notes/comments that I feel the developers may find useful.

I will often also include in a separate tab the business goals and KPIs, and yet another tab with variable definitions as a quick reference for the developers.

I feel the more information I can provide to the developers up front, the easier it will be for them to implement all the tracking correctly. It also reduces the amount of time we have to spend meeting to go through all the tracking requirements. Even if I am the one who is doing the actual implementation, I find creating a manifest first, keeps me from forgetting any critical custom tracking that may need to be set up.

Do you use tracking manifests when you’re implementing? If not, what do you use to communicate to developers, or to keep all the tracking straight before you begin an implementation?

Gabriele has been doing "Web Stuff" since the mid-1990s, and Web Analytics since 2005. She began with Omniture SiteCatalyst (now known as Adobe Analytics) and is now also well versed in Google Analytics. She has been building a team of professional analysts who have expertise in all the major analytics platforms, including Adobe Analytics, Google Analytics, IBM Coremetrics and WebTrends.
  • I like it. Short, sweet, and very street.

    One of the things I try do is look at the web Dev process to see if the information for parameter assignment is available within the workflow. In other words, the package does not get deployed unless this data is there. This insures that data will be there and will continue be there after I am gone. (Nothing kills a rep faster than a site that discombobulates in 6 months.)

    An interesting test I found is determining how a page is named. If it is difficult to impossible to derive a name naturally from what is available, without requiring special development, then I know how hard the job is going to be.

    Otherwise, I do pretty much what you describe here especially getting the business Objectives and KPIs nailed down right up front.

    Using tabs is a nice touch.