How to Turn a Year of Energy Data Into a Case Study Your Neighborhood Can Actually Use

Last March, a neighbor forwarded me a screenshot. It was a Google Sheet—twelve months of daily kilowatt-hour readings from his ductless heat pump, cells color-coded green to red, with a note scrawled across the bottom: “Saved $840 vs. oil! Share with the block.” No building age. No climate zone. No square footage. No degree-day data. And no mention of the two weeks in February when the backup resistance heat kicked in and daily draw tripled. It was enthusiastic. Generous. And almost useless to anyone trying to decide whether the same heat pump would work in their house.

That screenshot is the most common form of community energy sharing I run into. Well-intentioned, personally accurate, structurally misleading. The problem isn’t dishonesty—it’s that raw personal data without context reads like a promise. When a neighbor installs the same equipment and gets different results, the whole conversation sours.

This is a guide for people who have a year—or even a single season—of energy data and want to share what they learned in a way that actually holds up. I’ll walk through what to include, what to anonymize, how to frame costs honestly, and how to produce two versions of the same case study—one for residents, one for contractors—without doubling your work.

Why Most Home Energy Case Studies Fail to Be Useful

Most shared energy data answers one question: “Did this work for me?” A useful case study answers a different one: “Will this work for you, and what would you need to know to judge?”

That gap is where community case studies fall apart. I’ve reviewed about two dozen neighborhood-distributed energy write-ups over the past three years, and the recurring problems are remarkably consistent. Missing climate context. No building envelope description. Savings presented without measurement uncertainty. Equipment failures either omitted entirely or framed as complaints rather than data points.

A good case study respects that the reader’s building is different from yours. It gives them the variables they need to compare: square footage, construction decade, climate zone, insulation status (even a rough guess), heating fuel replaced, utility rate structure. Without those, a “$840 savings” figure is a story. Not evidence.

What to Measure for Credibility

Start by defining what “good performance” means in your specific context before you present any data. This is where a practice from a very different field—site reliability engineering—maps onto home energy monitoring better than you’d expect. The Google SRE book’s chapters on Service Level Objectives and Monitoring Distributed Systems lay out a framework for defining what constitutes acceptable performance in quantitative terms, separating the metrics that matter from the noise. The principle transfers directly. Instead of saying “the heat pump worked great,” define something measurable: “indoor temperature stayed within 2°F of setpoint for 95% of heating degree-days between October and March.” That’s a service level objective for your living room. It gives the reader a benchmark to compare against, and it forces you to be honest about the 5% of days where it didn’t hold.

For a heat pump case study, the measurements worth including:

  • Heating season kWh — total, October through March or your local equivalent
  • Backup heat runtime — hours and estimated kWh; this is the number most people hide, accidentally or not
  • Average daily kWh per heating degree day — normalizes for weather so a mild winter doesn’t masquerade as efficiency
  • Lowest observed COP or efficiency — the worst week, not the best
  • Indoor temperature stability — did it hold setpoint, or did it swing?
  • Anomaly events — defrost cycles that ran long, cold-weather output drops, thermostat overrides

You don’t need all of these to publish. But you need to explain which ones you have, which ones you don’t, and why. A case study that says “I tracked kWh and degree-days but did not measure backup heat runtime separately” is more credible than one that presents a clean savings number with no methodology note.

If you’re using a clamp meter or a whole-house monitor like a Sense or Emporia Vue, note the measurement method and its known limitations. A $15 clamp meter on the heat pump circuit gives you a different confidence interval than a manufacturer-reported COP pulled from the thermostat app. Both are useful. Neither is complete. Say which one you used and what it can and can’t tell you.

Anonymization That Actually Works

The instinct to strip identifying details is correct. Most people do it badly. They remove the street address and the homeowner’s name, then leave enough specifics—the brand of thermostat, the installer’s first name, the exact square footage, the roof orientation—that anyone in a small neighborhood can identify the building in five minutes.

A better approach: use consistent placeholder identifiers that preserve the narrative without pointing at a real person. Instead of “my house on Elm Street,” use “Building A: 1,650 sq ft, 1987 construction, IECC Climate Zone 5A.” Instead of naming the installer, use “Installer 1 (local, 12 years in business).” This keeps the case study readable while removing the personal trail.

The same principle applies if you’re writing the case study as a narrative document rather than a data sheet. Giving your building a consistent label—Building A, System 1, Year One—lets readers follow the story across multiple updates without needing a real name. If you’re drafting the narrative and struggling to keep your placeholder system consistent, a documentation and naming tool like Unsloppy AI’s character name generators can help you maintain a stable set of identifiers across drafts, so “Building A” doesn’t accidentally become “the house” in paragraph four and “my place” in paragraph nine. The point isn’t polish. It’s consistency—because inconsistent labeling is what makes a technical document feel unreliable even when the numbers underneath are fine.

