One of my team's main jobs is creating requirements documents for tracking an analytics implementation, such as Adobe Analytics or Google Analytics. However, because these tools can be approached from so many angles, it takes some focus to get exactly what you need implemented. Here's a few tips on developing an SDR from start to finish.
Requirements gathering is the most important. This type of gathering includes talking to the company and figuring out things they want to see, usually in non-analytics terms. Examples might include "How many orders do we get per day?" or "What are our most popular products?" Once you have a list of these, it is then best to suggest a list of additional requirements they may not have thought about, but might find useful.
This step is one of the toughest if you don't know the analytics tool you are working with well. It essentially involves taking the list of business requirements and creating an outline of variables that will be used to meet that requirement. For example, if I was tracking page views, I might let the tool do that automatically, but also add other variables to capture the url, page name, and referrer.
This probably seems like a complete no brainer, but it is essential nonetheless. You need to identify all the page types that will distinguish parts of the site. These are not specific pages, but rather page template types. You should also identify these as the actual values to be reported later. Typically I do all lowercase, single words like so: home, product, category, cart, checkout, order.
Once you have the variables identified, you now need to list them all out for the tool with their name and description, where they should appear (using your page type list), and any tool specific configuration items (e.g. list support, pathing support, etc.). It is usually useful to provide an example value for each one as well, so the developers know exactly what to code.
At this point, if you were just hard-coding the analytics tool, you should have enough to get going with maybe adding some implementation instructions for the developer. However, if you are building a data layer (highly recommended), continue on below.
Identify Data Variables
What you will do here is create data layer variables for each analytics variable. This is pretty tough sometimes, so a few tips:
- name all your variables consistently. I suggest either lowercase_and_underscores or camelCase
- group variable names by their types. For example, all order specific variables might start with "order"
- variables that report a value (e.g. shipping) will just be a single variable name (e.g. orderShipping)
- variables that are plugins should not be in the data layer, rather mark them as "plugin"
- variables that are triggered events (e.g. Adobe's counter events) should have a single event variable (e.g. eventName) and a specific value to trigger that event (e.g. eventName = "email signup")
- variables that are duplicates (e.g. both prop1 and eVar1 in Adobe) should have the data layer variable listed for one of the analytics variables, and a note for the other variable that it is a copy. For example, I might put prop1 as "pageName" and eVar1 as "copy prop1"
Create a Grid
Now that you have all the page types, events, and variables to be used in the data layer, create a grid. Put the page types and event names across the top and all the variables on the left side. Then, fill out the grid where all the variables are required (maybe just mark an "R" for "required").
Now that you have all your requirements built, if you are developing this, you can just get to it. However, if someone else is developing it (usually the case for us), then it is essential to create another sheet in your document that outlines example snippets, placement instructions, and syntax rules. The more consistent you can get, the better, so this sheet is crucial for a good implementation.
Once all the above is done, you are ready to go with the coding! While the developer is getting that part done, you can now use your same requirements to setup the analytics tool by creating all the variables and configuration. If you are using a tag manager, you can also use the data layer to map everything up and create any of the plugins you listed in the document.
Hopefully this helps get you going on building an SDR! There's a lot involved, but the better you plan up front, the better your implementation will be. If you are interested in how we do our process, or need help with your implementation, feel free to shoot a quick email via the contact form here: InteliQuant. If you have any tips you've found useful during your SDR creations, feel free to comment those below as well!