Case: a postback retry queue recovered 4.2% of conversions lost to tracker downtime

Case: a postback retry queue recovered 4.2% of conversions lost to tracker downtime

The leak: during a 25-minute tracker outage (server reboot during an update), every postback fired by networks in that window hit a dead endpoint and was gone. The conversions existed on the network side but never entered the tracker.

What the audit found:
— Over 90 days, total tracker downtime was ~3 hours across small windows
— Cross-referencing network exports, ~4.2% of monthly conversions had no matching tracker record, clustered around those windows
— Networks that retry postbacks recovered automatically; ones that fire-and-forget lost the conversion permanently

The resilience setup we built:
1. For self-hosted Keitaro, put the tracker behind a lightweight queue (an Nginx-level catcher) that accepts and stores postbacks even when the app is mid-restart, then replays them
2. For networks that support it, requested retry-on-failure with a 3-attempt schedule
3. Added a daily reconciliation job comparing network exports to tracker conversions, auto-flagging gaps over 1%
4. Scheduled tracker updates only behind the catcher, never on a naked endpoint

Outcome: the conversion gap fell from 4.2% to under 0.5%, and the daily reconciliation now catches any new leak within 24 hours instead of at month-end.

Your postback endpoint must survive your own deploys. Catch, queue, replay, reconcile.

Save this SOP. Run this before every launch.