5 minute

Learn how to optimize your Adobe Analytics implementation with business requirements, variable maps, and properties

Before getting started, download the playbook.

Business Requirements tab

WHAT:  A Business Requirements Doc (commonly referred to as BRD) is a very important piece of documentation that key stakeholders, business users and tech users will want to collaborate on. It is a place for documenting all of your desired KPIs, reporting requirements, and any data point you wish to see when your Adobe Analytics (AA) implementation is complete.

WHY:  This serves as a jumping off point for the documentation that follows (SDR, tech spec, etc.) and is a common source of truth for an agreed upon end state of AA. This document organizes thoughts across teams within the org to form one guiding direction to move forward with building out or enhancing your implementation.

HOW:  Documenting the business requirements is commonly done by the end business users of AA, but it is important to get feedback from tech users as there can be technical challenges to note and certain data points may require more effort than others, which factors into prioritization.

Ask yourself, “what are the things we want to track on our site”, “what data points will be important to me in reporting use”, and most importantly, “how will these data points inform decisions”. It is important to ensure each of your business requirements relates to a data point that can be used to inform business decisions. For instance, it can be tempting to want to track every click on your site, but at the end of the day, what insights are you gleaning from that reporting?

Start by filling in column C in the screenshot below (Business Requirement). This should be something like “How many internal searches are completed on our site” or “Which internal campaign spot is most effective in terms of impressions”. After filling in this level of detail, you can go back and fill in column B (Category) and group the requirements into categories like “Search” or “Internal Promo” which should correspond nicely with your tech spec sections.

You will also indicate whether you think using an eVar, event, prop or combination will achieve what you are looking to track.

And lastly, the Implementation Status column will serve as a status check as you start to add things to your site.

Variable Map tab (tagging doc/SDR)

WHAT:  A tagging doc (commonly referred to as SDR) is a critical piece of documentation that is valuable for both tech and business users of AA. It lists every variable in use by report suites along with all relevant details for the variable settings, how the variable is implemented, and what its purpose is in reporting. Like your properties doc, this should be a living, well-governed Excel doc with a point person responsible for keeping it up to date as tagging enhancements or implementation changes are introduced.

WHY:  This document will serve many purposes, but the most important are the following:

HOW:  Begin by listing all Adobe out-of-the-box variables (page, product, geo, etc.), as well as eVars, props, events, and list variables in an Excel doc. This should have one tab per site/report suite.
For each of those dimensions, I add the following columns:

Screenshot of sample SDR:

It is also recommended to use this tagging document to keep track of any free variables and any “junk” variables. When a dimension is no longer useful, dev will usually need a while to delete it. Even after that, caching may occur, or you may realize that the dimension was also being set elsewhere. Cleaning up dimensions is not easy, and often requires patience. Here are some tips to keep your junk hidden under the bed so that your users don’t get confused while keeping track of it.

This way your data is always clean, and you have a clear idea of your junk.

Properties tab

WHAT:  A properties document should list all your digital properties - websites, mobile apps, other tools (chat, feedback, etc.), whether those properties are tagged with Adobe Analytics or not. This should serve as a centralized, living document across business and tech users.

WHY:  This will give you a clear view of your user’s journey across all your digital properties, and what Adobe Analytics does and doesn’t cover so you can begin to prioritize adding tagging to any properties where it is missing. By laying out your digital ecosystem in this manner, you can identify potential opportunities in tagging strategy to gain a full view of your user’s journey. For example - do you need a global report suite to track across multiple domains/sites? Is there a visitor ID handoff needed between domains or app to hybrid experience? Do internal URL filters need to be updated for cross-domain tracking?

HOW:  Identify an owner of the doc to provide governance and a single source of responsibility for managing updates.
List the following on the properties tab:

Remember to include all digital properties, even if they are not tagged with Adobe Analytics. This will help you to understand your digital landscape and how your users interact with all your properties.

It’s recommended to keep this doc as simple as possible and not bog it down with too much info so that it remains easy to interpret by different parts of the organization. Analytics teams often understand the digital landscape better than any other team, so this doc is often used by other teams and executives to provide a thorough overview.

Create a site name/property dimension in Adobe Analytics. Having a dedicated dimension (usually an eVar) in Adobe Analytics that identifies the site name/app name will allow for segmenting, troubleshooting, virtual report suite creation, etc. The benefits are endless, especially when combining multiple sites in one (global) report suite. The key is making sure that your dev teams always set this value in the properties dimension, including all page loads (s.t calls/trackState) and all custom events (s.tl calls/trackAction). Processing rules may be a valuable tool to help you set these values properly and consistently.

Watch this video by Doug Moore for more information on filling out the implementation playbook.