What does postback do
Postback is a server-side transmission of an event between systems. In affiliate marketing, it helps to return information about registration, FTD or confirmed action to the tracker or advertising system without depending on the browser cookie.
What data is needed to link the event
The key element is the click ID or other tag that can be transmitted at the transition and retrieved at the event. Without this, the system knows that the conversion has occurred, but does not know which campaign to link it to.
| Element | The challenge |
|---|---|
| click_id | link the event to the original click |
| SubID | retain the campaign breakdown |
| event | Understand the conversion type |
| payout / value | transfer the value, if required |
| timestamp | reconcile event times across systems |
How to test integration
Don’t start with a real advertising budget. First, make a controlled test transition with a unique ID. Then check the chain by step:
- click_id is recorded on the transition;
- It is visible in the partner system;
- The test event has been formed;
- postback sent;
- The tracker has accepted the desired event;
- The event is related to the initial click.
Why the 200 OK test is not enough
HTTP 200 only means that endpoint responded successfully. It does not guarantee the correct value of the event, currency or identifier. After the request, you need to see how the event actually recorded in the receiving system.
Frequent causes of discrepancies
- click_id is cut off by the redirect;
- One system encodes a value differently.
- events are sent in a different time zone;
- an incorrect parameter name is used;
- A repeat event is considered a double event.
- The test is done with a cached old URL.
How to keep a log
For diagnosis, it is useful to save the date, the URL without sensitive data, the response code and the event ID. Do not log passwords, tokens and personal data in plain form.
Connection to markup
A postback does not replace a clear campaign structure. Define your UTM and SubID structure first, then return events to the same reporting context. This lets the report show both how many FTDs occurred and where the confirmed FTDs came from.
Separate Testing by Event
Do not try to check the entire chain of registration → FTD → confirmed. Test each event individually and make sure it has a unique name and the right status. If one endpoint accepts multiple types of events, a name error can cause them to all be recorded the same way.
Re-sending and deduplication
Good integration should understand what will happen when you re-query. If the network has temporarily returned an error, the system may attempt to send the event back. You need a stable identifier so that the repeat does not turn into a second conversion.
Security of parameters
Tokens and secrets should not appear in public pages, screenshots or UTMs. If endpoint requires a secret option, store it on the server side. Logs for diagnosis should also exclude sensitive values.
Integration documentation
Save a working example URL with replaced secrets, a description of each parameter, and the test date. After six months, this will allow you to quickly understand the current scheme, even if the integration was set up by another person.
Handle errors explicitly
If the host is temporarily unavailable, integration must distinguish between a successful response and an error. For critical events, a resending queue is useful with a limited number of attempts. Otherwise, a brief glitch turns into a permanent hole in analytics.
Keep an eye on the order of events
Sometimes FTD arrives before registration can be processed in another system. If logic rigidly requires a certain sequence, the event may be lost. Test not only the “perfect” order, but also the delays.
Control after modification
Any change in domain, tracker, redirect or link parameters is a reason to repeat the end-to-end test. Integration may look independent, but click_id often goes through the entire chain and is easily lost when migrating.
