Automated Solution Design Reference (SDR)
Businesses of all shapes and sizes seek to achieve various objectives— daily, weekly, monthly, quarterly, and yearly. These objectives should be tangible and measurable, otherwise how to tell that they are being met? In defining these objectives, businesses typically rely on a set of Key Performance Indicators (KPIs) which are actively monitored with the aid of reports.
These KPIs show how a business is trending as it relates with meeting its objectives. KPIs comprise a set of variables put together in a way that makes (intuitive and logical) sense for the business — and for its objectives. So when you see an insights report, you are really just looking at a picture of a business’ KPIs. In order to make these reports, analysts need to understand what variables matter to a business, but not just that, they need to be able to understand what these variables mean — this is where a Solution Design Reference (SDR) comes in handy as it contains all of this information, and then some. The SDR is one of the most important data analytics implementation documents ever, and we encourage you to create one if you do not already have one.
When I audit digital analytics implementations, besides the lack of defined business requirements … , I also am shocked by the utter lack of implementation documentation. As I review each aspect of their implementation, I see names of data points that a reasonable jury would not understand and when I ask for documentation, all I get as the outdated SDR that has very little information — Adam Greco, Search Discovery
At Telus Digital, we have our SDR on Confluence. Seeing as how one of our core digital data capturing platforms is Adobe Analytics, the SDR should ideally reflect the variables defined in our Report Suites in Adobe Analytics — speaking, eVars, props, and events. What this means, at least up until now, is when changes are made in the definitions of those variables in Adobe Analytics, someone has to update the SDR with those changes. If a new variable is created, for example, the SDR should be updated with this new variable. If an existing variable is disabled or re-purposed, the SDR should also be updated accordingly. You get the idea. You probably observe a couple of potential issues with this workflow: one, people may forget to update the SDR with changes made in Adobe Analytics; two, human error might creep into the SDR; and three, someone needs to always ensure the SDR is up to date.
We can do better indeed, and that’s why we elected to completely automate our SDR. This solves all three issues raised above. More, it frees up some time to focus on other priorities. But how did we do this?
In automating our SDR, we leveraged a couple of tools: Adobe IO, the Adobe Analytics 1.4 API, the Confluence API, and the Google Cloud Platform (GCP) App Engine. All of these are integrated in a Node.js application.
Let’s talk about how all the pieces fit together. The whole process starts when the cron job pings the variables’ endpoints. We have three endpoints: one for eVars, one for props, and one for events — collectively, we call these the variables’ endpoints.
First, we authenticate with Adobe IO which provides us the access token required to communicate with the Adobe Analytics API. We also authenticate with the Confluence API which provides us the access token that we use to communicate with the Confluence API. Both access tokens now live in our application.
Then, using the access token from Adobe IO, we ping the Adobe Analytics 1.4 API to grab all enabled eVars, props, and events. We get the eVars from the eVars endpoint, the props from the props endpoint, and the events from the events endpoint. We then send all of this data to the Confluence API which then completes the process for us by updating the respective SDR Confluence pages for eVars, props, and events with this data.
With all this, our SDR is always up to date and exactly mirrors what exists in the Adobe Analytics API — the best part, zero person hours are devoted to maintaining our SDR seeing as how it is completely automated.
Are you looking to automate your SDR? Hopefully, yes! Are you running into roadblocks in building out your automated SDR? More than happy to further discuss the technicalities of this.
