HomeGuidesAPI ReferenceChangelog
Log In
API Reference

Run a Savings Analysis

What is a Savings Analysis?

The Savings Analysis endpoint provides you with a calculator to project the potential future costs and savings of a change in energy use or rates. You can run a savings analysis to determine the potential savings from installing a solar system and optionally switching a rate plan (we are adding more projects from installing on-site storage to buying an EV). The Savings Analysis calculator is somewhat similar to the Cost Calculator. The big difference is that instead of running just one service bill(s), this calculator runs at least two bills (called scenarios) and then reports back not only the costs for each scenario but the differences (savings) between them.

Passing in your Property Inputs

Just like the Cost Calculator, the Savings Calculator accepts propertyInputs that you use to pass in basic inputs. Usage data is provided by passing in one or more profileIds or providerProfileIds, as is solar production. Tariffs can be set on the account or explicitly passed in via a masterTariffId. Other assumptions like expected future rate inflation can also be passed in this way. Each property in the list needs to be tagged with which scenario or scenarios it applies to. For instance, if you wish to use the same profileId for both the "before" and "after" scenarios you would tag that property with "scenarios":"before,after". Think of a scenario as one service that your customer pays for (like electricity that they pay the utility for or solar that they pay a lease or PPA on). A scenario therefore needs a tariff (rate plan) too. You need at least two scenarios otherwise there wouldn't be anything to compare to get savings.

Getting the results - Data Series

The response from calling the Savings Analysis endpoint comes back with an array of data points (SeriesMeasure) in the seriesData property. Examples of series are "First Year Monthly Numbers before going solar", "Annual Solar Numbers for the Next 20 Years", and "Savings Numbers over the Lifetime of the Project". More specifically, each series has a time granularity (e.g. monthly or annual), a time frame (for example the first year only or the entire project), and what scenarios it's computed from (e.g. the "before, the "after", the "solar" or the "series"). Each data series is identified by a unique ID (an integer). The series property on the response is an array of the series that were included in the response, giving you the meta-data about the series available. Then the seriesData property holds all the actual data points for all series. Each data point holds a cost, a quantity, and a rate for a time interval of its corresponding data series.

Data Definition

Savings Analysis Request

The savings analysis endpoint is very flexible. From this single endpoint, you can configure your analysis in thousands of different ways. You can change your account's tariff to a different one in the "after" scenario, you can change how quickly electricity rates go up each year, or you can use an entirely different solar power system than the one that you proposed. To enable all of that flexibility, you have a lot of different parameters to choose from. They are split into three groups: top-level parameters that set the stage for the entire analysis, property inputs that define the parameters of each scenario, and rate inputs that let you specify entirely new rates to apply to your analysis. Before we get into the parameters, though, we need to talk about the idea of a scenario.

Scenarios - Building Blocks of Savings Analysis

At the most basic level, savings is how much the customer would have paid for energy without solar versus how much they did pay after solar was installed. To capture this, the Savings Analysis endpoint uses the notion of a scenario. There are three scenarios:

  • The before scenario represents how much the customer would pay to their utility if they never installed solar.
  • The solar scenario represents the cost of solar energy only.
  • The after scenario represents how much the customer will pay to their utility after solar is installed.

These three scenarios are defined independently of each other. In general, specifying one input (say, a rate escalator) for a particular scenario will not cause that same input to be applied to the other two. A typical savings analysis will use the customer's pre-solar electricity consumption in both the before and after scenarios and will specify solar production in both the solar and after scenarios.

Top Level Parameters

The top-level parameters set the stage for the entire analysis. At a minimum, you'll need to provide a fromDateTime and an accountId or providerAccountId. Everything else is optional.

