Business Metrics and Unit Economics Questions

Definitions:

• GMV (Gross Merchandise Volume): total dollar value of goods/services sold through the marketplace in a period (e.g., $1,000,000).
• Take rate: the % of GMV the marketplace captures as revenue (fees, commissions). It’s revenue/GMV.
• Gross margin (marketplace view): (revenue − direct variable costs) / revenue. It measures profitability on each dollar of marketplace revenue.
• Contribution margin (common marketplace metric): (revenue − variable costs) / GMV or expressed as a % of GMV; it shows how much of GMV contributes to covering fixed costs and profit.

How they interact (conceptually):

• Take rate determines revenue from GMV (revenue = GMV × take rate).
• Variable costs are often also a % of GMV (e.g., payment fees, refunds). If variable cost rate is lower than take rate, the marketplace generates positive contribution per GMV. Gross margin looks at profitability relative to revenue; contribution margin expresses profitability relative to GMV and is useful for unit economics and scaling decisions.
• Key implication: raising take rate increases revenue linearly, but if variable costs scale with GMV, the incremental benefit equals (take rate − variable cost rate) × GMV.

Example (given numbers):

• GMV = $1,000,000
• Take rate = 12% → Revenue = 1,000,000 × 12% = $120,000
• Variable transaction cost = 3% of GMV → Variable cost = 1,000,000 × 3% = $30,000
• Gross profit (on revenue) = Revenue − Variable cost = $120,000 − $30,000 = $90,000
• Gross margin = 90,000 / 120,000 = 75%
• Contribution margin (as % of GMV) = 90,000 / 1,000,000 = 9%
  So each $1 of GMV yields $0.09 toward covering fixed costs and profit; each $1 of revenue yields $0.75 of gross profit.

Practical note: include other variable items (refunds, fraud, reimbursements) and fixed costs (platform, marketing, ops) when moving from contribution margin to net profitability.

Approach: show the immediate ARR change from a 30k MRR contraction, then produce 12‑month MRR and ARR (annualized run‑rate) under three scenarios. I'll report deltas (change vs. prior baseline) so this is plug‑and‑play with your existing baseline MRR.

Key formulae:

• ARR change from a one‑time MRR change = ΔMRR * 12
• MRR_t = baseline_MRR + ΔMRR_t
• Revenue over 12 months = sum_{t=1..12} MRR_t
• Average ARR over period (annualized realized revenue) = (Revenue over 12 months)

Let Δ = -30,000 (MRR reduction, dollars). Show monthly ΔMRR and cumulative 12‑month impact (we report MRR delta and ARR-equivalent lost revenue = sum monthly ΔMRR).

Scenario definitions (ΔMRR each month in $):

1. Permanent downgrade: months 1–12: Δ = -30,000
2. Temporary, recovery in 3 months: months 1–3: Δ = -30,000; months 4–12: Δ = 0
3. Downgrade then upsell in month 6: months 1–5: Δ = -30,000; month 6: net change = -30,000 + upsell_amount (example: upsell 40,000 → net +10,000 from baseline at month6); months 7–12: reflect post‑upsell level

Example table (showing ΔMRR and 12‑month totals). Values are deltas vs. baseline:

1. Permanent | -30,000 each month | -30,000 * 12 = -360,000 | -360,000 (ΔMRR*12)
2. Temporary (3mo) | months 1–3: -30,000; months 4–12: 0 | -30,000 * 3 = -90,000 | immediate ARR drop = -360,000, but run‑rate returns to baseline after month3
3. Downgrade + upsell (example upsell 40k in month6) | months1–5: -30,000; month6: -30,000+40,000=+10,000; months7–12: +10,000 | total = (-30k5) + (+10k7) = -150k + 70k = -80,000 | immediate ARR change at event = -360,000; post‑upsell steady run‑rate = +10,000 above baseline → ARR = +120,000 above baseline after month6

Interpretation & how to present to stakeholders:

• Immediate ARR impact uses ΔMRR*12 (shows the run‑rate hit today).
• 12‑month realized revenue impact = sum of monthly ΔMRR (shows cash flow / revenue impact over next year).
• Use the table above but substitute actual upsell assumptions if different. Also show sensitivity: if upsell is 30k, scenario3 ends near neutral; if 50k, net positive.
• Recommend including probability estimates for each scenario to produce weighted forecast and update bookings/churn dashboards to track recovery/upsell timing.

Short answer: Payback period is a timing metric that tells you how long it takes cumulative accounting profits or discounted cash inflows from an investment to equal the initial outlay. It’s useful for quick screening, but it can hide important cash-timing and working-capital issues the CFO cares about. Cash flow (especially operating cash flow) tracks actual cash in/out each period — when revenue is collected, when expenses and capital are paid, and how that affects bank balance.

Why they can diverge:

• Payback often uses accrual or projected revenue recognition (revenues booked when earned) while cash flow depends on collections (DSO), refunds, and payment terms.
• Payback ignores interim negative cash balances, timing of capex, and required working capital increases.
• Payback may ignore financing, taxes, or one-time cash needs (e.g., deposits, inventory build-up).

Metrics to add when presenting unit economics to the CFO:

1. Operating Cash Flow (or Free Cash Flow) per cohort/month — shows real cash generated after opex and capex, period by period.
2. Cash Conversion Cycle (Days Sales Outstanding + Inventory Days − Days Payable Outstanding) or change in Net Working Capital — quantifies timing gap between cash outflows and inflows.
3. Contribution Margin per Unit and Cash CAC Payback (months) — contribution margin shows profitability per sale; express CAC payback in cash months (considering collection lags and gross margin) so CFO sees when cash breakeven occurs, not just accounting payback.

Include short cohort cash-flow charts (monthly cash flow by cohort) and sensitivity scenarios (slow collections, higher refunds) to make the cash implications clear.

Requirements & approach (high level):

• Single canonical event/table for billing events (invoice/payment/subscription_change) plus customer and acquisition tables. Use immutable event logs (append-only) with event_id, source_system, occurred_at, received_at. Derive MRR/ARR via nightly aggregate jobs that are idempotent and windowed for backfill.

Core tables / events to capture:

1. SubscriptionEvent (event_id, customer_id, sku, billing_cycle, event_type: create/renew/upgrade/downgrade/cancel, price, quantity, effective_date, source_system)
2. InvoicePayment (invoice_id, customer_id, amount, currency, status, issued_date, paid_date)
3. Acquisition (acq_id, customer_id, channel, campaign, cost, acquired_at)
4. Customer (customer_id, cohort, region, created_at)
5. ProductCatalog (sku, list_price, billing_cycle)

Primary dimension keys:

• customer_id (always)
• channel (from Acquisition)
• sku (from SubscriptionEvent)
• billing_cycle (monthly/annual) and effective_date

Metric derivations & required signals:

• MRR: sum of normalized monthly price per active subscription row with effective_date within period. Normalize annual to monthly = annual_price/12.
• ARR: MRR * 12 (or sum of normalized annual prices for annual contracts).
• New ARR: ARR attributable to subscriptions whose first_subscription_date ∈ period (use SubscriptionEvent type=create).
• Expansion ARR: delta ARR from upgrade/expansion events where prior ARR >0 and event_type=upgrade/add_seat.
• Churned ARR: ARR lost from cancel/contract_end events (use effective_date and prior active ARR).
• ARPU: MRR / active_customers_count (count distinct active customer_id in period).
• CAC: sum(acquisition.cost) / count(new_customers_acquired_in_period) — tie cost to acquired_at and cost allocation windows if multi-touch.
• LTV: ARPU * gross_margin (%) * average_customer_lifetime (or derive from historical churn rate: LTV = ARPU * (1 / churn_rate) * gross_margin).

Idempotency approach:

• Use event_id + source_system as dedupe keys; ingestion upserts into raw_events by event_id. Downstream aggregates are computed from raw_events with deterministic SQL using last_value() by (event_id) or by selecting the latest received_at per event_id.
• Aggregation jobs write to partitioned, timestamped aggregate tables using upsert semantics (merge on keys: period_start, customer_id, sku, billing_cycle). Make aggregates deterministic and replayable.

Backfill safety:

• Keep event-level raw append-only store with received_at. Aggregation jobs are windowed and can be re-run for any historical date range. Maintain job run metadata (job_id, target_window_start/end, checksum) and write to aggregate table with run_id; if re-run, MERGE replaces previous rows for that window. Provide slowly changing dimensions snapshots for customer and product to reproduce historic calculations (store effective_date ranges for attributes like price, sku mapping).

Validation & monitoring:

• Row counts and checksum comparisons between raw events and aggregated sums.
• Reconciliation queries: sum(invoice.amount) vs derived revenue by period.
• Alert on unexpected reruns, late-arriving events, or material delta after backfill (>X%).

This plan keeps instrumentation minimal (few event types), uses canonical event IDs for idempotency, partitioned, mergeable aggregates for safe backfills, and clear derivation rules so analysts can reproduce MRR/ARR/LTV calculations.

Basic CAC formula: CAC = Total marketing spend / New customers acquired.

Here: CAC = $150,000 / 1,200 = $125 per customer.

Adjustments

1. Long funnel / multi-campaign acquisition

• Use a longer attribution window and cohort-based CAC: attribute spend across all campaigns that contributed to the cohort of customers who converted (e.g., sum spend over the previous 6–12 months for customers acquired this quarter). This avoids undercounting early-funnel investments.
• Prefer multi-touch or weighted attribution (time-decay or position-based) instead of last-touch so earlier investments get proportional credit. Example: if campaign A (top-funnel) drove awareness and campaign B closed deals, split costs according to attribution weights before dividing by customers.
• Practical step: create cohorts by acquisition date, aggregate all related spend within the chosen window, then compute CAC = aggregated spend / cohort size.

2. Significant offline acquisition channels

• Include offline channel costs (events, print, OOH, sales team) in total spend and reconcile conversions via tracking (promo codes, unique URLs/landing pages, call tracking numbers, CRM matchbacks).
• If direct tracking isn't possible, use econometric or mixed-media attribution (MMM) to estimate offline contribution and allocate a portion of offline spend to acquired customers.
• Also account for shared fixed costs (booth build, agency fees) by allocating them pro rata across channels or per-attribution model.

Notes: Document assumptions (attribution window, weighting) and present CAC along with sensitivity ranges (e.g., CAC = $125 base; with 6-month spend attribution it becomes $X) so stakeholders understand variability.