What Adobe should do for SiteCatalyst version 15

What Adobe should do for SiteCatalyst version 15

Given that my last post was number 100, I was thinking that this post should be a Web Analytics 101, but then I decided that was too cheesy for even me.  So instead, I’ve come up with a list of things that should definitely be in the next version of the SiteCatalyst tool powered by Omniture.  Although, I’m well aware that there is going to be a release of SiteCatalyst version 14.9 coming out soon, which will presumably have some nice feature updates – this is what I think should take the next step in Adobe’s next step and will be a bit far removed from improvements on the current system.

Before I go into anything else, I’d just like to point out the Omniture Ideas website.  It is awesome.  I am going to submit all of these to that website.  In the morning, once I have had some sleep.

1. Tagless Events

Let us start with the biggest one that is around.  Whatever you want to call them: conversions, events, goals – the things that you want people to do on your website.  In Omniture you can set them up as custom events (see the customer conversion section of my post on SiteCatalyst reports) in the tags on your page.  I’m not going to lie to you, I think for implementation they are overly complicated.  Moreover they are named completely wrong – how on earth can you have ‘events’ which are effectively conversions, whilst you have ‘coversions’?  I’m going to attempt to explain it to you here in layman’s terms:

A custom event in SiteCatalyst can work in three ways.  It can be a:

  • Counter – every time it occurs it goes up by one.  
  • Currency – it goes up by a certain amount of currency which you can specify in the tag
  • Numeric – it can go up by a certain number which you can specify in the tag

So first off you need to make sure you set it up in the admin screen and then you also have to code it into the page.  So with the counter ones you can just set them to go up by one by one by giving a parameter in the tag that says s.events = “event1”.  For Currency and Numeric ones you should also add in how much you want them to go up by in a separate variable which is described by the products tag.  You can put in here what the product is, how many of them there have been, how much value is associated with each of them.  This is amazingly powerful if you have lots of different products on the site that you want to tag through your events (eg an online shop).  It’s particularly powerful.

I don’t like it.

Why not?  Let’s see how you set up goals in Google Analytics:

See how easy that is?  It’s one step and I don’t need to change anything on the page.  The results of Counter Custom events in Omniture work exactly like Goals do in the results part of each of the two tools.  Omniture must come up with a way for us to create events on the fly without having to change the code on the page.

2. Custom Traffic variables defaulted to Custom Conversion variables as well

One of the biggest issues that I frequently have is where users of SiteCatalyst are using custom events in custom traffic reports.  Why?  They give back a gibberish answer.

Ok, Ok, they don’t really give back a gibberish answer, but they don’t necessarily give back the answer you were expecting.  Remember custom traffic variables are counter variables (page views, visits, entries, etc) whereas custom conversion variables are on page tagged campaigns.  Therefore having an event convert against a custom conversion variable makes a lot of sense.  You can choose in the interface if you want the event to occur against the most recent value, the first noted value or linearly across both (it would be nice if it could be fully attributed to both – the total of each of them doesn’t need to add up to the total of all of them).  You can choose when you want the campaign to expire (after the visit, after a time length, after converting against one of your events) and you can choose a whole load of other things (see my learnings from the Summit for custom conversions as counters).

However having an event convert against a custom traffic variable doesn’t make as much sense.  And indeed you can’t really track your events against something that are just counted as flat options.  Except in the case of page views, where it turns out you can.  How does that work?  Well instead of attributing it to the first page view (you can do this in your paths reports – if you have it enabled – where you have the choice of measuring against the entry page) or the last page view before you get to the conversion, it gives it a representative value against each of the page views.  That kind of makes sense – you might want to be able to attribute a value to all the pages in the journey.

But you might also want to see how good a page is at, say, driving registrations to a site, even though it isn’t directly linked to from there.  If you want to do this, you need to use your custom conversion reports and set up the same variable as in your custom traffic report.  This seems very long winded to me.  The data is collected anyway – why can’t there be a button in the admin section to just enable it?  Or better still, just auto enable it.

Yes, yes I know you can do this with a VISTA rule – but I shouldn’t need an Adobe consultant to flick a switch.

3. Default popular plugins
Our site uses a desperately old version of the SiteCatalyst code before plugins became popular.  To prove that they have become popular, Omniture’s website has come up with a list of them.  Some of these seem like a genius has come up with them. Why aren’t they implemented as default?

