Skip to main content
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.
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. 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 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.
  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:
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 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:
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: 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.
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.
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. For Google Ads, use the Google Ads integration guide for its specific connection and conversion setup.