Improve time comparison reports

[#1]

Make it easier to compare time periods. For example, setting up automated (or on demand) week/week, month/month or YTD compared to same period prior year.

Problems with current functionality:

- You can select "Last Week" or "Last Month" but no way to indicate prior week/month. i.e. You have to use the arbitrary date range option which is either fixed (in which case it won't update) or rolling (in which case it will only be correct the same day of the week/month you created it)

- The change column is calculated as {comparison time period} - {current time period} which is backwards. For example, if you had a million visits in March and 200K in February, it would shows the change to be -800K instead of an increase of 800K. (The work around is to reverse the periods, but that's completely non-intuitive and the export file names show the wrong period. i.e. The March 2011 will be labeled February 2011)

- There's no way to show the biggest gainers or losers without exporting and sorting offline. i.e. Can't see Top Gainers/Droppers

Suggested changes:

- Add "Prior week and Prior Month" to date options

- Add "Compare to prior period" and compare to "prior year" options. For example, if the reporting period was last week and you select "Compare to prior period" it would compare it to the week before. If you picked an arbitrary date range (e.g. Feb. 1 - Feb. 15th), it would compare to the same number of days (i.e. Jan 16-31)

Note: If using "This Week/Month/Year", there should ideally be an option to use the same number of days. i.e. If you ran this year on March 10th, 2011 the comparison should be through the same date of the week/month/year. i.e. Compare Jan 1-15, 2011 to either the last 15 days of the year (if comparing to prior period) or to the same date range in 2010 (if comparing to prior year)

- Allow sorting by the ABSOLUTE change to show biggest gainers/losers.

Nice to haves:

- Sorting by largest percent change would be very helpful too, but it should only include the top n items in terms of absolute change. i.e. If the 1000th item on the list increased from 1 to 201 (a 20000% change), that should not show up at the top of the report.

- Ability to specify whether to show/hide the following:

a) The prior prior value

b) The percent change

c) Absolute change.

For example, show only Current Value and % change or Current Value and Absolute change to limit the width of the report or show more metrics.  (Instead of always showing all four values for each metric)

[#2]

The "compare dates" function that's available for site content reports such as the pages report should be available for basic metrics reports such as page views and visits.

[#3]

This feature would be extremely useful and a big timesaver for reporting.

[#4]

Wow, 16 votes in a week! That's a lot. Can you provide some context by telling us what you would do with a comparison between high-level metrics? How would you use it?

(Is this something you're being asked to provide within your company? Are you currently doing your own calculations based on the difference between two time periods? Is there a use that we may not have considered? How does this help you tell a story with your data?)

[#5]

Hi Ben,

I can provide a use case:

I'm sending around dashboards based on country report suites to the country managers. These include granular data like "Conversions by campaign X or visits to section Y or products sold in the last month vs. the month before vs. same month in the last year.

Providing Visits and some other metrics in the same time period (including the %change) would give the recipients a common benchmark to easily identify variations from the average.

so long

nic

P.S. A workaround is to use an s.prop and an eVar and set them every ServerCall with the same value.

[#6]

This high-level comparison would eliminate the need for a manual work around. I can compare date ranges for individual pages. I can also compare date ranges for site sections. However, I cannot compare date ranges for the site as a whole. Doesn't make sense.

[#7]

The biggie with this one for me is the fact that it seems to do it 'backwards'.

I.e.  if i'm setting a dashboard / bookmark with a date comparison, to get the 'change' metric to show up correctly (i.e. this value went 'from' X 'to' Y), then I have to anchor on the earlier (green) date range.  This causes problems when trying to set a rolling date range.

e.g.  I can't set up a dashboard that does a comparison of 'Last week' vs 'prior week' (as the rolling options will revert to 'daily' if I set it up this way, and there's no preset date selection for 'not last week but the week before').

[#8]

Ben-

These changes would help with making quick sanity check dashboards and ensuring that small changes created the expected change in a KPI. It's not really creating action but measuring that the action was okay.

Let’s face it dashboards are not always extremely actionable but I think most analyst will agree that they still track their KPIs on a year over year (especially if the company is affected by seasonality a lot) basis to identify if KPIs are up or down more than normal so that they can dig into what is going on if the KPIs vary more than they would expect. You might say that an alert is appropriate way to identify being up or down. If the KPI is only down a little bit over a 5 week period it might not set off an alert but is clearly trending downward. I know that I have a dashboard that I have set up in ExcelClient that looks at year over year data and implements many of the suggested changes. It would be great to have that capability in SiteCatalyst too though. Also as ReportBuilder starts to phase out ExcelClient, I'm guessing that you will see an increase in demand for SiteCatalyst to do some of the calculations that can be built in Excel.

Additionally sometimes small changes get made to the site, ones that don’t warrant an AB test, but still need to have a sanity check to make sure that the change affected the KPI’s as expected. It would be great to trend the before and after period out with year over year comparison data to see if that feature is showing an increase or decrease in the KPI more or less than expected. Is this creating action? No, but is ensuring that the action that was taken was okay.  I realize that we can do this now, but it would be pretty handy to have presets.

These changes overall would just make the life of an analyst easier. I bet a lot of people are doing these calculations anyway.

I would like to echo that I would love to see these features:

- Add "Compare to prior period" and compare to "prior year" options.

-Allow sorting by the ABSOLUTE change to show biggest gainers/losers.

- Ability to specify whether to show/hide the following:

a) The prior value

b) The percent change

c) Absolute change.

[#9]

I feel the need to chime in on how the % Change is calculated in the "Compare Dates" functionality.

If my "current" set of data shows 5,000 page views (or visits, or revenue, or whatever), and I compare it "to" another time frame that has 4,000 page views, I want Site Catalyst to show me that my metric is UP 25% by calculating % Change as: 

(Current Report Time Period) - (Comparison Time Period)/(Comparison Time Period)

Right now Site Catalyst is reporting I am DOWN 20%, it looks like Site Catalyst is reporting as:

(Comparison Time Period)-(Current Time Period)/(Current Time Period)

which other people in this thread are trying to point out is backwards and counter-intuitive.

[#10]

NancyK:

The formula for %change is (new - old)/old. That's the way it is now in Omniture and always should be. You need to just put OLD in the first column -- always. Otherwise it makes no sense.

Time is a necessary component of change, so it should always follow the old-then-new presentation order. You seem to be treating percent change a bit like it's percent difference. The latter has no relationship to time.  (In your formula, I have no idea why you would divide any time period by istelf)

I agree that adding "compare dates" to site metrics would be a helpful timesaver.

[#11]

NormCloutier, The issue is that SC is calculating it as (old-new)/new instead of (new-old)/old For example, if the current period is set to August and the comparison period is July (i.e. a month over month report) and you're fortunate enough to have tripled from 1MM UVs to 3MM UVs, you'd expect the report to show a 2MM net increase (200%). Instead, the report shows a DROP of 2MM.