On a cash-on-delivery account, two numbers describe the same week and disagree. Meta reports a purchase the moment the order is placed. The money arrives days later, if it arrives at all, because a share of those orders is refused at the door, returned, or never answered. Every decision you make between those two moments is made on the first number.
That is not a reporting nuisance. It is an optimisation problem, because Meta is learning from the same event you are reporting on. If the event fires on a placed order, the algorithm gets very good at finding people who place orders, and some of them are people who place orders they do not intend to pay for. The account improves at the thing you asked for, and the bank balance does not follow.
Why the two numbers disagree
The purchase event fires on the confirmation page. Nothing that happens afterwards reaches Meta unless you send it. So the reported figure includes every order that was later refused, returned unopened, cancelled by phone, or never delivered because nobody answered the door on three attempts.
The gap between the two is not a constant, which is what makes carrying it in your head so unreliable. It moves with the offer, the price point, the category, the governorate, and the courier. A campaign that sells a low-consideration impulse product to a cold audience will carry a much wider gap than one selling a repeat purchase to people who already know the brand. So a single blended correction factor, applied across the account, hides exactly the differences you would want to act on.
The first job is therefore not to fix Meta. It is to get one honest number: for a recent month, what share of placed orders turned into money, split by campaign. Most stores can pull this from the courier's delivery report and their own order export in an afternoon. Until that number exists, everything downstream is a guess with a decimal point on it.
Pick the event Meta should learn from
Once you know the gap, the question is which event Meta optimises toward.
If you have the volume, send the paid-and-delivered event. This is the correct answer whenever it is available. Meta learns from the outcome you actually get paid for, and the people it finds are people who take delivery. The threshold is the usual one, roughly 50 conversions a week per ad set, and it bites harder here than elsewhere because the event arrives late. An ad set clearing 60 placed orders a week may only clear 25 confirmed ones, and an ad set below the threshold learns slowly and spends badly.
If you do not have the volume, keep optimising for the placed order and change what you judge it by. This is the honest fallback, and it is where most Egyptian stores sit. Leave the placed-order event as the optimisation goal so the algorithm has enough signal, and hold the account to a cost per paid order that you compute yourself, weekly, from the delivery data. The account optimises toward one number and is judged on another. That is uncomfortable and it is better than the alternative, which is judging it on the same inflated number it is chasing.
What not to do is sit between the two. Optimising for placed orders while reporting placed orders as revenue is the default setup, and it is the one that quietly funds the campaigns with the worst refusal rates for months.
Feed the real outcome back
Two routes get delivery status back to Meta, and both work.
The offline event route takes a file of confirmed orders, keyed to the original click, and confirms them after the fact. It is the lower-effort option and it suits a store whose courier sends a daily or weekly delivery report. The server-side route sends the event from your own systems at the moment the status changes, which is cleaner and needs engineering time you may not have.
Whichever route you pick, the hard part is the same and it is not on the Meta side. It is getting delivery status out of the courier and into your own order records on a daily basis, matched to the order, reliably enough to build on. Stores that skip this step end up with a measurement plan that describes a data feed nobody is maintaining. Solve the operational half first, and the technical half is a week of work.
One thing worth deciding early: whether a refused order is sent as nothing, or sent as a negative signal. Withholding it is simpler and is usually enough. Sending refusals as their own event is more powerful and much easier to get wrong, because a mislabelled event teaches the algorithm the opposite of what you meant.
The offer is a lever on refusals, and it is under-used
Refusals are not purely an audience problem. A meaningful share is caused by things the storefront did or failed to do between the click and the doorstep, and those are cheaper to fix than a targeting rebuild.
The clearest example sits in the Egyptian storefront data. Across the 23 storefronts in Mojo's review report, all 23 state a free-shipping threshold and not one states when the order will arrive. A buyer who does not know whether the box comes on Tuesday or in two weeks has no reason to be home for it, and every day of unexplained delay is another day for the purchase to stop feeling necessary. A stated delivery window is free to publish and it is the single most common gap in the market.
Proof is the second gap. In the same set, 21 of 23 storefronts showed no visible reviews at all, and review software is free or near-free. The one brand that had built real review volume paired it with a 45 percent repeat rate. A buyer who is being asked to hand cash to a stranger at the door is making a trust decision, and an empty product page gives them nothing to hold on to.
Three more that move the number: a confirmation message that a human answers, so a hesitant buyer cancels before the courier is paid rather than at the door; a small incentive for paying in advance, which converts your best-intentioned buyers to prepaid without turning the rest away; and honest delivery-cost presentation, because a fee that appears at the door is a refusal waiting to happen. Against internationals entering at the EGP 199 price points documented in the high street comparison, operational credibility is one of the few defences a local brand can build quickly.
Budget and bidding when a third of the orders may not pay
Set cost caps against the paid order, never the placed one. If your paid-order rate is 65 percent and you are willing to pay EGP 200 for a paid order, then the cap on a placed-order event is EGP 130, not EGP 200. This one piece of arithmetic is the difference between a cap that protects margin and a cap that looks reasonable and does not.
Be more patient than the reported numbers invite. A delivered-and-paid signal arrives days late, so a week's performance is not fully visible until the following week. Judging a COD ad set on three days of reported purchases is judging it on the half of the picture that flatters it. Give changes a full delivery cycle before reading them.
Watch refusal rate by campaign, not only in aggregate. It is common for one campaign to carry a refusal rate far above the account average, and for it to be a campaign that looks strong on reported ROAS. That campaign is the reason the blended figure is bad, and finding it is usually worth more than any bidding change. Month-end timing matters too: in a market where demand concentrates around payday, as covered in the payday cycle guide, an order placed at the thinnest point of the month is more likely to be refused than the same order placed three days after salaries land.
Where this does not work
Below roughly 200 orders a month, the paid-order rate is too noisy to split by campaign, and the honest answer is a single account-level correction factor recalculated monthly. Categories bought on impulse at low price points will carry refusal rates that no measurement work fixes, because the problem is the purchase decision rather than the reporting of it. And if the courier cannot return delivery status in a usable form, none of the feedback routes above is available, and the only remaining move is to price the refusal rate into the target and revisit the courier relationship.
None of this is a reason to leave the default setup in place. Even the weakest version of this work, one honest paid-order rate per campaign recalculated monthly, changes which campaigns get money. That is usually worth more than the rebuild it replaces.
If you want a second pair of eyes on where your reported and paid numbers diverge, tell us about the account and we will take a look.
