The client is a large utility (electric utility) located in California interested in taking their SiteCatalyst deployment to the next level. They're using a competing SiteCatalyst product and have decided to re-implement SiteCatalyst across their site using dynamic ASPX included footers and static server-side includes.
Their site is partitioned into two main categories of pages:This first Excel file is a review of the current Omniture implementation on abercrombie.com. I chose this site after having been involved in the development of a small section of it recently. I was pulled in literally a couple of days before the Club section launched to 'fix' the tagging plan. What made it a challenge is not only did I have no insights into the background of the project, but the developers (in Buenos Aires) had never implemented Omniture before. The tagging plan (put together by our group) was also pretty messy with lots of questionable things going on. So between gathering information about the project, reworking the tagging plan, and helping train the developers on Omniture requirements, it was a rather frantic week. I ended up prioritizing the Omniture tagging between Need by Launch, and what could wait until the days following launch. Throughout this process I noticed there were tagging issues with the main site, and a lack of good coordination between the tagging plan I inherited for the Club section and what I was seeing on the main site.
This first file is an review of the full site. It includes a breakdown of the Events, eVars, and props that I could see firing. I've also detailed a number of issues which I found; most of these are technical errors, but a couple are related to what I see as issues with how the SC data is structured. This is not a completely comprehensive site report, as I went through much of the site, but not every single page. I tracked the Products tags up to but not including the actual purchase, so the last steps in the purchase path were not tested.
ReviewThis is an updated SDR including recommended changes (highlighted in orange). The original plan looks to have been pretty solid overall, so I didn't make a great deal of changes. Having had a few follow up conversations with the client on reporting, some of the recommendations are based upon the difference between what the original plan outlines and what their expectations were. One of the most important aspects of any implementation is making sure you clearly understand the client's needs and expectations, and structure the data accordingly. Having the technical aspects working properly is of course always important. But even if the technical and coding stuff is perfect, if the client is not getting what they need the implementation will be flawed.
NOTE: This is not as comprehensive as a normal document would be, as it's more of an outline without getting into too much of the coding, such as function calls for plug-ins. It also includes a Charles tag converter which I built. I've found this to be helpful during the QA testing phase, especially if the tester is not fluent in the SDR.
Updated SDRNOTE: Some data may have been dummied for confindentiality reasons.
PDF includes link in Annex to more detailed list of Recommendations.
Presentation Link