How to debug postback mismatches

This article is part of the Performance Tracking and Fraud Control silo.

How to debug postback mismatches in brief

If a postback mismatch appears, the problem is usually a broken identifier chain, a timing race, or a policy mismatch. Start by comparing the same conversion at click log -> event payload -> postback receiver.

For a publisher, fix the identifier chain first. For an advertiser, verify campaign settings and payout policy rules align with what the postback is sending. For technical teams, isolate where dedupe, retries, or timezone conversion changes mutate fields during delivery.

Do this in order:

1. Freeze traffic changes for 30 minutes to stabilize a reproducible sample.
2. Pull one failed and one successful conversion with raw IDs and payloads.
3. Compare payload schema, IDs, and event status across all three checkpoints.
4. Apply a scoped fix and rerun one synthetic conversion before scaling again.

If the checks are clean but mismatch persists, assume policy interpretation mismatch and treat it as a business logic issue.

Who this is for

This page supports three teams:

• Publishers: protect EPC, approval rate, and payout predictability.
• Advertisers: align postbacks with campaign logic and reporting windows.
• Technical teams: prove root cause before changing production logic.

If your goal is only to add a new offer format or increase traffic volume, use S2S postbacks explained first and return here only when mismatch symptoms already exist.

Definition

A postback mismatch is a reconciliation failure where the same conversion appears with different identity or state across systems that should agree.

In KiwiWall context, a mismatch usually means:

• The click path and conversion event carry different IDs.
• Retries or dedupe logic dropped or double-counted one transaction.
• Systems disagree because of policy conflicts or reporting-window differences.

Your KPI is not “total postbacks sent.” The useful metric is matched postbacks: conversions with the same click-level identity and agreed status across click logs, conversion logs, and payout outcome.

Decision table

Use this when deciding where to fix first.

How it works

Treat mismatch troubleshooting as a trace, not a guess. Build a deterministic 7-step runbook.

Step 1 — Freeze the window and create one incident

Take a 30-minute sample where the issue repeats. Label one campaign, one offer, one geo, and one placement. Do not apply optimization changes while debugging.

Step 2 — Capture the three truth sources

For each failing conversion and one known-good conversion, capture:

• click_id and associated sub values as first-party source of truth.
• Click payload sent to KiwiWall at click time.
• Conversion payload at advertiser endpoint (or KiwiWall event entrypoint if available).
• Final postback payload received by KiwiWall reporting systems.

At this stage, compare data presence, not business KPIs.

Step 3 — Normalize ID fields and timestamp basis

Create a reconciliation matrix with the raw IDs. The most common mismatch is the same field with different names in different stages (click_id vs clickid, transaction_id lowercase/upper case differences, trailing spaces). Normalize:

• string case
• URL-decoding
• timezone to UTC
• retry counter
• signature/hash verification format

If one row cannot normalize cleanly, you have a transport issue, not a fraud issue.

Step 4 — Isolate transport from policy

Run each of the following with a synthetic test:

1. Disable retries temporarily and send one exact payload.
2. Keep dedupe off for one controlled window.
3. Keep policy engine on one fixed revision.

If mismatch disappears with transport changes, transport is likely root cause. If mismatch persists with fixed transport and policies still applied, move to rule alignment.

Step 5 — Align policy interpretation

Publishers should check that advertiser-side approval, payout, and attribution logic are stable across reporting timestamps. Advertisers should confirm payout tables include the same:

• geo segment
• device class
• campaign type
• offer category
• fraud flags

Technical teams should check for drift in policy snapshots. A replayed conversion should never be evaluated under a different policy revision than the click baseline unless this is explicitly documented.

Step 6 — Verify dedupe and retry behavior

Your dedupe logic should be deterministic:

• Primary key: click_id + transaction_id + offer_id
• Secondary key: event timestamp bucket (small window)
• Retry strategy: bounded, exponential backoff with explicit terminal state

If dedupe rules change per endpoint or environment, you will see phantom double counts that look like mismatches.

Step 7 — Re-run, then promote from test-only to full traffic

Start with 1 synthetic conversion, then 10, then 100. Confirm these match metrics:

• click-to-postback ratio
• accepted ratio by offer and geo
• rejection reason consistency

Only then remove hold state and reopen scaling.

Example

An advertiser campaign can show accepted clicks but rejected revenue status in one country because the click payload includes source while campaign policy reads traffic_source. Fix that with canonical field mapping, versioned schemas, and an offer-specific integration test before traffic returns.

Common mistakes

1. Only watching totals in dashboards
   • Fix: compare sample-level IDs, not only aggregated conversion counts.
2. Treating all failures as fraud
   • Fix: separate technical mismatches, policy rejections, and intentional quality filters.
3. Retrying into an unstable flow
   • Fix: make retry behavior deterministic first, then re-test retries.
4. Ignoring offer-level exception rules
   • Fix: include policy version in every postback and compare by that key in every environment.

Checklist

• Click ID present in every redirect and browser/device handoff.
• transaction_id stable for one conversion across environments.
• sub parameters preserved and consistent.
• Retry count tracked and limited.
• Dedupe key deterministic and logged.
• Policy version attached to each decision.
• UTC timestamps logged for click and conversion.
• Rejected reasons include machine-readable reason code and source.
• Reconciliation report includes one known-good and one failing sample.

Use this checklist before asking support teams to change offer routing.

FAQ

1) Is a mismatch always a tracking bug?

Not always. A valid mismatch can be policy-driven (offer eligibility, traffic quality, geo restrictions). Your debug process should first validate IDs, then policy.

2) Can retries cause both overcount and undercount?

Yes. If retries are not deduped by stable keys, duplicates can appear as overcount. If retries are dropped too aggressively, valid conversions become undercount.

3) Should publishers keep traffic flowing while debugging?

Keep traffic in a controlled slice only. Full traffic during active debugging usually corrupts your baseline and lengthens root-cause time.

4) What payload fields are mandatory for KiwiWall troubleshooting?

At minimum: click_id, transaction_id, offer identifier, timestamp, source or placement context, and policy version if available.

5) When is it safe to scale again?

When one synthetic, 10-test, and 100-test batch pass the reconciliation checks and rejection reason mix remains stable by offer/geo/device.

When this applies

Use this playbook when publisher and advertiser reports disagree, rejection rates change abruptly after an update, or status transitions look inconsistent. If postbacks are stable and the issue is only lower volume or higher CPC, fix offer selection, fraud policy, or creative quality first and return here only if mismatches remain.

Evidence notes

This page is written from the current sprint brief and strategy lock, with keyword and topic validation tracked in the latest execution notes:

• docs/content-silo-plan.md (last updated 2026-06-18) under Tracking, Postbacks, and Fraud Control.
• Obsidian execution registry entry in content-silo-strategy.md with 2026-06-18 sync status No drift detected.
• KIW-89 keyword research notes (2026-06-18) including autocomplete and social signal checks.
• Public guidance references: Google search docs on AI optimization, Google helpful content signals, and OpenAI crawler documentation.

No unsupported payout or revenue claims are included; operational checks are process-driven.

Conversion link

If this is live traffic, open your support packet and include one passing and one failing sample (raw payload + policy context) before contacting KiwiWall engineering.

For implementation support, conversion flow review, and rollout guardrails, continue to the commercial workflow at KiwiWall platform setup and align with your target conversion strategy.

Related reading:

• S2S postbacks explained
• Postback URL parameters guide