Server-to-server (S2S) postback tracking explained

1. A visitor clicks a publisher's tracking link. The tracking system gives the click a unique ID.
2. The ID travels with the visitor through the form and stays on the lead.
3. When the lead is sold, the system sends a postback: a request to the publisher's postback URL with the click ID and details such as the payout.
4. The publisher's tracker records the sale against that click.

Pixels run in the visitor's browser, so ad blockers, cookie limits and failed page loads can stop them. A postback does not depend on the visitor's browser, which makes it the usual choice for payout-critical events.

• Give each publisher offer its own tracking link.
• Make sure the click ID parameter is passed through every redirect and into the form.
• Give each publisher a postback URL with the macros their tracker expects.
• Test with a test click before sending real traffic.
• Use your own tracking domain so links look like yours.

• Lost click IDs. A redirect or app wrapper strips the parameter, so the sale cannot be matched.
• Duplicate postbacks. Retries must not create a second conversion.
• Mismatched statuses. Agree what "accepted", "rejected" and "returned" mean on both sides.
• Wrong events sent. Only send the events a publisher is paid on.

pingtype gives every click an ID that stays with the lead, sends postbacks to publishers when a lead sells, and supports your own tracking domain. You can also void conversions, import conversions from a CSV, and test a postback before it goes live. Reports show clicks, leads and revenue by publisher and offer.