# Build a Unit Economics Model

This guide explains how to build a unit economics model inside Model Reef using drivers and variables that link revenue, cost of goods, operating costs and acquisition costs to units such as customers, orders or active users.

## Before you start

You should have:

* A model that at least roughly represents your revenue and direct costs.
* A clear idea of your economic unit, for example:
  * Customer.
  * Subscription.
  * Order.
  * Project.
* An understanding of drivers and variables in Model Reef.

If needed, review:

* **Drivers and Variables Overview**
* **Build a Pricing Model**

## What you will build

* Drivers representing units, price per unit and cost per unit.
* Variables that translate these into revenue, COGS and acquisition costs.
* A view of contribution margin per unit and payback on acquisition costs.
* A structure for comparing unit economics across products or segments.

{% stepper %}
{% step %}

### Define your core unit and horizon

Start by defining:

* The economic unit you care about:
  * For example a customer contract, an order or a subscription.
* The horizon:
  * Single period unit economics (for example per month).
  * Lifetime unit economics (for example over the expected life of a customer).

This determines which drivers and variables you need.
{% endstep %}

{% step %}

### Create unit and pricing drivers

* In the Data Library, create **Operational drivers** for units, for example:
  * `Units - Active Customers`
  * `Units - Orders`
* Create **Economic drivers** for pricing, for example:
  * `Price per Unit - Standard`
  * `Price per Unit - Premium`
* Configure these drivers over time:
  * Growth in units.
  * Changes in pricing as strategy evolves.

These drivers represent the basic demand and price story.
{% endstep %}

{% step %}

### Build revenue variables from unit drivers

* Create variables such as:
  * `Revenue - Standard Units`
  * `Revenue - Premium Units`
* Use formulas approximating:

{% code title="Formula (conceptual)" %}

```
```

{% endcode %}

* If relevant, add seasonality or contract term effects via timing settings.

These variables will feed straight into P\&L and Cash Waterfall revenue.
{% endstep %}

{% step %}

### Create cost per unit drivers and COGS variables

* In the Data Library, create **Economic drivers** for cost per unit, for example:
  * `COGS per Unit - Standard`
  * `COGS per Unit - Premium`
* Build **COGS variables** that multiply units by cost per unit drivers:

{% code title="Formula (conceptual)" %}

```
```

{% endcode %}

* Consider timing delays if costs are paid before or after revenue (this creates working capital impacts).

This creates a direct link between unit volumes and direct cost of goods.
{% endstep %}

{% step %}

### Model acquisition and servicing costs

To capture full unit economics, include:

* Customer acquisition costs (CAC).
* Ongoing servicing or support costs.

You can model these as **Opex variables** driven by units or revenue, for example:

* `CAC = New customers × CAC per customer`.
* `Support Opex = Active customers × Support cost per customer per period`.

Use drivers in the Data Library for CAC per customer and support cost per customer.
{% endstep %}

{% step %}

### Derive unit economics metrics

Build derived metrics using custom formulas and charts such as:

* Contribution margin per unit\
  (Price per unit minus cost per unit minus variable servicing cost per unit).
* Contribution margin percentage\
  Contribution per unit divided by Price per unit.
* CAC payback period\
  CAC per customer divided by Contribution per customer per period.
* Lifetime value (approximate)\
  Contribution per period × expected life in periods.

You can implement these as chart formulas or external calculations using exported series.
{% endstep %}

{% step %}

### Compare unit economics across segments or products

* Create separate sets of drivers and variables for different segments or products, for example:
  * `Units - Self Serve`, `Units - Enterprise`
  * `Price per Unit - Self Serve`, `Price per Unit - Enterprise`
* Build separate revenue, COGS and CAC variables per segment.
* Use charts or reports to compare:
  * Contribution margin per segment.
  * CAC payback per segment.
  * Aggregate impact of shifting mix between segments.

This shows where you should invest versus where you should limit growth.
{% endstep %}
{% endstepper %}

## Check your work

* Units, pricing, costs and acquisition drivers all connect logically.
* Revenue and COGS variables correctly reflect unit times price and unit times cost per unit.
* CAC and servicing costs scale reasonably with unit counts.
* Derived metrics show realistic contribution and payback behaviour.

## Troubleshooting

<details>

<summary>Unit economics look too good</summary>

Check that all relevant costs are included, including acquisition, support and overhead allocations where appropriate.

</details>

<details>

<summary>Payback does not stabilise</summary>

For subscriptions or long lived units, ensure you model churn or finite contract lengths, not infinite lifetimes.

</details>

<details>

<summary>Hard to reconcile with total P&#x26;L</summary>

Make sure that your unit driven variables represent the bulk of revenue and direct cost, and that manual overrides are minimal.

</details>

## Related guides

* [Franchisee Unit P\&L Model](/use-cases/franchise-networks-franchisors-and-franchisees/franchisee-unit-p-and-l-model.md)
* [Variable Auto Creation](/help/xero-integration/variable-auto-creation.md)
* [Variable Overview](/help/drivers-variables-and-timing/variable-overview.md)
* [Autocomplete Behaviour](/syntax/formula-syntax/autocomplete-behaviour.md)


---

# 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://help.modelreef.io/how-tos/operations-and-unit-economics/build-a-unit-economics-model.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.