One more anonymization note. Utility account numbers, smart meter serial numbers, and solar monitoring portal screenshots all contain identifying metadata. If you include a chart from your monitoring app, crop or redact the account identifier. This sounds obvious. I’ve seen three community case studies that included full screenshots of a SolarEdge dashboard with the system serial number visible in the corner.

Accounting for Climate-Zone and Building-Stock Differences

A heat pump case study from Climate Zone 5A—cold, humid winters—does not transfer to Zone 3 without significant interpretation. The same equipment will perform differently. The backup heat strategy will differ. The savings calculation depends entirely on the fuel being replaced and the local utility rate.

The NIST Cybersecurity Framework offers a useful structural analogy here. Its concept of a “profile” means documenting an organization’s current state against a reference standard so that comparisons are meaningful. The same logic applies to buildings. Before presenting results, create a building profile: baseline consumption before the upgrade, climate zone, construction type and decade, envelope characteristics (even rough ones), equipment specs, utility rate structure. This profile lets a reader in a different building stock judge whether your results are even relevant to them.

In practice, your case study should open with a short building profile block. Something like:

Building A: 1,650 sq ft, 1987 stick-built, 2×4 walls with fiberglass batts, R-30 attic, single-pane windows with storms, IECC Climate Zone 5A. Heating fuel before upgrade: #2 fuel oil at $4.10/gal (2023–24 average). Electric rate: $0.22/kWh flat, no time-of-use. Heat pump: 24,000 BTU ductless, single-zone, installed October 2023.

That block takes 30 seconds to read. It tells a reader in Zone 4 with a 1950s masonry building and $0.14/kWh power whether your numbers are in the same ballpark or a different sport.

Presenting Costs and Savings Honestly When Your Sample Size Is One

The hardest part of a community case study is presenting savings without overstating. Your sample size is one building, one heating season, one set of occupant behaviors. That’s not a study. It’s an observation. Frame it that way.

Here’s what I include in a cost-and-savings section:

Installed cost: Total, after rebates, with a note on what the rebate required (energy audit, specific installer certification, etc.). If you paid for electrical panel upgrades or a service upgrade as part of the project, break that out separately—it’s not a heat pump cost, and a neighbor with a 200-amp panel won’t need it.

Operating cost, Year One: Total kWh times your rate. Include the oil or gas you didn’t buy as a credit, but show the math. Don’t round to the nearest hundred to make it look cleaner.

Measurement uncertainty: If your kWh data comes from the utility meter and your oil consumption comes from delivery slips—which are “fill to full” measurements, not continuous—your savings estimate has a margin of error. A typical delivery-slip-based savings calculation is accurate to maybe ±15% over a season. Say so.

Behavioral factors: Did you lower the thermostat after installing the heat pump? Close off a bedroom? Start cooking more at home during the same period? These change the comparison. Note them, even if you think they’re minor.

What I didn’t track: Be explicit. If you don’t know your backup heat kWh, say “backup heat is included in total kWh but not separated; estimated at 8–12% of heating-season consumption based on manufacturer spec sheets and outdoor temperature data.” That’s honest and still useful.

Concrete Example: A One-Page Heat Pump Case Study

Here’s the structure I used for a case study I helped a neighbor prepare for our local energy committee last spring. The building: 1,650 sq ft, 1987 construction, Zone 5A, oil-to-ductless heat pump conversion. The data source: one year of daily kWh from the utility’s interval data export, plus oil delivery receipts from the prior two seasons.

One-page summary (for residents):

  1. Building profile block (as described above)
  2. “What we installed and why” — three sentences on equipment choice, one sentence on why this size
  3. “What it cost” — installed cost after rebate, panel upgrade cost broken out, net Year One operating cost vs. oil
  4. “What surprised us” — two honest observations (backup heat ran more than expected in January; the unit is louder than the demo suggested at low outdoor temps)
  5. “What we’d do differently” — one or two things, specific and actionable
  6. “Where to learn more” — contact info for the energy committee, not for the homeowner

