Metrics

Metrics are a class of data point that can be emitted by your application and collected by RESTful Metrics. Metrics are made up of 3 components: Your application's unique identifier, the name of metric and the value. Optionally, you can submit a distinct user identifier if you want to be able to sort the metric by unique users later on.

Unique Application Identifiers

Each application in your account requires a unique identifier. Data points collected using this identifier will be properly attributed to the respective application. For more information about identifiers and creating applications in your account, see the Applications section.

Metric Names

Each metric requires a name that identifies that metric in your account. Names are case-sensitive and are only unique to a single account. All of your applications, in the same account, can submit data points to a metric. If you have multiple accounts, you will have a separate metric "namespace" for each account.

New metrics are automatically created when the first metric of a new name is collected by RESTful Metrics.

Naming Conventions

On the dashboard, metric names are automatically humanized and title-cased for the convenience of the dashboard users. That means that if you name a metric "new_accounts", it will automatically show up on the dashboard as "New Accounts".

It's common practice to name your metrics in the plural form since you will more than likely have multiple data points for that metric. We will automatically pluralize your metric name on the dashboard, though. So if your metric is named "new_account", it will automatically show up as "New Accounts" on the dashboard.

It's important though to always submit your data points using the original metric name you selected. Metrics cannot currently be renamed.

Data Point Collection and Values

Data points can be collected in real-time or on a delay. There are benefits of both and typically an application will collect some metrics in real-time and others on a delay. Each data point is emitted by your application using the same API, they are just emitted at different frequencies.

Real-time Data Points

There are certain events in your application, like when a user signs up or someone performs a search, that need to be tracked in real-time. For these type of metrics, you'll want to emit a data point from your application as they happen. You'll want to integrate RESTful Metrics somewhere within the code path for each of these real-time events.

Real-time data points will typically have a value of 1.

Delayed Data Points

Some data points aren't necessarily a user-based event. For these data points, such as user or account totals, you'll want to only submit a single data point per day. Each data point will then be aggregated over time and from the dashboard you'll be able to see the growth patterns for each of these metrics.

Delayed data points will typically have a value greater than 1.

Distinct User Identifiers

If you submit a distinct user identifier along with each data point, users of the dashboard will be able to aggregate metrics based on uniques. The distinct user identifier can be any string that distinctly identifies the user currently responsible for the specific data point being transmitted. In web applications, this might be the value of some unique cookie.