When partnering with a company during the launch or updating of their website, the process can be expedited if the company utilizes a Solution Design Document (SDD) from a tracking implementation standpoint. There are many benefits of using an SDD, which I will explain later on, and a few foolish excuses not to use it. An SDD can be used with any analytics tool; however, for the sake of this post, I will be referencing and using examples from SiteCatalyst.
People who are unfamiliar with a Solution Design Document might ask about its purpose and capabilities. An effective SDD should contain all of the parameters being considered within the report suite. It does not have to be complicated to be useful; in fact, if the model is more simplistic, there will be fewer opportunities for error or miscommunication. Here is a basic Solution Design Document
that I have used to help keep all of the moving pieces for tracking a website housed within one document. I prefer to use Microsoft Excel to create and maintain the SDD document because the columns and rows within the Excel program facilitate organization, but other programs could also be sufficient. To begin, the SDD for SiteCatalyst will contain all of the sprops, evars, events, custom links, and campaign parameters in one column; I would even recommend adding all of the default parameters that get used like s.pagename. The other columns in the example provide more detail about what should be collected when the image request is sent, when an event should be fired, and any useful notes for the other teams you are collaborating with. The example provided only has five columns, but do not hesitate to implement your own improvements. Another column that could be added is for custom variables with full or basic sub relations and traffic variables with one, five, or twenty correlations.
The beauty of this Solution Design Document
is that it allows all parameters to be displayed together at once, eliminating the need to navigate all of the menus in SiteCatalyst or any alternative analytics tool that is used. There are many benefits of creating and maintaining this document throughout the life of the website you are tracking, some of which are:
Mapping out tracking for site changes
Everyone involved in tracking the website will know which sprops and evars are able to be used for future tracking
Outlines what will be measured/tracked on the site
Can be utilized by the team that configures the code for tracking
Reduce ramp up time on establishment of new tracking/for new members of the team
Can easily display information about a specific “evar,” “sprop,” or event
All of the information is stored within one central document
Before deploying a new website or implementing changes to an existing one and after all requirements gathering has been finished, an SDD should be used as the drawing board for how the analytics tool will be configured. Mapping out all of the parameters will reduce confusion when everything is completed, can help ensure that nothing was forgotten, ensure the reports are populating with proper data, and conversions are captured.
Keeping the SDD current with the continuously evolving website will be the biggest obstacle to overcome. Someone needs to be delegated with the task of maintaining the document when changes are made and occasionally verifying information from the document with data from the interface.
Feel free to share if you have used a Solution Design Document before and have your own tweaks for improvement or success stories!