Example 3: Segmented Aggregation on Single Meter Usage - m3ter Documentation

m3ter Worked Example 3 - YouTube

Suppose you run a SaaS company that offers a service to companies to perform background checks on employee candidates to support their hiring process:

• Pricing for this service will vary by candidate location and the level of background check done.
• The service is offered for candidate locations across three countries: the USA, the UK, and China.
• Three levels of background check are offered for each location: Standard, Extended, or Complete.

If you want to price differently for each possible combination of location/level, this can mean having to set up multiple Meters/Aggregations to support usage-pricing for all possible combinations. However, for this kind of pricing use case that demands a wide spread of differentiated pricing metrics, you can use a Segmented Aggregation on the same Meter usage data - you can submit data for the same Meter and allow a different pricing to be created for each segment defined by the Aggregation. This topic provides a worked example to show how to set up a Segmented Aggregation to serve this differentiated pricing use case. The example goes on to show how to submit some test data against a test Account and then generate a Bill for the test Account and check billed amounts against submitted usage.

Step 1: Create Product

Products represent a product or service that you offer to your end customers. A Meter, Aggregation, Plan Template, Plan, or Pricing typically all belong to a Product. To create a Product:

1. In the Console, select Products. The Products page opens.

2. Select Create Product. We’ll create a single Product called Premium Candidate Checks:

3. Select Create Product.

The Premium Candidate Checks Product can now serve as a container for any Meters, Aggregations, Pricing, Plans, and Plan Templates we’ll need for the example.

Step 2: Set up Meter

Meters define the Data Fields that your system will use to submit usage data to the m3ter platform:

• As well as simple Data Fields, which collect raw usage data, you can define Derived Fields that reference and apply calculations to simple fields.
• You can create Product-specific Meters or Global Meters.

For this worked example, we’ll create a single Meter for our Premium Candidate Checks Product. To create a Meter:

1. Select Usage>Meters. The Meters page opens.
2. In the Product drop-down, select Premium Candidate Checks.
3. Select Create Meter.

Here’s the set up for the Meter to support the pricing model we want to use in the example:

For the example, we’ve set up Candidate Check Meter 1 and added the three Data Fields:

• A Location field: Category is Where, which is a String field.
• A Type field of: Category is What, which is a String field.
• A Checks field: Category is Measure, which is a Numeric field.

4. Select Create Meter.

We now have a single Meter for the example, which we can use to collect usage data on any Account that consumes the Premium Candidate Checks Product. This metered usage data will serve as the basis for the Segmented Aggregation we shall create to apply differentiated pricing for Product consumption.

Step 3: Define Aggregations

Aggregations define how to transform into a single number the individual measurements submitted to a Meter Data Field as usage data. For the usage-based pricing model we want to implement in our example, we’ll need to create a Segmented Aggregation based on the usage data collected by our single Meter - Candidate Check Meter 1:

• We’ll use the Location and Type string Data Fields to create the required segments on the usage data.
• We can target the Checks numeric Data Field to give a sum of the number of checks performed for each defined segment.

To create a Segmented Aggregation:

1. Select Usage>Aggregations. The Aggregations page opens.
2. In the Product drop-down, select Premium Candidate Checks.
3. Select Create Aggregation. The Create page opens.
4. Enter a Name and Code for the new Aggregation.
5. Select the Meter previously created for the example and with the required Data Fields: Location, Type, and Quantity.

Here’s the basic setup for the Segmented Aggregation:

We’ve targeted the Checks field on Candidate Checks Meter 1. 6. Scroll down and click the arrow to open the Segments panel:

7. Select the two fields to define segment values by location/type.

8. We can add the appropriate location/type segment values using the Segments panel:

9. Select Create Aggregation.

We now have the Candidate Checks Aggregation 1 with appropriate segment values defined and which we can use to apply differentiated pricing to a Plan for the Premium Candidate Checks Product.

Step 4: Create Product Plan

Plans represent a pricing plan for one of your products or services. A Plan is always derived from a Plan Template and inherits settings from the Plan Template which control billing operations, such as billing frequency and currency. You can override some of these settings when you create a Plan from a Plan Template. To meet the example requirements:

1. Select Pricing>Plan Templates. The Plan Templates page opens.
2. In the Product drop-down, select Premium Candidate Checks.
3. Select Create Plan Template. The Create page opens.

