A falling purchase CPA is hard to argue with. The dashboard is green, order volume is climbing, and the algorithm appears to have found a cheaper customer. Then the cash-on-delivery orders begin returning, the verification calls pile up, and the supposed efficiency disappears somewhere between checkout and delivery.
Meta did not necessarily find a cheaper customer. It found a cheaper purchase event. The difference belongs in the campaign decision before the lower CPA earns more budget.
Count the order after checkout
A purchase event records a moment in the funnel. The business pays for everything that happens after it: failed verification, return-to-origin costs, pickup costs, manual calls, and orders that never become collected revenue.
Platform CPA is one input to unit economics, and it settles nothing on its own. A cheaper cash-on-delivery order can still lose money that a more expensive prepaid order keeps once enough of the cheap orders fail after checkout. Measure against the delivered, legitimate order: the outcome the business can actually keep.
Build the comparison at the order level. Separate prepaid and cash-on-delivery volume, carry the post-purchase losses into each group, and calculate the effective cost of the outcome the business can actually keep. A campaign that looks more expensive inside Ads Manager may be the cheaper commercial system.
Falsifying the purchase value destroys the measurement
When automation favors an unwanted order mix, lowering the reported purchase value for cash-on-delivery orders can feel like a clever correction. It is also a dangerous shortcut. The value sent back would no longer describe the purchase that happened; it would become a private penalty invented to steer delivery.
That makes future reporting harder to trust. The campaign may move, but the team loses a clean account of what the event was worth and why the system changed. A steering mechanism that corrupts measurement creates a second problem while hiding the first.
Feed the real post-purchase outcome when the system can support it. Until then, keep the purchase value honest and apply the quality adjustment in business reporting. The goal is to make customer quality legible. Disguising a preference as transaction value does the opposite.
The average can hide an unacceptable month
Broad automation adds another complication: the average result can look stable while individual campaigns swing from excellent to terrible. Consolidation removes some of the averaging that separate ad sets once provided, so each campaign can become a wider draw from the same expected outcome.
Inspect the spread of campaign CPAs over the same decision window, not only the blended average. A business with enough volume may absorb that variance inside a week. A smaller advertiser may experience the same distribution as one damaging month. Neither is automatically using the wrong structure; they have different tolerance for the bad draw.
The decision is partly financial. Ask how much variance the business can survive before automation earns the freedom to find its average.
Verify the cheap orders before you diagnose them
An abrupt wave of cheap cash-on-delivery orders deserves verification. It does not justify declaring the orders fraudulent or automated without evidence. Check whether the customers can be reached, whether addresses and order patterns look legitimate, and whether delivery outcomes differ from the previous mix.
If order validity collapses, the lower CPA has already failed the business test. If the orders are genuine but less profitable, the problem is unit economics rather than fraud. Keeping those diagnoses separate prevents a weak result from turning into an unsupported story about why it happened.
The reporting rule is simple: show platform CPA beside effective cost per delivered order, split by payment type, and include the work and losses after checkout. Then inspect the spread across campaigns before scaling.
Automation deserves credit only for the outcome the business can keep. A cheaper event that creates a more expensive customer is not efficiency; it is a measurement gap with a green number on top.