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

# Send conversions back to a traffic source

> Send conversions and revenue to another platform, send a percentage such as 50% with event cost, and verify the delivered amount.

An affiliate network can tell Metricanic that an order happened. Your traffic source may also need that result to associate revenue or a conversion with the original ad click. These are two separate requests with different destinations and identifiers.

```text theme={null}
Affiliate network or site
  → Incoming event URL on your Metricanic tracking domain
  → Campaign event rule
  → Outgoing postback URL on the receiving platform
```

Use an outgoing postback after incoming tracking works. Otherwise, a missing conversion in the traffic source could come from either connection, making the fault harder to locate.

## Know which click ID each system expects

Suppose a traffic source sends its click ID `ad-731` to Metricanic. Metricanic creates its own signed click ID and passes it to the offer. The offer returns that signed ID when order `1042` pays USD 24.50.

The incoming event uses Metricanic's signed ID. The outgoing request usually needs `ad-731`, which identifies the ad click in the traffic source.

| Value           | Typical purpose                                                         |
| --------------- | ----------------------------------------------------------------------- |
| `{external_id}` | The original traffic source click ID stored with the visit              |
| `{click_id}`    | The signed Metricanic click ID                                          |
| `{payout}`      | Incoming payout when supplied, otherwise an available configured payout |
| `{event_cost}`  | The event cost available for the outgoing request                       |
| `{tx_uid}`      | Metricanic's normalized transaction identifier                          |

Check the receiver's parameter names. A field called `click_id` on another platform does not necessarily expect Metricanic's `{click_id}`.

To send a percentage of revenue, such as a 50% partner commission, configure **Event cost** as **Revenue share (%)** and put `{event_cost}` in the receiver's amount parameter. The [50% example](#send-50-percent-of-revenue-in-an-outgoing-postback) below connects these settings and explains their effect on reports.

## Configure the outgoing request

1. Confirm that the traffic source's click ID is captured as **External ID** on the visit. See [Traffic sources](/tracking/traffic-sources).
2. Obtain the postback URL template from the receiving platform.
3. Edit the campaign and open the relevant event in **Events and rules**.
4. Enable **Outgoing postback** and enter the template in **Destination URL**.
5. Insert Metricanic macros for the values the receiver requires.
6. Save the campaign and send one new test event for a tracked visit with a real external ID.
7. Open **Postbacks** and inspect the attempt, then verify the result in the receiving platform.

For a receiver that documents `ad_click` and `amount` parameters, a template could look like this:

```text theme={null}
https://receiver.example.com/conversion?ad_click={external_id}&amount={payout}
```

For the example visit, the resolved values should be `ad_click=ad-731` and `amount=24.5`. The receiver's real endpoint and field names must replace this illustrative URL.

**Use source postback** copies the selected traffic source's postback URL into the event. Review and save that event when the source template changes. Treat the copied URL as part of the campaign configuration.

## Send only the stages the receiver needs

For a submitted-lead and approved-lead funnel, you may want the tracker to keep both stages while the traffic source receives only approvals. Enable the outgoing postback on the approved event and leave it off for the submitted event.

Sending a postback is an independent event setting. **Count as conversion** controls Metricanic's conversion totals. It is not an automatic switch for outgoing delivery.

Conditional event rules can choose a different destination for selected offers or traffic. The first matching rule supplies the event action, including its postback settings. Check the [rule order](/conversions/goals) if one segment delivers correctly and another does not.

## Send 50 percent of revenue in an outgoing postback

Metricanic can send half of an incoming payout using **Revenue share (%)** and `{event_cost}`. Use this setup when the amount sent to a partner or traffic source is also an event expense, such as a commission.

1. Edit the campaign and open the relevant event in **Events and rules**. Apply the settings to the action in the rule that will handle this event.
2. In **Advanced**, set **Revenue** to **From incoming event** so the percentage follows each incoming payout. **Simple** already uses incoming payout and does not show this selector.
3. Set **Event cost** to **Revenue share (%)** and enter `50`.
4. Enable **Outgoing postback**. In **Destination URL**, use `{event_cost}` for the receiver's amount parameter.
5. Save the campaign and send a new event with `payout=100` for a tracked visit.
6. Open **Postbacks**, inspect the resolved URL, and confirm that the receiving platform recorded `50`.

