> ## 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.

# Decide what counts as a conversion

> Model leads, purchases, and other funnel stages so conversion totals and revenue answer the right business question.

A submitted form and a paid order are both useful events, but they do not necessarily represent the same business result. Before connecting a postback, decide which action should increase **Conversions**. This choice also changes CV, CR, and CPA throughout your reports.

Metricanic gives a campaign ten event slots, identified by **Event ID** `1` through `10`. An incoming request selects a slot with `idx`. The event's settings decide whether it counts as a conversion, how much revenue and cost it contributes, and whether Metricanic sends an outgoing postback.

The event name helps you recognize the slot in the editor. The sending system must still use its numeric `idx`.

## Choose a useful event structure

For a lead campaign that pays only for approved leads, use this structure:

| Event ID | Meaning        | Count as conversion | Revenue             |
| -------- | -------------- | ------------------- | ------------------- |
| 1        | Lead submitted | Off                 | No revenue          |
| 2        | Lead approved  | On                  | From incoming event |
| 3        | Lead rejected  | Off                 | No revenue          |

Suppose 40 people submit the form, 12 leads are approved at USD 15 each, and 8 are rejected. The other 20 are still pending. Your report should show **Event 1 = 40**, **Event 2 = 12**, **Event 3 = 8**, **Conversions = 12**, and **Revenue = USD 180**.

If you enable **Count as conversion** for both submitted and approved leads, the same flow produces 52 conversions. That can be useful when you intentionally measure several actions, but it will not represent 12 approved customers.

For a campaign with one paid action, one event is enough. **Simple** setup uses Event 1 as a conversion with revenue from the incoming event. Use the full event editor when you need several stages or different treatment for selected traffic.

## Configure the campaign

1. Edit the campaign and open **Events and rules**.
2. In **Defaults**, add the event slots you need and assign clear **Event name** values.
3. Set **Count as conversion** for each event according to your reporting goal.
4. Choose **Revenue** and **Event cost** settings. For the lead example, Event 2 uses **From incoming event** and **No event cost**.
5. Configure **Outgoing postback** only for events you want to send to another platform.
6. Save the campaign.
7. Copy the matching **Incoming event URL** for each stage and configure its trigger in your affiliate network or site.

Send approval for the example with `idx=2&payout=15`. Keep the same event mapping in every system that sends data to this campaign. See [Send incoming events](/conversions/incoming-events) for the full request and transaction ID setup.

## Use a rule when the same event needs different treatment

A rule can change the action for selected visit or event characteristics. For example, you might record a fixed USD 18 for approved leads from one offer and use the incoming payout for all other offers.

Rules are checked in order. All conditions in a rule must match. The first enabled matching rule wins, and Metricanic then looks for the enabled action with the request's Event ID inside that rule. **Defaults** applies when no conditional rule matches.

This order matters. If a rule matches the offer but has no enabled Event 2 action, Metricanic does not continue to the next rule or fall back to Event 2 in **Defaults**. The incoming event can appear without the intended conversion, revenue inclusion, or postback behavior.

Start with working defaults, then add the narrow exception. Keep required events in each matching rule. The editor's **Inherited**, **Customized**, and **Add missing** controls help you maintain that relationship when the event catalog changes.

## Verify the business result

For the lead example, test one submission followed by one approval for a new tracked visit:

1. Send Event 1 with a transaction ID for the lead.
2. Send Event 2 with the same lead identifier and `payout=15`.
3. Open **Events** and find both records.
4. Open the campaign report for the original visit date and display **Event 1**, **Event 2**, **Conversions**, and **Revenue**.

Expect one event in each stage, one conversion, and USD 15 revenue. Event ID is part of event identity, so the same transaction ID can identify the lead across two different stages.

If the event appears but the conversion total does not increase, check the winning rule and **Count as conversion**. If the count is right but the amount is wrong, check [revenue and cost](/conversions/revenue-and-cost).

## Treat statuses as separate events

The incoming endpoint does not change an existing order when it receives `status=approved` or `status=rejected`. Use separate Event IDs for those milestones and choose which milestone contributes to totals.

A rejected event does not subtract an earlier conversion or its revenue. Plan the event structure before sending production data, especially when payment happens after approval. See [Missing conversions](/troubleshooting/no-conversions) if the configured flow does not produce the expected result.