At the core of our Billing Cloud, built from the ground up to tackle the demands of real-time usage-based pricing and billing, is a highly flexible and scalable Pricing Machine State Engine (a.k.a rating engine).

We describe below some of the artifacts and how the pricing machine works. This background will help you understand the unique and powerful capabilities and flexibility of the pricing engine and, we hope, will unleash your imagination in building and deploying the pricing models that best suit your products and customer base.

It provides the tools needed to create any pricing plan that you have in mind.

Before delving into the different types of price machine nodes, we will provide a high-level description for how the price calculation works.

Amberflo invoice calculator is the logic which converts a specific meter's hourly usage aggregation for a given customer to an invoice.

The exact input which the invoice calculator consumes is the meter hourly usage aggregation of a given customer partitioned by all of the official dimensions of the invoice.

Then the price calculator executes the following steps: Step 1: Fetch the relevant price machine for the customer and the meter. Step 2: Reduce the input to a smaller set of partitions as defined by the specific price machine. Step 3: Execute the price machine on the reduce input.

The exact output of the price machine is set of what call an 'Item-Variant-Invoice'. An 'Item-Variant-Invoice' is a partition of the invoice by a sub-set of the meter official dimensions.

Given these we will define each price machine using two properties:

Let's assume you have the following meter:

Then the price machine will create the following 'Item-Variant-Invoice':

Now that we know something about how Amberflo's price machine works, we will introduce the different types of machines we offer.

The leaf price machine is the simplest price machine one can think of, and yet as we will see next it by itself quite an advance price machine.

The properties of this machine are:

Bellow is the 'leaf price machine' schema:

Unless you want to partition the invoice by a subset of the meter dimensions then this machine is likely all you need.

Let's look at a few examples of possible configuration for this machine.

A machine that calculates a price of $0.10 per 1 unit of usage.

For example the price of 12 units of usage is $1.20.

A machine that calculates a price of $0.50 per 5 units of usage with no partial batching.

Unlike the previous example this machine doesn't allow partial batches, which means, the price usage will be rounded up to whole unit of the batch size, and the price will be determined based on the amount of batches.

For example, the price of 12 units of usage is $1.50 (3 batches).

A machine that calculates a price of $0.10 per each 1 unit of usage for the first 10 units of usage, and then drop the price to $0.05 for each unit afterwards.

For example, the price of 12 units of usage is $1.10 (0.1 10 + 0.05 2).

A machine that calculates a price of $0 per each 1 unit of usage for the first 10 units of usage, and then increases the price to $0.05 for each unit thereafter.

For example, the price of 12 units of usage is $0.1 (0 10 + 0.05 2).

Discrete-price-leaf-node is another type of a leaf node. It is different than the Price-leaf-node in a way that it calculates the price of each usage time slot independently of other hours.

For example: Let's assume we have the following tiers:

Now let's assume we had the following usage:

With the original Price-leaf-node we will charge that customer for $70 (95 + 75 - 100). This is because the that model applies the tiers for the usage over the entire period.

With this Discrete-price-leaf-node we will charge the customer for $0 because on each day we used less than 100 units.

The properties of this machine are:

Bellow is the 'discrete leaf price machine' schema:

A leaf node can calc the price of a given usage (of a given invoice-variant) without deferring any pricing decisions to subsequent nodes. In other words a leaf node can't have subsequent nodes which it depends on.

For this leaf-node the only thing that dictates the price of a meter is the total amount of usage over time.

This price node is based on the total usage volume. For example, Let's assume we have the following tiers:

Example: let's assume that during an invoice cycle we have a total of 15 units used. Then the price should be: 15 * 3 = $45

The properties of this machine are:

Bellow is the 'Volume based leaf leaf ' schema:

Example:

In the example above we describe the following tiers table:

And to calculate the price of 15 units of usage we just multiple 15 by 3 = $45.

But what if the values were decreasing as the usage goes ?

For example let's assume we have the following table:

Now, a customer with 15 unit of usage will pay $15, while a customer with 9 unit of usage will pay 9 * 3 = $27. That stands against the core ideas of "usage-based-pricing", that guide us to create fair price machines (where if you use more you pay more, and there is no reason to use the system more just to pay less).

So, one by design limitation of this price-machine is that the price per unit can only increase as we use the system more. If you wish to let it decrease then please refer to the 'price-leaf-node' and 'discrete-price-lead-node' mentioned above.

This type of machine allows you to create a different price logic for different combinations of dimensions values.

Basically you define a Price-Leaf-Node for each combination of dimensions values. Notice that this price machine will drop any usage for which the dimension values are not defined in the price machine (we will share an example for this below).

The properties of this machine are:

The machine below defines a price according to the following pricing plan:

Equivalent price machine:

This machine counts the distinct values for a subset of dimensions and then calculates a price using a Price-Leaf-Node for the count.

The distinct values count function can be applied on:

The properties of this machine are:

Let's assume your company has a pool of machines and provides a service which allows your customers to use your machines to run all kind of tasks on-demand.

Let's also assume that you measure how long each task runs, but for simplicity you want to invoice customers by the distinct number of tasks that they run during the invoice period. In such a case you can define the following price machine:

This machine will have a distinct count for all of the jobs that ran during the invoice-period (regardless of how long they ran or if the runtime was spread over multiple hours or days), and charge the customer $2 per each batch of 5 jobs.

Similarly to the 'Distinct-Resource-Reducer' this price machine node can also reduce the time granularity of your hourly usage. This price machine finds the max value to pick the value of each usage partition.

This model allows you to charge your customers based on the peak hourly usage over:

The properties of this machine are:

NOTICE: you can plug this price-machine-node to any of the price machines described above.

Let's use the previously mentioned example and assume your company has a pool of machines and provides a service that allows your customers to use your machines to run all kind of tasks.

But this time, let's assume you want to charge your customers according to the max hourly usage rate they incurred during the invoice period.

You can create a map_reducer similar to that described below.

Let's assume we take Example 2, mentioned above (for the dimensions matrix), but this time we want to calculate based on the max daily value.

As mentioned, we can have any node as the next node of the max_reducer price machine. Therefore we can just wrap the aforementioned 'DimensionMatrixNode' inside of a max_reducer.

This node has a similar logic to the "Max Reducer" described above with two main differences:

Regarding #2:

Avg is calculated using the following formula:

Now, let's look at the following example and ask ourselves what is the denominator, meaning what are the t2, and t1 values.

To make things simple let's assume our avg price state machine granularity is 'entire_invoice_period':

So, at 7/22 we have two options for how to calc the denominator: Option 1 - from 7/15/2022 to 7/22/2022, using current usage Option 2 - from 7/15/2022 to 8/15/2022, using current usage

When we said that the avg is being calculated over the ORIGINAL time period of invoice we meant is that we follow option 2. Option 2, has some big advantages over option 1 among them are:

The main reason to use this node is if you want to partition your usage by a certain set of dimension values which is not included in the next nodes, without specifying a unique leaf-price machine as done in the dimensions-matrix-node.

For example, let's assume you operate on many regions but you have the same pricing logic for all regions. Having said that, let's assume that when generating the invoice you want to calculate the price-per-region using the same leaf-node. You can use this method to have such logic.

The properties of this machine are:

We can implement the example mentioned above (partition by region but keep the same price logic for all regions) using a configuration similar to the one below:

Two ways to define a price machine: