Savings Analysis

Use Savings Analysis to compare energy scenarios and project future costs, usage, rates, and savings for an account.

The Savings Analysis endpoint projects the potential future costs and savings of a change in energy use or rates. You can use it to model solar installation, tariff switching, storage, and other energy scenarios. For the full analysis workflow, see Analysis APIs.

The Savings Analysis calculator is similar to the Account Cost Calculator, but it compares at least two bills, called scenarios. It returns the costs for each scenario and the differences between them.

Savings Analysis Request Structure

Review common propertyInputs patterns for profiles, typical baselines, solar, and storage.

Helpful Request Templates

Start from templates for Quick Switch, Full Switch, and Storage-in-Switch workflows.

Savings Analysis History

Retrieve previously run Savings Analyses from the related history endpoints.

Passing in your property inputs

Like the Cost Calculator, the Savings Analysis endpoint accepts propertyInputs for calculation inputs. Use profileId or providerProfileId to provide usage or solar production data. Set tariffs on the account or pass them explicitly with masterTariffId.

You can also pass assumptions, such as expected future rate inflation, through propertyInputs. Each property must specify the scenario or scenarios it applies to. For example, to use the same profileId for both the before and after scenarios, set "scenarios": "before,after".

A scenario represents one service or cost stream that the customer pays for, such as utility electricity or a solar lease/PPA. Each scenario needs a tariff or rate plan. A Savings Analysis needs at least two scenarios so there is something to compare.

Getting the results: data series

The Savings Analysis response includes data points, called SeriesMeasure objects, in the seriesData property. Example series include first-year monthly values before solar, annual solar values over the project lifetime, and total savings over the project lifetime.

Each series has a time granularity, such as monthly or annual, a time frame, such as first year or full project lifetime, and a scenario formula, such as before, after, solar, or savings. The series property contains metadata about each returned series. The seriesData property contains the actual data points. Each data point includes cost, quantity, and rate values for a time interval.

Data definitions

Savings Analysis request

The Savings Analysis endpoint is flexible. You can change the account tariff in the after scenario, change annual electricity rate inflation, model a different solar power system, or add storage inputs.

Request parameters are grouped into three categories:

Top-level parameters set the stage for the entire analysis.
Property inputs define scenario-specific inputs, such as profiles, tariffs, project duration, and assumptions.
Rate inputs define custom rates to apply to the analysis.

Before using those parameters, understand how scenarios work.

Scenarios: Building blocks of Savings Analysis

At the most basic level, savings is the difference between what a customer would have paid without the project and what the customer pays after the project. To capture this, the Savings Analysis endpoint uses scenarios.

For a standard solar analysis, the core scenarios are:

The before scenario represents how much the customer would pay to the utility without solar.
The solar scenario represents the cost of solar energy only.
The after scenario represents how much the customer pays to the utility after solar is installed.

These scenarios are defined independently. Specifying an input, such as a rate escalator, for one scenario does not apply it to the other scenarios unless you include those scenarios in the scenarios field.

In a typical solar Savings Analysis, the customer's pre-solar electricity consumption is used in both the before and after scenarios, while solar production is specified in both the solar and after scenarios.

Top-level parameters

Top-level parameters set the stage for the entire analysis. At a minimum, provide fromDateTime and either accountId or providerAccountId. All other parameters are optional.

Name	Type	Description
accountId	String	The Arcadia-generated UUID of the account for which you want to conduct the savings analysis.
providerAccountId	String	The alternative user-defined ID of the account for which you want to conduct the savings analysis.
fromDateTime	DateTime	Indicates the starting point of your analysis and should align with when you expect the system to interconnect (typically 1-6 months in the future). This setting affects the version of the account's tariffs that are in effect during the first year of the analysis. The `fromDateTime` must be set to the first day of the month to return 12 monthly values for the first-year series.
~~toDateTime~~	DateTime	Deprecated. To make the analysis span 25 years instead of the default of 20, use projectDuration, not `toDateTime`.
propertyInputs	Array of PropertyData	The parameters for the analysis. There are many different options available. We discuss them below.
rateInputs	Array of TariffRate	You can use this to define lease rates, PPA rates, special tax rates, or user-adjusted rates. Make sure to set the `scenario` property so that your rate is applied correctly.
populateCosts	Boolean	If set to `true`, your results will contain an even more detailed breakdown of the first year of results for this calculation.
tariffEffectiveOn	DateTime	Use one specified version of a tariff for the calculation. For example, if you specify the 2016-01-01 version of PG&E's E-1 tariff, calculations for 2013, 2015, or 2016 use rate data from only that tariff version. Optional.
autoBaseline	Boolean	Use this field to disable intelligent baselining in the unusual case where you do not want it. Defaults to `true`. Optional.
useIntelligentBaselining	Boolean	This field works in conjunction with `autoBaseline` (above) and determines how to interpolate and extrapolate usage data when that is set to true. Read intelligent baselining for details.

