Sep 24, 2026 · Germán Muñoz Moreno, Co-founder
8 things that inflate your reported ROAS without moving a single sale

My reported ROAS went up but revenue did not. What could have caused that?
Every mechanism below is something a competent person does on purpose for a good reason. None of them is a trick. What they have in common is that each one raises a reported number while the business stays exactly where it was, and reports do not label which kind of increase you are looking at.
That matters because the next budget gets set against the number. A merchant who raises spend against a figure that moved for a measurement reason finds out in the bank account rather than in the dashboard, usually a quarter later.
1. Switching on server-side event delivery
This is the most common one by a wide margin, and it is first on the list because it is the thing almost everyone in this market sells.
A conversions API sends your purchases from your server instead of the shopper's browser, which recovers the population the browser loses: ad blockers, tracking protection, a checkout that renders on a payment provider's domain, a tab closed on the confirmation screen. Those are real sales that really happened and the platform genuinely influenced some of them, so reported conversions rise. That is the intended effect and it is a good thing.
It is also not more revenue. What changed is how much of the same revenue the platform can see and claim. Write down your reported ROAS the day before you switch it on, so nobody reads the step change as growth.
2. Widening an attribution window
A longer window catches more sales while the spend stays the same, so the ratio improves arithmetically. Nothing about the campaign changed.
Worth knowing which direction the platforms are moving: Meta's default has shortened twice, and on 12 January 2026 the 7-day and 28-day view windows were removed entirely while a newly created ad set now defaults to 7-day click alone. Existing ad sets keep their old setting, so a single account often holds several windows at once and a change made months ago can still be shaping a comparison today.
3. Adding a conversion action to the primary set
The platform's Conversions column sums every action the account has configured and marked primary. Promote add-to-cart, or a newsletter signup, or a phone call, and it joins the same number you have been dividing by spend.
There is nothing wrong with optimising toward those outcomes. What goes wrong is that the column is often the numerator in a ROAS calculation somebody built months ago, and nobody revisits that calculation when the conversion set changes.
4. A deduplication failure
The most expensive one, because it scales with your volume and it looks like the best news you have had all quarter.
Sending purchases from both the browser and the server is correct practice, and what makes it safe is that both events carry the same event ID so the platform can collapse them into one. If the two sides generate their IDs independently, or one omits it, every sale arrives as two. Reported conversions roughly double and reported ROAS doubles with them.
It is also among the easiest to rule out. Meta reports it directly under redundant purchase events, and publishes deduplication feedback per key showing what share of events were actually collapsed and on which identifier. Google rejects a repeated order id and the rejection appears in its upload diagnostics.
5. Summing the platforms
Each platform sees only its own touch. A buyer who clicked a search ad on Tuesday and a social ad on Thursday and bought on Friday gives both platforms a defensible claim on that one order, and both report it as one conversion. Neither is wrong and neither can adjust for the other, because neither can see it.
The inflation appears at the moment you add them together and read the total as sales. Every spreadsheet that lists platforms as rows and totals the column does this by default, which is why the sum of platform-reported revenue routinely exceeds what the store actually took.
6. Not subtracting refunds
A cancelled or fully refunded order stops being revenue in your store the moment it settles. In the ad platform it generally stays a conversion, because the platform was told about the purchase and never told about the reversal.
So reported ROAS is computed on gross sales while your margin is computed on net, and the gap grows with your return rate. It runs in the flattering direction and it is invisible unless you deliberately pull the same window twice, once with cancellations included and once without.
7. A filter on one side and not the other
The classic version is the new-customer filter. Turn it on and your side of a platform comparison narrows to first-time buyers while the platform's side stays whole, because the platform is reporting every purchase it believes it drove.
This does not always inflate ROAS directly, but it reliably distorts every derived number built on top of it, including cost per new customer. And it is worth naming its cousin: a bounded lookback for deciding who is new. Any window silently demotes a loyal buyer to new whenever their last purchase falls outside it, which inflates the new-customer denominator with people you already had. That one is ours: we shipped a version that did exactly this and the fix was to compute first-order status over the customer's entire history.
8. Counting view credit and click credit in one number
A view-through conversion credits a sale that followed an ad which was shown and never clicked. It is a real phenomenon and it is also the credit you cannot corroborate anywhere, because it produced no visit and therefore left no trace in your own data.
Blending it into the same total as click-driven conversions does not inflate the total dishonestly, but it does make the total less checkable than it looks, and the share is invisible unless you read the click-only figure alongside it. Two numbers with different amounts of evidence behind them should not sit in one cell.
The one check that catches all eight
Every mechanism above raises a number that has an attribution model inside it. So put that number next to one that does not: total revenue divided by total marketing spend, blended across everything, sometimes called MER.
That ratio cannot be inflated by a window change, a conversion action, a deduplication failure, or a summation error, because it never attributed anything in the first place. Real growth moves both numbers. A measurement change moves only the reported one, and it usually moves it on a date you can find.
The underlying reason is the same one that answers most questions on this blog. Your store's settled orders are the only figure in this picture with no credit rule inside it. A platform can legitimately resolve a buyer you never saw, but no platform can resolve an order that does not exist, which is why anchoring on that list turns an argument about models into arithmetic you can check.
Common questions
How do I tell a measurement change from real growth?
Put the reported number next to total revenue divided by total marketing spend, sometimes called blended ROAS or MER. That ratio has no attribution model in it and therefore cannot be inflated by any of the eight mechanisms here. Real growth moves both. A measurement change moves only the reported one, and it usually moves it on a specific date you can find in a change log.
So should I not install a conversions API?
Install it. It recovers real sales that the browser genuinely lost to ad blockers, tracking protection and off-domain checkouts, and better data going in produces a better-informed claim coming out. Just write down your reported ROAS the day before and expect it to rise, so that nobody in the next budget meeting reads recovered reporting as new revenue.
Is a longer attribution window dishonest?
No, it is a judgement call about how long your buying cycle really is, and the honest way to make it is from your own data rather than from a default. What is dishonest, or at least misleading, is comparing a period before the change against a period after it. That comparison contains the settings change, performance may also have moved, and the report cannot separate them.
Why would summing my platforms inflate anything?
Because each platform sees only its own touch. When a buyer clicked a search ad on Tuesday and a social ad on Thursday and bought on Friday, both platforms hold a defensible claim on that one order and both report it as one conversion. Neither is wrong. The error appears at the moment you add them together and read the total as sales, which is exactly what a spreadsheet with platforms in rows invites.
Which of the eight is the most expensive to get wrong?
The deduplication failure, because it scales with your volume and looks like the best news you have had all quarter. If your browser and server events do not share an event ID, every sale arrives as two, reported conversions roughly double, and reported ROAS doubles with them. Meta reports it directly under redundant purchase events, so it is also one of the easiest to rule out.
