Back to all articlesData

Cash on delivery: the sale your dashboard counts and your bank never sees

With cash on delivery, the event your campaign celebrates isn't money in the bank. Somewhere between 15% and 35% of orders are never collected, and your algorithm keeps hunting for people who confirm without paying. Optimize for delivery instead.

Talent Warehouse··4 min read
A delivery rider waits at night outside a closed door, package in hand, direct flash lighting the wet pavement.

If you sell cash on delivery in Colombia, Peru, Ecuador or much of Mexico, your Meta dashboard lies to you every single day. Not because of attribution or cookies, but because it is counting an event that is not money yet.

The Purchase event fires when someone confirms an order at checkout. With cash on delivery, that is not a sale. It is a stated intention that has already cost you shipping. The sale happens three, seven or twelve days later, when a rider knocks and the customer pulls out cash. Or does not.

You are optimizing a number you never collect

Meta and Google learn from whatever you feed them. Feed them a purchase at the moment of confirmation and they will go find more people who confirm orders. People who confirm an order in one tap, with zero money down, are not the same people who pay when the package arrives.

Those are two different audiences and the platform only knows one of them. Over a few weeks the campaign specializes in the cheap profile: the one who fills the form at 11pm, gives half an address, and does not remember what he ordered when the doorbell rings. Your CPA drops, your ROAS climbs, and your bank balance does not move.

Rejection rates in COD operations across the region typically land between 15% and 35%, depending on country, category and how seriously the confirmation step is run. That is not an ops footnote. At 30% rejection, a reported 3x ROAS is really 2.1x before you touch the cost of the return.

The costs no dashboard shows you

A rejected order does not cost zero. It costs:

  • Outbound freight, already paid or about to be deducted by the carrier anyway.
  • Return freight, which almost nobody builds into unit economics.
  • Packaging that comes back damaged and often cannot be resold.
  • Inventory frozen for ten to twenty days between transit and the returns shelf.
  • Team hours spent calling and chasing someone who was never going to pay.

Add it up and a business with 30% rejection does not keep 70% of its margin. It keeps noticeably less, because the failed 30% eats into the margin earned by the orders that worked. This is the arithmetic most paid media teams skip, and it explains why an account that looks profitable in the report is broke at the bank.

What changes when delivery is the conversion

The fix is easy to describe and awkward to ship: stop sending the algorithm the confirmed order and start sending it the delivered, collected one.

  • Keep the standard Purchase at confirmation if internal reporting needs it, but add a separate event, call it Collected, that fires only when the carrier reports both delivery and payment.
  • Send that event through the conversions API with the amount actually collected, not the cart value. If the customer negotiated at the door, send what landed.
  • Optimize scaling campaigns on that event. You get less signal and more latency, which is exactly why the confirmation event still earns its keep on new campaigns fighting through learning.
  • Deduplicate on order_id. A seven to twelve day gap between the two events breaks any setup without its own identifier.

Latency, not configuration, is the real constraint. Meta attributes inside its window, so if average delivery is nine days out, a chunk of your conversions never gets seen by the campaign that produced them. Two ways out: shorten delivery time, which is an operations project rather than a marketing one, or run value-based optimization with a weighted value.

The shortcut worth running first

If you cannot close the technical loop this week, there is a middle step that pays off fast: put expected value into the confirmation event.

If your delivered-and-collected rate over the last ninety days was 68% in Bogota and 54% in Barranquilla, stop sending the same cart value for both. Send cart value multiplied by that segment's historical rate. The algorithm starts favoring the cities, hours and products that actually get collected, without waiting twelve days to learn it.

Segment it by city, contact channel, product and hour of order. The spreads are wide and usually counterintuitive. There are cities where CPA runs 20% higher and real margin is double.

Confirmation is not marketing, but it sets your ROAS

No amount of media optimization rescues a weak confirmation process. What actually moves the number in this region is unglamorous:

  • Call or WhatsApp inside thirty minutes of the order, not the next morning.
  • Active confirmation. The customer has to reply something, not merely be notified.
  • A heads-up on delivery day with a real time window.
  • The exact amount in the message, so nobody is caught scrambling for cash.

An operation that moves from next-day confirmation to thirty-minute confirmation picks up several points of delivery rate, and that single change is worth more than any creative test you will run this month.

The report you should be sending

If your weekly report shows ROAS but not delivery rate, you are not reporting on a business. You are reporting a pixel's opinion. Three columns are enough: orders confirmed, orders collected, and collected revenue divided by spend. Only the last one can be taken to the bank.

#cash on delivery#ecommerce#roas#measurement#latam