Buglist.net

Have you ever noticed that some of the SiteCatalyst Report Settings appear to have a life of their own ? You know, You change a setting, and then later on, say late in the evening when you are working at home, the setting is suddenly back to where it was before you changed it, but it doesn’t always happen when you change a setting.

I myself find it a bit annoying, so I started digging into what’s actually happening to those settings when you hit the Save button.
The explanation is quite funny, only a few of the settings are actually saved in the way you would expect them to be saved, that is as properties tied to your login. Most of the settings are only stored locally on the computer you are currently using to change the settings.

The settings you can count on are :

• Include Calendar Events in Reports
• Enable network acceleration for improved report performance
• Currency
• Scheduled Report Encoding

The rest, you’ll have to adjust on every computer you use for SiteCatalyst.

Let me save you some time: It doesn’t work!
Although the discover.jnlp (Java Web Start) file does indicate that Discover should be able to run on several Linux variants, well Ubuntu Linux isn’t one of these.
The problem lies in the desktop manager, Omniture Discover is, as of now, not compatible with the Gnome desktop manager.

Workarounds:

• Switch to Kubuntu or some other NON-Gnome based Linux distro
• Make your Ubuntu installation capable of running with the KDE desktop manager (sudo apt-get install kubuntu-desktop)

Another maintenance release from Omniture, this time with some great news/changes & fixes.
Most noticeable is a change in the way data feeds are being processed, they are now processed based on the timezone of the report suite instead of the data center timezone, for me, located in Denmark I guess this means a Data Warehouse request that includes yesterdays data will be able to start processing 9 hours earlier than it is today
Apart from the data feed news I think it’s great to see a sign of life from the Omniture Survey product, I’m not sure any active development is being done on the product, but at least they started fixing some of the issues with the current version, that being said, I still have a 560+ day old Survey issue…

I’ve been spending some time with Omniture Discover lately. What a truly amazing product Discover is, I’m almost speechless.
Unfortunately it does have a few rough edges here and there, character encoding difficulties being an example.

This is what the Danish characters æ ø and å looks like inside Discover: (perfect)

This is the same data after being exported in Excel format by Omniture Discover: (not pretty)

I’ve been writing about Omnitures way of dealing with timzones previously, since then a few changes has been made to both the SiteCatalyst and the Data Warehouse report scheduler.

SiteCatalyst

When setting the scheduling options in a report scheduled for later delivery in SiteCatalyst You’ll see a dialog box pretty much like this, notice the lack off timezone indication next to the “Time of day” dropdown.

So what timezone is this? Is it Utah time? No, it’s in fact your local timezone, this will become obvious if you try editing an existing report, in this case you’ll see the timezone indicator next to the “Time of day” dropdown.

I know, no big deal, just confusing, especially for the new SiteCatalyst user.

Data Warehouse
Schedule editing in Data Warehouse is not that different from SiteCatalyst, but there is one big difference you need to be aware about. Even though the dialog box shows you that things will execute at a certain time in your local timezone, this isn’t what really happens, everything in Data Warehouse happens at Pacific Standard Time (I think it is).
Being located in Denmark as I am, this means that the earliest possible time at which I can get a Data Warehouse request to execute is 9 AM local Danish time if I need yesterdays data included in the report.

A few days ago while trying to rearrange our Campaign classifications, I found yet another SiteCatalyst conversion classification editor issue.
You can’t date enable a classification, and by the way disabling an already date enabled classification won’t work either.
I do think the Conversion classification editor has been having quite a few issues lately.
Workaround:
As usual, switching back to the SiteCatalyst 13.5 GUI while performing administrative tasks is a possible workaround.

Some time ago, on October 22, Omniture announced the availability of http://customers.omniture.com/.
Early today on November 4. the site wasn’t very much available, as it went down together with Omniture Sitecatalyst. It’s hard to say precisely what went wrong, but my guess is that the loginsystem on customers.omniture.com shares some resources with the normal Omniture production environment.

One of the supposedly great features of customers.omniture.com is a System status grid where you can get updates on the current system status of the Omniture production environment, needless to say that for such a System status grid to be really smart, it has to be running even when everything else isn’t.
Perhaps Omniture should make customers.omniture.com a bit more of a standalone system, without any ties to the rest of the Omniture network. I myself would probably even move the system to a location outside the Omniture network, this way customers.omniture.com could be available even in a situation where Omniture suffers from a complete network blackout.

A maintenance release a couple of months ago had a strange side effect on our report suites.
The first Custom report viewed after logging in gets the report date set to 1. Jan 1969 – 31. Dec 1969.

This is how it looks in ranked view :


And this is how it looks in trended view (this view effectively invalidates your report since no values are being displayed):


Downloading a PDF version of the report creates an funny variant where the date is being set to 1. Jan 1997:

Workaround:

• Setup your report suite to display a Dashboard as the SiteCatalyst startpage.

Another maintenance release from Omniture, and this time the release notes includes a list of fixes made to SiteCatalyst, thank you Omniture !
Well at least most of the fixes, as far as I can see the changes/fixes made to the admin area of SiteCatalyst they don’t really get mentioned in the release notes.

I’ve especially noticed a minor change made to the conversion classification editor.
Prior to the 9/17 maintenance release, deleting a child numeric classification was impossible, You got no reaction from the editor when trying. This behaviour has changed a bit, trying to delete a child numeric classification now results in the parent being deleted instead, and when you recreate the lost parent classification the child magically re-emerges as well.
I’m still trying to figure out the purpose of this change.

Update:
Here is a video demonstrating the strange conversion classification editor behaviour.

Although Numeric Classifications are having a few issues I still think it’s a great feature in Sitecatalyst.
However, now that our Numeric Classifications just suddenly for no apparent reason started working, I’ve noticed a few peculiar things about the way they work on our report suites.

Sorting
Numeric Classifications creates new metrics you can use in your reports.
I would expect any new metric, numeric, or otherwise calculated, to behave just like any build-in metric in regard to sorting.
Metrics normally sort in descending order in SiteCatalyst, Numeric Classifications not being the exception, but they are not sorted on the actual value of the metric, the sorting is performed using the user provided values used to multiply by the existing metrics (Click-Throughs, Units, Orders etc).
Bottom line: Numeric Classification metrics don’t sort.

Totals
Sometimes the totals on our Numeric Classifications are working, sometimes they are not (total=0). It’s possible there is a pattern, but I haven’t been able to figure out what that would be.