Sending Delivered-Order Feedback to Ad Platforms
Your ad platform reports a purchase the moment a customer submits a cash-on-delivery order. Your business only earns money when the parcel is handed over and the cash is collected. The decision in front of you is whether to keep letting the platform optimise toward the first moment, or to feed it the second.
Why the order-created signal misleads
A platform optimises toward whatever you tell it counts as a conversion. If that is "order submitted", it will look for people who submit orders. It cannot tell the difference between a customer who will accept the parcel and one who will refuse it, cancel by phone or never answer the courier.
Two things make this worse in cash on delivery. Orders are cheap to place, since there is no payment step to filter out casual clicks. And the gap between order and outcome is long, often days. So the number in your ad dashboard can look healthy while the number in your cash account does not.
For the economics behind this, see Delivery and Return Rates: The Real Cost of Failed Orders and How to Calculate Your Advertising Break-Even Point Before Scaling.
A model: three stages, three signals
Think of every order as passing through three stages. Each can be sent to a platform, and each answers a different question.
Order created
Customer submits the form. Fast, but the least reliable.
Stage 1Confirmed
Your team or an automation reaches the customer. Cleaner, still not cash.
Stage 2Delivered
The parcel is accepted and cash collected. Slowest, closest to revenue.
Stage 3
The earlier the signal, the more data and the more noise. The later the signal, the cleaner it is and the longer you wait.
You do not have to pick one forever. Many businesses keep the first signal for speed and add the third as the one that reflects value. The right mix depends on volume, which the section on trade-offs covers.
What an illustrative example shows
Illustrative example, not real results. Suppose a store spends 6,000 SAR in a week and receives 100 orders worth 200 SAR each. Of those, 70 are delivered and paid.
Orders counted
Delivered: 100
**70**
Revenue counted
Delivered: 20,000
**14,000**
Cost per order
Delivered: 60
**85.71**
Revenue per 1 spent on ads
Delivered: 3.33
**2.33**
Same spend, same week. The platform's default view is more flattering than the delivered view.
Check the arithmetic: 6,000 divided by 100 is 60, and divided by 70 is about 85.71. Revenue is 100 x 200 = 20,000 against 70 x 200 = 14,000. Return on spend moves from 3.33 to 2.33.
The point is not the figures. It is that a campaign judged by its default numbers and one judged by delivered numbers can rank differently, and only one of them matches your bank.
How the signal reaches the platform
The mechanism differs by platform, and the details change, so read the current documentation before building.
- Meta. The Conversions API can receive events from your own systems, and Meta documents a route for sending offline events tied to a dataset. A purchase event needs a time, a currency and a value, and an order identifier helps with matching. See Meta's own page on sending offline events.
- Google Ads. Google supports importing conversions that happened after the click, matched through a click identifier or through hashed customer details. Google's help pages describe the older file-based import as legacy and point towards enhanced conversions for leads and its Data Manager. Because this area is changing, confirm which route your account should use.
- TikTok and Snapchat. Both offer server-side event routes. Check their current documentation for event names and fields.
In every case the pattern is the same. Store the identifier the platform gave you at click time (or the customer details it can match), keep it with the order, and when the order reaches "delivered", send one event with the real value.
Trade-offs and when the advice changes
- Volume. Platforms learn from enough conversion events. If delivered orders are very few, a delivered-only signal may starve learning. Keeping an earlier event as the main optimisation target and using delivered data for your own evaluation is a legitimate choice.
- Delay. Delivery takes days, and platforms accept late events only within windows they define. If your courier cycle is longer than that window, the signal arrives too late to use. Check the limits in current documentation.
- Duplicates. Sending both an early and a delivered purchase can double-count. Use a separate event or conversion action for delivered orders, or follow the platform's deduplication rules. See Duplicate Purchase Events.
- Data quality. A wrong delivery status is worse than none. If statuses come from couriers by hand, expect gaps.
- Consent and privacy. Customer details you send must be ones you may use for this purpose. If unsure, confirm with your legal adviser.
Implementation steps
- Capture the platform click identifier or matching details at order time and store them on the order.
- Define "delivered" precisely: accepted by the customer and cash received, not "left the warehouse".
- Decide what to send: a separate delivered event with the order value, kept apart from the early event.
- Automate the trigger: when the status changes to delivered, send the event once, with the order identifier as a duplicate guard.
- Test with the platform's testing tool on a small batch before relying on it.
- Compare the delivered view to your accounts each week.
What you still cannot know
A delivered event tells the platform which clicks led to cash. It does not prove the ad caused the sale, and it does not recover customers who bought later through another channel. Matching is partial: some events will not be matched to a click. Delivery lag means recent campaigns always look worse than they will. Treat the delivered view as a better lens, not as the truth.
Next step
If your delivery data lives in a courier sheet or a store admin, the first job is a reliable status per order. The Delivery Signal service is built around sending that status back, and the tracking setup service covers the browser and server events around it. Start with Cash on Delivery vs Prepaid: How Order Economics Differ and Meta Conversions API Explained for the groundwork.