What is postback tracking?

Introduction

Postback tracking is the server-to-server layer that reports a conversion after the click and landing-page steps are already complete. Instead of relying on browser pixels, the tracker, CRM, or backend sends an HTTP request directly to the partner endpoint.

Use this page to understand the architecture and vocabulary of postbacks: what a callback is, which identifiers it should carry, who usually sends it, and which systems depend on it later. If you are validating a new setup before launch, move to How to test a postback. If a live campaign is already broken, move to Postback not working.

Explanation of the concept

A postback URL usually contains placeholders for click IDs, payout values, goal IDs, offer IDs, and any auth tokens the partner expects. When a conversion happens, the sending system replaces those placeholders with live values and fires an HTTP GET or POST request.

The important point is role separation. Redirects and landing pages preserve identifiers up front; postbacks send those preserved identifiers back out later. That is why a healthy callback depends on healthy click capture, healthy storage, and a correctly formatted outbound request.

Common problems

Most confusion starts before any debugging tool is opened. Teams mix up three different jobs: defining how postbacks should work, testing a new integration before launch, and triaging a live callback that already stopped crediting conversions.

Another common problem is role ambiguity. One team thinks the tracker owns the callback, another thinks the CRM sends it, and a third assumes the partner will normalize malformed payloads. Without a shared definition, every later incident turns into guesswork.

• Treating this definition page as if it were a live troubleshooting runbook.
• Using partner terms like postback, callback, S2S, and conversion ping interchangeably without defining the payload owner.
• Assuming a click ID problem and a callback formatting problem are the same incident.
• Skipping documentation of required fields, auth rules, and expected response formats.
• Letting every partner implement a different naming or currency convention without a shared reference.

Step-by-step troubleshooting

This page should end with a routing decision, not a production fix. Once you understand the callback model, decide whether your next task is setup QA, live failure triage, or payload comparison.

Keeping those branches separate makes the whole content cluster easier for Google and for operators: one page defines the system, one page tests it before launch, and one page investigates incidents after launch.

When a live callback exists but the result still disagrees with partner reporting, continue into Postback not working for the production triage flow, then use the live request guide if the payload shape is the likely owner.

1. Confirm whether you are still in the definition stage

   Use this page if the team still needs a shared understanding of which system sends the callback, which identifiers it should include, and which partner requirements govern the payload.

2. Branch into pre-launch QA when the integration is new

   If traffic is not live yet and you need to validate templates, auth, and test conversions, continue with How to test a postback.

3. Branch into live incident triage when production is broken

   If the campaign is already live and the partner does not credit real conversions, continue with Postback not working.

4. Use the request-comparison guide for payload mismatches

   If the key question is why the live request differs from the approved template, compare expected and actual requests in the request comparison guide.

5. Document the ownership model before moving on

   Write down who owns click capture, who owns callback delivery, which fields are mandatory, and what a successful partner response should look like. That reference prevents later tickets from collapsing into terminology debates.

Tools that help solve the problem

Postback troubleshooting spans the entire stack. Redirect Checker proves the click path, Click ID Extractor confirms identifiers, UTM Builder keeps templates tidy, Postback Tester simulates the callback, and Facebook CAPI Tester mirrors the server upload to ad platforms.

When combined, these tools give you reproducible logs for every stakeholder.

Conclusion

This page is the architectural reference for the postback cluster, not the full troubleshooting playbook. Its job is to define the callback model clearly enough that the next page can focus on one operational intent.

Once the team agrees on payload ownership, required fields, and downstream dependencies, move to How to test a postback for repeatable QA or Postback not working when production evidence is already on the line.