Property inputs

Use propertyInputs to customize the analysis. These inputs can change tariffs, usage data, solar production, project duration, rate inflation, and other scenario assumptions.

Each input can apply to more than one scenario, so set the scenarios property carefully.

Name	PropertyData Type	Scenarios	Description
profileId	String	before, after, solar	The ID of the usage profile that you want to use for this scenario. Can be set for `before`, `solar`, and `after`. If nothing is set for `before` or `after`, the default behavior is to use the account's default profile. You can add more than one profile per scenario and combine them using the `operator` property on this input. The `operator` can be `+` or `-`, which indicates whether you want to add or subtract the indicated profile's values from the other ones for that scenario.
providerProfileId	String	before, after, solar	The alternative user-defined ID for the profile that you want to add to the analysis.
baselineType	String	before, after, solar	If you want to use a typical baseline for the usage in a particular scenario, set a data value of `typicalElectricity` for this property. For solar, use `typicalSolarPv`. You can use this if you don't have usage or solar data for the account and you just want to do a quick switch analysis.
masterTariffId	Integer	before, after	The tariff that will be used for this scenario. If this is not set, it defaults to whatever is currently set as the `masterTariffId` on the account.
rateInflation	Decimal	before, after, solar	The rate at which the cost of energy rises for every year of the analysis. Use a `dataValue` of `3.5` to use 3.5%, for example.
solarDegradation	Decimal	solar, after	The rate at which energy production from the solar system degrades year over year. If your degradation rate is 0.5% per year, use a value of `0.5` here.
projectDuration	Integer	before, after, solar	Lifetime of the project in years. This can range from 1 to 25. Defaults to `20` when omitted.
solarPvLoadOffset	Integer	solar, after	If you don't have an existing solar profile, you can use `solarPvLoadOffset` to specify a percentage of the customer's existing load to offset with a PV system. By default (if you just set `baselineType` to `SOLAR_PV` for the `solar` scenario), this will be set to 80%. If you want to specify the solar production in kWh rather than as a percentage of the load, you can do so by entering annual solar production as the `dataValue` and "kWh" as the `unit`.
loadOffset	Integer	solar, after	An alternative name for `solarPvLoadOffset`.
loadSize	Integer	before, after	If you don't have an existing usage profile, you use this parameter in conjunction with a `baselineType` of `TYPICAL` to size your customer's annual usage. It will use a typical profile from our database and scale it up or down to the annual value that you specify.

Rate inputs

Rate inputs are a collection of TariffRate objects with one additional property: scenarios. Use scenarios to specify which scenario the custom rate applies to. You can use rate inputs to set a first-year PPA or lease rate, a custom tax rate, or another user-adjusted rate.

Savings Analysis response

The Savings Analysis response describes the results of the calculation, including summaries, scenarios, series metadata, and series data.

Summary fields

The Savings Analysis summary contains a number of fields that describe the basic results for a Savings Analysis. These fields include things like preTotalCost, postTotalKWh, and netAvoidedCost.

Pre-solar summary fields

These fields summarize values for how things would have been in the first year without solar.

