I’ve wanted to document what I’ve done with Omniture Data Sources for a while now. Data Sources is one of the most powerful features of Omniture, with very little practical documentation. Data Sources allows you to upload any data and integrate it into SiteCatalyst (and Discover) reporting. The real power lies in the fact that you can upload offline data about transactions that were completed online. For example, most e-commerce businesses have returns and cancels. With Data Sources you could upload your data for returns and cancels and see it in reporting for marketing channels as well as product reporting and any other reports in SiteCatayst. This all being said, Data Sources isn’t something to be taken lightly. These uploads require planning and preferably testing in a development version of your report suite. Once you upload the data, it’s there for good (trust me, I’ve messed it up before and all you do is loose variables and events). Here, I’ll tell you what you need to do to get one of the most common things you might think of into SiteCatalyst, returned orders. First, let’s look at setting up SiteCatalyst and your online orders so that you can import offline data at the transactional level.
Transaction IDs
Anything can be uploaded into Data Sources. But, if you want the data to do anything other than be a flat number you’ll first need to implement Transaction IDs. Transaction IDs are basically unique identifiers for your orders. You could simply use your current order ID at the time of purchase if you like, but you do not have to (your choice). The Transaction ID is what enables SiteCatalyst to associate uploaded data with transactions placed online. Note that Omniture will only hold this Transaction ID on its end for 90 days (meaning you can only upload offline data for transactions made online in the last 90 days). You can pay Omniture to hold the Transaction IDs longer if you need to (maybe if you are in a business with a sales cycle longer than 90 days). Here are the steps to getting Transaction IDs in place:
That’s pretty much all you need to do to get the Transaction ID in place. Now let’s look at uploading data for returns/cancels at the transactional level.
Returns/Cancels Data Source for Omniture SiteCatalyst
First of all and most importantly, be sure that you test these things in a dev report suite before you upload the real stuff into you live report suite. I’m also going to assume here that you’ll want to see the 4 following metrics when you upload returns (cancels work exactly the same):
So, this will take up 4 of your 80 events. You don’t have to import all four of these metrics, you can just bring in the revenue number if you like. However for our purposes here, these 4 make it the most complex and will make the best example.
You’ll want to use the “Product Returns” Data Source template:

The four events you’ll need to setup:

Mapping the four events to your SiteCatalyst custom events:

Setting up your dimension (required for any data source):

Mapping your dimension to products (a little obvious here):

After walking through the above wizard, the last screen will present you with a template to use as well as FTP information for the upload.
Next, you’ll need to get the return data from your team with the following columns:
The challenge in getting this data is when you come across a transaction with more than one unique product. Not multiples of the same product, but two different products in the same order. Here’s an example of what two transactions would look like when one transaction has a single product and another transaction has 2 unique products:
Now move the returns data you received from your database into your data source template and upload this “.txt” file along with a blank file named exactly the same, but ending with a “.fin” extension to the FTP location provided at the end of the setup of the Data Source.
It could take some time to see the results of your upload depending upon the size of the upload itself. However after that, you will have the 4 return metrics available in any conversion-based report.
This covers only one of the types of uploads of Data Sources that you can accomplish with Omniture’s Data Sources functionality. This is also not the only way you can upload returns data, but this is what I have found to work well. You can also upload cost of goods sold and any other data that you can link to the Transaction ID that you set on your site.
If you have any specific questions about this example or any other possibilities of data sources, please feel free to shoot me an email at jason [at] jasonegan.net, or you can follow me on Twitter and hit me up there for some info, http://www.twitter.com/jasonegan.
Jason!
Agree very less documentation on this!
This is great and thanks for the write up
Sweet work Jason–I wondered if anybody else out there was using Transaction ID’s! Thanks for the placeholder about cost of returns and COGS–I hadn’t thought that far forward!
Great post, Jason! We use Data Sources every week to capture web leads converted offline. The reliability is so-so: the uploads fail about every 1 in 10 times. Unfortunately, you were dead on about the lack of documentation. Even Live Support – sorry Client Care – seems to know very little about this powerful Omniture feature.
Corry, I’m not sure how your uploads would be failing once the data source was setup correctly. It would seem that once it works the first time, that it wouldn’t fail moving forward. I can say that once we upload correctly we’ve not had any of them fail afterward. I guess you can call client care and get them on the case, and then escalate through your account manager. We’ve been working with a senior best practices consultant at Omniture, and he’s been of great help and is very knowledgeable about data sources.
Hi Jason, great post!
We are also doing some tests with transactionID but when looking at the event we upload in any other report then the products report it’s listed as None. Do you have any idea why that could be?