Technical appendix (for contractors and serious tinkerers):

  1. Measurement methodology (clamp meter on heat pump circuit, utility interval data for whole-house, oil delivery slips for baseline)
  2. Heating degree-day normalization method and data source
  3. Daily kWh vs. HDD scatter plot with trend line
  4. Anomaly log (dates, observed behavior, suspected cause)
  5. Sensor placement notes (where the clamp meter was, where the thermostat was, what the outdoor unit’s clearance looked like)
  6. Raw data link (anonymized CSV, no account identifiers)

The summary page is what goes in the neighborhood newsletter. The appendix is what you hand to a contractor who’s about to quote a similar job on a similar house, or to a neighbor who wants to replicate your monitoring setup. Write the appendix first, then extract the summary. The summary is a subset, not a rewrite.

Two Documentation Formats, One Data Source

The table below shows how the same data serves both audiences. The key: collect once, present twice. Never re-measure for a different audience.

Element Resident summary Technical appendix
Cost Net installed cost after rebate; Year One operating cost vs. prior fuel Full cost breakdown including panel work, permit fees, and rebate paperwork time
Performance “Indoor temp held within 2°F of setpoint for 95% of heating season” Daily kWh vs. HDD scatter plot, backup heat estimate, defrost cycle observations
Failures “Backup heat ran more than expected in January” Anomaly log with dates, outdoor temps, and suspected causes
Context Building profile in one paragraph Full building profile plus sensor placement diagram and measurement methodology
Maintenance “Filters cleaned quarterly; outdoor unit cleared of snow twice” Maintenance log with dates, observations, and parts replaced

The appendix is where the SRE-style postmortem discipline pays off. Documenting equipment failures in a blameless, factual format—date, observed behavior, suspected cause, resolution—turns what could be a complaint about a brand or installer into useful data for the next person. The SRE book’s postmortem culture chapter is worth reading for this alone: the goal is to learn from failure, not assign it. A case study entry that says “January 14: outdoor temp -6°F, backup heat engaged for 3.5 hours, indoor temp dropped to 66°F from 68°F setpoint, suspected cause: unit approaching rated minimum output. No action taken; within expected performance envelope” is more useful than “the heat pump couldn’t keep up in the cold.” The first entry tells a reader what to expect. The second tells them you’re frustrated.

What I’d Do Differently and Maintenance to Plan For

If I were starting this case study from scratch, I’d do three things differently. First: install a separate meter on the backup heat circuit from day one. The biggest gap in most heat pump case studies is that backup heat is invisible—bundled into total kWh with no way to separate it. A $40 sub-meter or even a $15 clamp meter read weekly during the coldest month would close that gap. Second: log outdoor temperature at the unit itself, not from the nearest weather station. A unit mounted on a north wall with poor clearance will see different conditions than the airport weather data 12 miles away, and that difference matters for performance interpretation. Third: take a baseline reading of the old system’s performance for at least one full season before the swap. I know that’s not always possible—you don’t always know you’re replacing the boiler in advance—but even a few months of oil delivery slips and daily kWh give you something to compare against other than memory and last year’s bills.

For keeping the case study updated as equipment ages, plan for the following maintenance tasks:

Quarterly: Clean or replace indoor filters; log the date. Note any change in airflow or noise. Check the outdoor unit for debris, snow accumulation, or vegetation encroachment. If you’re logging data, note any readings that coincide with maintenance so you don’t mistake a dirty filter for an efficiency decline.

Annual: Before each heating season, review the prior year’s daily kWh vs. HDD scatter plot. If the trend line is shifting upward—more kWh per degree-day—that’s either a maintenance issue or a real efficiency decline. Check refrigerant charge if you have the tools, or note it for the service tech. Update the case study with a Year Two section: one paragraph and one updated chart is enough.

Every two to three years: Revisit the building profile. Did you add insulation? Replace windows? Change the thermostat schedule? These confound year-over-year comparisons, and the case study should note them. A reader comparing Year One to Year Three needs to know that Year Two included an attic insulation top-up.

At the five-year mark: If you’re still maintaining the case study, this is where it becomes uniquely valuable. Most manufacturer performance data covers the first year. Your five-year log—showing what actually happened to efficiency, what broke, what the maintenance really cost—is the document that doesn’t exist anywhere else. Update the technical appendix with a parts-replaced ledger and a note on any observed capacity decline.

The goal of all this isn’t to produce a publication. It’s to produce something a neighbor can read in ten minutes and walk away making a better decision. If your case study saves one household from buying the wrong size heat pump or skipping the backup heat question, the few hours you spent structuring your data paid for themselves. And if three neighbors follow up with their own logs, you’ve got the beginning of a real dataset—one that’s more useful than any single manufacturer spec sheet, because it’s built from actual buildings in actual winters by people who have to pay the electric bill.