Yesterday I got myself a Failed to schedule report error.
After some testing I found the reason: Don’t use a double quote as the first character of your Dashboard name, as this will effectively prevent you from setting up scheduled deliveries.

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.

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)

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.

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.

This is not something I’m making up myself in an attempt to flood ClientCare with phonecalls
This is information from Omniture.

So what’s the problem ?
Well in many of the cases I’ve found myself it simply seems as if that the documentation hasn’t been able to keep up the pace, as the products and API’s have evolved.
In other situations you won’t find the information where You would expect to find it, a lot of stuff ended up in the knowledge base instead of the documents where the information belongs.
And finally, there are things that are completely undocumented.

Lets take a look at a few examples:

In Understanding the Data Insertion API, in the section about Data Insertion Mechanisms, the documentation says:
“The SiteCatalyst response to each data insertion includes a status message (SUCCESS or FAILURE).”

It’s possible that’s the way things used to be, but it certainly is no more, now you’ll only get a status message in case of success, in case of failure you get no reply at all, and because of this, the accompanying PHP Data Insertion sample kode also ends up being a lot less useful than it could have been.

The section about Visitor Identification completely fails to mention the fact that you can reuse data from the existing visitorID cookie set by Omniture in case you are running a 1. party cookie solution, and thereby making it really easy to mix Data Insertion API tracking with normal Javascript beacon tracking.

Omniture makes frequent updates to the core javascript tracking code, but both major and minor releases are made without any kind of release notes.

Even something as basic as the SiteCatalyst implementation guide contains some obvious goofs, I can’t help thinking: If obvious errors aren’t caught by the editor & technical writers, wonder how many non-obvious errors the documentation contains ?

• The Conversion Classification editor problem has finally been fixed. Even though the fix isn’t mentioned in the release notes.
• The time zone confusion has been solved, or partly solved would probably be a more precise description, it has been fixed when setting up reports in SiteCatalyst, but the issue persists when settings up Data Warehouse reports.