A dashboard is naturally built around a single survey - one set of questions, one set of respondents, one instance of data. A tracked metric doesn't live inside a single survey, though; it lives across several, one per wave, each a separate survey instance run at a different point in time. That mismatch is easy to overlook right up until the second wave of a quarterly tracker comes in and there's no obvious built-in place for a wave-over-wave trend line to appear, since each dashboard is scoped to the survey it was built from, not automatically aware of the surveys that came before or after it. Worth being upfront about: there's no native mechanism to compare a metric across separate survey instances on the same dashboard - what follows are practical, honest workarounds, not a hidden feature to enable.
Table of Contents¶
- Why This Gap Exists
- Workaround One: A Manual Reference Point in the Metric's Context
- Workaround Two: A Standing Tracking Document Outside the Dashboard
- Workaround Three: One Long-Running Survey Instead of Separate Waves
- When a Workaround Costs More Than It Saves
- A Worked Example
- FAQ
Why This Gap Exists¶
Each dashboard connects to one specific survey's data, and each new wave of a tracked survey - a new quarter's version of the same questions - is a separate survey instance from the platform's point of view, even if the questions and the underlying intent are identical wave to wave. A dashboard built from this quarter's survey has no automatic awareness of last quarter's survey, since they're two distinct instances rather than two time slices of one continuous dataset. This is a genuine limitation worth knowing about before planning a reporting workflow around a dashboard doing wave-over-wave comparison automatically - it doesn't, and building a workflow around an assumption that it does leads to a frustrating surprise the first time a second wave comes in.
Workaround One: A Manual Reference Point in the Metric's Context¶
The lightest-weight workaround is manual, and it works well for a dashboard that's presented live by a person rather than consumed as a static artifact: keep last wave's key figures in a simple external note - a spreadsheet, a doc, even a saved screenshot - and manually add the comparison as context when presenting this wave's dashboard, either verbally or as a text widget stating "up 4 points from last quarter" alongside the current number. This doesn't automate anything, but it's fast, requires no ongoing technical setup, and is genuinely sufficient for a metric tracked quarterly or less often, where the manual effort of noting one or two comparison figures each wave is small relative to how infrequently it needs to happen.
Workaround Two: A Standing Tracking Document Outside the Dashboard¶
For a metric tracked more frequently, or for a team that wants a genuine multi-wave trend line rather than a single wave-over-wave comparison note, maintaining a simple external tracking spreadsheet - one row per wave, with the key metrics pulled manually from each wave's dashboard - is a more durable workaround than relying on memory or scattered notes. This external document becomes the actual source for any trend chart spanning multiple waves, built in a general-purpose spreadsheet or chart tool rather than inside the survey dashboard itself, with each new wave's numbers added to the running log as they come in. It's more setup than the first workaround, and it pays off specifically once you're tracking more than two or three waves, where a genuine trend line becomes more valuable than a single most-recent comparison point.
Workaround Three: One Long-Running Survey Instead of Separate Waves¶
For some tracking use cases, the cleanest fix is avoiding the multi-instance problem entirely by using a single, ongoing survey instance rather than launching a fresh one each wave - collecting responses continuously (or reopening and relaunching the same survey instance each period, if your workflow allows it) rather than creating a distinct new survey per quarter. This keeps all the data within one dashboard's native scope, which means filtering by date range - this quarter's responses versus last quarter's - substitutes for cross-survey comparison entirely, since it's really just one dataset viewed through different date windows rather than genuinely separate instances needing to be stitched together. This isn't the right fit for every tracked metric - some genuinely benefit from a fresh, clean survey each wave, particularly if question wording or structure needs to change between waves - but where it's viable, it sidesteps the whole workaround problem rather than managing around it.
When a Workaround Costs More Than It Saves¶
Any of these workarounds is worth weighing against a simple question: is the manual effort of maintaining an external comparison, wave after wave, actually less than the cost of not having the comparison at all. For a metric tracked once or twice a year, with a small number of headline figures to carry forward, a manual note each wave is trivial. For a metric tracked monthly, across many segments, with a genuine need for a real multi-wave trend visualization, a spreadsheet-based external tracker starts to become real, recurring maintenance work - worth doing deliberately, with someone actually responsible for keeping it updated, rather than assumed to happen automatically as a side effect of building each wave's dashboard.
A Worked Example¶
An HR team runs a quarterly engagement survey and wants to show a four-quarter trend at each review. Rather than trying to force a comparison inside a single dashboard, the team keeps a simple running spreadsheet with one row per quarter, recording the five or six headline metrics from each quarter's dashboard as soon as it's finalized. Ahead of each quarterly review, someone builds a simple trend chart directly from that spreadsheet - outside the survey platform entirely - and adds it as the opening slide before diving into the current quarter's live dashboard for the detailed, current-period breakdown. The combination gives the review both the multi-quarter trend the audience actually wants to see first and the detailed current-quarter drill-down the live dashboard is built to provide, without needing the dashboard itself to do something it isn't built to do.
FAQ¶
Is there any way to get an automatic wave-over-wave chart directly on a dashboard?
Not natively - each dashboard is scoped to a single survey instance, so a genuine cross-wave trend needs to be built and maintained outside that instance, using one of the workarounds in this guide.
Which workaround should I use for a metric tracked quarterly with just two or three waves so far?
The lightest option - a manual reference note or context line comparing this wave to the last - is usually sufficient at that volume. A standing external tracker becomes more worthwhile once you have enough waves that a genuine trend line adds real value over a single comparison point.
Does using one long-running survey instead of separate waves have downsides?
It can make question wording changes harder to introduce cleanly mid-tracking, and it blurs a natural wave-to-wave boundary that some teams find useful for framing distinct reporting periods. It's a good fit specifically when the questions genuinely don't need to change wave to wave.
Should the external tracking document be treated as the source of truth?
For any multi-wave trend specifically, yes - since no single dashboard holds the full multi-wave picture natively, the external tracker (spreadsheet or otherwise) is the actual authoritative record of the trend, and it's worth someone being explicitly responsible for keeping it current.
For the underlying reasoning behind trustworthy wave-over-wave comparison, see Tracking a Metric Over Time Without Mistaking Noise for a Trend and Benchmarking Your Survey Results the Right Way.