Name	Description
preTotalCost	The first year, pre-solar cost of energy. It is the highest of the `preTotalNonMinCost`, `preTotalMinCost` and `preTotalNonBypassableCost`.
preTotalKWh	The first year, pre-solar amount of energy used.
preTotalKWhCost	The first year, pre-solar cost of kWh only. This does not include minimum costs.
preTotalKWhRate	The first year, pre-solar rate for kWh only. This does not include minimum costs.
preTotalMinCost	The customer's minimum costs for the first year (if applicable).
preTotalNonBypassableCost	The customer's non-bypassable costs for the first year.
preTotalNonMinCost	The first-year bill for the customer. Will almost always be the same as `preTotalCost`.
preTotalRate	Pre-solar blended kWh rate. Equal to (`preTotalCost`/`preTotalKWh`)

Post-solar summary fields

These fields represent the first year after solar intervention. Not all of these values will show up in every situation. For example, netAvoidedRate won't show up if you haven't included a solar profile, as there's no "avoided" rate to calculate. For a standard solar analysis, though, these values will always be available.

Name	Description
postTotalCost	The first year, post-solar cost of energy from the utility only (i.e., not including the cost of solar). It is the highest of the `postTotalNonMinCost`, `postTotalMinCost`, `postTotalNonBypassableCost`, and 0.
postTotalKWh	The amount of energy that is still consumed from the utility in the first year after solar intervention.
postTotalKWhCost	The first-year post-solar cost for kWh only. This does not include minimum costs.
postTotalKWhRate	The first-year post-solar rate for energy from the utility only. This is equal to (`postTotalKWhCost`/`postTotalKWh`).
postTotalMinCost	The minimum bill for the first year.
postTotalNonBypassableCost	The minimum bill for the first year, calculated using non-bypassable Charges (NBCs). Non-bypassable charges cannot be offset by other NEM credits, creating a second minimum charge for solar customers.
postTotalNonMinCost	The customer's new utility bill (not accounting for minimum charges).
postTotalRate	The post-solar blended kWh rate for energy that is still purchased from the utility. This is equal to (`postTotalCost`/`postTotalKWh`).

"Net" summary fields

Net fields represent the difference between pre-solar and post-solar values.

Name	Description
netAvoidedCost	The cost of energy that is no longer purchased from the utility in the first year post-solar. This is equal to (`preTotalCost` - `postTotalCost`).
netAvoidedCostPctOffset	The percentage of the first-year cost from the utility offset by solar. This is equal to (`netAvoidedCost`/`preTotalCost`).
netAvoidedKWh	The amount of kWh generated by the solar power system. This is equal to (`preTotalkWh` - `postTotalkWh`).
netAvoidedKWhPctOffset	The percentage of first-year kWh offset by solar. This is equal to (`netAvoidedkWh`/`preTotalkWh`).
netAvoidedRate	The average value of an avoided kWh. This is equal to (`netAvoidedCost`/`netAvoidedKWh`)

Lifetime summary fields

Lifetime values represent total cost summaries for the project's duration.

Name	Description
lifetimeSolarCost	The cost of solar energy over the life of the project.
lifeTimeUtilityAvoidedRate	Avoided cost of power (ACP) over the life of the project.
lifetimeWithoutCost	The lifetime cost of energy without solar system intervention.
lifetimeAvoidedCost	Customer savings over the life of the project. This is equal to (`lifetimeWithoutCost` - [`lifetimeSolarCost` + `lifeTimeUtilityAfterCost`]).
lifeTimeUtilityAfterCost	The amount still paid to the utility after solar over the life of the project.

Account Analysis

The Account Savings Analysis call returns an AccountAnalysis object when you run a calculation. It has the following data structure.

Name	Type	Description
designId	String	This is `null` for Account Analysis (so ignore it). It is used in Project Analysis (different endpoint).
dataStatus	Integer	Represents the status of the underlying data (profiles) that the analysis was run on. `2` indicates that all the underlying data is up to date. `1` means it's still processing, and you should re-run the analysis once the profile is done (this is very unusual).
scenarios	Array of Scenario	Each scenario in the analysis. For a solar PV analysis, there will be a "before" for without solar electric bill, "after" for the with solar electric bill, "solar" for the solar system, and "savings" for net savings with solar (before - after + solar). See below for the data structure of the `Scenario` object.
series	Array of Series	A list of `Series` objects, each one describing the data points (`SeriesMeasure`) it contains. The `Series` object is documented in further detail below.
seriesData	Array list of Series Measures	This list holds the actual data points, each of type `SeriesMeasure` (described below). Each ties to a particular series (above) using a unique integer value. Each `SeriesMeasure` holds a rate, quantity, and cost.
seriesCosts	Map of Integer to Calculated Cost	If `populateCosts` is set to `true`, this field is populated with `CalculatedCost` objects (CCIs) corresponding to each series. They are indexed by `seriesId`, which you can find from the `series` collection.