NameTypeDescription
accountIdStringThe Arcadia-generated ID of the account for which you want to do the savings analysis.
providerAccountIdStringThe alternative ID of the account for which you want to do the savings analysis.
fromDateTimeDateTimeIndicates the start of your analysis and should align with when you expect the system to interconnect (1-6 months in the future, typically). 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 in order to return 12 monthly values for the first-year series.
toDateTimeDateTimeDEPRECATED. To make the analysis span 25 years instead of the default of 20, use projectDuration, not toDateTime.
propertyInputsArray of PropertyDataThe parameters for the analysis. There are many different options available. We discuss them below.
rateInputsArray of TariffRateCustom tariffs for this analysis. You can use this to define lease rates, PPA rates, or special tax rates. Make sure to set the scenario property so that your rate is applied correctly.
populateCostsBooleanIf set to true, your results will contain an even more detailed breakdown of the first year of results for this calculation.
tariffEffectiveOnDateTime(Optional) This field enables doing a calculation with a single, specified version of a given tariff. For example, if the user specifies that they want to use the 2016-01-01 version of PG&E's E-1 tariff, any calculation, whether it's for 2013, 2015, or 2016, would use the rate data from that version and only that version of the tariff.
autoBaselineBoolean(Optional, Default=true) Use this field to disable intelligent baselining in the usual case where you don't want it.
useIntelligentBaseliningBooleanThis 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

For customizing a savings analysis, the propertyInputs collection is where the action is at. With these inputs, you can customize your analysis in any number of ways, including changing tariffs, changing usage data, and changing your solar system. Each input can apply to more than one scenario, so make sure to set its scenario property.

NamePropertyData TypeScenariosDescription
profileIdStringbefore, after, solarThe ID of the usage profile that you want to use for this scenario. Can be set for beforesolar, 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.
providerProfileIdStringbefore, after, solarThe alternative ID for the profile that you want to add to the analysis.
baselineTypeStringbefore, after, solarIf 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 analysis.
masterTariffIdIntegerbefore, afterThe 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.
rateInflationDecimalbefore, after, solarThe 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.
solarDegradationDecimalsolar, afterThe rate at which energy production from the solar system degrades. If your degradation rate is 0.5% per year, use a value of 0.5 here.
projectDurationIntegerbefore, after, solarYou can make the project last however long you want. The default is 20 years.
solarPvLoadOffsetIntegersolar, afterIf 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. The system will be a south-facing and tilted at 30 degrees. 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.
loadOffsetIntegersolar, afterAn alternative name for solarPvLoadOffset.
loadSizeIntegerbefore, afterIf you don't have an existing usage profile, use this option 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 simply a collection of TariffRate objects with one new property: scenario. Use that parameter to specify which scenario you want this custom rate to apply to. This field can be used for things like setting the first-year PPA or lease rate and setting a custom tax rate.

Savings Analysis Response

The data that you get back from the savings analysis represents a complete description of the results of your calculation.

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 preTotalCostpostTotalKWh, and netAvoidedCost.

Pre-Solar Summary Fields

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

NameDescription
preTotalCostThe first year, pre-solar cost of energy. It is the highest of the preTotalNonMinCostpreTotalMinCost and preTotalNonBypassableCost.
preTotalKWhThe first year, pre-solar amount of energy used.
preTotalKWhCostThe first year, pre-solar cost of kWh only. Does not include minimum costs.
preTotalKWhRateThe first year, pre-solar rate for kWh only. Does not include minimum costs.
preTotalMinCostThe first-year minimum bill for the customer.
preTotalNonBypassableCostThe first year non-passable costs for the customer.
preTotalNonMinCostThe first-year bill for the customer. Will almost always be the same as preTotalCost.
preTotalRatePre-solar blended kWh rate. Equal to (preTotalCost/preTotalkWh)

Post-Solar Summary Fields

These fields represent the first year after solar. 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.

NameDescription
postTotalCostThe 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 postTotalNonMinCostpostTotalMinCost and postTotalNonBypassableCost.
postTotalKWhThe amount of energy still consumed from the utility in the first year after solar.
postTotalKWhCostThe first-year post-solar cost for kWh only. Does not include minimum costs.
postTotalKWhRateThe first-year post-solar rate for energy from the utility only. Equal to (postTotalKWhCost/postTotalKWh).
postTotalMinCostThe minimum bill for the first year.
postTotalNonBypassableCostThe minimum bill for the first year, calculated using NonBypassable Charges (NBCs). Non-Bypassable charges cannot be offset by other NEM credits, creating a second minimum charge for solar customers.
postTotalNonMinCostThe customer's new utility bill, without accounting for any minimum charges.
postTotalRateThe post-solar blended kWh rate for energy still purchased from the utility. Equal to (postTotalCost/postTotalKWh).

