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)

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.

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.

Workaround:

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

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.

Click here to view the embedded video.

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.

Update: I should note however that Omniture Clientcare does the best they can to update the customers on any fixes and progress as soon as the information becomes available to Clientcare.

The “Targets editor” has been fixed. This is really great news, the targets editor has been broken for almost a year. You’ve always been able to create new targets, but editing existing ones wasn’t working, in the beginning all conversion related metrics were missing from the dropdowns when trying to edit a target, but then as part of the SiteCatalyst 14.6 release, the editor became completely broken, all metrics were missing when trying to edit a target and a few javascript errors were also included.
This has all been fixed now. Perfect ?
Close, but not 100%, as usual, engineering didn’t bother testing on any foreign character sets, so at least Danish characters aren’t supported in the dropdowns.

For those unfamiliar with Danish:
bredbÃ¥nd is supposed to be bredbånd
søgeord is supposed to be søgeord

Clickmaps: Finally Omniture is moving towards supporting the BUTTON tag in Clickmaps, if you add a s_objectID in the onclick handler of your button tags, you can now be pretty sure those buttons will show up when turning on the Clickmap plug-in.
I think it’s great news that Omniture has started fixing some of the Clickmap issues, but there is still a long way to go before things are working as specified in the Clickmap user manual.

Update
I just noticed yet another thing that slipped through the release testing at Omniture.
In the Targets Manager, all target names now have the textstring Name prepended.
If You create a target with the name Sales, it will show up in the Targets Manager as : Name Sales.
I know it’s no big deal, it just looks sloppy, but I guess we’ll get used to those new names.

Then one day I realized that I had hidden a menu that I on rare occasions actually need. This is where the “Show Omniture’s default menu structure” is supposed to come in handy, you’ll find it in the “My Account -> Report Settings” area.
Unfortunately it isn’t working, checking this option changes absolutely nothing