Alguna supports various billable metrics in order to meter usage. These metrics describe how to aggregate a set of billable events over a period of time.

Billable Events

Events are the basic unit of billable usage. They are emitted by your source systems or sent from one of our integrations and describe a single action occurring that the customer may be billed for.

Events have the following attributes:

  • uniqueId - A unique identifier for the event. This is used as a key to deduplicate events, or to allow upserting if configured.
  • eventName - The name of the event. This is used to group events together for aggregation.
  • accountId - The identifier of the customer that performed the action. This can either be the Alguna account ID or an alias configured for the account.
  • timestamp - The time the event occurred. This is used to attribute an event into a billing period.
  • properties - A set of key/value pairs that describe the event. These are used to filter events and build aggregations.

Ingesting Events

See the Measuring Usage page for more information on how to ingest events.

Creating Metrics

To create a metric, navigate to the Billable Metrics page and click the New Metric button.

  1. Enter a name and description for the metric
  2. Select the event name that the metric should be based on
  3. Add any filters that should be applied to the events based on their properties
  4. Select the aggregation type and field (if required)

Supported aggregations

  • count - The number of events that match the metric
  • sum - The sum of the values of the specified field
  • average - The average of the values of the specified field
  • min - The minimum value of the specified field
  • max - The maximum value of the specified field

Example

Let’s say you have a SaaS application that has mixed pricing based on number of seats and API requests used. You are a global company and therefore you have APIs deployed in NA, EMEA and APAC, and a customer is charged differently based on which region they are using.

In this case you would want to send two types of events:

  • merchant_seat_changed - This event would be sent when a new user is added or removed from the merchant’s account. This event would have a total_seats property that would be the total number of users on the account.
  • api_request - This event would be sent when a customer makes an API request. This event would have a region property that would be the region that the API request was made to, and a value that describes the number of requests used.

And create metrics:

  • Merchant Seats - You may want to aggregate by average or max depending on how you want to charge your customers
  • API Requests (NA) - Filtered on region = NA and aggregated by sum
  • API Requests (EMEA) - Filtered on region = EMEA and aggregated by sum
  • API Requests (APAC) - Filtered on region = APAC and aggregated by sum