Sunday, 25 August 2013

If I could do it again: Report Suite ID Naming Convention



It is now coming up to 4 years since I have started in the Digital Analytics industry.  And for more than 3 years, I have spent with a single company in a unique position: assisting with the migration from HitBox to Omniture (now Adobe Analytics).  Now I have thought back to this time with a simple thought: “If I was running the show and had a chance to redo everything – what would I do?”.  I will have a small series covering this topic. 

But while I was thinking about this, I had one that came straight to the top of the list.  This is one thing I wish we had done as it would have saved a lot of time, energy and headaches now days.  This of course is consistent Report Suite ID naming. 

Oddly enough, this is something that Omniture never covers and I hope they would listen to this post and recommend future customers to consider this and hopefully, follow my suggestion (and listen to my mistakes).

Current Issue:  I wanted to create a Report Suite Group for all accounts that are used on our live environment (thus, the data the analysts use to report back to the business).  The problem I have found – there is no format.  Some Report Suite ID’s have prod, dev, stag – but not all.  Some indicate which environment they belong to in the friendly name, but not all.  So, there is no way of indicating in the very short Advanced Filter. 

Now the company I work for has 500+ report suites.  I did the only thing that I could do: go one by one and guess which ones go where.  Later, I will do a mass edit and change the names for the report suites that are no longer being used. 

But what could I have done differently that would have saved a lot of time?  Not only consistent naming, but a naming format.  When Adobe Lists the report suites in Admin, it is done alphabetically based on the report suite ID.  What if we had a naming convention that would group like report suites together, and can easily filter for what you want?  Here is what I had in mind:

          1)      Company ID.  Adobe uses this to ensure they do not have multiple Report Suite ID names across their numerous clients.  This is something you cannot edit after initial setup
          2)      Environment: This indicates if the report suite is for Production (live), Development, or Staging.
          3)      Type: which type of report suite is this for?  Web, App, Mobile, etc. 
          4)      Optional * device type.  If this is for Apps, is it for Android, iOS, Windows….
          5)      Unique Name – the unique name or Site name for the report suite.

An example for WebbingYourWay blog would be:
                a)      Web production / blog: wywpwblog.
              1.       Company ID: wyw
              2.       Environment: p – this indicates production.
              3.       Type: w – this indicates web
              4.       No optional
              5.       Unique name – Blog
         
         b)      Web Development / Blog: wywdwblog
             1.       Company ID: wyw
             2.       Environment: d – this indicates development.
             3.       Type: w – this indicates web
             4.       No optional
             5.       Unique name – Blog

        c)       App – iOS Staging / Executive Dashboard: wywdaiexecdash
            1.       Company ID: wyw
            2.       Environment: s – this indicates staging.
            3.       Type: a – this indicates it is a mobile app
            4.       Device type: I – this indicates the mobile app is for iOS
            5.       Unique name: execdash – this indicates this is for the executive dashboard.

By doing this, all your environments are grouped together, making it easy for you to create a group for your production.  You have a simple way to get to your mobile report suites, all of your iOS report suites, etc.   Your Admin -> report suite section is simple to understand. 

If I could roll back time, this is the first thing I would insist we would do.  Now, if only I could rename these suites now, I would be golden.

2 comments:

  1. I like your suggestion, however I believe you need to have some sort of separator to separate your identifiers, for example use underline, e.g. wyw_d_w_blog
    As you know Adobe RSIDs are not case sensitive, however in your documentation you can use CamelCasing to make them more human readable for example: wywDwBlog

    ReplyDelete
  2. Hi Mehdi,

    Thanks for your comment. this is a great idea, and If you wanted to do this, you could. But the RSID is not meant to be viewed by the wider audience, thus my purpose was focused on distinguishing between the different type of report suites. A current project I am working on will show what this purpose which I hope to share here on the blog in 2 weeks that will help every web analytical manager greatly.

    ReplyDelete