666 is the Number of the Beast, but it’s also the amount of days (and counting) I’ve been waiting for Omniture Engineering to explain to me how to get my Flash Clickmaps working.
Glad I don’t give up easy 
I’ve been writing about character encoding issues in Omniture products previously, and here is another one. When s_code version H.21.1 was released it became a little more challenging to use the Omniture Javascript debugger, as all our Danish characters gets wrongly encoded in the debugger output. (compare pageName in the screenshots above)
I was hoping for a fix when, s_code H.22 was released recently, but no 
Note: The data does get transmitted correctly to the Omniture data collection servers, this is only a debugger issue.
Update (2010/10/07) Today s_code version H.22.1 was released, and still with no proper ISO-8859-1 charset support for the Omniture Javascript debugger
In Denmark we pay with Danish kroner, our thousands separator is a period, and our weeks start on mondays.
In Omniture SiteCatalyst the weeks work as supposed to and start on mondays.
In Omniture Data Warehouse a week does also start on a monday.
But inside Omniture Discover a week, for some reason, has to start on a sunday, making it impossible to schedule a (correct) weekly delivery of a report.
If you have an idea on how to overcome this one, please let me know !
Update: While Omniture Data Warehouse is capable of generating a one-shot weekly report (Monday-Sunday) it appears to ignore the reportsuite calendar setting when in comes to scheduled weekly reports, in this case Omniture Data Warehouse works pretty much like Omniture Discover
I really really like the new dashboards in SiteCatalyst, it’s a major step forward for the dashboard functionality in the product.
It is however still possible to find peculiarities here and there in the corners of the dashboards.
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.
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 :
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:
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.
