# Offering metered Usage

**Definition (short).** Customers pay in proportion to what they consume—API calls, GB stored, kWh, messages, transactions. Revenue scales with usage, not (only) with time or seats; pricing can be linear or tiered.

**Recent examples.** AWS, Azure, and GCP bill per compute hour, GB, or request; AWS alone produced >$100 B in 2024 revenue. Utilities charge [\~16.4¢ per kWh](https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a\&utm_source=chatgpt.com) to U.S. residential customers on average (Apr 2025), and the average home uses [\~10,500 kWh/year](https://www.eia.gov/energyexplained/use-of-energy/electricity-use-in-homes.php?utm_source=chatgpt.com) (≈875 kWh/mo).

**Historical example.** Edison’s Pearl Street Station (1882) billed electricity by the kilowatt‐hour—one of the earliest metered models. Taxi meters (1890s) and postage (per-letter) are other classic pay-per-use forebears.

<figure><img src="/files/YRrfgUplQ86kybINLBZ6" alt=""><figcaption></figcaption></figure>

#### KPI Definitions

1. **Profit per Unit of Usage (PPUU)**\
   \&#xNAN;*EN:* Profit generated for each billable unit (after variable costs).\
   \&#xNAN;*Pseudo:* `PPUU = (Effective_Unit_Price - Unit_Cost) / Unit` or more commonly `(Revenue - Variable_Costs) / Total_Units`

   *Why:* Forces clarity on both monetization (price) and efficiency (cost). High volume without profit per unit is a trap; high margin without volume underutilizes the model.\
   \&#xNAN;*Benchmark:* Digital infra aims **70–85% gross margin**.
2. **Total Usage Volume (UV)**\
   \&#xNAN;*EN:* Sum of consumed units (API calls, kWh, GB, etc.).\
   \&#xNAN;*Pseudo:* `Σ usage_units_all_customers`\
   \&#xNAN;*Why:* Primary revenue driver; shows engagement/demand intensity.\
   \&#xNAN;*Benchmark:* Target **>30–50% YoY** usage growth early on.
3. **Effective Unit Price (EUP)**\
   \&#xNAN;*EN:* Average realized price per unit after tiers/discounts.\
   \&#xNAN;*Pseudo:* `Total_Usage_Revenue / Total_Usage_Volume`\
   \&#xNAN;*Why:* Monetization efficiency; erosion may signal commoditization.
4. **Gross Margin per Unit % (GMU)**\
   \&#xNAN;*EN:* % of unit price kept after variable cost.\
   \&#xNAN;*Pseudo:* `(EUP - Unit_Cost) / EUP * 100`\
   \&#xNAN;*Why:* Unit economics; determines scalability of volume growth.
5. **Active Users / Accounts (AU)**\
   \&#xNAN;*EN:* Unique customers generating billable usage in period.\
   \&#xNAN;*Pseudo:* `COUNT(DISTINCT user_id WHERE usage>0)`\
   \&#xNAN;*Why:* Breadth of adoption; needed to diversify revenue and de-risk whale dependence.
6. **Average Usage per User (AUPU)**\
   \&#xNAN;*EN:* Mean consumption per active user.\
   \&#xNAN;*Pseudo:* `Total_Usage_Volume / Active_Users`\
   \&#xNAN;*Why:* Depth of engagement; helps forecast infra needs.
7. **Tiered / Overages Mix % (TIER)**\
   \&#xNAN;*EN:* Share of revenue from higher tiers or overage charges vs base rate.\
   \&#xNAN;*Pseudo:* `Revenue_from_Tiers_>1 / Total_Usage_Revenue * 100`\
   \&#xNAN;*Why:* Shows success of pricing design in capturing heavy users’ value.
8. **Unit Cost (Variable)**\
   \&#xNAN;*EN:* Direct variable cost per unit (bandwidth, compute, fuel).\
   \&#xNAN;*Pseudo:* `Variable_Costs / Total_Units`\
   \&#xNAN;*Why:* Drives GMU; optimizing infra/vendor deals pushes PPUU up.
9. **New Active Users (ACQ)**\
   \&#xNAN;*EN:* Fresh customers who generated usage this period.\
   \&#xNAN;*Pseudo:* `COUNT(users with first_usage_date in period)`\
   \&#xNAN;*Why:* Pipeline for future volume; complements expansion of existing users.
10. **Expansion Usage % (EXPu)**\
    \&#xNAN;*EN:* Incremental usage from existing users vs last period.\
    \&#xNAN;*Pseudo:* `(Usage_existing_t - Usage_existing_{t-1}) / Usage_existing_{t-1} * 100`\
    \&#xNAN;*Why:* Land-and-expand health metric in usage world.
11. **Growth Efficiency Factor (GEF)** *EN:* How efficiently you convert capacity (supply) growth into profitable usage growth. *Pseudo:* `GEF = (Demand_Growth % / Capacity_Growth %) * (GMU / 100)` *Why:* If you scale infra faster than demand or without keeping margins, you destroy PPUU. GEF >1 means you’re growing demand faster than capacity (or holding margin so growth is efficient). *Benchmark idea:* Cloud/API teams often target **GEF ≥ 1.2** in growth phases; utilities, constrained by regulation, hover near 1 (capacity expansions match load forecasts).
12. **Demand (Usage) Growth % (DG)** *EN:* Year-over-year change in total billed usage units. *Pseudo:* `(Usage_t − Usage_{t−1}) / Usage_{t−1} * 100` *Why:* Core top-line driver in metered models; faster than price hikes, usage growth proves product value. *Benchmark idea:* Early-stage APIs: **30–50%+ YoY**; mature utilities: **1–2% YoY**.
13. **Capacity Growth % (CG)** *EN:* YoY change in maximum deliverable capacity (compute throughput, MW, TPS). *Pseudo:* `(Cap_t − Cap_{t−1}) / Cap_{t−1} * 100` *Why:* Overbuild wastes capex; underbuild throttles revenue (throttling, outages). *Benchmark idea:* hyperscalers expand capacity \~in line with forecasted demand + buffer (e.g., **20–40% YoY** during high-growth years).
14. **Capacity Utilization % (CI)** *EN:* Average share of provisioned capacity actually used (often measured at peak window or averaged). *Pseudo:* `Avg_Usage / Provisioned_Capacity * 100` *Why:* Direct efficiency metric—too low means idle assets, too high means no headroom for spikes. *Benchmark idea:* Power plants target **\~60–80%** load factors; cloud infra teams often aim **40–60% average** to leave burst room.
15. **Provisioned Capacity (PC)** *EN:* The maximum sustained throughput you can deliver (e.g., kWh/day, requests/sec). *Pseudo:* `Cap = Σ(node_capacity)` (or grid MW installed) *Why:* Sets the ceiling; also denominator for utilization. Needed for capex planning.
16. **Peak Usage / Peak Load (PU)** *EN:* Highest instantaneous (or short-window) usage observed in the period. *Pseudo:* `max(usage_rate_t)` over period

    *Why:* Determines required headroom and auto-scaling needs; drives worst-case cost.

    *Benchmark:* Peak multiples of 1.5–3× average are common; extreme bursty APIs can see 10×.
17. **Peak-to-Average Ratio (PAR)** *EN:* Ratio of peak load to average load. *Pseudo:* `Peak_Usage / Average_Usage`

    *Why:* Quantifies burstiness; high PAR stresses infra cost and pricing design (need overage/tier pricing).

    *Benchmark:* Utilities PAR \~1.3–1.6; consumer APIs (chat/LLM) can be **>3–5** during viral events.
18. **Capex per Unit Capacity (CAPU)** *EN:* Capital required to add one unit of capacity (e.g., $ per kW, $ per 1k TPS). *Pseudo:* `Capex_added / Capacity_added`

    *Why:* Guides ROI on expansion; lower CAPU means cheaper scaling.

    *Benchmark:* Data center build costs ≈ **$7–12M per MW**; GPU clusters vary wildly but trend \~$25–40 per deployable TFLOP.
19. **Auto-Scaling Latency (ASL)** *EN:* Time it takes to provision additional capacity after demand spike. *Pseudo:* `t(scale_complete) - t(threshold_trigger)`

    *Why:* Slow scaling means you must over-provision; fast scaling lets you run lean.

    *Benchmark:* Best cloud-native infra targets **seconds–minutes**; regulated utilities can’t “auto-scale,” they plan years ahead.
20. **Headroom % (HR)** *EN:* Buffer capacity above expected peak. *Pseudo:* `(Provisioned_Capacity - Expected_Peak) / Provisioned_Capacity * 100`

    *Why:* Prevents outages and throttling; too much wastes capital.

    *Benchmark:* Cloud SREs often keep **20–30%** headroom; grid operators maintain N-1 redundancy (varies but \~15–25% capacity reserve).
21. **Usage Concentration Risk %** *(auxiliary)*\
    \&#xNAN;*EN:* % of total usage (or revenue) coming from top X customers.\
    \&#xNAN;*Pseudo:* `Usage_top_X / Total_Usage * 100`\
    \&#xNAN;*Why:* Whales are great—until they churn. Tracks fragility of revenue base.\
    \&#xNAN;*Benchmark:* Aim <30% from top 5; many infra/API firms start >50% and work it down over time.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.getdot.ai/ai-analytics-wiki/kpi-trees/offering-metered-usage.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.