Scenario

A Savings Analysis has at least two Scenario objects in its response. A solar analysis typically has four: before, after, solar, and savings. You only need to send this object in a request when running a generic analysis type. Scenario has the following data structure.

Name	Type	Description
id	String	This is not used for Account Analysis (it's used for Project Analysis). This will be `null`, please ignore it.
name	String	The unique name (key) of this scenario. Solar PV has "before", "after", "solar", and "savings".
serviceType	String of ServiceType	The type of service for this scenario. This will be either `"ELECTRICITY"` or `"SOLAR_PV"`.
inputs	List of PropertyData	The important inputs that were used in this scenario's calculation. This defines the usage data profiles, the rate plan and plan arguments, and other parameters for the calculation.
rates	List of TariffRate	Used to pass the site's specific contracted electricity rates (only needed if they are in a deregulated market), their tax rates (if you want us to calculate post-tax numbers), and possibly their solar PPA or lease rate.

Series

The Series object identifies the scenario, time frame, and granularity of each data series in the results. It has the following data structure.

Name	Type	Description
seriesId	Integer	All the series measures (below) for this series have this identifier. It is a unique integer within the response. You should not assume the integer will be the same for the same series between responses. Instead, look at the series' `period`, `duration`, and `scenario` fields to find the `seriesId` you need.
fromDateTime	DateTime	The start date of the series.
toDateTime	DateTime	The end date of the series.
scenario	String	Mathematical formula of scenarios that produced this series.
displayLabel	String	The display label for this series.
seriesPeriod	String	The series period/term. Possible values are: `"YEAR"`, `"MONTH"`, `"DAY"`, and `"HOUR"`.
seriesDuration	Integer	The duration of the series with respect to the `seriesPeriod`. e.g. if this is 20 and `seriesPeriod` is `"YEAR"`, this series' data covers 20 years.
designId	String	Not populated for Account Analysis.
key	String	For future use.
rate	Decimal	Average rate over the entire duration of this series.
qty	Decimal	Total quantity over the entire duration of this series.
cost	Decimal	Total cost over the entire duration of this series.

There are several common series that you'll get back in most Savings Analysis calls:

Before Solar Utility
After Solar Utility
Solar
Total Savings

Each series is returned with three granularities: monthly for the first year, annual for the life of the project, and total over the life of the project. For a standard solar Savings Analysis, this produces twelve Series items.

SeriesMeasure

The SeriesMeasure object holds one data point, such as before-solar electricity for one month in the first year. It has the following data structure.

Name	Type	Description
seriesId	Integer	The identifier of the series that this data point belongs to (See Series above).
fromDateTime	DateTime	Start date and time of this data point.
toDateTime	DateTime	End date and time of this data point.
rate	Decimal	The average rate of charge for this timeframe is denominated in the major currency applicable. For instance, in USD, this would be 0.12 for 12 cents (¢).
qty	Decimal	Quantity for this timeframe (usage or production, etc., typically in kWh).
cost	Decimal	Cost (or savings) of this timeframe

Put it all together

This abbreviated response example shows the main response components described above.

{
  "status": "success",
   "count": 1,
   "type": "AccountAnalysis",
   "results": [
      {
         "designId": null,
         "dataStatus": 2,
         "summary": {
            "preTotalCost": 1552.74,
            "preTotalKWh": 7079.3096,
            "netAvoidedCost": 1043.46,
            "postTotalCost": 509.28,
            "lifetimeSolarCost": 39564.18,
            "lifeTimeUtilityAvoidedRate": 0.411,
            "lifetimeWithoutCost": 43910.76,
            "postTotalMinCost": 53.9616,
            "postTotalNonBypassableCost": 0,
            "netAvoidedCostPctOffset": 0.672,
            "netAvoidedKWh": 3792.5,
            "netAvoidedKWhPctOffset": 0.5357,
            "postTotalKWh": 3286.8096,
            "preTotalRate": 0.21933495,
            "postTotalNonMinCost": 509.27982,
            "lifetimeAvoidedCost": -14342.92,
            "postTotalRate": 0.15494661,
            "netAvoidedRate": 0.275138,
            "lifeTimeUtilityAfterCost": 16816.861,
            "preTotalNonMinCost": 1552.7365,
            "preTotalMinCost": 53.9616
            "preTotalNonBypassableCost": 0,
         },
         "scenarios": [
            {
               "id": null,
               "name": "before",
               "serviceType": "ELECTRICITY",
               "inputs": [
                  {
                     "keyName": "lseId",
                     "displayName": "Pacific Gas & Electric Co",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "734",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "masterTariffId",
                     "displayName": "Residential",
                     "dataType": "INTEGER",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "522",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "profileId",
                     "displayName": "2012 CA Electricity Residential Profile",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "5350801df203671e925d49c8",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "territoryId",
                     "displayName": "Territory",
                     "description": "Territory where tariff is operational",
                     "dataType": "INTEGER",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "3538",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "rateInflation",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "3.5",
                     "scenarios": "before,after"
                  },
                  {
                     "keyName": "tariffCode",
                     "displayName": "E-1",
                     "dataType": "STRING",
                     "fromDateTime": "2013-06-01T00:00:00+00:00",
                     "toDateTime": "2014-06-01T00:00:00+00:00",
                     "dataValue": "E-1",
                     "scenarios": "before,after"
                  }
               ]
            },

            // Inputs for other scenarios omitted.

         "series": [
            {
               "seriesId": 1,
               "fromDateTime": "2013-06-01T00:00:00-07:00",
               "toDateTime": "2014-06-01T00:00:00-07:00",
               "scenario": "before",
               "displayLabel": "Before Solar Utility (Mo/Year 1)",
               "seriesPeriod": "MONTH",
               "seriesDuration": 12,
               "designId": null,
               "key": null,
               "rate": 0.21933495,
               "qty": 7079.3096,
               "cost": 1552.74
            },

            // Metadata for other series omitted.

         ],
         "seriesData": [
            {
               "seriesId": 1,
               "fromDateTime": "2013-06-01T00:00:00-07:00",
               "toDateTime": "2013-07-01T00:00:00-07:00",
               "rate": 0.21295582,
               "qty": 499.97726,
               "cost": 106.47307
            },

            // Additional series data omitted.
         ]
      }
   ]
}

Run Savings Analysis

Send a POST request to run a Savings Analysis. The Solar PV analysis type calculates the savings from a customer going solar. A standard Solar PV analysis uses these scenarios:

before: the future electricity bill without solar, sometimes called the "do nothing" scenario.
solar: what the solar system produces and costs.
after: electricity costs and usage after the system is installed.
savings: net savings, calculated from before - after + solar.

Resource URL

POST /rest/v1/accounts/analysis

Request parameters

Along with the required authentication parameters, send the Savings Analysis request as JSON in the request body. This example shows the basic structure:

{
  "providerAccountId" : "api-eg-01",
  "fromDateTime" : "2013-06-01",
  "propertyInputs" : [ {
    "scenarios" : "before",
    "keyName" : "masterTariffId",
    "dataValue" : "522"
  }, {
    "scenarios" : "after",
    "keyName" : "masterTariffId",
    "dataValue" : "522"
  }, {
    "scenarios" : "before,after",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "1.5"
  }, {
    "scenarios" : "after, solar",
    "keyName" : "providerProfileId",
    "dataValue" : "PVWATTS_RESIDENTIAL_CA_2012"
  } ],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "FIXED_PRICE",
    "rateBands" : [ {
      "rateAmount" : 137.05
    } ]
  } ]
}

