Archive for July, 2008

How does analysis become reporting?!

Posted by Jason Egan

July 22, 2008

I’m not sure of others’ experiences, but ts has seemed to me that most of the time I provide a very insightful analysis to management and they are very pleased, the inevitable followup on their part is, “can we start getting this every week?” So while Web analysts want to provide analysis as opposed to becoming report monkeys, are we just creating more work for ourselves with our great analyses? More importantly, how do we get management to stop turning every analysis into a “regular report?” I think that the answer here is 3 fold:

Learn how to set management expectations
Have alternative (or more in-depth) anlayses planned at all times
Assert your expertise

I think that if you do all of the above with an already existing base of established reporting, you can have success as a true analyst and not a report monkey. First though, how do you set clear expectations to management?

Email is all about setting expectations

One of the most important parts of a successful e-mail marketing campaign is setting the expectation of how often the recipient can expect to be emailed and what they will be e-mailed. The same goes for analyses of Web data. First, inform management of the analysis that you will be performing. This can enable them to ask some questions up front so that “feature creep” doesn’t occur later in the analysis (or worse yet, afterwards). Also, you’ll want to make management aware that reporting on this information on a regular basis and simply trending it isn’t the end/best result. Inform them that you will be delivering actionable insights after which it is their responsibility to act (unless the necessary resources are within your sphere of influence should you be so lucky).

Alternatives and the next big thing

One of the best ways to convince management to not make an analysis a regular report is to have the next few things lined up and planned out. This way, you can then tell them what was planned next and that regularly reporting on what you just delivered will decrease the number of analyses that you can deliver that are actionable.

You Are an Expert in Web Analytics & Analysis

If you weren’t, you’ve done a good job in fooling people that are signing your paycheck. We all know that convincing the HIPPO (highest paid person’s opinion) that you know more than them will usually fail. This is where it is your responsibility over time to build your own personal brand as an expert. This isn’t going to happen over night. You’ll have to prove yourself. My recommendation here is to plan EVERY week what you are going to deliver to management to wow them. If this means slowly delivering great things then so be it. Trust me the result is worth it. One of the most important things that I learned in grad school is the following, and it was sort of a career epiphany:

Being good at your job and being successful are two TOTALLY different things.

These are just a few of the things that I try to keep in mind so that analyses don’t turn into boring reports that eventually and inevitably get ignored.

How do you ensure that your big ideas and analyses don’t get ignored? This also reminds me, if you haven’t read it, you should also check out the book “Made to Stick: Why Some Ideas Survive and Others Die…” You can get the book here: http://www.amazon.com/Made-Stick-Ideas-Survive-Others/dp/1400064287

Omniture Data Sources

Posted by Jason Egan

July 13, 2008

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:

Call your account manager and get them to enable Transaction IDs (easy enough).
Your account manager will give you an updated version of your JS file that has the requirements for the implementation of the Transaction IDs.
Have your developers implement the creation of the unique Transaction ID on your order completion page. The updated JS will pick that up and send it to Omniture.

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):

Returned Revenue (define as a currency event in SiteCatalyst admin)
Returned Orders (define as a numeric event in SiteCatalyst admin)
Returned Units (define as a numeric event in SiteCatalyst admin)
Cost of Returns (to add back to cost of goods sold when you start doing that too!) (define as currency event in SiteCatalyst admin)

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:

Product Returns Data Source

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:

Order Date
Product ID
Revenue
Orders
Units
Transaction ID

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:

http://snurl.com/2xvlk

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.