Monthly Archives: July 2007

Data Source fun with Omniture

One of the killer features within Omniture is the ability to import other offline data to merge with the data you are collecting on the web. This includes stuff like ship & return data, data from email vendors, call center data, CSAT surveys, and a whole host of other possibilities. The only scary drawback has been that you can overwrite existing data, and really there isn’t a way to fix it. So I’ve been pretty nervous in doing much with it, but some of the things I want to do have necessitated that I learn it. I spent some time yesterday with our account rep at Omniture and came away less scared and a lot more knowledgable about it.

So today’s entry consists of a couple of tips to make it work.

Right now I am in the midst of doing imports from our fulfillment system into Omniture. The reason is that in Omniture we are collecting point of sale for revenue, orders, etc but we know we have a percent of those orders that never become anything, such as credit card fraud or orders being cancelled by customers after the fact. To get a ‘true’ revenue picture I wanted to factor out these cancels and also bring in data on when those orders and part numbers ship.

First tip, do all of this stuff in a development report suite first to see how data looks etc. Doing this against one of your real report suites could be catastrophic.

To start in the upper tabs there is a section called ‘Data Sources’ where you can create a Data Source. To minimalize risk, I would suggest creating metrics that don’t exist already within Omniture, especially when dealing with things like Revenue. So to bring in Cancels, I created a couple of new events called ‘Cancel Revenue’, ‘Cancel Units’, and ‘Cancel Orders’. Another reason I hadn’t really tried this in the past (besides being terrified of detonating my database) is that we had a limit to like 24 events in previous iterations of SiteCatalyst. Recently, version 13.5 was released and gave us 100 events to play with, which is a huge help.

The reason you want to set these as new events is that you won’t overwrite what is already captured as Revenue in Omniture. You are creating a whole new metric essentially. And then you can create a calculated metric such as ‘Net Revenue’ which would take Revenue – Cancel Revenue.

In the setup for DataSources you can link up the existing data and your Data Source by using Purchase ID and Part Number. That way that Order and Part have metrics for Revenue and Cancel Revenue, if that ordered happened to be cancelled. If not, the Cancel metrics will just be zero.

In my initial trials, I had another eVar in there that was used it to distinguish the order status, whether the order was shipped, cancelled, or returned. I changed that the second time around, as its better to add a classification by order number to do that as opposed to the data source. For instance, the status of an order could change and you’d have no way to change it in the data source, but classifications give you the flexibility to do that. And doing that way you could have the classification have information like Reason for Cancel, etc which makes the data really interesting.

So next week I am going to start setting up our feeds to ftp everyday and merge within Omniture. Wish me luck. If I am looking for job in 2 weeks, you know I failed.

In the spirit of automation, I wonder if Omniture has thought about creating a Genesis-like function for internal systems such as SAP where the fulfillment data etc would be tied in a real-time way as opposed to manual data feeds.

Also, for those that are scared of the possibility of messing up your existing data, I believe Omniture is working on a way in the future to fix data once its loaded so you won’t run the risk of overwriting stuff. That will go a long way in making sure customers utilize this valuable function.