Test your tracking and postback

Before you start

Finish the network setup. Ask the advertiser how to create a permitted test action and how it marks or reverses test results. Do not create unauthorized purchases, fake customer details or payable test events.

Have the generated publisher link, advertiser test contact, expected rates and a place to record the result. Keep real click IDs and partner information out of public screenshots.

Understand the two messages

The click travels from the publisher through your tracking link to the advertiser. The postback travels from the advertiser’s server to your network after an action.

The two connect through the same click ID. If the advertiser never receives or stores that ID, a later callback cannot reliably match the action to your original click.

A publisher may also need a callback to its own tracker. That is a second, outbound postback. Test it separately after the advertiser-to-network path works.

Follow one click

1. Note the test time and open the tracking link generated for your test publisher.
2. Confirm the destination is the advertiser’s approved landing page and the intended market/offer is used.
3. Check that the advertiser receives the substituted click ID. It must be a real value, not the literal text {click_id}.
4. In OfferDaemon, open Reporting → Clicks and locate the test click.
5. Record its offer, publisher and click ID. Check your test sub-parameter if you used one.

If the landing page is wrong or the click is missing, fix that problem before testing conversions. A later success message will not make an incorrect publisher assignment acceptable.

Configure the advertiser callback

Go to Settings → Postback URL and use the URL shown for your network. Give the advertiser the required click-ID parameter and its own macro that returns the value previously stored.

A simplified example looks like this:

https://your-tracking-domain.example/postback
  ?click_id=THE_ORIGINAL_CLICK_ID
  &tx_id=UNIQUE_TEST_TRANSACTION
  &event=sale
  &amount=20
  &currency=USD

This is an explanation, not a URL to paste into production. Use the actual endpoint and advertiser macro syntax from your integration. Keep any additional required authentication or identifiers supplied by the current setup.

tx_id identifies the transaction. event identifies the action type. The meaning of amount depends on your offer model; for RevShare, a missing or zero amount does not create a normal revenue-sharing conversion. Check the postback reference for the current accepted parameters.

Complete the test and compare

Ask the advertiser to trigger its permitted test event using the original click ID. Then:

1. Open Logs → Postback Log and find the callback using the click or transaction ID.
2. Read the outcome. A missing parameter, unknown click, duplicate or rejected event needs investigation.
3. Open Conversions and locate the resulting record if the callback was accepted.
4. Compare the offer, publisher, event, status, revenue and payout against the test brief.
5. Confirm with the advertiser how this test is excluded from normal billing or reversed under its test procedure.

A successful HTTP request alone is not sufficient evidence. You need the correct conversion and values in the correct account.

A worked result

For an illustrative fixed CPA offer with $20 advertiser revenue and $14 publisher payout, a successful test should attribute to the selected publisher and use those configured values. Its approval status must match your chosen workflow.

If the advertiser reports a callback but you cannot find a conversion, begin with the postback log. If the log says the click was not found, compare the returned identifier character for character with the click record. Check whether a tracker changed the value or sent its own ID instead.

With permission, test a duplicate callback and review the log. Do not assume duplicate behavior without considering transaction identifiers and the offer’s recurring-postback setting.

Check the publisher callback

If the publisher uses one, configure its postback URL in the publisher profile and confirm that its receiving tracker gets the expected identifiers and payout. Publisher callback delivery is best-effort; dashboard records still need reconciliation if the receiving endpoint fails.

Save a small test record: time, offer, publisher, expected values, observed values and any open issue. Do not launch until discrepancies are resolved.

Common mistakes

Testing only the redirect. A working landing page does not prove a conversion will be attributed.

Sending a made-up click ID. Use the identifier from your actual test click.

Testing real billing unintentionally. Agree the advertiser’s test procedure first.

Your checklist

• The click reaches the approved destination and appears in reporting.
• The advertiser stores and returns the original click ID.
• The postback log has the expected outcome.
• The conversion has the right publisher, offer, values and status.
• Any publisher callback and test-billing treatment are checked.

Next step

Use the weekly operating routine to keep tracking and commercial records aligned after launch.