"Net" Summary Fields

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

NameDescription
netAvoidedCostThe cost of energy that is no longer being purchased from the utility in the first year post-solar. Equal to (preTotalCost - postTotalCost).
netAvoidedCostPctOffsetThe percentage of first-year cost from the utility offset by solar. Equal to (netAvoidedCost/preTotalCost).
netAvoidedKWhThe amount of kWh generated by the solar power system. Equal to (preTotalkWh - postTotalkWh).
netAvoidedKWhPctOffsetThe percentage of first-year kWh offset by solar. Equal to (netAvoidedkWh/preTotalkWh).
netAvoidedRateThe average value of an avoided kWh. Equal to (netAvoidedCost/netAvoidedKWh)

Lifetime Summary Fields

Lifetime values represent totals over the life of the project.

NameDescription
lifetimeSolarCostThe cost of solar energy over the life of the project.
lifeTimeUtilityAvoidedRateACP over the life of the project.
lifetimeWithoutCostThe lifetime cost of energy without a solar system.
lifetimeAvoidedCostCustomer savings over the life of the project. Equal to (lifetimeWithoutCost - [lifetimeSolarCost + lifeTimeUtilityAfterCost]).
lifeTimeUtilityAfterCostThe 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.

NameTypeDescription
designIdStringThis is null for Account Analysis (so ignore it). It is used in Project Analysis (different endpoint).
dataStatusIntegerRepresents the status of the underlying data (profiles) that the analysis ran on. 2 means all the underlying data is up to date. 1 means it's still processing, and you should run the analysis again once the profile is done (this is very unusual).
scenariosArray of ScenarioEach 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.
seriesArray of SeriesA list of Series objects, each one describing the data points (SeriesMeasure) it contains. The Series object is documented in further detail below.
seriesDataArray list of Series MeasuresThis 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.
seriesCostsMap of Integer to Calculated CostIf populateCosts is set to true, this field is populated with CalculatedCost objects 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. For a solar PV analysis, there are 4. You only need to worry about sending this in a request to the Savings Calculator when running a generic analysis type. Scenario has the following data structure.

NameTypeDescription
idStringThis is not used for Account Analysis (it's used for Project Analysis). Will be null. Ignore it.
nameStringThe unique name (key) of this scenario. Solar PV has "before", "after", "solar" and "savings".
serviceTypeString of ServiceTypeThe type of service for this scenario. "ELECTRICITY" or "SOLAR_PV"
inputsList of PropertyDataThe 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 calc. See examples below.
ratesList of TariffRateUsed 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 offers PPA or lease rate. See examples below.

Series

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

NameTypeDescription
seriesIdIntegerAll 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' periodduration, and scenario fields to find the seriesId you need.
fromDateTimeDateTimeThe start date of the series.
toDateTimeDateTimeThe end date of the series.
scenarioStringMathematical formula of scenarios that produced this series.
displayLabelStringThe display label for this series.
seriesPeriodStringThe series period/term. Possible values are: "YEAR""MONTH""DAY", and "HOUR".
seriesDurationIntegerThe 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.
designIdStringNot populated for Account Analysis.
keyStringFor future use.
rateDecimalAverage rate over the entire duration of this series.
qtyDecimalTotal quantity over the entire duration of this series.
costDecimalTotal 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 will be returned with three granularities: monthly for the first year, annual for the life of the project, and the total over the life of the project. This means that for a standard solar savings analysis, you will get back twelve Series items.

SeriesMeasure

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

NameTypeDescription
seriesIdIntegerThe identifier of the series that this data point belongs to (See Series above).
fromDateTimeDateTimeStart date and time of this data point.
toDateTimeDateTimeEnd date and time of this data point.
rateDecimalThe 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.
qtyDecimalQuantity for this timeframe (usage or production, etc. typically in kWh).
costDecimalCost (or savings) of this timeframe

Put it all together

Here's an example of a response back, in JSON, with all the parts 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 */

         "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 about the other series */

         ],
         "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
            },

			/* more series data */
         ]
      }
   ]
}

