Unit economics: cost per X · ZopDev University

Outcome

By the end of this lesson, you will be able to configure a unit metric in ZopNight, trace cost-per-X over time, and avoid the most common denominator and source-pipeline pitfalls.


Prerequisites	M4.5.L1-L4 (showback dimensions + tagging)
Time	9 minutes

1. Concept

Unit economics means dividing cost by something the business counts: active users, orders, requests, tenants, anything that grows as the company grows.

That ratio is the honest measure of efficiency. A rising bill means nothing on its own when the business is also getting bigger; a rising cost per customer means something immediately.

ZopNight draws that ratio over time on Cost → Unit economics, and can lay it over a team’s cost chart on Cost Reports → Teams.

This lesson is the product mechanics: configuring a unit metric, wiring up where the number comes from, and reading the trend. You have what you need for that above.

Choosing a denominator well, and building the practice around it, is a larger subject. T5.M5.3 takes it up when you get there.

Setup in ZopNight

1. DEFINE a unit metric
   Cost → Unit economics → New

   Name:          monthly_active_users
   Label:          MAU
   Display scale:  1     (or 100, 1000 for compactness)
   Source:         Push API (most common; alternatives below)
   Cadence:        Daily values
   Retention:      24 months (matches cost data retention)

2. CONFIGURE the source
   Push API:      Customer's pipeline POSTs daily {date, value} arrays
   CSV upload:    Bulk historical data; one-time or periodic
   Pull API:      ZopNight fetches from customer's HTTPS endpoint daily
   (L6 covers ingest paths in detail)

3. AUTHENTICATE the source
   API key or PAT: depends on the path
   First push:    today's MAU = 5,000

4. STORAGE
   ZopNight persists in unit_metric_values
   Cross-references to date for daily alignment with cost

5. READ the trend
   Cost → Unit economics charts cost-per-MAU over the last 30 days

Where unit metrics appear

SURFACE                      USE
──────────────────────────────────────────────────────────────────
Cost → Unit economics        Metric definitions (source, last value
                             date) and a 30-day cost-per-unit trend,
                             one metric at a time

Cost Reports → Teams         Pick a metric for a team: cost-per-unit
                             summary plus an overlay on the team's
                             cost chart; a failed pull is flagged

There is no unit-economics dashboard widget and no stored target: keep your target alongside the review and compare by hand.

Reading the trend

UNIT ECONOMICS for MAU (read at each month end):

  Each point:   cost for the day, MAU for the day, $ per MAU

  Apr:  spend $84K  / MAU 11,700  =  $7.20 per MAU
  May:  spend $96K  / MAU 14,200  =  $6.76 per MAU
  Jun:  spend $102K / MAU 16,000  =  $6.40 per MAU

  ABSOLUTE COST  +21%  (Apr → Jun)
  PER-MAU COST   -11%  (Apr → Jun)  ← efficiency improving

  STORY: cost is growing, but slower than the user base.
         Efficiency is improving even though headline cost is up.

The story changes completely when you add the denominator. The absolute number rises; the per-MAU number falls. Both are real; the per-MAU story is the right one for leadership.

Per-team unit economics

When you scope a metric to a team on Cost Reports → Teams, the comparison is more nuanced:

PER-TEAM COST-PER-MAU:
  platform-team:    $7.20/MAU
  product-team:     $6.40/MAU
  data-team:        $12.50/MAU
  ml-team:          $48.00/MAU (intensive workload)

CAVEAT: cost-per-MAU is not a competitive metric across teams.
Different teams have different workload natures. ml-team running
inference for AI features will always be more expensive per MAU
than product-team running CRUD endpoints.

