Advertiser postback reconciliation guide
Reconcile advertiser and publisher reporting with a repeatable workflow that prevents payout disputes and silent quality regressions.
Advertiser postback reconciliation guide in brief
Reconciliation is only reliable when you can map every accepted conversion to one canonical event and one ledger line. If you run this as a recurring workflow, you remove ambiguity about who deserves each payout and who owns each rejection.
Who this is for
- Advertisers who need campaign reporting confidence before scaling budget.
- Finance teams resolving variance between internal tracker and KiwiWall reports.
- Publisher operations owners who need to understand why discrepancies appear.
Definition
Advertiser postback reconciliation compares two truths:
- What the KiwiWall event says (accepted, rejected, latency, reason).
- What your campaign platform says (installs, leads, sales, value, chargeback state).
Your process has three layers:
- Event capture validation
- Status harmonization
- Settlement proof
A mismatch is no longer an incident by default; it is a data signal with ownership and closure path.
Decision table
| Report gap pattern | Likely root cause | Immediate action |
|---|---|---|
| Higher advertiser conversions than KiwiWall accepts | Missing click metadata before publisher handoff | Pause affected source and verify click_id, campaign id, and objective tags |
| Higher KiwiWall accepts than advertiser conversions | Delayed conversion import or conversion de-dup path differences | Compare raw event timestamps, queue age, and retry counts |
| Same volume, different reason codes | Reason mapping mismatch (rejected, filtered, invalid) |
Create a shared reason code dictionary and enforce versioning |
| Payout differs by value | Pricing table or objective mix drift | Lock objective-specific payout tables and re-run prior 7-day window |
How it works
- Align identity fields first: publish one shared required identifier policy and freeze naming for at least one sprint.
- Set a canonical event window: compare only the same
event_dayand campaign objective. - Normalize status language: map
approved,rejected,pending, andinvalidinto shared buckets. - Run side-by-side daily checks:
- total postback accepts
- total advertiser conversions
- rejects by reason and owner
- latency percentiles
- Escalate only when a tolerance threshold breaks: e.g., more than 2% delta across two windows.
Checklist
- Confirm
click_id,transaction_id, and source identifiers are present in both systems. - Create a shared status dictionary for accepted, rejected, rejected-after-review, and invalid.
- Compare totals by objective and campaign before payout decisions.
- Validate retry and dedupe behavior for delayed postbacks.
- Document root causes for each mismatch and tag owner.
Common mistakes
- Comparing hourly windows when one platform reports daily.
- Treating different objective buckets as one metric.
- Investigating volume differences without checking
pendingandawaiting reviewstates. - Running reconciliation ad hoc only when disputes appear.
Conversion link
Use this flow before the first budget step-up in Advertiser performance scaling, then schedule a support call if two consecutive windows exceed your tolerance at Contact.