guides · 8 min read

Affiliate Postback QA: 8 Checks Before You Buy Traffic

A practical pre-launch checklist for testing click IDs, status mapping, payouts, duplicate callbacks, and end-to-end affiliate conversion tracking.

A postback can look correct in a tracker interface and still lose conversions after launch. The safest approach is to test the full route before the first paid click: tracker → offer or affiliate network → conversion → tracker report.

This checklist focuses on the parts that most often break: click IDs, parameter mapping, statuses, payouts, duplicates, and reporting delays.

1. Confirm which click ID your tracker expects

A postback needs a unique click identifier so the tracker can connect the conversion to the original visit.

Keitaro uses the subid parameter. Its documentation states that subid and status are mandatory for recording a conversion. Voluum uses cid for its click ID and requires the valid value to be sent to the offer first and returned in the postback.

Do not assume that every platform uses the same parameter name. Write down the mapping explicitly:

  • tracker click ID;
  • offer URL parameter that receives it;
  • affiliate-network token that returns it;
  • postback parameter used by the tracker.

A simple mapping may look like this:

tracker click ID → s2 in offer URL → {sub2} in network → cid in postback

The names are examples. Use the exact tokens shown by your tracker and network.

2. Inspect the outgoing offer URL

Open the campaign through a real tracking link and inspect the final offer URL. The click ID field must contain an actual generated value, not a literal placeholder such as {clickid}.

Check three things:

  1. the parameter exists;
  2. the value is not empty;
  3. redirects do not remove or overwrite it.

Copy the click ID into your QA notes. You will need it when you send a test postback and search tracker logs.

3. Send one controlled test conversion

Use the affiliate network's test tool when it provides one. Otherwise, send a postback manually with the click ID captured in the previous step.

Start with the minimum required fields. For Keitaro, that means a valid subid and status. For Voluum, the conversion request must include the valid cid associated with the earlier visit.

Do not add every optional parameter on the first test. First prove that the click-to-conversion link works. Then add payout, currency, transaction ID, goal, and custom fields one at a time.

4. Verify status mapping

Networks and trackers may use different names for the same state. A network can send lead, approved, rejected, or numeric values, while the tracker expects its own status vocabulary.

Create a small mapping table before launch:

| Network value | Tracker result | Expected revenue |

|---|---|---:|

| pending | pending | 0 or provisional |

| approved | sale/approved | confirmed payout |

| rejected | rejected | 0 |

Run at least one test for every status that affects optimization. A campaign can appear profitable if rejected conversions remain counted as approved.

5. Check payout and currency separately

A recorded conversion does not prove that revenue is correct. Verify:

  • decimal separator;
  • currency code;
  • gross versus net payout;
  • whether a missing payout falls back to a default campaign value;
  • whether an update replaces the old payout or creates another conversion.

Use a deliberately unusual test amount, such as 7.43, so it is easy to identify in reports. Do not use production financial data for a QA test.

6. Protect against duplicate conversions

Send the same test postback twice. Then check whether your setup creates two conversions or updates one.

When the network supports a transaction or conversion ID, pass it through and verify duplicate handling. If the tracker cannot deduplicate the event automatically, document how repeated network callbacks will be handled before scaling traffic.

7. Compare raw logs with the report

Do not rely only on the campaign dashboard. Check the postback or conversion log and confirm:

  • request timestamp;
  • received click ID;
  • HTTP result;
  • parsed status;
  • payout and currency;
  • campaign or offer attached to the conversion.

Then compare the same event in the main report. If it exists in the raw log but not in the report, check timezone, filters, report range, and status selection before changing the integration.

8. Run a final end-to-end test

Before buying traffic, repeat the complete path with a new click:

  1. open the campaign tracking URL;
  2. confirm the click appears in the tracker;
  3. confirm the click ID reaches the offer or network;
  4. trigger one test conversion;
  5. confirm the postback request succeeds;
  6. confirm the conversion appears under the correct campaign;
  7. confirm status, payout, and currency;
  8. save the click ID and screenshots in the launch notes.

A compact pre-launch checklist

Do not launch until every answer is yes:

  • Is a real click ID added to the offer URL?
  • Can the network store and return that ID?
  • Does the tracker accept the returned parameter?
  • Are conversion statuses mapped correctly?
  • Are payout and currency correct?
  • Are duplicate callbacks handled?
  • Does the event appear in both logs and reports?
  • Has the full route been tested with a fresh click?

Postback QA takes less time than reconciling missing conversions after traffic has already been bought. The goal is not merely to make a test request return HTTP 200. The goal is to prove that one real click becomes one correctly attributed conversion with the correct status and value.

Sources

  • [Keitaro documentation — Postback](https://docs.keitaro.io/en/conversions-and-postback/postback.html)
  • [Voluum documentation — Parameters in Postback URLs](https://doc.voluum.com/article/parameters-in-postback-urls)

Editorial policy