For all available parameters and options, see Savings Analysis Request. When calculating solar savings for a customer, pass these scenarios:

the before electricity scenario, which represents what the customer pays for electricity without solar.
the solar scenario, which represents how much the solar system produces and what it costs, such as a PPA or lease.
the after electricity scenario, which represents the customer's utility bill after solar is installed.

Example: Solar PV analysis for lease

This example uses providerAccountId to identify the account. Because the request does not explicitly pass the account tariff or default electricity profile, Switch uses the current tariff and default electricity profile for the account. The tariff is used for both the before and after scenarios.

The other parameters are passed through property and rate inputs:

rateInflation for before sets the expected future electricity rate increase. 3.5 means 3.5%.
solarDegradation for after,solar sets how much less energy the solar system produces each year. 0.5 means 0.5%.
providerProfileId for after,solar identifies the solar model profile. You can use profileId instead.
A FIXED_PRICE rate input for solar models a solar lease. In this example, the lease is $295, and the rateInflation value for solar sets a 1.9% annual lease escalator.

{
  "providerAccountId" : "api-example-01",
  "fromDateTime" : "2013-02-01",
  "propertyInputs" : [ {
    "scenarios" : "before",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "0.5"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-1"
  } ],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "FIXED_PRICE",
    "rateBands" : [ {
      "rateAmount" : 295.00
    } ]
  } ]
}

