The first product-level export from a catalog campaign is a good afternoon. 1,800 SKUs in the feed, 63 of them with more than 20 euros of spend last month, one row sitting at 9.1x ROAS and another at 0.4x. Inside 10 minutes you have a kill list and a scale list, and both feel obvious.

I have built that list. It was wrong in a way that took a quarter to notice, and the data being incomplete had nothing to do with it.

Short answer: Product level reporting for catalog ads describes how Meta's delivery system spent your budget across the feed, so a SKU's ROAS mostly reflects which audiences it was shown to. Use the export for coverage, spend concentration and zero-revenue exceptions. Ranking the middle of a catalog by ROAS is noise.

The takeaways

Delivery picked the sample. Meta decides which product each person sees, so a SKU's ROAS reports on the impressions it was handed.
Most rows are unreadable by design. In the catalogs I have worked in, well under 5% of SKUs collect enough monthly purchases for a ratio to hold still.
A zero beats a ratio. 200 euros of spend and no revenue across 90 days is a claim thin data supports. 1.4x against 2.6x on 3 orders each is not.

Where do the per-product numbers come from?

From the same place the ad-level numbers do. Meta's Marketing API returns spend, impressions, clicks and results per product_id, which is what the catalog reporting connectors are built on. Commerce Manager shows a slice, a warehouse holds all of it, a spreadsheet export gets you started.

Access is not the interesting part of this problem, even though most of the advice written about it treats access as the whole problem.

One setup detail has to be right before any row is true: the ID your pixel sends in content_ids must match the id column in your catalog. When those drift, revenue lands on the wrong product or on none, and the table still looks reasonable. Check 5 recent orders by hand first.

Why doesn't a low ROAS mean the product is the problem?

Because you did not choose who saw it. A catalog campaign runs one ad, and the delivery system decides which product goes in front of which person. A SKU served to somebody who left it in a basket yesterday converts. The same SKU dropped into cold prospecting as the fourth card in a carousel does not.

Your export cannot tell those 2 impressions apart. It adds them up and prints a ratio.

So product-level ROAS measures an allocation you never made. Winners look strong partly because delivery handed them the easy impressions, and they got those impressions partly because they were already converting. The loop is closed, and your export sits inside it.

Same trap as judging an ad set on ROAS after the algorithm has steered its budget for 3 weeks. The number is real. What it measures is the steering.

How much spend does a product need before you can read it?

More than most of your catalog will ever get. Sort the export by spend and the shape repeats across every feed I have seen: a short head takes the budget, and hundreds of rows sit on single-digit euros.

Work backwards from orders rather than spend. A ratio built on 2 purchases swings by half when the third one lands, so it will cross any threshold you draw in both directions inside a month. I want roughly 20 purchases on a row before I read its ROAS as a number instead of a mood.

At a 2% conversion rate and a 1 euro click, 20 purchases is about 1,000 euros on one SKU. In an 1,800 product feed, a couple of dozen rows clear that bar. The rest still belong in the report, as a group.

What can the export actually decide?

Three things, and a ROAS ranking is not among them.

Coverage first. Count the SKUs that received any impressions at all. A catalog of 1,800 products where 300 ever got served is a feed finding: the other 1,500 are out of stock, missing an image, failing a policy check or priced out of the auction. Meta catalog feed errors walks those checks.

Concentration second. What share of spend and revenue do your top 20 rows take? That is a merchandising fact about the assortment, and it survives thin data because you are reading sums.

Exceptions third. Real spend, zero revenue, over a window long enough that an order would have appeared. Zero is a cheap claim: it needs no stable denominator. A product that burned 200 euros across 90 days without one purchase is the single row you can act on alone.

How do you test a product-level hunch?

By changing something the delivery system can see. You cannot A/B two SKUs inside one catalog ad set, because the mechanism assigning impressions is the mechanism you would be testing.

The cheap version is a feed change. Pull the suspect group out of the product set, leave the structure alone, and watch the campaign total for 2 weeks. If the aggregate holds, those products were spending without contributing. If it drops, they were doing work the per-product view hid.

The expensive version is structural: custom labels, a separate product set, its own ad set and budget. Now you have an entity with a name and a number, bought with pooled delivery and a learning reset. How to pause losing products in catalog ads prices that trade.

Either way the test lands on a group. The single SKU is almost never the unit of a decision, even though it is always the unit of the report.

The export is a description, so read it as one

None of this makes product-level reporting useless. It makes it a different instrument than it looks like: a map of where your money went, drawn at the resolution delivery chose.

Adscalr does not score SKUs. Its composite runs per ad across 6 metrics (hook rate, CTR, CPI, ROAS, share rate, revenue per install), weighted per project and funnel stage. The piece worth borrowing here is the correction underneath it: a new ad's wild early score gets pulled toward what its format normally does, so one lucky day never becomes a decision.

That instinct is the whole skill here. Read the sums, stay strict with the ratios, let the group carry the verdict. For how a number earns the right to be acted on, the ad intelligence pillar lays out the machinery.