Cost Caps and Target CPA When You Only Capture 60% of Your Conversions

A UK media buyer asked a question recently that deserves a better answer than it usually gets. On average they capture around 60% of their conversion data to send back to Meta, because consent rates in the EU and UK mean a large share of visitors are never observable. Can you use cost caps or bid caps at all when the in-dashboard CPA is knowingly wrong? The answer is yes, and the arithmetic is simple, but almost everyone gets the direction of the error backwards.

What a partial capture rate does to your CPA

Start with the mechanics, because the instinct here misleads people.

Suppose you spend £1,000 and genuinely generate 100 sales. Your true cost per acquisition is £10. Now suppose only 60% of those conversions are observable and reported back to the platform. The platform sees 60 sales for the same £1,000, so the dashboard shows a CPA of £16.67.

Your reported CPA is inflated, by exactly the inverse of your capture rate. At 60% capture, the dashboard number is roughly 1.67 times your real one. At 50% it would be double. Nothing is broken and nothing is lying; the platform is correctly dividing your spend by the conversions it was permitted to see.

Now look at what happens when someone sets a cost cap. They know their business can afford £10 per sale, so they set the cap at £10, which feels obviously correct. But the system evaluates that cap against the conversions it can see, and against that population £10 means demanding performance roughly 40% better than the business actually requires.

Delivery then does exactly what a cost cap is designed to do: it declines to bid, because it cannot find inventory that meets an impossible standard. The advertiser concludes that cost caps choke delivery and turns them off, when in fact the cap was set at a number they never intended.

The correction, in four steps

1. Find your true CPA from the backend. Take a stable period, ideally a month. Take total spend on the channel and divide it by the orders or qualified leads your own systems actually recorded for that period. This number does not depend on consent, cookies or attribution, which is precisely why it is the one to anchor on.
2. Measure your capture rate. Divide the conversions the platform reported for the same period by the conversions your backend recorded. If the platform reported 600 and you recorded 1,000, your capture rate is 60%. Do this for a full month rather than a week, since weekday and weekend consent behaviour differ.
3. Convert your target into dashboard units.Divide your true target CPA by the capture rate. A £10 true target at 60% capture becomes roughly £16.67 in the dashboard's terms. That is the number to put in the cap field, and it will feel too high, which is the point.
4. Validate against the backend, not the dashboard. After a couple of weeks, recompute spend divided by real orders. If your true CPA is landing near £10, the cap is working correctly regardless of what Ads Manager displays.

The same conversion applies to target CPA, target ROAS and bid caps. Any control that references a conversion count inherits the capture-rate distortion, and every one of them needs the same translation.

The assumption that has to hold

This arithmetic depends on one thing being true: that your capture rate is roughly uniform across the traffic you buy. If 60% of conversions are observable everywhere, scaling your target by 1.67 works cleanly.

It often is not uniform, and it is worth knowing where it breaks.

• Consent rates vary by country. Germany behaves very differently from Spain. A campaign running across several European markets has a blended capture rate that describes none of them accurately, which means one cap is simultaneously too loose in one market and too tight in another.
• Consent rates vary by device. Mobile users decline more often than desktop users, so a mobile-heavy campaign has lower capture than your account average.
• Capture varies by conversion type. A purchase you can also send server-side from your order system is far better captured than a soft conversion that only ever existed in the browser.

Where those differences are large, segment. Compute capture per market or per device and set caps per campaign accordingly. Where they are modest, a blended rate is fine, and better than not doing the correction at all.

Two things that shrink the problem instead of working around it

Correcting your caps is a workaround. It is a good one, but it is worth spending some effort on the underlying number, because a higher capture rate makes every downstream decision easier.

Consent mode and modelled conversions. Implemented properly, consent signalling lets platforms model some of the behaviour of users who declined, which partially fills the gap in a way that is compliant rather than sneaky. It does not restore individual-level data and it should not be sold to you as if it does. The detail is in consent mode and your tracking.

Server-side events with first-party identity. This is usually the bigger lever. A conversion sent from your own systems with hashed customer data attached does not depend on a browser having been allowed to fire, so accounts that move purchase reporting server-side often lift capture meaningfully above where a browser-only setup sat. The setup is covered in how to set up the Conversions API, and the reason identity matters so much is in improving event match quality.

Both come with the same caution. Neither is a licence to report conversions from people who declined to be tracked. The point of server-side events here is capturing the conversions you are permitted to capture more reliably, not evading consent.

Why the capture rate belongs on your dashboard

There is a second reason to compute this number beyond fixing your caps, and it may be the more valuable one.

Once you know your capture rate, it becomes a monitorable quantity. A stable 60% is a fact about your market and your consent design that you can plan around. A 60% that becomes 45% over three weeks is something breaking, and it will reach you first as a rising CPA and falling delivery that looks exactly like an auction or creative problem.

The causes of a falling capture rate are mundane and invisible: a consent banner updated by the vendor and now defaults differently, a tag that moved behind a consent category it was not in before, a site migration that stopped passing identity, or an expired credential on your server-side integration. None of those throw an error. All of them look like the ads got worse.

If you only take one operational habit from this article, take that one. Write down platform-reported conversions over backend conversions this month. Check it again next month. A drifting ratio is the earliest warning most measurement setups will ever give you, and it is the difference between finding a problem in days and finding it at the quarterly review. The wider version of this argument is in how much tracking discrepancy is normal.

When not to use a cap at all

The corrected arithmetic makes caps usable on a partial-capture account. It does not make them the right tool in every situation, and low capture makes two of the usual warnings sharper.

• When observed volume is genuinely thin. A cap needs enough conversion events for the system to find inventory that meets it. If your true conversion count is modest and your capture rate then removes 40% of it, the population the algorithm is learning from may be too small to work with. Below roughly a handful of observed conversions per week, a cap tends to produce erratic delivery rather than controlled efficiency, and controlling spend through budget is more honest.
• During any learning period. A new campaign, a new creative set, or a change to the optimisation event all reset what the system knows. Layering a tight cap on top of that means you are constraining a model that has not worked out what it is doing yet. Start looser, then tighten once delivery has stabilised.
• When your capture rate is moving. This is the one specific to consent-heavy markets. If your capture rate is drifting, the translation between your true target and the dashboard number drifts with it, and a cap you set correctly in March is silently wrong by June. Either stabilise the capture rate first or recompute the translation monthly.

There is also a reasonable case for skipping caps entirely on low-capture accounts and steering with budget plus a disciplined weekly review of true CPA from the backend. It is more manual and it removes an entire category of self-inflicted error. For a small account that is often the better trade.

What to tell the client

One last practical note, because this conversion creates an awkward reporting moment. When you correct the cap upward, the dashboard CPA will rise, and to anyone reading the report without context that looks like performance got worse.

Get ahead of it. Explain before you make the change that the reported number is inflated by an incomplete view of conversions, that the cap is being set in the dashboard's units rather than the business's, and that the number you will both be judging success on is spend divided by real orders. Agree that denominator in advance.

That conversation is much easier to have before the number moves than afterwards, and it tends to raise your standing rather than lower it. Few things build confidence faster than being the person who predicted the confusing number a month before it appeared.