The first one on this list involves taking a query string parameter from the url and putting into into a custom (traffic or conversion) variable.  I don’t know of any website that doesn’t contain the search term that a user typed in as a query string in the url.  Omniture can collect the url of the pages (it collects it at least once to populate the pages report to match the page names up to the urls).  Why can’t it auto-populate an internal search report.  Or use an editor in the admin section that allows you to describe which of the custom traffic variable (with a switch for the custom conversion variable) you want each query string to relate to.
even Google has the search paramters in the url
How do we know that they do it anyway?  We know because you can set up campaigns to be picked up in the javascript code from the query string.  Why can’t SiteCatalyst capture all the query strings and then just use the ones described in the admin section.
4. Update javascript file automatically
I wrote a spec a few weeks ago to put a new bit of the site under the latest version of the javascript code.  It took a bit of work by me to make sure all the plugins worked correctly and that it would be fine.  We’ve been doing some testing this week to make sure it works properly.  It didn’t.  I went back to my code to come up with the reasons why.  In fact I went all the way back to the original code as it was spat out by SiteCatalyst.  It turns out in that short period of time, Adobe had come up with a new version of the code and we were working off H.22.
Now there is no way I am going to rewrite the entire thing, so I’ve told our developers that we’re already out of date.  We haven’t even put it live yet.
When will someone come up with a solution that allows Adobe the right to push our minor changes to the code to everyone else?  Could there be a common include in the javascript file that referenced a common file that was the same for everyone?  I don’t know anything about this, but I can’t be the only one to have realised that their code is so out of date that SiteCatalyst is no longer supporting it.
5. Full metrics in Hierarchy reports
This is one of those words that I can never spell and always turn it into a heirarchy.  I’ve come up with a definition for the word: It’s a list of people who are in line for the thrown in order.
Anyway, enough of the pleasantries, the hierarchy reports are very, very useful.  If you set them up correctly you can drill down level by level of your content.  It’s a great way to be able to drill down into sections of the site.  If you don’t use the hierarchy report, I suggest you set it up.  You can of course do this with your products that you convert against as well – using classifications.
My big problem with this report is that you can’t do anything else with it.  It’s entirely stand alone.  I think that Adobe should improve the functionality of this report to allow all sorts of added extras.  The added extras I’m talking about are those additional metrics (like entries, exits, single access, time, etc).  
Not only should these added extra metrics be available, but we should also be able to correlate this report against any of the other reports.  The reports I’m thinking of that should be defaulted would be the traffic sources, search engines and search terms.  In fact, linking it up to the new channel report would be the most awesome thing.
Currently to get around this issue, I’m having to record each of my levels of my hierarchy in a flat format in separate custom traffic variables, each of which need to be correlated with each other and each of which takes up time in processing.
6. Enable visits on correlation reports
For the love of god – do this.  It is so annoying that you have to create correlations for reports and then suddenly you are reduced to just page views.
There are ways around this problem.  The options are that you can put both values in the same custom traffic variable and separate them with a colon (or some other punctuation), but this causes you problems when you want to know the visits all as a group, rather than associated with another value.  It would be so much easier if you could just correlate and keep visits.
Plus, whilst they are at it, they could add the ability to trend the correlated reports.

4 Comments on “What Adobe should do for SiteCatalyst version 15

  1. Alec,

    This is some great feedback. I’m glad to see that you are going to add these on the Idea Exchange, or vote on existing ideas that apply to these suggestions. That remains the best way to ensure that your opinions count.

    Let me respond to each point briefly.

    1. Love the idea. Noted.
    2. I’m not totally clear on this; could you give a specific example? Does participation not give you what you need?
    3. The problem with including all of the popular plug-ins by default is that they can inflate the size of the JS file, something that many users are very concerned with. However, I do agree that it could be easier to grab query string parameters, and we’ll look into that.
    4. Agreed.
    5. I think this is what you’re looking for 🙂
    6. Take a look at the last comment here.

    Once again, thanks for this feedback. I love the way you’re thinking about the future of SiteCatalyst. Please feel free to reach out to me, personally, at any time if you’d like to bounce any other suggestions off of us! I am at ben {at symbol} adobe dot com.

    Thanks,

    Ben Gaines
    Product Manager
    Adobe Systems, Inc.

  2. Great post.

    1. I love this idea. Many of us have been asking for something similar for years. Moving events from the page to the admin console is a huge win.

    2. I think I understand what you are asking for, and if I do it would be slick. Are you saying, create a setting in the admin console to copy the value of a specific eVar to the corresponding prop? So, if eVar1 has “copy value” set, then the system would automatically copy any value assigned to eVar1 to prop1?

    3. Not sure I agree with this one. I would much rather just have the option to include specific plugins upon code creation.

    4. I disagree with this one unless there is a way to opt out of auto updates. Many companies have a very strict development life cycle and having the JS automatically updated could be flagged as a major risk. I am fine having the code pushed out through the traditional channels with indepth documentation of the changes. I have a real concern about blackbox changes that could be pushed out without my consent.

    5. I rarely use the heir reports for some of the reasons you point out. I just don’t see much value there. Could be because I’m a Discover user before I’d ever use SC.

    jason thompson
    @usujason

  3. Hi Ben, Jason,

    Thanks for your comments.

    Just as clarification on a couple of points:

    2. What I really want is the ability to say that if I am collecting a value in an s.prop I don’t want to have to change the code on the page to capture the same information in an s.evar. Maybe if you just collected s.variable1 and then could decide in the admin section whether you wanted it to be an custom traffic variable, a custom conversion variable or both.

    I do really like the participation option though – there are some really clever things that you can do – although if you could do more without having to change codes on pages it would be better 🙂

    3. Hmm – maybe we’ll have to rethink this. I was just thinking that it’s entirely possible to miss a really good plugin because you just didn’t know it was created. Anything that could be done without using the javascript would be good (although probably difficult!).

    4. This would have to be thought through with the ability to opt out if needed. All the changes presumably allow you to do more stuff, so it seems like you’d want them. Building them into development cycles is tricky though – hence my thinking of a keeping a common bit of code that just references a bit of code on a common server for the common bit. I am sure it would cause problems though as every website is different.

    6. Does that mean visits on correlations already is a possibility if I ring up my account manager? I have upvoted this on the ideas website though.

    Again – thanks for the comments both.

    Alec

  4. 1. You don’t necessarily HAVE to code events into the page. Consider just writing them into the js file. We use at least a dozen events for carfax.com that are not coded into the page at all. In fact, I transitioned us from HBX to SiteCat pretty much only using the js file. Only one page on our site (the thanks page) had to be changed. My developers happily agreed to work on only that single file instead me always going back to them to change individual pages.

    5. Hierarchy…ugh. When I was at NatGeo, I wrote full hierarchies into traffic variables for the reasons you describe. You might try something like Enviro > Pollution Prevention as a value, for example. And you can always use SAINT to make those values more descriptive.

Leave a Reply to Benjamin Cancel reply

Your email address will not be published. Required fields are marked *

*