Toward the beginning of the 4th quarter 2015, we had a global electronics retailer approach us looking for a solution to a business problem they had. This client is a major electronics retailer that operates online and brick-and-mortar stores for multiple brands. Our primary contact at the client, who manages the team responsible for analytics and insights, saw this problem while the rest of the business didn’t realize they even had a problem.
The client has a fairly robust Adobe Analytics implementation in place on the various brand sites. This is also a client whose core business has historically been brick-and-mortar stores. In a push make analytics more and more relevant in the organization, our client realized there were issues with the way information collected for the online sites was distributed throughout the organization. In the first attempt to address this they used Adobe Report Builder, but that turned out to be problematic.
Initial Try
A little over a year ago, our client put in place automated report delivery using Adobe Report Builder to send KPIs for the online stores to key stakeholders every hour. They set up a dedicated computer in the office that had Microsoft Excel open at all times. The spreadsheet they used had macros programmed to retrieve the data through Report Builder, take the resulting table and paste it into a new email within Microsoft Outlook, then send it to an email distribution list.
This became problematic very quickly. The macros would fail often for a myriad of reasons preventing any kind of data distribution. The client was also limited in the data they could provide to the organization. The email consisted of revenue, units, and orders and that was about it. They wanted to send out other data such as onsite search term and campaign data. Since the spreadsheet was already choking on this limited data set, there was no way it would work with the expanded data set.
Aside from the limited data set and the issues with the regular generation and distribution of the data, the presentation was very basic. The data was sent in a basic table. There were no visualizations that made reviewing the data more palatable or interesting. Our contact at the client knew this was a key part of the opportunity.
Getting Involved
Our contact originally approached us with the problem they were having with the hourly emailed report. He asked us to review it and first solve for the errors they were encountering. Once the issues were resolved, we we’re going to look to enhance it.
Investigating the issues proved troublesome and not easy to solve. We also discovered that Report Builder wouldn’t be the best tool to use if we wanted to enhance the report. We started to look into other options that Adobe offered out of the box, but none would suffice. Beyond having a solution that brought powerful visualizations to enhance the presentation of the data, we needed to account for year-over-year calculations. The previous period data needed to be displayed to the current hour, not the full day. This is not available in any of the out of the box solutions.
We also took a look at what could be done by using one of the BI vendors out there. The problem here was that we didn’t have the time to get budget approval to bring one of those vendors in nor the time to integrate.
The client was looking to get this resolved by the start of the peak holiday season, which left us weeks, not months to work with.
Identifying a Solution and Moving Forward
In a conversation with the client, they mentioned the Adobe Reporting API. The Reporting API gave us a significant amount of flexibility and capability, but our initial concern was the development involved. The development necessary to retrieve the data, perform the necessary transformations, and then display it via a custom presentation layer presented a potential roadblock with the timetable we had.
We discussed this concern in great detail and were able to find a path forward using the Adobe Reporting API. The first step was that we weren’t going to over-engineer the dashboard. We were going to keep it as simple as possible, limited to the key data points necessary. The client was able to secure a developer that would be able to dedicate time to this effort to ensure we could have a complete presentation layer.
Now that we identified using the Adobe Reporting API as the best option, we quickly identified the roles for those involved. This is a critical, but often overlooked, step with efforts such as this. The work we were doing was more skunk works and less organization-sanctioned project. There was no formal team charter or assigned project manager. That can lead to a situation with everyone running around trying to complete any task they see fit. In order to prevent that, we kept the team small and clearly identified what each was responsible for. Our primary contact at the client was responsible for identifying the KPIs and building mock-ups of the presentation. Our role was to provide feedback on other KPIs that were available to us, take the mock-ups and identify what reports in Adobe Analytics would provide them, and then provide the developer with API call samples to retrieve the data. The developer was responsible for taking the design that we provided to build an application to programmatically retrieve the data, transform it, and display it based on the design.
For those that have used the Adobe Reporting API, you know that the data returned is not a pretty, formatted report. The data returned is a JSON object with the metrics calculated based on the granularity and dimensions defined. Those that are just getting involved with the API and are used to working primarily with the front end are usually shocked to learn this.
A request to queue the data and identified metrics for products will look like this:
That request will return that is structured like this:
While taking this and turning it into a visualization that senior level leadership will want to see may seem daunting, the beauty of it is that you have complete control and flexibility. The information we provided the developer on the project were not only the API call examples, but a detailed matrix on how to read the resulting data and how to connect it to the presentation mock ups – a full dashboard architecture.
Completed Solution
After all of the work that was done and the steps taken, the ultimate solution we ended up with was a custom dashboard hosted on an internal URL that leveraged the Adobe Reporting API. The dashboard was built in such a way that while there are complexities that need to be worked through, the benefit is something that is completely flexible that can meet the needs of the business. What would have been the “easier” solution would be to either use the out of the box features of Adobe Analytics or bring in a data visualization platform, but in actuality neither of those were the best or easiest answers.
Our team will be at Adobe Summit EMEA 2016, so be sure to reach out to chat with them regarding this solution or any other you may be in search of.
Guy Dahan, Director of Client Success
guy@33sticks.com
Jim Driscoll, Consultant, Solutions Engineering
jim.driscoll@33sticks.com
[author] Jim Driscoll [author_image timthumb=’on’]http://i2.wp.com/33sticks.com/wp-content/uploads/2015/08/9239556033_a7e5c89228c15928b3f0_192.jpg?w=192[/author_image] [author_info]Jim is a consultant on the Solutions Engineering team at 33 Sticks who brings 15 years of solution design and technology implementation experience, with 9 years focused on web analytics and digital marketing technologies. He is a fitness enthusiast and avid sports fan. He also thinks he can play golf.[/author_info] [/author]