Measurement and verification data for retrofit programs

A retrofit savings claim is only as good as the data behind it. You can install the right measures and still fail to prove the outcome if the baseline is thin, the post-retrofit reads are patchy, or the adjustment inputs (weather, occupancy, production) never got collected. Measurement and verification lives or dies on the data pipeline that sits underneath the methodology. This article is about that pipeline: what to collect, at what granularity, and how to keep it clean. For the methodology itself, see our primer on measurement and verification with IPMVP.

The stakes are rising because retrofit activity has to accelerate. Building retrofit rates are currently less than 1% per year in most major markets, well below the pace climate goals require, while deep retrofits are defined by savings that exceed roughly 30 to 50%. Bigger savings and more projects both raise the bar on proving results.

What M&V data actually has to prove

The International Performance Measurement and Verification Protocol, maintained by the Efficiency Valuation Organization, frames savings as a comparison of two periods. A baseline period captures energy use before the measures, a reporting period captures use after, and the difference is adjusted for anything that changed but was not caused by the retrofit: weather, occupancy, hours of operation, production volume. Savings are never a raw before-minus-after subtraction. They are that subtraction plus a set of documented adjustments, which is why the input data matters as much as the meter reads.

IPMVP offers four options (A, B, C, and D), and each option has a different appetite for data. The U.S. Department of Energy's M&V guidelines apply the same structure to federal projects. Whichever option a program picks, the data pipeline has to supply a defensible baseline, consistent ongoing reads, and the independent variables used for adjustment.

The choice of option is really a choice about where the data comes from. Whole-facility approaches lean on the utility bill and interval meter, so the data problem is completeness and history. System-level approaches lean on sub-meters and device readings, so the data problem is instrumentation and continuous logging. A program that picks an option without checking whether the underlying data can actually be collected at that granularity ends up rewriting its M&V plan halfway through, after the baseline window has already closed.

Building a defensible baseline

The baseline is the part teams most often get wrong, because it is set once and then hard to revisit. A usable baseline usually needs at least twelve continuous months of utility data so it spans a full heating and cooling cycle, with no gaps and no estimated reads standing in for real ones. If the baseline period includes a stretch of estimated bills or a meter change that was never reconciled, every savings number computed against it inherits that error. This is where pulling a full history through a standardized connection pays off: under Ontario's Green Button regulation, for example, most utilities provide up to 24 months of historical billing and interval data, which is enough to build and sanity-check a baseline before the first measure is installed.

Normalization inputs are data, not an afterthought

The adjustment step needs its own inputs, and they have to be captured on the same clock as the energy data. Weather is the big one: comparing a mild reporting period against a harsh baseline will overstate savings unless you normalize with degree days, which we cover in weather normalization for energy analysis. Occupancy, operating hours, and production are the others. If a facility ran two shifts during the baseline and one during the reporting period, unadjusted savings are fiction. A pipeline that only pulls kilowatt-hours and dollars will leave the M&V engineer chasing these variables by email every reporting cycle.

Granularity: monthly bills versus interval data

Monthly bills are enough for whole-facility comparisons, but they hide load shape. Interval data (typically readings every 15 minutes to an hour) lets you separate baseload from peak, confirm that a measure changed the profile it was supposed to, and catch a failed control before it quietly erodes savings. Many retrofit programs run both: monthly billing for the headline savings number and interval data for diagnostics. Our comparison of interval data versus monthly bills covers when each is worth the effort.

Document the non-routine events

The adjustments most likely to be challenged are the non-routine ones: a tenant moved out, a wing was closed for renovation, a new server room came online, a process line was added. These are not captured by weather normalization and they are not visible in the meter data alone, yet they can swing a savings number more than the retrofit did. A disciplined M&V pipeline records these events with dates alongside the energy data, so the analyst can adjust for them transparently rather than discovering an unexplained jump months later. When several buildings are in a program, keeping that event log next to the reads is the only practical way to keep every project's story straight.

Uncertainty follows from the data, not the spreadsheet

A savings figure without a sense of its uncertainty invites dispute. The uncertainty in an M&V result comes largely from the data: how many baseline points there are, how well the model fits the independent variables, and how much scatter the readings carry. Gaps, estimated reads, and inconsistent units all widen the error band, sometimes to the point where a modest savings claim is statistically indistinguishable from zero. That is the practical reason clean, complete, continuous data is not a nicety in M&V. It is what lets a program report savings with a confidence interval it can stand behind, and it is why the collection and validation steps deserve as much attention as the analysis.

Keeping the data clean over the reporting period

M&V is not a one-time pull. A savings claim usually has to hold across a reporting period that runs for a year or more, which means the ongoing reads need the same validation as the baseline: gaps flagged, estimated reads marked, meter swaps reconciled, units kept consistent across commodities. When several buildings enter a program at once, the data quality problem compounds. Our note on utility data quality for energy programs goes deeper on the checks that keep a portfolio of projects defensible.

The practical goal is boring on purpose: by the time an M&V engineer opens the savings model, the baseline, the reporting-period reads, and the adjustment variables are already collected, normalized, and validated. The engineer spends their time on the analysis and the savings narrative, not on assembling and correcting spreadsheets.