The Dreaded SDR!

by Jan 22, 2020

In the last install­ment of this blog series on being success­ful with digital analyt­ics, I discussed why your team should strive to be a profit center versus a cost center within the orga­ni­za­tion. The profit center vs. cost center concept will be a recur­ring theme in this series, but in this post, I’d like to talk about the infa­mous Solu­tion Design Refer­ence or SDR for short. While there are many out there who love their digital analyt­ics SDR, I am going to share why I have seen this docu­ment be prob­lem­atic and how you can miti­gate its short­com­ings.

If you are reading this, the odds are that you know what a digital analyt­ics SDR is, but just in case, it is a docu­ment (usually a spread­sheet) that lists all of the data points that you are track­ing or intend to track in your digital analyt­ics imple­men­ta­tion. Some people refer to it as a “tagging docu­ment” as well. If you are an Adobe Analyt­ics customer, it lists the Success Events, eVars and sProps related to your imple­men­ta­tion. If you use Google Analyt­ics, it contains things like Goals and Dimen­sions. My contempt for this docu­ment is not based upon the docu­ment itself — there is no reason why you should not be docu­ment­ing what data points you are collect­ing and in which vari­ables. My issues with the SDR are that most orga­ni­za­tions:

  • Don’t keep it updated
  • Use it in place of iden­ti­fy­ing actual busi­ness require­ments

On the first point, most orga­ni­za­tions create their SDR when they first imple­ment and then forget about it. Websites change all of the time and, thus, the data you collect related to your website (or mobile app) must change. When I was in my “Wolf” role at Omni­ture, I would say that over 90% of the time that I began working with a trou­bled client their SDR was years old. Often times devel­op­ers had “gone rogue” and started allo­cat­ing vari­ables left and right that no one knew about. This became even worse when orga­ni­za­tions had multi­ple websites/apps and had differ­ent SDR’s for each. This meant that they could not easily merge their data together and see rollup totals. Since the SDR is a docu­ment wholly sepa­rate from the digital analyt­ics tool, it is easy to see how its infor­ma­tion could diverge from what is actu­ally in the tool.

However, my true disdain for the SDR comes from the fact that it only tells you WHAT data is in your imple­men­ta­tion, not WHY it is there. For example, if your SDR lists that you are storing “Inter­nal Search Keywords” in eVar5, that is good to know, but doesn’t tell you or your stake­hold­ers why you care about inter­nal search keywords. Are keywords being tracked to see which ones are the most or least popular? Are they being tracked to see which keywords produced zero search results? Are they tracked to see which keywords even­tu­ally lead to orders and revenue? To see from which page each keyword was searched to iden­tify oppor­tu­ni­ties to improve page-specific content? Or is it all of the above? How are your analyt­ics stake­hold­ers and users supposed to know what to do with “Inter­nal Search Keywords” data if none of this is defined?

I have found that SDRs tend to give analyt­ics teams permis­sion to be lazy about their imple­men­ta­tion. They can say that they have docu­mented it by point­ing to the SDR and tagging spec­i­fi­ca­tions, but they haven’t gone the extra step to dig into WHY data is being collected. When I begin working with clients in an analyt­ics consult­ing capac­ity, the first thing I request is any docu­men­ta­tion they have on their imple­men­ta­tion. Ninety-nine percent of the time, what I get is an outdated SDR and a file that contains the old code used for the initial imple­men­ta­tion (years ago!). If you were honest, would you have anything better to provide me?

Action Items

Here are some home­work assign­ments that will help when we get to the next post:

  • Update your SDR. Make sure you have an up-to-date list of all of your data points. Make sure this is 100% in sync with what is in your digital analyt­ics tool. If you are an Adobe Analyt­ics user, you can down­load the latest vari­able infor­ma­tion using this site: https://reportsuites.com/
  • While doing this, make sure that your imple­men­ta­tion is iden­ti­cal across all of your differ­ent report suites/profiles. It is not advis­able to have differ­ent vari­ables in differ­ent slots in differ­ent data sets. If one dataset requires more vari­ables than another, simply ignore or hide the vari­ables not needed in the more basic dataset but continue to label the vari­ables the same every­where. That will prevent people from causing conflicts the next time they need a new vari­able.

In the next post, I am going to dig into how you can iden­tify WHY you are track­ing things and use that infor­ma­tion to improve your SDR and actu­ally make it some­thing of value.

We’re here to help you through this.

I consent to having Search Discovery use the provided infor­ma­tion for direct market­ing purposes includ­ing contact by phone, email, SMS, or other elec­tronic means.