If the receiver uses `ad_click` and `amount`, its template could be:

```text theme={null}
https://receiver.example.com/conversion?ad_click={external_id}&amount={event_cost}
```

Use the receiver's actual endpoint, identifier, and parameter names. Even if its amount parameter is named `payout`, you can set `payout={event_cost}`. The parameter name belongs to the receiver, while the macro selects the Metricanic value.

For one Event 1 with incoming `payout=100` and a 50% share, expect:

| Value                   | Result  |
| ----------------------- | ------- |
| **Revenue 1**           | USD 100 |
| **Cost 1**              | USD 50  |
| Outgoing `{payout}`     | `100`   |
| Outgoing `{event_cost}` | `50`    |

Enter `30` to send 30%, or another percentage appropriate to the commission. There is no need to halve the incoming payout. Keeping the full incoming amount preserves the event's revenue.

<Warning>
  Selecting **Revenue share (%)** also enables this event's contribution to **Cost** in the normal editor flow. A USD 50 event cost reduces **Profit** by USD 50, in addition to any traffic spending. Choose this method when the share is an expense you want to record. It does more than change a number in the outgoing URL.
</Warning>

The percentage uses the event's configured revenue. With **Fixed amount = 20**, a 50% share produces `10` even if the incoming payout is `100`. With **No revenue**, the calculated share is zero.

URL macros do not support arithmetic modifiers such as `{payout:50}` or `{payout*0.5}`. Those strings do not calculate a percentage. If you only need to scale the outgoing amount while leaving event costs unchanged, there is no dedicated outgoing multiplier in the current editor. Calculate that separate value in the system forwarding or receiving the postback.

## Check the amount before relying on it

The outgoing `{payout}` macro prefers a valid payout supplied by the incoming event. This can differ from the revenue recorded by a fixed event action.

For example, an incoming `payout=24.50` combined with **Fixed amount = 20** records USD 20 revenue, while `{payout}` can still send `24.5`. If the receiving platform needs the configured fixed amount, use an explicit value that matches the intended setup or change how the sender supplies payout.

For incoming requests to `/event`, `{event_cost}` uses the configured fixed event cost or revenue share. Calculate the amount in **Event cost**. Adding `cost=50` to an incoming event URL does not configure that expense.

`{profit}` subtracts the outgoing `{event_cost}` value from the outgoing `{payout}` value when both are available. It excludes visit cost and can differ from the event's recorded revenue minus cost when incoming and configured amounts differ.

Macro values are URL-encoded. Unknown macros and macros without a value remain as placeholders. A visible `{external_id}` in a resolved URL means the original visit did not supply a usable value or the macro is wrong. Empty placeholder text should not be treated as a successful mapping.

## Distinguish delivery from attribution

Generic outgoing postbacks use HTTP GET. The delivery worker treats a successful HTTP response as successful transport and can retry failed attempts. One conversion can therefore have multiple delivery attempts.

A 2xx response does not guarantee the receiving platform credited the conversion. The receiver can apply its own click matching, event configuration, duplicate handling, and reporting rules.

| What you observe                     | What to inspect next                                                     |
| ------------------------------------ | ------------------------------------------------------------------------ |
| No event in Metricanic               | [Incoming event tracking](/conversions/incoming-events)                  |
| Event exists, no outgoing attempt    | Winning event action, enabled postback, valid destination URL            |
| Attempt exists with unresolved macro | Original visit values and macro spelling                                 |
| Attempt failed                       | HTTP status, response text, and receiver configuration                   |
| Attempt succeeded, receiver is empty | Receiver's click ID, event mapping, date range, and attribution settings |

For Google Ads, use the [Google Ads integration guide](/integrations/google-ads) for its specific connection and conversion setup.