A postback can return 200 OK and still fail to create a conversion. It can appear in a tracker but never reach the advertising platform. A retried callback can also look like another sale when it is only a delivery retry.
That is why “did the postback arrive?” is the wrong diagnostic question. Test four independent layers: request delivery, click lookup, event interpretation and final persistence. This checklist isolates the broken segment instead of rebuilding the URL blindly.
For parameter ownership, read Click ID, Sub ID and postback macros. Use the Postback URL Builder to assemble a controlled test.
The working chain
- The tracker creates a unique internal click ID.
- It passes that value into an offer through an agreed sub field.
- The affiliate system stores the value unchanged.
- On conversion, the system expands its postback macro.
- The tracker receives the callback, finds the click and normalizes the status.
- A stable transaction ID prevents a retry from adding revenue twice.
- An approved event can then be forwarded to Meta, TikTok or another platform.
Pass/fail checklist
| Segment | Expected result | Evidence | Pass? |
|---|---|---|---|
| Incoming click | One unique click ID is created | Raw click record | ☐ |
| Offer URL | The ID reaches the agreed sub field | Final URL after redirects | ☐ |
| Storage | The network preserves it byte for byte | Network click/conversion log | ☐ |
| Callback URL | Every macro is expanded | Raw request URL | ☐ |
| Transport | Request reaches the correct endpoint | Code, timestamp and body | ☐ |
| Click lookup | Tracker finds the original click | Ingress processing result | ☐ |
| Status | Raw value maps to the intended event | Status mapping | ☐ |
| Money | Payout and currency have the agreed meaning | Network record | ☐ |
| Deduplication | A retry does not add another conversion | Repeat the same transaction | ☐ |
| Feedback | The correct event reaches the ad platform | CAPI/Events API delivery log | ☐ |
1. Capture one control click
Do not debug inside thousands of live events. Generate one control click and record its exact timestamp and timezone, internal click ID, campaign, stream, offer, final outbound URL and the network field expected to store the ID.
Treat the identifier as an opaque string. Do not trim it, cast it to a number, change case or reconstruct it between systems. One changed character means a different lookup key.
2. Verify the forward path
If a network accepts an arbitrary value in aff_sub, the template may be:
https://network.example/offer?aff_sub={click_id}After the redirect, the real URL must contain the actual value:
https://network.example/offer?aff_sub=dc_01K2A7M9X4Literal braces or %7Bclick_id%7D mean the macro was not expanded. An empty value means you must determine where templating should occur: tracker, PWA, landing page or redirect service. If the value disappears at an intermediate redirect, fix that forward path before investigating the callback.
3. Inspect the raw callback
A saved template is not evidence of the request that was actually sent. Compare the template:
https://track.example/p?click_id={aff_sub}&status={status}&payout={payout}with the raw request:
https://track.example/p?click_id=dc_01K2A7M9X4&status=dep&payout=45.00&txid=7719Confirm that macros are expanded, the click ID matches exactly, special characters are URL-encoded, and the endpoint belongs to the intended workspace and environment. A practical Adset diagnostic guide highlights the same recurring failures: literal macros, modified IDs, incorrect status mapping and authentication errors.
4. Do not treat 200 OK as a recorded conversion
HTTP success only proves that an endpoint handled the transport. Some systems deliberately return a generic response for an unknown click, duplicate, or ignored status. The ingress log needs a useful processing result such as:
acceptedduplicateclick_not_foundstatus_unmappedinvalid_payoutunauthorized
If the product has no raw log, use a request catcher for a controlled test only. Never expose production tokens or personal data to a third-party catcher.
5. Map status separately from click lookup
Finding the click does not guarantee the correct business event. Networks may send lead, reg, dep, ftd, approved or rejected. Write an explicit contract:
| Raw status | Internal status | Send to platform? | Count revenue? |
|---|---|---|---|
reg | Registration | According to optimization policy | No |
dep | First deposit | Yes | Yes |
approved | Approved sale | Avoid a second purchase event | Yes |
rejected | Rejected | No or correction | No |
DarkCore keeps this mapping in Conversion Statuses. Avoid collapsing registration and deposit into the same generic Lead; it weakens both reporting and platform feedback.
6. Validate payout, currency and corrections
payout=45 can mean affiliate commission, advertiser revenue or order value. Agree on the semantics before implementation and carry currency separately. Test decimal separators and missing values.
When a status or amount changes later, update the existing transaction rather than creating an unrelated sale. A stable transaction ID and an event history make that correction auditable.
7. Run the duplicate test
Send the exact callback twice. The first request should create the event; the second should be marked duplicate; conversion count, revenue and downstream platform events must remain unchanged.
Deduplicate with a transaction identifier plus event type. A click ID alone is insufficient when one click can produce a registration, first deposit and later deposits.
8. Tracker has the event, but Meta or TikTok does not
That is a different segment of the chain. Check whether the internal status is eligible for forwarding, the platform click context (fbclid/fbc or ttclid) survived, the access token is valid, the API accepted the payload, and Browser Pixel plus server events share the intended event_id.
The roles of these channels are compared in Pixel vs CAPI vs Postback. TikTok’s official documentation confirms that TTCLID is appended to landing URLs and supports attribution and measurement (TikTok Ads Help).
Symptom map
| Symptom | Check first |
|---|---|
{...} remains in the request | Sender’s exact macro syntax |
click_not_found | Forward parameter and click ID value |
| Conversion lands on another campaign | Sub field overwritten or reused |
| Registration exists, deposit does not | Separate callback and dep/ftd mapping |
| Revenue doubles | Transaction ID and idempotency |
| Tracker has it, Meta does not | Platform ID, token, policy and API log |
| Meta reports more | Window, view-through/modeling and Pixel+CAPI dedup |
| Tracker reports more | Organic traffic, status filters or duplicate callbacks |
Evidence package for support
Send a timestamp with timezone, control click ID, sanitized outbound URL, raw callback with secrets masked, response code/body, ingress result, expected versus actual status, transaction ID and one exported conversion row. That package lets support inspect a specific boundary instead of repeating setup questions.
FAQ
Why does a manual postback work while the real one fails?
The manual test often contains a correctly substituted ID while the production template sends an empty value or a literal macro. Compare the raw production URL byte for byte.
Can I test a postback in a browser?
You can test a GET endpoint’s reachability. A browser does not prove that the network can expand macros, apply authentication and follow its retry policy.
Which fields are essential?
A stable click ID is essential for attribution. A transaction ID is also needed to distinguish legitimate multiple events from retries. Status and payout are required whenever they affect optimization or finance.
When is the issue actually closed?
After an end-to-end test: control click, offer handoff, first callback, exact retry, status or amount correction, and downstream feedback. The output should be a completed pass/fail table, not “it seems to work.”