Skip to main content
Choose one order or lead that should have converted. Find its stored Metricanic click ID, the time the action occurred, and the exact request sent to Metricanic. This is more useful than repeatedly sending new test requests while watching a total. The first question is where the action disappears. An order in your backend, an event in Metricanic, a counted conversion, and a conversion in the traffic source are separate checkpoints.

​
Follow the checkpoints in order

Do not start by changing the outgoing traffic-source postback if the incoming event is absent from Metricanic.

​
Inspect what the sender actually transmitted

The final request should contain the full signed click ID and the intended event slot:
Look for unresolved placeholders, an empty click ID, the wrong domain, or a campaign ID substituted where the click ID belongs. Check the sending log rather than only its saved template, because substitution happens when the request is sent. If a POST sender also supplies query parameters, remember that a nonempty query value overrides the corresponding body field. A template with idx=1 in the URL still selects Event 1 even when its JSON body contains idx: 2. An invalid_clickid response points to identifier validation. bad_idx points to the event index. Body errors point to the request format. See Incoming event fields for supported values and formats.

​
HTTP 200 is not the end of the test

The incoming endpoint normally returns a small GIF. Event attribution and processing happen after that response. A 200 does not certify a new conversion, and protective rate limiting can also return the GIF without creating another event. Open Events for the time the callback was sent and Errors for related failures. If attribution cannot recover the original visit, the action cannot be assigned to the intended campaign result. If the failure persists, keep the test time, campaign, response, and tracking identifiers for investigation.

​
If the event exists but Conversions stays at zero

Edit the campaign and inspect the action for the received Event ID:
  1. Confirm the event slot is enabled.
  2. Confirm Count as conversion is on if this action should count.
  3. Check the first enabled conditional rule that matches this visit and event.
  4. Confirm that winning rule contains an enabled action for this Event ID.
  5. Check the campaign report for the original visit date, not only the callback date.
When a conditional rule matches, Metricanic does not fall back to Defaults just because that rule lacks the requested event action. This can explain an event record with no expected conversion or outgoing postback. If the event is counted but revenue is zero, investigate revenue mode and payout separately. A missing payout does not by itself prevent Count as conversion from adding the conversion.

​
Check whether the request is a repeat

The same underlying visit, event index, and normalized txuid produce the same event identity. Repeating order 1042 should not be treated as a new business action just because its request was delivered again. For a new test action, use a new stable transaction ID. For a retry of an existing action, preserve the existing ID. Omitting txuid creates a new identity on each request and can inflate counts. Do not resend an old transaction with status=approved expecting an update. The incoming endpoint does not implement status changes that way. Model the approved stage as its own configured event.

​
Run one controlled retest

Use a test campaign or account for the effects of the event in production reporting. A configured outgoing postback can also be triggered.
  1. Start a fresh tracked journey and retain the signed click ID received by the offer.
  2. Configure the intended slot to count as a conversion with From incoming event revenue.
  3. Send one event with payout=12.50 and a new transaction ID.
  4. Find the processed record in Events.
  5. Check the campaign report covering the visit date.
For that one processed action with the matching rule, expect one increase in the indexed event column, one conversion, and USD 12.50 revenue. If an outgoing destination is enabled, verify it separately in Postbacks and at the receiver.