At Omniture Summit 11, I was honored to be part of the Analytics All-Stars team. In the break-out session, I talked about how you can make use of APIs to create custom dashboards that drive action.
One universal truth I have discovered, after working with many different companies to optimize their analytics practice, is that no two companies look at data exactly the same way. The major analytics players in today’s market have done a fantastic job at providing product offerings that cover a large part of most customer needs. However, it is not possible for a single solution to align perfectly with every customer’s needs and if it were, the product would be so bloated that no one would want to use it.
So if my analytics package of choice doesn’t present the data in all the ways my key stake holders demand, what options do I have? Many, if not all of the top vendors, have a set of APIs that allow you to export data out of the applications so that you can present the data in a way that better aligns with your business needs.
The desire to present data in ways other than what is available in out-of-the-box reporting seems to be high on everyone’s agenda, however I was shocked when I asked the Omniture Summit audience how many people were making use of the APIs and I saw less than 10 hands go up in a room of well over 250 people.
Building applications and dashboards using APIs doesn’t have to be scary. Let’s walk through a custom dashboard that I built using the Omniture Reporting API.
NOTE: If you are an Omniture customer and you want more information on using the APIs, there is a ton of great information inside the Developer Connection.
The following is the high level data flow for the custom dashboard I developed:
1. Omniture Data Store: This is the Omniture Report Suite that contains all of the click-stream and conversion data for my site.
2. PHP Application: The PHP application is the engine the drives the process. It is a simple application that extracts data from Omniture, loads the data into an internal database, and then transforms the data into a format that aligns with business goals. It it scheduled to run on a daily basis at 4 am via a cron job. The first component of the application extracts data from Omniture using the Reporting API and loads the data into a custom MySQL database that has been setup to accept the specific data points being extracted from Omniture.
3. Internal MySQL Database: A custom MySQL database was setup with a table structure to match the specific data points that are being exported from Omniture in step 2. This allows for custom trending calculations that may not be available out-of-the-box with Omniture.
4. PHP Application: At this point, the data has been exported from Omniture and is now being stored internally. This component of the application transforms the data into a format the business is more familiar, complete with custom trending. Once the dashboard has been properly formatted, the application deliveries a daily copy of the dashboard, via email, to a list of subscribers.
The following is an example of a daily dashboard that is built using the process described above. Although this is a copy of a real dashboard, the dashboard has been populated with fictitious numbers for privacy reasons. The dashboard shows key conversion metrics for 3 segments of visitors. The conversion metrics are trended against the 4 previous same days of week and a 7 day average.
If you are interested in extending your reporting by using APIs and need a little help, please feel free to reach out to me, I’d be happy to point you in the right direction.



Pingback: EmptyMind | Custom Omniture Dashboards: Part 1 – Getting the Data