COD Approve Rate Tracking: Which Event Fires on Confirmation

Underneath COD approve rate tracking lies a liar's hour between the order and the sale: the user "buys" at checkout, but the money exists only after a call center confirms the order, the warehouse ships it, and the courier collects the cash. Send the checkout event as a Purchase and you teach the platform to find people who order and vanish. Silence until approval and you starve it. The working answer is a two-event stream wired through your tracker's statuses - and this guide builds it: what each event says, how confirmation travels through the tracker, how approve rate decides the mix, and how the confirmation lag fits inside the platform's window. Its status-policy foundation sits in the hold status guide; this page is the COD-specific build on top of it.

The Two Events: What Each One Tells the Optimizer

Every COD funnel produces two facts at different times:

Sending only the first trains the algorithm on forms - cheap to fill, easy to fake with junk traffic. Waiting for the second before sending anything is truthful but slow: by the time confirmations arrive, the optimizer has been running blind for days. Two-event streams feed both truths without mixing them, and the custom conversion machinery keeps the named events reportable and optimization-eligible.

The one thing the pair cannot survive is name-sharing. If lead and confirmation both fire as Purchase, the platform counts the same order twice at different values - the duplicate problem from the three-systems guide in its purest form.

How Confirmation Travels Through the Tracker

On the tracker side, a COD order is a conversion that changes status. Keitaro's postback contract models this directly: statuses like lead and sale are documented values of the status parameter, status transitions are validated - a conversion cannot jump to a state its configured transitions disallow - and the settings define which status fires which outgoing postback (postback URL, postback troubleshooting).

The COD wiring reads like a state machine:

1. The order form converts; the network posts a lead-status conversion tied to the click's subid.
2. The call center calls. Confirmations and rejections come back through the network as new postbacks on the same subid - without a separate tid, so the repeat postback updates the existing record instead of adding a second conversion.
3. The tracker's transition rules move the row from lead to sale - or to rejected - and the S2S postback configured for the sale status fires to the delivery layer (S2S postbacks).
4. The delivery layer sends the Purchase-class event with the confirmed payout as value (custom data parameters).

Because the outgoing postback is bound to a status, the two-event stream needs no extra plumbing: the lead stream fires on one status, the sale stream on the other, and rejected transitions fire nothing.

Approve Rate: The Number That Picks Your Policy

Not a platform term, approve rate is arithmetic on tracker data. For each campaign slice, divide confirmed orders by total orders over a period:

approve_rate = confirmed_sales / total_leads

At 70 percent approve rate, a lead event is a decent promise - the optimizer can lean on it. Near 25 percent, lead events are mostly noise, and the purchase stream deserves the weight. Practical uses:

1. Budget triage. A campaign whose approve rate collapses after a creative change found a new kind of junk - pause before the purchase stream drowns.
2. Event weighting. The lower the approve rate, the more your reporting and optimization should lean on confirmed sales, with lead events treated as a volume signal only.
3. Offer comparison. Same traffic source, different call centers - approve rate is the honest comparison metric, and it lives entirely in tracker reports.

The denominator matters as much as the ratio: hold windows mean recent leads have not finished becoming sales, so compute approve rate on cohorts old enough to be decided - the same wait-for-the-window logic from the hold guide.

Confirmation Lag Versus the Platform Window

Meta's Conversions API accepts event_time up to seven days in the past, and one stale event fails a whole request (using the API). COD confirmations typically arrive within hours to a few days, leaving headroom - but the chain's total lag is call center plus network reporting plus your delivery queue, and slow verticals can eat the budget.

Two rules keep the stream safe. Measure the actual lag percentiles in the tracker's logs rather than guessing - Keitaro's postback and S2S logs show when conversions arrived and what fired (logs). And if confirmations structurally outrun the window, the fix is upstream - faster-confirming offers, or the lead event carrying the optimization weight while sales serve reporting, as in the warming discipline.

Verifying the COD Stream

1. Place a real test order through the campaign link; network test postbacks carry no real subid.
2. Watch the lead event arrive at the platform - Meta's Test Events shows it immediately; Events Manager within about 20 minutes (get started).
3. Confirm the order in the tracker (or have it confirmed), and watch the sale event fire with the right value.
4. Check the numbers: one order should show one lead and one sale across the chain - any more is the duplicate wiring failing.

Pixel Activator can pre-verify the platform leg for free; the full postback troubleshooting checklist covers the tracker-side failure modes.

COD Approve Rate Tracking: Frequently Asked Questions

Sources