Example: Multi-array Solar PV analysis for PPA with rate switch

This example is similar to the lease example, but it uses a 15.5¢ solar PPA instead of a lease by passing a CONSUMPTION_BASED rate input. It also switches the after scenario to a more solar-friendly tariff and passes two solar model profiles, such as one for a south-facing roof and one for a west-facing roof.

{
  "providerAccountId" : "api-example-01",
  "fromDateTime" : "2013-02-01",
  "propertyInputs" : [ {
    "scenarios" : "after",
    "keyName" : "masterTariffId",
    "dataValue" : "3250619"
  }, {
    "scenarios" : "before",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "0.5"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-1"
   }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-2"
  } ],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "CONSUMPTION_BASED",
    "rateBands" : [ {
      "rateAmount" : 0.155
    } ]
  } ]
}

Example: Solar PV analysis without Intelligent Baselining

The previous examples use Intelligent Baselining (IB). To run a Savings Analysis without Intelligent Baselining, load usage data that covers the first year of the analysis.

If you run a future Savings Analysis, such as one starting January 1, 2019, load usage data for the future 12 months, from January 1, 2019 to January 1, 2020. If you run a historical Savings Analysis, such as one starting January 1, 2015, load usage data for the past 12 months, from January 1, 2015 to January 1, 2016.

If you load monthly readings for the electricity profile, each hour of the month is prorated as a flat amount. This works for a flat charge rate plan, but it does not work well for time-of-use (TOU) tariffs or rate plans that have different rates for import and export. For those cases, provide hourly interval data for the year.

If you have historical usage data but want to use the current version of a tariff, use tariffEffectiveOn. In this example, fromDateTime is in the past because usage data covers January 1, 2015 to January 1, 2016. The tariffEffectiveOn date is more recent, so that tariff version is used to calculate the full year's costs. This can produce a more accurate projection into the future.

{
  "providerAccountId" : "api-example-01",
  "fromDateTime" : "2015-01-01",
  "autoBaseline" : false,
  "useIntelligentBaselining": false,
  "tariffEffectiveOn": "2017-11-01",
  "propertyInputs" : [ {
    "scenarios" : "before",
    "keyName" : "masterTariffId",
    "dataValue" : "522"
  }, {
    "scenarios" : "before",
    "keyName" : "rateInflation",
    "dataValue" : "3.5"
  }, {
    "scenarios" : "solar",
    "keyName" : "rateInflation",
    "dataValue" : "1.9"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "solarDegradation",
    "dataValue" : "0.5"
  }, {
    "scenarios" : "after,solar",
    "keyName" : "providerProfileId",
    "dataValue" : "solar-1"
   }],
  "rateInputs" : [ {
    "scenarios" : "solar",
    "chargeType" : "CONSUMPTION_BASED",
    "rateBands" : [ {
      "rateAmount" : 0.155
    } ]
  } ]
}

Next steps

Return to Analysis APIs to choose another analysis workflow.
Use Savings Analysis Request Structure to choose common propertyInputs patterns.
Use Savings Analysis Request Templates to start from Quick Switch, Full Switch, or Storage-in-Switch examples.
Use Savings Analysis History to retrieve analyses that were already run.