Qlik Sense Set Analysis Temporal: Compare with Previous Year Without Breaking Context

There is a question a manager asks in every results meeting that, surprisingly, almost no dashboard answers well: "is this better or worse than last year?". It sounds trivial. It is not. The Qlik Sense Set Analysis temporal is the difference between a dashboard that compares periods with surgical precision and one that breaks the moment someone clicks a filter. In this article I show you how to build year-over-year comparisons that survive any user selection, with no fragile formulas and no duplicating the model.

The uncomfortable data point: 78% of companies have already implemented at least one BI platform, but most still read figures in isolation. And a figure without comparison is a mute figure.

The real problem: comparing over time is where BI falls apart

Think of analytics as navigation. An absolute number —»we sold 340 million this month»— is like knowing your speed without knowing your heading. Useful, but incomplete. Time comparison is the compass: it tells you whether you are moving forward, falling back, or simply riding the same seasonality as always.

Year-over-year (YoY) analysis exists precisely to strip out seasonal distortion. Comparing December against November misleads: December always sells more. Comparing December 2025 against December 2024 reveals the truth about the business. That is why companies with high BI adoption make sound decisions five times faster, and those exploiting real-time analytics report a 29% improvement in decision speed.

The technical problem shows up the moment the user interacts. Many developers calculate the prior year with a formula that depends on the current selection. The manager filters «North Region», and the comparison falls apart because the time logic was tied to the wrong context. That is where Set Analysis comes in: to shield the comparison period from the user's selections.

The solution: time-based Set Analysis in QlikSense

The core idea is simple and powerful: a set defines which records the expression considers, regardless of what the user has selected. Let us go from the basics to the robust version.

Step 1: sales for the selected period and for the prior year

Assume a master calendar with the fields Año, Mes and MesAño. The naive comparison would be to subtract a year by hand. The right way uses dollar-sign expansion to calculate the year dynamically:

// Ventas del período actual (respeta la selección del usuario)
Sum(Ventas)
// Ventas del MISMO período, un año antes
Sum({<Año = {$(=Max(Año)-1)}>} Ventas)

Let us break down the second expression, because every symbol counts:

• { ... } opens the set modifier: it tells QlikSense which universe of data to use.
• <Año = { ... }> overrides the selection on the field Año.
• $(=Max(Año)-1) is the key: the expansion $() is evaluated formerly than the rest. Max(Año) takes the highest year the user has selected and subtracts one. If the user is looking at 2026, this returns 2025.

Step 2: YoY growth that does not break

With the two pieces above, year-over-year growth is a governed division. And here comes the mistake that sinks 60% of these dashboards: dividing by zero when there is no data for the prior period.

// Crecimiento YoY blindado contra división por cero
Sum(Ventas)
/
Sum({<Año = {$(=Max(Año)-1)}>} Ventas)
- 1
// Versión robusta con guarda:
If(
  Sum({<Año = {$(=Max(Año)-1)}>} Ventas) = 0,
  Null(),
  Sum(Ventas)
  / Sum({<Año = {$(=Max(Año)-1)}>} Ventas) - 1
)

The guard with If(... = 0, Null(), ...) returns null instead of an error or an infinity. On an executive dashboard, an empty cell says «not comparable»; a «#DIV/0» says «I do not know what I am doing».

Step 3: comparing the same partial period (the current-month trap)

Here is the subtlety that separates the senior analyst from the beginner. If today is the 24th and you compare the whole current month against the whole month of last year, the result lies: you are comparing 24 days against 30. The fair comparison is month-to-date against month-to-date (MTD vs prior-year MTD).

// En el script del calendario maestro, generamos una bandera:
// DiaDelMes = Day(Fecha)
// Así podemos recortar ambos períodos al mismo día tope.
// Ventas MTD del año anterior, recortadas al día de hoy:
Sum(
  {<
    Año = {$(=Max(Año)-1)},
    DiaDelMes = {"<=$(=Day(Today()))"}
  >} Ventas
)

The modifier DiaDelMes = {"<=$(=Day(Today()))"} uses a numeric search: it includes only the days less than or equal to today. You compare like with like. This detail, which sounds minor, is the difference between a board that trusts the dashboard and one that questions it out loud.

Step 4: year-to-date (YTD) versus prior-year YTD

For the classic «how are we doing this year», we combine a calendar flag with the year offset:

// FlagYTD = 1 para fechas del inicio de año hasta hoy (se calcula en script)
// YTD del año actual:
Sum({<FlagYTD = {1}, Año = {$(=Max(Año))}>} Ventas)
// YTD del año anterior (mismo tramo del calendario):
Sum({<FlagYTD = {1}, Año = {$(=Max(Año)-1)}>} Ventas)

Business impact: from the mute figure to the decision

Let us translate this into what a general manager actually buys. A dashboard with correct time comparison turns every KPI into a story with direction. It is not «we sold 340 million»; it is «we sold 340 million, 12% more than the same stretch last year, but with margins three points lower». That second sentence starts a strategic conversation; the first one only earns a nod.

The return is measurable. Organizations that consolidate data-driven decision making achieve 3.8 times greater ROI and decide five times faster than those relying on instinct and stale monthly reports. Robust time comparison is, quite literally, the mechanism that speeds up that decision: the manager sees the variance instantly, without waiting for someone to build next month's comparative spreadsheet.

And there is a silent saving: every hour an analyst does not spend rebuilding manual comparatives is an hour spent interpreting rather than collecting. In a BI market racing toward 14 billion dollars in 2026, the advantage is not in owning the tool, but in squeezing its time logic.

Common Mistakes and How to Avoid Them

1. Tying the prior year to the selection with Only() or expressions with no Set Analysis. If you calculate the previous period based on what the user filtered, any click breaks it. Fix: always wrap the time offset inside the set modifier with $(=...).

2. Comparing full periods against partial ones. The current month against the full prior month inflates or deflates the variance. Fix: trim both with a day flag (DiaDelMes <= today).

3. Not shielding against division by zero. A new product with no sales last year produces infinities or errors. Fix: the guard If(denominador = 0, Null(), ...).

4. Pushing calendar logic into the expression. The If() statements in the interface destroy performance. Fix: precompute flags (YTD, MTD, MesAño) in the load script.

Best practices from experience

First, govern your time expressions as master measures: define «Prior-Year Sales» and «YoY Growth» once in the library and reuse them. That keeps every developer from inventing their own version of last year, each one slightly different.

Second, document the semantics of the period. «YTD» in finance can mean fiscal year, not calendar year. Make sure the script flag reflects the company's real fiscal year, not the January-to-December default.

Third, test your expressions by filtering aggressively: select a region, a salesperson, a product. If the year-over-year comparison stays coherent under any filter, your Set Analysis is well built. If it breaks, look for the hidden dependency on the selection you left behind. You can go deeper into modeling and analytics techniques at hectorpincheira.com.

Strategic conclusion

The Qlik Sense Set Analysis temporal is not a technical trick: it is the infrastructure that turns data into judgment. A number alone describes; a compared number decides. The difference between the two is four well-placed characters inside a set modifier and a calendar flag calculated in the right place.

The question that opens this article —»better or worse than last year?»— should answer itself on your dashboard, no matter who looks at it or what they filter. If it does not today, you know where to start. And if you lead a data team, this is the conversation worth having this week: do our time comparisons survive the manager's click, or do they collapse on the first selection?