An energy platform cannot draw its own data. A meter reporting every fifteen minutes produces 35,040 intervals a year, so anything a customer sees on a screen has already been reduced by some function, chosen by somebody, usually by default.
That choice is normally invisible and here it is the whole product. Two of the most consequential numbers in a commercial energy bill survive one reduction and are destroyed by another.
Averaging Deletes the Number That Sets the Bill
Consumption is billed on kilowatt-hours and demand is billed on the highest instantaneous draw. We Energies describes the second one in its own tariff language: the on-peak demand charge "is for the 15-minute interval when you use the most electricity during the on-peak time period" (We Energies, checked 4 September 2026).
The financial weight is not marginal. GlacierGrid's commercial-rate analysis reports that "demand charges run 30 to 50 percent of a multi-site electric bill" and that "they are set by the single highest 15-minute interval in the billing cycle" (GlacierGrid, checked 4 September 2026).
Now put the two facts together. Downsampling by mean is the default in most charting stacks, a mean over a day flattens a fifteen-minute spike into nothing, and the spike was between a third and a half of the invoice.
The Reducer Belongs to the Metric, Not to the Chart
Consumption reduces by sum, demand reduces by max, and power factor reduces by neither. The correct function is a property of what the number means, so it cannot be a rendering option that a chart component picks when it decides how many points fit.
This is the argument for defining the metric once, in a semantic layer, stated more sharply than usual. Elsewhere an inconsistent definition produces two numbers that disagree; here it produces a number that is silently wrong in the customer's favour, which is the kind of error nobody reports.
The practical test is short. Take one meter, plot a month, then plot the same month at daily resolution, and check whether the peak is the same value in both.
The Billing Window Is Not the Chart Window
A dashboard defaults to a period: this month, last 30 days, this quarter. Demand billing does not always respect one.
The same tariff carries a maximum demand charge computed over "the peak 15-minute interval across any time during the current or previous 11 months". Under a ratchet like that, a spike from last winter can still be setting this month's charge, and a chart scoped to the current month cannot show the reader why their bill looks the way it does.
So the window is a property of the tariff the customer is on, which means it is per-account configuration rather than a UI preference. A platform serving several utilities is serving several window rules at once.
What This Changes in the Build
- Store intervals, derive everything else. A pre-aggregated daily table that keeps only means cannot answer a demand question later, and the raw intervals are the only place the answer exists.
- Attach the reducer to the metric definition so the chart, the export, the alert and the API all reduce the same way. A drill path that reveals a different peak than the tile above it is the visible symptom.
- Make the tariff window a stored attribute of the account, not a default range in the component.
- Test with a real spike. Insert one fifteen-minute peak into a month of flat data and confirm it survives every surface: the chart, the export, the scheduled report and the API.
- Decide what happens to estimated reads. We did not test how any specific vendor handles the replacement of an estimated interval with an actual one, so treat that as an open question for your own pipeline rather than a settled one.
The first four have a definite answer in a test environment. The fifth is named here because it is unchecked, not because it is unimportant.
Where to go next
- Real-time dashboard guide: which architectures the word real-time can mean, and what each one costs.
- Headless BI guide: where a metric gets one definition, including its reducer.
- Multi-tenant analytics architecture: the tenant contract underneath a multi-utility deployment.
- Chart types guide: which chart survives high-frequency data and which does not.
- Embedded analytics complete guide: the evaluation path from data audit to pilot.
Put One Spike Through Every Surface
Take a month of interval data with a single peak in it and check the chart, the export, the alert and the API against the same number.