Calculate Savings Analysis for Solar PV

The Solar PV analysis type allows you to calculate the savings from your customer going solar. The standard scenarios ran for an analysis of this type are 1) "before" which is what the electricity bill would be in the future without solar (sometimes called the "do nothing" scenario), 2) "solar" which denotes what the solar system being considered would produce and cost, 3) "after" which is the electricity costs and usage given the system is installed (so electricity usage is reduced by what the system produces), and 4) "savings" which are the net savings ("before" minus "after" plus "solar").

Resource URL

POST /rest/v1/accounts/analysis

Request Parameters

Along with the required security parameters, this endpoint requires you to post a particular JSON structure in the body of the request. Here's an example:

{
  "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
    } ]
  } ]
}

You can read more about all of the available parameters and options up above. When calculating solar savings for your customer, you need to pass in these scenarios:

  • the do nothing or "before" electricity Scenario. That is, what your customer will pay for electricity without going solar.
  • the "solar" Scenario, or how much the system produces and what that costs. In other words, what the Account will pay for solar (e.g. the PPA or lease)
  • the "after" installing solar electricity Scenario. In other words, your customer's electricity bill given solar. This should be lower than the "before" scenario because less power is bought from the grid.

Example: Solar PV Analysis for Lease

The following is a common scenario. The providerAccountId denotes the account to run this against. By passing this in, the current tariff and default electricity profile are used without having to explicitly state them. The tariff is used for both before and after scenarios. The other parameters are passed in via property and rate inputs:

  • PropertyInput "before" for rateInflation denotes the expected rate at which electricity will increase in the future. 3.5 is 3.5%
  • PropertyInput solarDegradation for "after,solar" denotes how much less the solar system will production each year. 0.5 is 0.5%.
  • PropertyInput providerProfileId for "after,solar" denotes the solar model profile (in this case a PV Watts one). You can use profileId too.
  • In this case, we are passing in a Solar Lease (rate input of type "FIXED_PRICE"). Here it's $295. Also, the PropertyInput rateInflation for "after,solar" denotes that this lease will escalate annually at 1.9%.
{
  "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

The following is similar to the example above, but this has a 15.5¢ solar PPA rather than a lease ("CONSUMPTION_BASED"). It also switches tariffs "after" solar to a more solar-friendly tariff. Finally, we pass in 2 solar model profiles (e.g. one for south roof, one for west).

{
  "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

Our IB feature is used in the two previous examples above. However, if you would like to run a Savings Analysis without Intelligent Baselining, you will need usage data to cover the first year of your analysis. If you are running a Savings Analysis in the future (e.g. January 1, 2019), you will need to load usage data for the future 12 months (e.g. January 1, 2019 to January 1, 2020). If you are running a Savings Analysis in the past (e.g. January 1, 2015), you will need the past 12 months of usage data (e.g. January 1, 2015 to January 1, 2016).

If you load monthly readings for your electricity profile, each hour of the month will be prorated as a flat amount. This is fine for a flat charge rate plan but does not work well for time-of-use tariffs or rate plans that have different rates for import and export. In a case like that, we recommend doing your own Intelligent Baselining and providing us with hourly data for the year.

If you have historical usage data but would like to use the current version of a tariff, you will use the tariffEffectiveOn property. Here is an example where the fromDateTime is in the past (e.g. 2015-01-01 since usage data is for January 1, 2015 to January 1, 2016), and the tariffEffectiveOn date is set to a more recent date (e.g. 2017-11-01) so the current version of the tariff will be used to calculate the whole year's costs. This makes for 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
    } ]
  } ]
}