A demand response aggregator makes money by pooling many customers' flexible load and offering it to the grid as a single controllable resource. That business only works if the aggregator can see, measure, and settle each participant's consumption accurately. Behind every megawatt of enrolled flexibility sits a stack of meter data from dozens or hundreds of separate accounts.
Participant data arrives through the same channel as any other customer data, which is described in utility data API.
The market is large enough to matter. FERC's 2024 assessment reported that demand response across the seven major U.S. wholesale markets totaled more than 33,000 MW in 2023, roughly 6.5 percent of those markets' peak demand. Aggregators are a growing share of how that capacity reaches the grid.
Aggregation is a data problem before it is a grid problem
FERC Order No. 2222 opened wholesale energy, capacity, and ancillary services markets to distributed energy resource aggregations, and set the aggregation size threshold at no more than 100 kW. That means small commercial and even residential loads can be bundled into a market-eligible resource. FERC defines distributed energy resources broadly, from roughly 1 kW to 10,000 kW, including demand response, storage, and generation.
The consequence is a lot of small accounts. Reaching a meaningful bid size out of 100 kW building blocks means enrolling many participants, and every one of them has a meter, a utility account, and a consumption record that the aggregator needs in order to enroll, baseline, dispatch, and settle.
Where the data is needed
Utility data shows up at every stage of an aggregator's operation:
- Enrollment and eligibility: confirming a prospective participant's typical load and account details before signing them up.
- Baselining: establishing what each account would normally have consumed, so a reduction during an event can be measured against it.
- Settlement: reconciling metered performance after an event to determine payments to participants and revenue from the market.
- Portfolio visibility: tracking aggregate enrolled load across many accounts and utilities in near real time.
Interval data is the raw material
Demand response settlement is an interval-data exercise. Advanced metering makes that possible: the EIA reports that AMI meters record usage at a minimum of hourly intervals and deliver readings to the utility and the customer at least daily, with about 119 million such meters installed in the United States as of 2022. The measurements exist. The aggregator's challenge is collecting them consistently across every participant's utility, in a format that lines up for baselining and settlement.
Because participants sign up individually, an aggregator's portfolio naturally spans many different utilities. Each utility has its own portal and export format, and the aggregator needs the same standardized view across all of them.
Data quality also has a direct effect on revenue and trust. Settlement determines how much the market pays the aggregator and how much each participant is paid in turn, so a gap or an error in the metered record is not just a reporting nuisance, it is a payment that is wrong. Participants who feel their reductions were undercounted do not stay enrolled, and churn quietly erodes the very portfolio the aggregator worked to build. Accurate, complete interval data is what keeps both the market settlement and the participant relationship on solid footing.
Green Button and standardized collection
Green Button gives interval data a consistent structure. Connect My Data (CMD), the automated feed version of the standard, suits aggregation because it authorizes an ongoing flow of a participant's usage from the utility to a third party through an API, rather than a one-time export. Download My Data (DMD) covers the standardized historical export a participant can share directly. Both are built on the NAESB ESPI standard, so data from different utilities arrives in the same shape.
How EZGB fits an aggregator's workflow
EZGB collects the participant-level utility data that demand response programs run on:
- Green Button CMD and DMD: ongoing usage feeds for enrolled participants plus standardized historical exports for baselining.
- Multi-utility collection: one workflow across the many utilities an enrolled portfolio spans, instead of a separate manual process for each.
- Bill digitization: structured data from PDF bills for accounts at utilities that do not offer Green Button, so those participants are not left out.
- API and ongoing feed: connected accounts deliver new interval and billing data on a schedule, which matches the recurring nature of enrollment, dispatch, and settlement.
The point is not to replace an aggregator's dispatch or settlement engine. It is to feed those systems a clean, standardized stream of participant consumption data, so the analytics team is not stuck assembling it from many incompatible utility exports.
This matters more as a program grows. Adding a hundred new participants should be a matter of onboarding a hundred more feeds, not hiring more people to log into more portals. When collection is standardized and automated, the marginal cost of each new account stays low, and the aggregator can pursue the small commercial and residential loads that FERC Order 2222 made eligible without the back-office work becoming the limiting factor. Where a utility does not offer Green Button, digitizing that participant's bills keeps them inside the same standardized dataset rather than excluding them from the program.
Practical steps for scaling an enrolled portfolio
- Standardize on interval data: collect usage at the interval resolution your market's settlement requires, not just monthly totals.
- Automate authorization capture: enrollment is the moment to secure the data consent that keeps a CMD feed flowing.
- Backfill for baselines: pull each participant's history so a baseline exists before the first event.
- Keep collection continuous: settlement runs after every event, so the data feed has to be ongoing, not periodic.
Retailers and brokers work from the same interval history for a different purpose, which is set out in utility data for energy retailers and brokers.
Load aggregation is a numbers business at both ends: the grid pays for measured performance, and participants are paid for measured reductions. Both depend on collecting interval data reliably from many small accounts across many utilities. Get the data layer right and the aggregator can grow its enrolled portfolio without the collection work growing just as fast.
Source: ferc.gov