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

How about a way to create a custom classification on the date/time dimensions? We could just make them what we want instead of requiring Adobe to provide what works best for most. Just thinking of another way to provide a solution to this issue.

Is / Has this been worked on?

I'm reading the notes here to get caught up. My company works through watching sales by "Hour" for key volume dates YoY.

I would love a feature within the Custom Date Range functionality that could be part of the Current (Day / Week / Month / Quarter / Year) which include "Hour" to key off of.

In numerous times I've built reporting off of custom Excel lookups to be able to key off "through" Same Hour YoY.

If this was a standard out of the box feature to do Rolling "Hour" Current Date - 365 it would be the perfect solution to being able to true up aggregate sales YoY by Hour for deadline periods and not back my way into it through Excel.

Thanks!

Tom

@jer

Thank you for taking your time to describe your "Clumsy" work-around. 

It can probably buy me some time as the task at hand can be solved using this.

However customers subscribing to a solution with this level of ambitions should not have to use clumsy work-arounds for basic hour of day flow analytics, day of week etc.

Again thank you for responding so fast to my request. Lets keep the communitive alive

@Delfs, Firstly, I agree there are many aspects of Workspace that need to catch up to the times.

As for your specific need, our team has found a clumsy 'work-around':

- Row dimension: Hour

- Column Dimensions: Visits (or any metric) with Time sub-dimensions (eg; Today, Yesterday, Today-7)

                                                                               Visits

Hour                                            Today       |   Yesterday        |    Today-7

00:00 2017-03-13

01:00 2017-03-13

02:00 2017-03-13

03:00 2017-03-13

...

The row titles are a bit misleading since they have the date in it, but if you look in the data columns you'll see it notes the applicable date timestamp for Today/Yesterday/Yesterday-7.

Hopefully this is helpful.

Jeremy

This was changed to 'In progress' over a year ago ?

I have a very hard time defending internally that this is not information out of the box in Adobe Analytics.

There need to be improvements in this area very soon. This has been part of other Web Analytics solutions for more than 5 years.

@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.

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

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. 

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.

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.