> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metricanic.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Record event revenue, cost, and value

> Choose fixed or incoming payout, model an event expense, and understand which amounts change campaign profit.

A conversion count tells you how often an action happened. Revenue and cost tell you whether that action was profitable. Configure them separately so a free registration, a paid order, and a commission expense do not all produce the same accounting result.

An event action answers three questions: should this event count as a conversion, what revenue does it record, and what cost does it record? A fourth input, `value`, can hold a measurement such as units sold without changing revenue.

## Pick the revenue source

The **Revenue** selector is available in **Advanced**. **Simple** already uses **From incoming event** and hides this selector.

| Setting                       | When it fits                                                  | Result for incoming `payout=24.50` |
| ----------------------------- | ------------------------------------------------------------- | ---------------------------------- |
| **No revenue**                | Form starts, rejected leads, or other stages with no earnings | USD 0                              |
| **Fixed amount**, set to `20` | Every qualifying occurrence earns the same fee                | USD 20                             |
| **From incoming event**       | Payout differs between orders or offers                       | USD 24.50                          |

For a network that pays a flat fee and has no payout macro, a fixed amount is sufficient. For variable order values, pass the amount in the incoming event and select **From incoming event**.

A missing or invalid incoming payout becomes zero with **From incoming event**. The event can still count as a conversion, so a conversion count with zero revenue is a reason to inspect the amount rather than immediately blaming attribution.

Metricanic displays money in USD. The incoming endpoint does not use a `currency` parameter to convert amounts. Convert money in the sending system when needed and keep revenue and cost on the same currency basis.

## Decide whether there is an additional event cost

| Setting                | Use it when                                                    | Example                                        |
| ---------------------- | -------------------------------------------------------------- | ---------------------------------------------- |
| **No event cost**      | The expense is already captured as traffic spending            | No extra cost from this action                 |
| **Fixed amount (CPA)** | Each occurrence creates a fixed expense                        | `4` adds USD 4 per occurrence                  |
| **Revenue share (%)**  | The expense is a percentage of this event's calculated revenue | Revenue `20` and share `30` produce USD 6 cost |

An event cost is added to tracked visit cost when its cost contribution is enabled. If you already record the full ad bill as traffic cost, adding the same bill again through an event action would overstate your spending.

Revenue share uses the event's calculated revenue. A fixed revenue of USD 20 with an incoming payout of USD 24.50 and a 30% share produces USD 6 event cost. It does not use 30% of the discarded incoming amount.

## Send a percentage of revenue to a partner

Use the calculated event cost in an outgoing postback when a partner should receive a share of each payout. Set **Revenue** to **From incoming event**, set **Event cost** to **Revenue share (%)**, and enter `50` for half. Put `{event_cost}` in the amount parameter of **Destination URL**.

For an incoming `payout=100`, Metricanic records USD 100 event revenue, calculates USD 50 event cost, and sends `50` through `{event_cost}`. Using `{payout}` in that same URL would send `100`.

This setup normally includes the USD 50 in overall **Cost**, reducing **Profit**. Use it for a real commission or expense. Changing only the amount disclosed to a receiver is a different requirement from recording a cost. See [Send 50% of revenue in an outgoing postback](/conversions/postbacks#send-50-percent-of-revenue-in-an-outgoing-postback) for the URL example, verification steps, and limits.

## Set up a purchase with a commission

Suppose one order earns USD 20 and costs a 30% commission. The visitor also cost USD 0.50 in traffic spending.

1. Edit the campaign's purchase event in **Events and rules**.
2. Enable **Count as conversion**.
3. Set **Revenue** to **From incoming event**.
4. Set **Event cost** to **Revenue share (%)** and enter `30`.
5. Save the campaign.
6. Send a new purchase event with `payout=20` and a stable transaction ID.
7. Open a report containing that visit and add **Revenue**, **Cost**, **Profit**, and the event's indexed amount columns.

For this isolated visit and purchase, expect:

| Metric                       | Result             |
| ---------------------------- | ------------------ |
| Conversions                  | 1                  |
| Revenue                      | USD 20             |
| Event 1 / Revenue 1 / Cost 1 | 1 / USD 20 / USD 6 |
| Cost                         | USD 6.50           |
| Profit                       | USD 13.50          |

The difference between **Cost 1** and **Cost** is the USD 0.50 visit expense. The indexed event column is useful for checking the commission calculation independently of traffic spending.

## Understand inclusion in totals

Selecting a revenue or cost mode normally enables its contribution to the corresponding overall total. Imported actions can carry a different inclusion setting. For those actions, the full editor shows **Include in revenue metrics** or **Include in cost metrics**. These controls are not shown for an ordinary action whose inclusion follows its selected mode. The event's **Affects Revenue** and **Affects Cost** fields show the resulting flags in **Events**.

**Revenue N** and **Cost N** show recorded amounts for Event ID N, including amounts excluded from overall totals. **Revenue** and **Cost** use the contribution flags. **Count as conversion** controls counts independently of both amounts.

This separation lets you keep a stage's recorded payout visible without adding it twice to campaign revenue. For example, if the network sends the full order amount at both order creation and payment, decide which stage contributes to overall revenue.

A [manual cost correction](/reports/cost-corrections) changes the aggregate cost calculation for its campaign period. It can make **Cost** differ from both raw amounts and the sum of indexed event costs.

## Keep quantity separate from money

For a two-item order, send:

```text theme={null}
/event/ACTUAL_SIGNED_CLICK_ID?idx=1&payout=20&value=2&txuid=order-1042
```

After processing, **Value 1** increases by `2`. Two such orders give **Value 1 = 4**, not an average of two. Use a [custom metric](/reports/custom-metrics), such as `ifnull(value1 / event1, 0)`, when you want units per recorded order event.

## When the amounts are unexpected

* **Fixed revenue ignores the sender's amount:** this is the purpose of fixed mode. Choose incoming revenue for variable payout.
* **A conversion has no revenue:** check the numeric payout, revenue mode, inclusion flag, and winning rule.
* **Overall cost exceeds event cost:** inspect traffic cost and other contributing events.
* **Revenue exists without conversions:** inspect **Count as conversion**. Monetary contribution can be intentional without a conversion count.
* **A refund did not reduce revenue:** the incoming endpoint does not accept negative payout as a refund or update an earlier order by status.

See [Metric dictionary](/reports/metrics) for how the resulting amounts affect CPA, ROI, and profit margin.