Unit Metric Case Studies
Case Study 1: Wants to understand a single unit cost
Scenario
Company 1 wants to analyze their cost per daily active user in their platform. There is no additional information they need other than cost data divided by the number of users in their system, broken out by day.
Solution
Example shape of the stream data posted to their daily-active-user
stream
{
"records": [
{
"timestamp": "2023-11-07",
"value": 10011
}
]
}
Using the new endpoint, the stream name will now be derived from the path parameter as outlined in the API documentation. For example, using this example, stream path would be https://api.cloudzero.com/unit-cost/v1/telemetry/metric/daily-active-user
Case Study 2: Has a single, simple associated cost
Scenario
Company 2 wants to analyze their spend data per API call, broken out by Service.
Solution
In order for the metric data to filter by Service appropriately when the Service dimension is used in the dashboard, the metric data needs to include the appropriate service
associated to each value in the data we receive.
Example shape of the stream data posted to their https://api.cloudzero.com/unit-cost/v1/telemetry/metric/spend-by-api-call
stream:
{
"records": [
{
"timestamp": "2023-11-06",
"associated_cost": {
"custom:Company Services": "aggregation"
},
"value": 10011
}
{
"timestamp": "2023-11-07",
"associated_cost": {
"custom:Company Services": "streaming"
},
"value": 458.33
}
{
"timestamp": "2023-11-06",
"associated_cost": {
"custom:Company Services": "allocate"
},
"value": 112.53
}
{
"timestamp": "2023-11-07",
"associated_cost": {
"custom:Company Services": "budget"
},
"value": 225
}
]
}
In this case, we have a single value, number of API calls per hour, each associated with different values for the Company Services
dimension.
Case Study 3: Single associated cost & multiple streams
Scenario
Company 3 is a video streaming service and they want to analyze their cost per user per user type, in addition to their total plays per user per user type. This request requires two streams, one providing the number of users per day and another providing number of plays per day, both broken out by user type (logged-in vs anonymous).
Solution
In order for the metric data to filter appropriately when the User Type dimension is used in the dashboard, the metric data needs to include the appropriate User Type
associated to each value in the data we receive.
Example shape of their https://api.cloudzero.com/unit-cost/v1/telemetry/metric/total-streams-by-day
stream:
{
"records": [
{
"timestamp": "2023-11-06",
"associated_cost": {
"custom:User Type": "logged-in"
},
"value": 591063.958333333
}
]
}
Example shape of their https://api.cloudzero.com/unit-cost/v1/telemetry/metric/total-users-by-day
stream:
{
"records": [
{
"timestamp": "2023-11-06",
"associated_cost": {
"custom:User Type": "anonymous"
},
"value": 359491.333333333
}
]
}
Case Study 4: Multiple associated costs & single stream
Scenario
Company 4 wants to analyze their cost per client per region. This request requires two associated cost dimensions, client and region.
Solution
In order for the metric data to filter appropriately when the Client and Region dimensions are used in the dashboard, the metric data needs to include the appropriate Client
and Region
associated to each value in the data we receive.
Example shape of their https://api.cloudzero.com/unit-cost/v1/telemetry/metric/client-and-region
stream:
{
"records": [
{
"timestamp": "2023-11-01",
"associated_cost": {
"custom:Client": "Client 123",
"Region": "Australia"
},
"value": 84
},
{
"timestamp": "2023-11-01",
"associated_cost": {
"custom:Client": "Client 456",
"Region": "Europe"
},
"value": 2978
},
{
"timestamp": "2023-11-01",
"associated_cost": {
"custom:Client": "Client 789",
"Region": "North America"
},
"value": 26
}
]
}
📘 Please Note: In this example, we are using both a custom dimension, and a CloudZero default dimension of Region. As you can see in the example above, when using a default dimension you should not provide the custom: prefix.
Case Study 5: Dimensions defined from associated dimensions
Scenario
Company 6 wants to analyze their cost per API call broken out by Customer. It’s a simple filtered metric situation.
Example shape of their https://api.cloudzero.com/unit-cost/v1/telemetry/metric/my-customer-ids
stream:
{
"records": [
{
"timestamp": "2023-12-07",
"associated_cost": {
"custom:CustomerID": "743e5233-82a1-42e0-a7a0-c66ac6778558"
},
"value": 999
}
]
}
This works fine for the Customer ID
dimension, but they have a dimension called CustomerName
that is derived from Customer ID
and intuitively, they expect would filter the metric data with the cost data.
However, they are surprised to discover that this is not the case. Why did this not work?
The answer is…
🚧 You must explicitly define all dimensions you expect to filter the metric data in the
associated_cost
parameter.In addition, please keep in mind that any dimension you associate with a metric needs to be as static as possible. That is, if any value changes in the underlying data it will break any historical records that contained the previous value.
For example, if
CustomerID
in the above example is sent to us, and then the customer changes that ID, the data we already received with the old ID value will not be automatically updated to reflect the new name.Please Note: This warning does not include additions to the data, only modifications.
Updated 10 months ago