Postback not recording conversions? Trace the failing step

When a conversion is missing, start with one callback and find the first handoff without evidence. Save the Tracked click ID, advertiser event ID, request time, and response body. Redact customer details and secrets before sharing logs.

Tracked's inbound /postback endpoint needs a recorded Tracked click ID in its click_id query parameter. Its response is useful evidence, but 200 OK alone does not confirm that a report row was stored. For the setup flow and request fields, see Postback URLs: how server-to-server conversion tracking works.

Check the callback template before resending

Use the free postback URL builder to inspect parameter names and encoding without sending a callback. For Tracked, the receiving click field must be click_id; the advertiser’s saved sub-ID is its value, not a replacement parameter name.

Enter raw values, not percent-encoded text. A copied template is not proof that the advertiser saved the right ID or that its macro expanded. Compare the final delivered request with the recorded offer click before retrying. Do not paste credentials or customer data into the tool.

Diagnose by symptom

No callback request appears in the advertiser log

Evidence: Check the advertiser or checkout delivery history for the conversion and the configured callback URL. Confirm which event status triggers delivery, such as an approved lead or completed order.

Likely boundary: The advertiser has not fired a callback, or its test event does not reach the state configured to send one.

Repair: Confirm the event trigger, enable the advertiser's supported test mode, and point its callback at the Tracked domain serving the campaign. Use the advertiser's current documentation for its token syntax; macro names are source-specific.

Retest: Trigger a new test event and inspect the outgoing request in the advertiser's delivery log. The request should be a GET to /postback and include a non-empty click_id.

Tracked returns 400 Missing click_id parameter

Evidence: The response says the required click_id query value is missing or blank. Compare the full callback URL with the advertiser's saved click field.

Likely boundary: The callback omits click_id, uses a source-specific parameter name directly, or expands its click token to an empty value.

Repair: Keep the advertiser's saved field name on its side, but map its value into Tracked's click_id parameter. Check the final URL after macro expansion; the literal macro text is not a click ID.

Retest: Use a fresh campaign click, save its Tracked ID, and send that value in click_id through the advertiser's test callback.

Tracked returns 404 Click not found

Evidence: The handler did not get a matching click row for the supplied value. Compare the callback's exact click_id with the click event in Tracked, including any truncation, encoding, or accidental whitespace.

Likely boundary: The wrong identifier was passed, a redirect or form changed it, or the callback is being tested with an ID that is not a recorded Tracked click. The handler also maps a failed click lookup to this response, so a value that matches a visible click but still gets 404 can indicate a lookup problem.

Repair: Correct the handoff if the values differ. If the same value is visible on a Tracked click and repeated callbacks still get 404, preserve the redacted request and timestamp for investigation instead of repeatedly resending it.

Retest: Follow a new test click end to end, then compare its recorded ID to the decoded click_id in the callback.

Tracked returns 200 OK, but no conversion appears

Evidence: A normal callback returns 200 OK while its event storage runs asynchronously. Collection policy can also return 200 OK without storing an event. A callback recognized as a retry can instead return JSON with status: "idempotent" and the existing conversion_id.

Likely boundary: The response confirms handling at the endpoint, not that a new report row finished storing. The event may have been suppressed by the site's collection policy, still be processing, or already exist as an idempotent receipt.

Repair: Check the collection policy for the campaign's site, then search Tracked reports or the event journey by click ID and advertiser event ID. Do not send repeated callbacks just to make the response look different; first check whether the original event or receipt exists.

Retest: Send one callback for a fresh test click and verify that the report shows one conversion attached to that click. Treat the callback response and the report row as separate evidence.

A callback is missing, duplicated, or suppressing a second event

Evidence: Compare the advertiser's event identity, Tracked conversion_id, event type, and request times. Tracked checks idempotency_key, conversion_id, and event_id first. With transaction_id, it includes the conversion type in the receipt key. Without an explicit identity, the fallback uses click ID, conversion type, and a fixed 60-second receipt-time bucket.

Likely boundary: A retry may arrive with a new conversion ID, or distinct events may reuse the same per-event ID. If there is no event ID, requests in different 60-second buckets can be treated as separate; the fallback is not a rolling window or a permanent one-conversion-per-click rule. For example, Everflow documents transaction_id as the parent click and conversion_id as an individual conversion event; other sources may name or scope their IDs differently (Everflow identifier guide).

Repair: Use a stable ID that identifies one conversion event when the advertiser provides one. Keep that ID the same across retries of that event, and use a different ID for each legitimate additional event. If only a parent transaction ID is available, send the distinct event type as well.

Retest: In a controlled test, send the same event identity twice and inspect the report. Then send a separate event with its own identity and verify it remains distinct. These checks exercise your configured callback; they do not establish that a live advertiser sale occurred.

A conversion is present, but its type or payout is wrong

Evidence: Inspect the raw callback fields and the conversion type shown in Tracked. Tracked accepts conversion_type and the alias type; conversion_type takes precedence when both are sent.

Likely boundary: The advertiser's event name does not match the Offer's configured event, or an explicitly typed callback is being treated as a secondary funnel event. The current handler stores payout as zero for explicitly typed callbacks; an untyped primary callback can use a supplied payout or configured default.

Repair: Map the source event to the intended Offer event and decide which callback represents the primary sale. The event mapping and postback backfill guide covers how to map source names without re-sending completed deliveries.

Retest: Use a new test click and source event. Confirm the raw event name, mapped type, and payout in Tracked before checking any downstream provider.

Tracked records the event, but the ad network does not

Evidence: First confirm that the conversion exists in Tracked. Then check the separate outbound integration or postback delivery record for its status and provider response.

Likely boundary: The advertiser's callback into Tracked is inbound. Conversion feedback from Tracked to an ad network is a separate, provider-specific delivery path with its own mapping and configuration.

Repair: Check the provider mapping, permissions, and delivery log for that outbound integration. A successful inbound callback does not prove that an outbound API request succeeded.

Retest: Trigger the provider's supported test flow and confirm the outbound delivery record separately. See native integrations vs. postbacks vs. conversion APIs for the path differences.

Where Tracked is today

Tracked's /postback endpoint records an inbound advertiser callback against a matching Tracked click, subject to the site's analytics collection policy. Reports and event journeys let you inspect the resulting click-to-conversion path.

Outbound conversion feedback is a distinct, provider-specific workflow. A generic inbound postback does not establish native API coverage or successful delivery to every ad network.

For a hands-on check, start free and build a Tracked campaign. Follow one click ID from campaign link to advertiser record and back to its conversion report.

Frequently asked questions

Does 200 OK mean Tracked stored the conversion?

No. The handler returns before asynchronous storage finishes, and collection policy can skip storage while returning 200 OK. Check the report row or event journey.

What does 404 Click not found mean?

The lookup returned no click row for the supplied ID. Check the exact value against a recorded Tracked click. Because a failed lookup can produce the same response, a matching visible click with repeated 404 responses needs investigation.

Will Tracked always collapse callback retries into one conversion?

No blanket guarantee applies to every callback. Tracked uses supplied event identity when present. Without an explicit identity, its fallback is scoped to a click, event type, and fixed 60-second receipt-time bucket; use a stable per-conversion ID when the source provides one.