Affiliate tracking is a chain, not a single number. A publisher’s tracker records a click. MyLead receives the campaign visit and the click identifier. An advertiser reports an action. The network applies the offer’s status and validation rules. A postback can then send that event back to the publisher’s tracker.
If one field is missing or mapped to the wrong parameter, the journey may still appear to work: the offer opens, the visitor converts, and one dashboard shows a lead. But the publisher’s tracker may not know which click generated it—or whether the event is pending, approved, rejected, or associated with a payout value. The aim of setup is to preserve enough consistent identifiers and event detail to investigate that path.
Keep the identifiers and events separate
Several values can appear in a tracking setup. They have different jobs, so give each a clear owner and mapping:
- Tracker click ID: the unique value created by your tracking platform when it records a click.
- MyLead
ml_sub1: MyLead’s guide uses this field to pass the tracker’s click ID with the campaign link, so a later conversion can be matched to the originating click. - MyLead
ml_sub2: MyLead’s postback guide maps this field toaffid, the sub-publisher identifier in its example configuration. Use it only when that identifier is relevant to your setup. - Status: the conversion state being sent, such as pending, approved, or rejected. Its exact values and available triggers depend on the current MyLead and tracker configuration.
- Payout: the commission value returned for the event, using the parameter and format accepted by your tracker. MyLead documents tokens such as
[payout]and[payout_decimal]; confirm which one the selected integration expects. - Transaction or event ID: a unique action reference, if the systems expose one. It can help identify repeat notifications, but do not assume every offer, network, or tracker provides the same field.
These are mappings, not universal naming conventions. A tracker may call its click ID clickId, cid, or something else; a network parameter does not automatically share that name. MyLead’s offer-to-tracker guide describes the ml_sub1 mapping for supported trackers, while its postback guide explains the current MyLead-side fields and status trigger.
Understand what the postback does
A postback is a server-to-server notification that sends an event from one system to another. In MyLead’s documentation, a configured postback can be triggered by the chosen lead status. An API workflow is different: a client makes requests to retrieve updates rather than relying only on a status-change notification. Which approach is available or appropriate depends on the integration you are using.
The postback does not create the original click, prove that attribution was correct, or guarantee that a commission is final. It transmits the fields that the network configuration makes available. If the click identifier was never passed into the offer link, the callback may arrive without the value needed to connect it to a visit in your tracker.
When the postback is configured to fire for Any status, include the status parameter in the callback mapping. MyLead warns that omitting it can make the tracker’s statistics misleading because the receiving system cannot distinguish status updates. If you choose one specific status instead, make sure the tracker is set up to interpret that event as intended.
Map the fields before you build the link
Create a small data dictionary before editing the campaign URL or postback. For each parameter, record the source value, the destination field, the purpose, and an example of a valid test value. For a basic MyLead-to-tracker setup, that may look like this:
- The tracker creates a click ID.
- The campaign link forwards that ID to MyLead through
ml_sub1. - The postback returns
[ml_sub1]in the tracker’s click-ID field. - If the integration needs sub-publisher attribution, map
[ml_sub2]to the receiving field foraffid. - Map
[status]when the callback can deliver more than one status, and map the appropriate payout token only if the tracker expects commission values.
An illustrative mapping—not a ready-to-paste URL—could be expressed as:
tracker_click_id = [ml_sub1]
sub_publisher_id = [ml_sub2]
conversion_status = [status]
commission_value = [payout_decimal]
The receiving endpoint’s actual parameter names, required fields, encoding, and payout format come from your tracker’s current documentation. Do not copy a sample from another tracker and assume its placeholders will work unchanged in yours.

