Create a proper Hour dimension for Web (Native already has it)

[#1]

I posted this already, just bringing it back to the top!  Apologies for not following the rules.

We currently have both web and native implementations going to the same report suite.  Web has an "Hour" dimension that takes the following format (10:00 2016-11-13), Native has an "Hour of Day" dimension that takes the following format (23).

For me, the native dimension is preferred because that allows me to compare dates based on the time of day.  The we dimension is limiting because it is tied to a date so you cannot compare metrics.

[#2]

Agreed 100%, @michael-jet. We'll be removing the date so that comparison is possible. 

[#3]

In Ad Hoc, I can select Hour/Day/Month as a dimension but they are always stored as the exact calendar date. If I want to compare the months of two calendar years against each other, it would be useful to have a dimension that only stores the month. That way I can build tables with year in the columns and month in the rows directly in Ad Hoc. For the same reason, having hour and day in the same format woulf be useful.

[#4]

sweet! thanks!  daily/hourly dashboards/workpaces will improve considerably!

[#5]

per a Ben Gaines suggestion a while back:

1. I have the standard time of day eVar (10:23|Friday) which I classify into different time dimensions.

2. I then create segments by hour of day and label them 00, 01, 02, 03...

3. I then drag these segments into an analysis workspace table to compare metrics.

4.  analysis workspace allows you sort segments.

this works well as a good hack.  however, everytime I change a metric, segement, or dimension in the report, the segments will resort highest to lowest. 

as an addon feature - it would be great to be able to lock the components in a table so they do not resort when you change a comparison component.

[#6]

@jer @viclin: This should be available on November 10. Note that this will NOT give you hour as a dimension to be used anywhere. It will let you compare a specific hour against the same hour on another day. For hour as a dimensions, we continue to recommend a Time Parting solution using JavaScript. 

[#7]

Noted, @michael-jet, and thanks for the reminder. This is a good idea, and we will keep an eye on it. The workaround that you noted is still relevant, and if you or anyone else has this use case, we recommend passing hour of day into a prop or eVar so that it aggregates across days at the hour level for now. 

[#8]

The JavaScript work around for this is pretty horrible because I believe the value reported is based on the users system clock.  Therefore if their clock is wrong or in a different time zone you get a different value reported for the same hour.

[#9]

You may be right, @AndyW. I thought the JavaScript solution typically converted the user's time zone into the report suite time zone, but I could be wrong about that. I don't see the "user's clock could be off" as a statistically significant problem; the overwhelming majority of people are likely ot be accurate within a few minutes, no? 

Either way, I don't think any of this takes away from the merit of this idea, which has been commonly requested and up-voted. 

[#10]

Thanks Ben, to be honest the plugin might have got more sophisticated since I last looked at it.  I've never relied on it - Where ever I've gone I've forked out on a VISTA rule as it just felt the more robust way to acheive this.

I guess even if it is trying to adjust for time zones it's still relying on the setting being correct on the machine, I just remember seeing some odd results from this in the past.  Agree in general, as things get aggregated up statistically it's probably not an issue, but there are low volume areas of a site where things don't always work out

[#11]

@AndyW - you are 100% right on the javascript work around issue.  We definitiely see data showing up in time segments that havent happened yet.  We are currently trainig end users to ignore incomplete hours.  again, not ideal.