A number alone doesn't tell you very much – you need to compare it with something. And very often you want to compare this year’s number with last year’s.
It is called Year-over-Year (YoY).
In such a comparison, you can for example compare the sales of the current month with the sales for the same month last year. Or – if you want to avoid fluctuations due to good or bad months, you instead look at the accumulated sales in the current year compared the same period last year. Then you look at the Year-to-Date (YTD) number.
But how do you calculate it? How do you write a simple formula that picks out a subset of transactions from last year and compares them to the corresponding transactions from the current year?
If you have Month as dimension and show accumulated numbers in the chart, you don’t need to do anything. The numbers are comparable as they are.
However, if you don’t use Month as dimension, the numbers will no longer be comparable since last year contains transactions from a longer period. You still may want to make the comparison, but with another first dimension and Year as the second.
There are several ways to do this, and they differ in how the reference date is defined. One way is to let the user define an arbitrary reference date – either through a selection or through a variable – and then use this is an advanced Set Analysis expression.
Another, much simpler way is to use the date of the script run as reference date. If your application is refreshed every night, this would mean that the Year-to-Date calculation always is up until today’s date.
Here’s how you do it:
In your Master Calendar you should define flags – Boolean fields – that define whether or not a specific date should be included in the calculation:
The above formula tests whether the date falls before today’s date or not. Note that this flag will be useful also for dates belonging to other years than the current. The value of the flag will be 1 for dates in the beginning of the year irrespective of which year it is.
Then you can use this flag in a simple Set Analysis expression:
Sum( {$<IsInYTD={1}>} Amount )
The Set Analysis expression will pick out the correct dates and thus the correct transactions for the comparison. Further, this expression can be combined with any dimensions.
Flags for a number of different time periods can be created like this, not just Year-to-Date, but also Quarter-to-Date, Month-to-Date, Current Month, Last Month, etc.
It has one essential advantage - the variable vCurrentDate (I prefer to call it vKPIDate) can be set to any date, which allows YoY and other "Period over Period" comparison using any date as a base date.
Yes, it means there is separate expression for each year. Well, in my case it worth the effort...
Very interesting alternative, I always use Set Analysis based on the Max Date selected or possible, but this option allows to compare non continuous years.
Yes Henric, you're right. Each solution has its advantages and drawbacks. I guess it depends on what the business/user needs are, as usual : have the Year as a dimension, or not.
If you have 10 years of data, this can clutter the Chart and you would have to create a new dimension containing the current year and the previous one or go back to the 2-expressions solution.
In the whole picture, the intermediate Calendar-Link-Table is more evolved than what I exposed and is used to do more stuff. For instance, be able to chose between cumulative/single amounts and/or deal with different fact granularities (as you do in your Generic Keys whitepaper).
I was trying to implement this once in my application but realized that in our apps if user selects 2013 YTD should be for 2013 and PYTD for 2012 not 2014 and 2013. then i decided to with sets only.
Hi Brice, I would be very much interested in the full history demo application of your colleague. Sounds like it would solve the overlapping expressions problem in a year-month graph, using a LinkTable technique that sounds similar to the one I used in a pivot table P&L
Very interesting article. I am currently having difficulties achieving a periodic analysis. Would you / anyone else be able to take a look at my thread: http://community.qlik.com/thread/109539