Compound Aggregations - Examples

This topic gives some examples of Compound Aggregation calculations as guidance on how to work with them to achieve the precise pricing you need for products and services:

• Example 1 - Combining Aggregations in Seconds to Minutes
• Example 2 - Calculating Credits for Reduced Product Usage
• Example 3 - Global Compound Aggregation for Product Bundling

​

Example 1 - Combining Aggregations in Seconds to Minutes

Suppose your production environment contains three Meters each collecting usage data for time duration measures in seconds. You have set up simple Aggregations to SUM each of these Meter Data Fields:

• Watch duration: watch_seconds
• Testing duration: test_seconds
• Live duration: live_seconds

However, you want to set up pricing on a Product that charges your end-customers on the basis of their combined usage duration per billing period across all three simple Aggregations, and to charge by the minute, not by the second. To satisfy this pricing use-case, you can use a Compound Aggregation that adds together the simple Aggregation values and then divides the total by 60:

Calculation: aggregation.watch_seconds + aggregation.test_seconds + aggregation.live_seconds/60

​

Example 2 - Calculating Credits for Reduced Product Usage

Suppose you a run a cloud service company which offers end customers computing capabilities. You’ll set up pricing for products to charge on a monthly basis with a usage measure of total Gigabytes-per second used per month together with a monthly standing charge. However, as a sign-up bonus you want to offer credits to new customers for the first six months whereby they receive a credit rebate each month if they log into their accounts fewer than 20 times that month per user - roughly, that is, at least once for every user they have for every working day in a month. For each time fewer than the expected number of user logins, they’ll receive a $10 credit rebate on their Bill. To implement this and incorporate it into your pricing schema, you therefore need a way to count the number of user logins fewer than 20 each month for each user registered under a customer Account. This might seem like a difficult use case to satisfy as part of your overall UBP model, but by using the following Compound Aggregation in m3ter you can quickly implement it. First we set up two simple Aggregations:

• The total number of registered users under the end customer Account at the end of each monthly billing period: number_regusers
• The total actual number of logins recorded for all the registered users on the Account in a given month: total_reguserlogins

We can then create a Compound Aggregation that references these two simple Aggregations:

Calculation: Math.max(20*aggregation.number_regusers - aggregation.total_reguserlogins,0)

This calculation yields the required count of the number of fewer than expected registered user logins in the month:

• We take the number of registered users for the Account and multiply this by 20 (using this as a rough average of the number of working days per month) to generate an expected number of user logins (one login per user per working day).
• We then subtract the actual number of user logins from the number of expected user logins to generate a number of credits to rebate the Account that month.
• We use a Math.max() function to give a zero (no credits) if the number of actual user logins exceeds the number of expected logins for that Account.

​

Example 3 - Global Compound Aggregation for Product Bundling

Suppose you a run a cloud service company which offers financial institutions products designed to prevent them becoming victims of online fraudulent behavior:

• A service to catch and block suspect attempts to gain access to their online services - either by login attempts that use bogus accounts or login attempts using registered accounts that show suspicious traits. In either case, the login attempt is blocked and the attempt logged. You market this under the product name: “Account Secure”.
• A service that checks payments submitted by legitimate account holders using credit cards. If the payment details are not validated, the payment attempt is rejected and logged. You market this second service under the product name: “Payments Check”.

Your pricing schema for both these services will be similar:

• For both services, you will charge on the basis of the number of events where your protection service has been activated during the agreed billing period:
  • For customers who take the Account Secure product: a count of the number of events where your service activated, identified something suspicious, and blocked an attempt at login.
  • For customers who take the Payment Check product, a count of the number of events where your service was activated, checked submitted payment details and, finding those details to be false, rejected the payment submission.

In addition for both products, you differentiate within the total count of these events by recording the country of origin of the online users, which is useful when reviewing and analyzing bogus login attempts and attempts to pay using false credit card details. For the sake of the example, we suppose your customers operate across these three countries - the United States, Canada, and the United Kingdom. To price each product, we can now use a Compound Aggregation that simply adds the simple Aggregations that count events across the three countries of operation: Account Secure Product: we create three simple Aggregations to count bogus login attempts for each country:

• account_uslogins
• account_canlogins
• account_uklogins

We can now create a Compound Aggregation for this product, which adds together the values of these three simple Aggregations:

Calculation: aggregation.account_uslogins + aggregation.account_canlogins + aggregation.account_uklogins

This is now available to price Plans for your Account Secure product and for charging end customer Accounts that consume this product. Payment Check: we create three simple Aggregations to count payments that tried to use false credit card details for each country:

• payment_ussubmit
• payment_cansubmit
• payment_uksubmit

We can now create a Compound Aggregation for this product, which adds together the values of these three simple Aggregations:

Calculation: aggregation.payment_ussubmits + aggregation.payment_cansubmits + aggregation.payment_uksubmits

This is now available to price Plans for your Payment Check product and for charging end customer Accounts that consume this product. However, a new customer approaches you and wants to take both products as a combined contract and you’ll likely want to offer them discounted rates across both products. For this use case, we can now set up a global Compound Aggregation - one that is not tied to a specific product - and adds together both sets of simple Aggregations we used for pricing a specific product, and therefore creates a Compound Aggregation that forms a cross-product bundle:

Calculation: aggregation.account_uslogins + aggregation.account_canlogins + aggregation.account_uklogins + aggregation.payment_ussubmits + aggregation.payment_cansubmits + aggregation.payment_uksubmits

This is now available to price Plans for your product bundle offering and for charging end customer Accounts that consume both products under the bundle.