Here’s the setup for our Product Plan Template:

For the Candidate Checks Plan Template 1, we’ve:

• Chosen US dollars as the billing currency.
• Selected a monthly Bill frequency with a Bill interval of 1, which means Accounts put on the Plan will receive a Bill each month for a month’s period of usage.

4. Select Create Plan Template. You are returned to the Plan Template Details page.

We can now create a Product Plan for the example based on this template.

To create a Product Plan:

1. Select Pricing>Plans. The Plans page opens.
2. In the Product drop-down, select Premium Data Checks.
3. Select Create Plan. The Create page opens.

Here’s the setup for our Product Plan:

4. Select Create Plan. The Plan Details page opens for our new Product Plan.

We can now price Candidate Checks Plan 1 using our Candidate Checks Aggregation 1 Segmented Aggregation.

Step 5: Price Product Plan

Pricing allows you to configure the cost of usage data under a specific Plan you apply to an Account, and is used to calculate bills. We can use the Pricing Editor in the m3ter Console to quickly price up our Product Plan to meet the pricing requirements for the example.

To price Product Plan:

1. Select Pricing>Pricing Editor. The Pricing page opens.
2. In the Product drop-down, select Premium Candidate Checks.
3. Select Add Plans. The Select Plans dialog opens and lists all Plans created for the Premium Candidate Checks Product.
4. Check Candidate Checks Plan 1 and select Confirm.

We’ll use the Segmented Aggregation we created at Step 3 for the usage-based metrics to apply differentiated price to the Plan in accordance with the requirements set out in the example.

5. Click Add Aggregations. A Select Aggregations dialog appears and lists all Aggregations created for the Premium Candidate Checks Product.

6. On the Select Aggregations dialog check Candidate Checks Aggregation 1.

7. Click Confirm. The dialog closes and the selected Aggregation is added to the Pricing page for the added Plan.

8. In the pricing grid, select Edit segmented pricing. The Segments pricing page opens:

9. Scroll down the page to reveal the Segments pricing grid, which contains a row for each segment defined for the Aggregation:

10. For the example, we’ll suppose that for each segment we want to charge customers a different flat rate per candidate check performed:

11. For the first segment row - China/Standard - select Create Plan Pricing.
12. Work down the form to enter:

• Start and End dates for the period the pricing will be active for the Plan.
• A Description that will appear for any usage charge line items on Bills, such as China/Standard Check Charges.

13. Select Create Pricing.

14. Repeat the steps for the remaining five segments to create pricings for them.

15. Now we have a Product Plan to which we’ve applied differentiated pricing according to the pricing requirements using our Segmented Aggregation.

Step 6: Create Test Account and Attach Priced Plan

Accounts represent one of your end-customers, and contains the end-customer name and contact details:

For this step, we’ll create a test Account for the example and attach our priced Plan to it. To create a test Account and attach Plan:

1. In the main Console navigation, select Accounts. The Accounts page opens.

2. Select Create Account.

3. Enter the details of the new Account which include Name, Code, and Email Address.

4. Select Create Account. The Account Details page for the new Account opens.

5. Select the Attached Plans tab.

6. Select Attach plan.

7. Use the Product drop-down to select the Product, which is Premium Candidate Checks for the example.

8. Select the Plan, which is Candidate Checks Plan 1 for the example.

9. Select Create Plan.

We now have a test Account set up that will be billed according to the segmented pricing schema we’ve configured for the Plan for any metered usage of the Product.

Step 7: Submit Data to Test Account and Check Bill

We’ll now submit some test data to our Candidate Checks Customer 1 test account and for the Candidate Check Meter 1. This will allow us to generate a Bill for the test Account and check that the usage charges on the Bill for the submitted test data are correct.

1. Select Accounts. On the Accounts page, select the name of the Candidate Checks Customer 1 test Account. The Account Details page opens.

2. Select Submit usage.

3. Under stage 1: Select a meter, use the Meter drop-down to select Candidate Check Meter 1 and then select Continue.

4. Enter test data Values for the Location, Type, and Checks Data Fields:

5. Select Submit usage.

6. Repeat the steps to submit test measures for each of the remaining five segment values for the bill generation.

7. After submitting, we can calculate what the cumulative usage charges should be for the submitted test data.

For the example, we can see that the Bill based on test usage data we submitted has been calculated correctly in accordance with our usage-based differentiated pricing schema.