Validate each handoff with an approved test
Testing should prove the route without manufacturing a conversion. Do not create self-referrals or fake leads unless the campaign explicitly provides an approved test method. MyLead’s offer terms and the campaign’s promotion rules determine what activity is allowed.
Use a controlled checklist:
- Confirm the campaign and source. Copy the current tracking URL from the correct MyLead campaign. Confirm the traffic source is permitted and that your tracker is configured for MyLead.
- Check the click-ID handoff. Make one permitted test click and verify that the tracker generated a click ID and that the link sent the intended value through
ml_sub1. A page opening successfully is not proof that the ID was preserved. - Check the postback mapping. Compare the configured MyLead token with the exact tracker field. Watch for URL encoding, missing
?or&separators, duplicate parameters, and a placeholder that belongs to a different tracker. - Confirm status behavior. Verify which MyLead status triggers the notification. If using Any status, ensure the status is included and recognized by the receiving platform.
- Check payout format. If payout is transmitted, compare the returned value with the expected currency, decimal convention, and tracker field. Do not treat a blank or malformed value as zero commission without investigating the mapping.
- Match the receiving event. Where a permitted test or real event is available, verify that it appears under the correct campaign and click ID in both systems, then confirm how later status changes are represented.
If the campaign does not permit a test conversion, validate the click path and callback setup with the network’s documented test option or support channel before live promotion. Keep any support sample sanitized; do not send names, email addresses, phone numbers, or other customer data in a tracking URL or public troubleshooting post.

Reconcile reports on the same basis
When totals differ, first compare like with like. Use the same campaign, date range, time zone, currency, event status, and attribution window. One panel may count clicks; another may show conversions; a third may show only approved commissions. The numbers can differ without a broken postback if the definitions or time windows differ.
Then trace the first point where the records stop matching:
- Tracker click, no MyLead visit: inspect redirects, link format, campaign URL, and whether the request reached MyLead.
- MyLead visit, no matching tracker click ID: inspect
ml_sub1, parameter encoding, and any redirect that might remove the value. - MyLead conversion, no tracker event: inspect the status trigger, postback endpoint, token mapping, server response, and tracker-side logs.
- Tracker event, wrong status or payout: inspect whether the callback sent
[status], whether the receiving field expects a different value, and whether the commission token uses the right format. - Duplicate events: compare the event or transaction identifier if available, timestamps, retry behavior, and whether the receiving tracker supports idempotent updates.
Preserve timestamps, campaign identifiers, status, and a redacted click ID when asking for help. Do not edit totals manually to make reports agree. Document what is observed, what is still unknown, and which system owns the next check.
Separate attribution evidence from earnings evidence
A matched click and conversion show that the tracking chain connected those records under the configured rules. They do not by themselves establish that the advertiser approved the event or that the amount is withdrawable. Keep MyLead’s campaign status and withdrawal balance separate from the tracker’s attributed conversion report. MyLead’s withdrawal guide explains the commission states and payout request process; the specific campaign terms define the qualifying event and any approval conditions. (MyLead: Publisher terms and conditions (PDF))
For campaign decisions, compare approved outcomes after the relevant validation period. Use raw click and conversion data to diagnose the funnel, and use approved commission and completed payout data to understand the financial result. A postback improves the event trail; it does not replace the offer rules or payout status.
Keep the tracking setup maintainable
Save a short versioned record with the campaign name, link owner, tracker, parameter map, callback URL owner, triggering status, payout format, test date, and any campaign-specific restrictions. Store credentials and private endpoint secrets in the appropriate protected configuration, not in an article, screenshot, shared spreadsheet, or public support request.
Recheck the setup whenever you change tracker, campaign, traffic source, redirect, event status, or payout mapping. MyLead’s current instructions show that tracker defaults differ: some platforms append the ml_sub1 click-ID token automatically, while others require a manual parameter. After a change, repeat the permitted click-path check and confirm that the event lands under the intended campaign.
The reliable question is not simply “Did a number appear?” It is “Can I trace this event from a permitted click to the correct MyLead status and the matching tracker record, then distinguish that evidence from approved, withdrawable earnings?” When the mapping is documented and each handoff is checked, discrepancies become diagnosable rather than mysterious.


