# 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="https://3709841693-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCeRlmJf2y704TpjpubE1%2Fuploads%2Fj5LpCoNqoZzAU661nYF5%2Fimage.png?alt=media&#x26;token=54e48d3e-1028-4eec-933a-a32552cadc15" 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.