USE per-team unit metrics for:
  - Trending within the team (is THIS team improving?)
  - Comparison to the team's own goal (kept outside ZopNight)
  - Investment justification ("ML workload is $48/MAU; we expect
    that to drop to $35 with the new model")

DON'T USE for:
  - Cross-team competition
  - Resource-allocation fairness arguments
  - Performance reviews

The denominator matters more than the absolute number. The same team can have wildly different per-X numbers depending on whether X is “active user,” “request,” “tenant,” or “transaction.” Pick the denominator that matches the value the team produces.

Common pitfalls

PITFALL                                  FIX
──────────────────────────────────────────────────────────────────
Wrong denominator                         Tie to revenue or core KPI.
                                          "MAU" is generic; "active
                                          paying subscribers" or
                                          "transactions" is sharper.

Stale data                                Push daily and check the
                                          Last Value date on Cost → Unit
                                          economics. Nothing alerts when
                                          values stop arriving.

Multiple metrics; no priority             Pick one primary metric;
                                          track 3-5 max. More creates
                                          confusion in reports.

Comparing teams unfairly                  Cost-per-MAU is not directly
                                          comparable across teams with
                                          different workload natures.
                                          Use within-team trends
                                          instead of cross-team
                                          rankings.

Denominator changes definition            "MAU" today vs "MAU" six
                                          months ago must mean the
                                          same thing for trends to be
                                          interpretable. Document the
                                          definition; resist redefining.

Anchoring on absolute cost                Leadership wants per-X
                                          number; engineering wants
                                          absolute. Both views,
                                          contextually.

The “denominator changes definition” pitfall is the most insidious. Six months in, someone redefines MAU to include logged-out browsing sessions. The number doubles overnight; the cost-per-MAU halves. The improvement is illusory.

Picking the denominator

The choice depends on the business model:

BUSINESS MODEL                  RECOMMENDED DENOMINATOR
──────────────────────────────────────────────────────────────────
SaaS (B2C / B2B per-seat)        Active users, paid seats
SaaS (B2B per-tenant)            Active tenants, paying tenants
Marketplace                      GMV, transactions, paying customers
API platform                     API requests, paying calls
Ad-supported                     Impressions, sessions, MAUs
E-commerce                       Orders, GMV, paying customers
Consumer mobile                  DAU / MAU, retained users
B2B services                      Contracts, ACV

A common starter is MAU for consumer-facing products, ACV for B2B, GMV for marketplaces. Refine after the basics are working.

Source paths

PUSH API (recommended for live data)
  Customer's analytics platform POSTs daily values
  Authentication: API key or PAT
  Format: [{date: '2026-05-20', value: 5000}, ...]
  Cadence: daily; can backfill historical

CSV UPLOAD (for backfill or batch)
  Multipart CSV upload via UI or API
  One-time or periodic
  Useful for: bulk historical data; small orgs without dev resources

PULL API (when customer prefers central control)
  ZopNight fetches from customer's HTTPS endpoint
  Customer provides: URL, auth mechanism, expected cadence
  Useful for: orgs that maintain central data lakes; compliance
  preferences

(L6 covers ingest paths in detail; this lesson covers the metric
itself.)

How ZopNight uses unit metrics

The unit_metric_values table stores daily (date, metric_id, value) triples. The unit economics trend joins this with cost on date to compute cost-per-X for the window. When the view is scoped to a team (Cost Reports → Teams), the join produces that team’s cost-per-X.

For audit purposes, the source of each value is logged: which API call, which user/PAT, what timestamp. Customers preparing for compliance audits can show the data provenance back to the original push.

2. Demo

A SaaS company adding an MAU metric for the first time:

COMPANY:  B2B SaaS, user base growing about 17% MoM
PROBLEM:  CEO sees cloud bill +21% over 90 days; concerned
QUESTION: "Is this growth healthy or wasteful?"

SETUP (one-time, ~30 minutes):
  Step 1: Define metric in ZopNight
            Name: monthly_active_users
            Label: MAU
            Display scale: 1

  Step 2: Configure push from their analytics platform
            Endpoint: POST /orgs/{orgID}/unit-metric-values/{metricId}
            Auth: PAT
            Source: customer's data pipeline pushes daily at 04:00 UTC

  Step 3: Historical backfill (CSV upload)
            Upload 90 days of daily MAU values
            ~90 rows

  Step 4: Open Cost → Unit economics and pick MAU
            The cost-per-MAU trend appears. Done.

REPORT TO CEO (next monthly review):
  Cost-per-MAU, read from the trend at each month end:

    Apr  spend $84K   MAU 11,700   $7.20/MAU
    May  spend $96K   MAU 14,200   $6.76/MAU
    Jun  spend $102K  MAU 16,000   $6.40/MAU

  HEADLINE: "Cost grew 21% as user base grew 37%.
             Cost-per-user fell 11%.
             Growth is more efficient than last quarter."

DECISION:
  CEO understanding shifts from "we're spending more" to
  "we're more efficient per user." Continued growth investment
  approved.

OUTCOME:
  The unit-economics trend reframes the cost conversation. The
  absolute number (which was rising and scary) becomes a sub-
  story; the per-MAU number (which is falling and good) becomes
  the headline.

3. Hands-on (5 min)

For your business, draft the unit-economics setup:

BUSINESS MODEL:        __________ (SaaS / marketplace / etc.)
PRIMARY DENOMINATOR:    __________ (MAU / ACV / GMV / etc.)

DEFINITION OF YOUR DENOMINATOR (one sentence: be specific):
  __________________________________________________________

PIPELINE FOR DATA:
  Source system:          __________ (analytics platform name)
  Ingest path:            Push API / CSV / Pull API
  Cadence:                Daily / weekly
  Owner of the pipeline:  __________

TARGET COST-PER-X:
  Current (estimate):     $______ per __________
  Target (1 year):        $______ per __________
  Strategy to improve:    __________________________________________

POTENTIAL PITFALLS:
  □ Denominator definition could change
  □ Source data could become stale
  □ Cross-team comparison risk
  □ Lack of historical baseline

If you cannot define the denominator in one specific sentence, the metric will drift. Lock the definition before configuring.

4. Knowledge check

Q1

A team’s cost-per-MAU is $7.20 falling to $6.40 over 3 months. The interpretation:

A. Cost is going down now
B. The cost is quite stable
C. The cost is going up
D. Efficiency is improving

Show answer

Correct: D. Absolute cost may be rising, but it’s rising slower than the user base. The unit-economics narrative (“cost-per-user is down 11%”) is more useful than the absolute narrative (“cost is up 21%”) for leadership. Falling cost-per-X = improving efficiency. The absolute number may be up; the unit story is positive.

Q2

The three ingest paths for unit metrics:

A. Just the one path, which is the API and nothing else at all besides it
B. Push API (customer-driven, live), CSV upload (bulk / historical), Pull API (ZopNight-driven, scheduled)
C. Two paths only, which are the Push API and a CSV upload, and no polling option is provided anywhere
D. Only a CSV upload, which is the reason the metric always lags by a whole day or so

Show answer

Correct: B. Customer picks based on their data pipeline shape. L6 covers each in detail. Three paths. Push for live; CSV for backfill; Pull when customer wants central control.

Q3

Per-team unit economics across very different workloads:

A. Different teams have different workload natures
B. Use it to rank the teams against each other
C. Identical metrics across every single team
D. Aggregate at the whole-organisation level only

Show answer

Correct: A. Per-team cost-per-MAU isn’t directly comparable across teams: ML inference will always cost more per MAU than CRUD endpoints. Use the metric for within-team trends and target-tracking, not for cross-team rankings. Use it WITH context, not as a leaderboard. Per-team variation is expected; rankings would be misleading without context. Trend within teams is the right use.

5. Apply

Configure unit metrics on Cost → Unit economics. The setup walks through metric definition, source configuration, and historical backfill. Once values arrive, the metric’s cost-per-unit trend appears on the same page.

For executive reporting, read cost-per-X from that page at each month end and report it with its month-over-month change: this becomes the headline number for monthly cost reviews. There is no unit-economics dashboard widget.

Glossary terms touched

Unit metric · Cost-per-X · Unit economics

Outcome

1. Concept

Setup in ZopNight

Where unit metrics appear

Reading the trend

Per-team unit economics

Common pitfalls

Picking the denominator

Source paths

How ZopNight uses unit metrics

2. Demo

3. Hands-on (5 min)

4. Knowledge check

Q1

Q2

Q3

5. Apply

Related lessons

Glossary terms touched

Start with the bill.