Skip to main content
You can set up Meters to collect usage data on your end customer activity when they consume your products and services. For example:
  • Number of logins.
  • Duration of session.
  • Amount of data downloaded.
Meters offer you wide-ranging flexibility when configuring the types of data you need to collect to support the usage-based pricing models you want to apply to your products and services. Metering for data need not stop there. The m3ter platform offers virtually unrestricted scope in the range and types of data you can collect - not just the immediate customer usage data measures you require to price your products and services very precisely - but also to gather any associated data you need to feed into your business performance and analytical tools; tools which can then support and inform your long-term business management and improvement decisions. This topic explains the difference between Product and Global Meters and the configuration options available for Meters:

​
Product Meters vs. Global Meters

You can create Meters that belong to a specific Product or create Global Meters. Usage data Meters collect:
  • You can use Product-specific Meters to charge for usage data the Meter collects for the Product.
  • You can use Global Meters when you want to charge for the usage data the Meter collects across multiple different Products.
Aggregations targeting Meters:
  • Any Aggregations that target a Product-specific Meter, then also becomes Product-specific and can only be used to Price Plans for that Product.
  • Any Aggregations that target a Global Meter are also Global, meaning they are not tied to a specific Product and can be used to price Plans belonging to different Products.
Switching Meters between Product-specific and Global:
  • You can switch a Product-specific Meter to Global, but you cannot switch it back to make it a Product-specific Meter again.
    • If you have already created any Aggregations that target a Product-specific Meter and you then switch the Product-specific Meter to be Global, then the Aggregations then become Global.
  • You cannot switch a Product-specific Meter to another Product.
  • You cannot switch a Global Meter to Product-specific.

​
Configuring Meter Fields

When you create and set up a Meter, the key configuration is adding fields to collect data:
  • Data Fields. Baseline fields for collecting raw usage data.
  • Derived Fields. Fields whose values are the result of a calculation/function performed on Meter Data Fields, Custom Fields, or Timestamp Fields.
  • Custom Fields. Allow you to attach custom data to the Meter as name/value pairs.

​
Data Field Options

You can add Data Fields to a Meter to collect;
  • Usage data on which you want to base your measurements for pricing.
  • Any associated data required for other business needs, such as for analytics purposes.
Each Meter can have up to a maximum of fifteen Data Fields. For each field, you can define the type of data you want the field to collect using the Category attribute. There are eight options:
  • Who. String. Use to collect usage data about an individual or organization - data events that answer a “Who” question, such as, “Who or which organization logged-in?”, “Who was contacted?”, and so on.
  • What. String. Use to collect usage data about some object or thing, whether it be a physical object in the real world or something in a virtual context.
  • Where. String. Use to collect usage data about a location - where something happened, whether in physical geographical space or a virtual space.
  • Measure. Numeric. Use in a general way to collect quantitative usage data.
  • Metadata. String. (Max. 256 characters). Use for high-cardinality fields that you don’t intend to segment when you aggregate the data.
  • Income. Numeric. Use to collect usage data associated with income.
  • Cost. Numeric. Use to collect usage data associated with costs.
  • Other. String. Use to collect textual usage not applicable to Who, What, or Where events.
Important: When setting up Measures on Meters, consider how you want to aggregate your usage data! The options for Aggregating usage data collected by a Meter are constrained by the Categories you select for a Meter’s Data Fields - not all data aggregation methods can be applied to all Data Field Categories. For details on which aggregation methods are available for which Categories, see Configuring Aggregations.
These options offer a very wide range in the type of data you can collect about your customer activity. Importantly, they allow you to gather data associated with your customer’s behavior when using your service not only for the purpose of charging them but also for other crucial business purposes, such as performing advanced analytics on accumulated data about customer behavior over time. For example:
  • Who. Suppose you want to charge for your service based on the number of times a customer logs in to your system. You can define a Data Field using this option to meet this requirement. This option would allow m3ter to identify a specific customer at login and then count the number of logins by that customer within a defined period. Additionally, you might want to gather this usage data on login frequency not simply for the purpose of charging customers but to feed into analytical tools that will afford useful insights into your customer behavior when using your service over time.
  • Where. You might also want to charge customers not only on the number of logins but also by location, with charges varying across geographical regions. To enable this, you can define a second Data Field using this option. Alternatively, you might want to use this option to capture the source of the data your customer downloaded when they were logged in your service - say from which server instance it came - and this could provide very useful for analytical purposes over time.
In general when setting up Meters, your approach should be to use multiple Data Fields on a single Meter where the data types collected are related to the same event. So to continue the example, if in addition to charging customers by number of logins and by geographical location, you want to include charges for the amount of data customers upload to and download from your service during their login session, you would set up a second Meter and add Data Fields of type Measure to collect these upload and download volumes.

​
Derived Fields

Each Meter can have up to a maximum of fifteen Derived Fields. The values of a Derived Field are not raw usage data values but always the result of a calculation or function performed on Meter Data Fields, Custom Fields, or Timestamp Fields as source fields. Derived Fields add a very powerful extra dimension of flexibility for setting up the data on which your usage-based pricing plans will be based.
Tip: Examples? The Derived Fields for Meters - Examples and Supported Syntax topic offers numerous examples of how to set up Derived Fields on your Meters to serve your usage-based pricing needs.

​
Units for Meter Fields - Examples

For numeric Meter Data and Derived Fields - Measure, Income, or Cost - we recommend that you conform to the The Unified Code for Units of Measure (UCUM), which is designed to facilitate the communication between electronic systems of quantities with their units. With reference to section 4.6 of the UCUM Specification for Prefixes and Unit Used in Information Technology, this section offers some typical examples.

​
Measures of Data Storage

For example, services that want to price on sum of storage used:
  • Kilobyte: KiBy
  • Gigabyte: GiBy
  • Megabyte: MiBy
  • Terabytes: TiBy

​
Measures of Rates of Consumption

For example, services that want to price on maximum rates of consumption:
  • Gigabytes per second: GiBy/s
  • Megabytes per hour: MiBy/h

​
Measures of Computing Resource

For example, services that want to price on sum of memory allocation over time, that is, for memory allocation multiplied by execution time for called computing functions:
  • Gigabyte-seconds: GiBy.s
  • Megabyte-hours: MiBy.h

​
Non-Units of Measure - Counts

Counts aren’t strictly units of measure, but within UCUM curly braces can be used to represent them as described in Appendix A of the UCUM specification. For example, a service that wants to price on the basis of number of API calls:
  • A count of number of API calls: {API_calls}
  • A count of the number of API calls per second: {API_calls/s}
Tip: Other Resources? You might also like to consult the Wikipedia article on the Unified Code for Units of Measure.

​
Custom Fields

You can define Custom Fields when creating a Meter or edit the Meter at a later date to do this. Any Custom Fields you create for an individual Meter override those you’ve created for Meters at the Organizational level. We strongly recommend reviewing Working with Custom Fields before you create and use Custom Fields.