The Electric Price Analysis is a new app that we launched here at HData. We’ve done a bit of coverage on what it is and how to use it, but in this segment I’ll dive into why we developed it. From the why, we’ll be able to develop a bit of a list of use cases.
The Electric Price Analysis app, or EPAA for short, assesses normalized pricing for electricity along five customer classifications of residential, commercial, industrial, transport, and total retail. This data is reported monthly by the Energy Information Administration as the 861m, while we also include data from the annual 861 report.
We built this application because of a conversation with a current customer. We released an earlier version last year of the EPAA called the “Electric Rates Driver” based on the annual Form 861 data. It quickly gained interest with customers, but it also immediately highlighted weaknesses in the application:
Data is old: EIA 861 data, while a great source, is delayed by a year due to work by the EIA in creating it. It is excellent for historical numbers while not being as useful for decision-making in the present.
No benchmarking capability: prices are great if you see it for an individual company, but even more impactful if you can show that number against a peer group, state average, or regional average. It’s not helpful to have the data merely there, we needed to take the extra step to provide a better visualization capability.
It’s “technically” not rates: I will chalk this up to being new within energy. I created the original driver as a freshman in the industry. A year later, I knew much better and decided that a nomenclature change was due and was guided by our customers on how to do that. It is “price” instead because rates are what customers pay within rate schedules. Our source is not from these rate schedules and is a series of calculated numbers, so “price” is more appropriate.
It’s along these three dimensions that we revamped our driver into the Electric Price Analysis app.
Why is this data from the EIA useful, especially on a monthly basis? Think of this as a proxy for rates. Rate data itself is difficult to access and normalize across companies, let alone display in a way that makes sense for users. The best approximation of this is data from the EIA.
This is accomplished by taking total revenue from customers and dividing by the amount of electricity sold to customers (Revenue / Volume = Price). It’s a simple calculation. However, this may not be what customers actually end up paying on their bill. I’ll use the example from Dominion Energy via Virginia Electric & Power which is my provider for electricity.
This is a snapshot of Dominion’s website where they host all their residential rate schedules. The basic residential rate is about 2.10 cents per kWh for the first 800 kWh for distribution, 3.49 cents for generation per kWh, 0.97 cents for transmission per kWh, plus some other fees. In my bill last month, I paid roughly 18 cents per kWh. This is just one way to pay, looking at Dominion’s website shows there are numerous caveats or special rates depending on the customer’s situation.
However, looking at Dominion’s number in the EPA it came out to 13.1 cents per kWh in March of 2022. Slightly different, but taking into account each schedule would be difficult where a normalized number like from the EIA generally gets you in the ballpark of all the rate schedules. EIA data is great at showing spikes in pricing either due to extraneous events or seasonal adjustments, as is the latter case in the snapshot below with Pacific Gas and Electric. Expand this out to individual customer classes of residential, commercial, industrial, transport, and total retail; you start to get a pretty good holistic picture of a utility’s price position.
The Electric Price Analysis also shows how a single or series of companies perform relative to a peer group, state, or regional average. Energy companies and regulators quickly point out data points that show your utility being “above average or the norm” in metrics. I call this “peeking above the trench;” no one wants to be at the bottom of the trench, but peeking above the trench means you’re likely to get in the scope of a regulator. It’s the nature of a heavily regulated industry like energy. This is why we’ve built the benchmarking feature.
There are two main areas where benchmarking occurs in our application, both on the initial company summary page, and the explicit benchmarking page. In either case, you can select and benchmark a company; the company profile is more pre-baked, while the benchmarking page is customizable.
Given the nature of the energy industry and the EIA data, we have a diverse blend of companies that could either look at this dataset as a series of peers, legitimate competitors, or potential customers. Regulators take a different tack by looking at this data as a way to ensure service is consumer-focused. In any case, the EPAA is central to many analyses that require looking at other utilities.
One use case comes from Texas. Texas is unique among states in that they have a deregulated electricity market. This means that many companies that may have been peers at one time with a designated geographic monopoly now have to compete for customers. This is even more prominent with the introduction of retail energy providers that dominate the Texas electric market. The EPAA captures price data for these utilities from the annual Form 861 under the Part D bundled service type. Monthly data from the 861m can be assessed for the larger utilities and co-ops every month.
A more traditional use case is peer research. Most utilities under a formally regulated monopoly don’t have competitors. Instead, they have a peer group of companies that are similar in structure, service, and customer base that companies and regulators use to benchmark against each other. Much of this use case is further explained (see my “peeking above the trench” above), but it is important to re-emphasize that benchmarking is hugely prominent within regulatory proceedings. Ensuring that you have the latest data with easy benchmarking capabilities means it’s less likely to be caught unaware and answer questions. It also allows you to adjust your peer group more easily. Peer group development, from our current customers' experience, is a laborious process. Once a peer group is set, it isn’t re-set for a few years. Tools like the EPAA allow you to see data more easily relative to other utilities, and adjust the peer group based on new information and trends.
One unique aspect of our version of the data is the effort we put into cleansing historical records and companies. Things change. Companies come and go, are bought out, or are reorganized. That doesn’t mean it should be a headache to account for these changes, and a company switch shouldn’t be the end of the world for a delicate excel spreadsheet. We worked to eliminate this issue specifically.
All historical companies are accounted for within our dataset and mapped to their current iterations. For example: Tesla bought SolarCity in 2016 and amalgamated it into Tesla Energy. Before 2016, it was SolarCity that filed to the EIA and whose data populated the 861 and 861m. We automatically reconciled these names, so all SolarCity data is known as “Tesla (prev. SolarCity).” Another example is Entergy, who renamed many of their companies, such as Arkansas Power & Light, Louisiana Power & Light, etc, into Entergy Arkansas and Entergy Louisiana respectively. We’ve accounted for these name changes within the data.
This is the primary use case for one notable customer who became the primary proponent of revamping the EPAA, and to whom we ultimately gave access for beta-testing. They regularly report 861m stats to the c-suite team. This encompassed comparing themselves against the price positions of other op-cos in their network and region, summarizing rate case information, and peer group development. This information would be updated monthly, meaning they would download the excel files from the EIA and manually add it to their running excel spreadsheets, wasting hours cleaning and merging data. They reached out to us to specifically fix this pain point. We designed many aspects of the application for easy exporting not just as excel files, but visual reports via PDF and PowerPoint that could be included in presentations, thus skipping over many aspects of the manual labor associated with the project.
The use cases mentioned above are not the only ones. We cannot possibly think of every use case, so we’ve built the app to be as flexible as possible, allowing you quick access to this data to garner the most insight you can from it. The question is: what will you find?
Interested in a demo? Request one and chat with our team!