Short answer. A SKU that looks profitable on gross margin can be loss-making once you factor in PPC. ACOS divides ad spend by ad revenue, TACOS divides total ad spend by total revenue. Allocate your ad spend per SKU to your real net margin, and only then do you see which products still make a profit after PPC and which ones cost you money.
Your dashboard says product X runs a 38 percent gross margin. You also advertise it, because without PPC it does not sell in its category. And nowhere in your standard reporting do you see what those ad costs do to the margin of that exact product. That is the gap where profit quietly disappears.
ACOS and TACOS are not the same number
ACOS stands for Advertising Cost of Sales: ad spend divided by the revenue directly attributed to those ads. Spend 250 euros and generate 1,000 euros in ad revenue, and your ACOS is 25 percent. That number steers your campaigns: which keywords perform and which do not.
TACOS stands for Total Advertising Cost of Sales: the same ad spend, but divided by your total revenue, organic plus paid. TACOS tells you something completely different, namely how dependent your entire product is on advertising. A healthy TACOS for a mature product often sits around 5 to 10 percent. If your TACOS rises while your ACOS falls, you are eating into your organic ranking. A good explanation of both metrics is available at PCO Studio.
The point: ACOS is your campaign gauge, TACOS your strategic gauge. But neither tells you whether a specific SKU still makes a profit after ad costs. For that you have to go deeper.
Break-even ACOS is your ceiling, not your target
Your break-even ACOS equals your net margin before you advertise. A product with a 40 percent margin breaks even at 40 percent ACOS. Stay below that and you earn. Go above it and you pay out of pocket on every unit sold. The formula is simple: profit per unit before advertising, divided by selling price, times 100.
But break-even is a ceiling, not a target. In practice, profitable sellers want to run 10 to 20 percentage points below their break-even to actually keep something. According to market data in early 2026, the average Amazon account sits around 32 percent ACOS. The question is not whether that is good, but whether it fits the margin of that one product. A useful benchmark is available at Trellis.
Why you have to allocate this per SKU
This is the mistake I keep seeing. Sellers calculate ACOS at the account level, or at best per campaign. But ad costs do not move in step with margin. Your high-margin product can have a low ACOS and your low-margin bestseller a high one. At the account level that averages out into a number that is accurate and says nothing.
What you need is this: per SKU, the real net margin after referral fee, fulfillment fee, returns and landed cost, and then the actual ad spend of that same SKU subtracted from it. Only then do you see that product X with its 38 percent gross margin, at an ACOS of 33 percent and 8 percent returns, is actually running a loss, while you keep promoting it because it "sells well".
In most competitive categories, PPC is not a choice but a condition for being visible at all. That makes this allocation no luxury. It is the difference between knowing you are growing and thinking you are growing.
Why standard tools cover the happy path but not your case
Tools like Sellerboard and Helium10 do the basics well. They pull in your Amazon fees and ad spend and give you a margin picture per product. For the standard case, one marketplace, clean data, that is fine and you should simply use it.
It breaks down at the exceptions. You also sell the same SKU on bol and your own webshop, where ad costs and commissions differ and you want a consolidated margin picture per product across channels. You have bundles or variants where the fee allocation does not line up one-to-one. You want to put PPC data next to your own purchase tiers and exchange rates. That is exactly the allocation a standard tool does not make for your situation.
That is when I build the connection and the logic underneath it: PPC per SKU from the Advertising API, fees from the SP-API, your landed cost and channel costs, combined into a single margin-after-PPC per product across all your channels. Before I build anything, I look at your process first. Often it turns out that half of the manual work in your current routine can be removed or done more cleverly, and I only build what is left.
Frequently asked questions
What is the difference between ACOS and TACOS?
ACOS divides your ad spend by the revenue directly attributed to those ads and measures the efficiency of your campaigns. TACOS divides the same costs by your total revenue, organic plus paid, and measures how dependent a product is on advertising. ACOS steers campaigns, TACOS steers strategy.
How do I calculate my break-even ACOS?
Your break-even ACOS equals your net margin per unit before you advertise. Take your profit per unit, divide it by your selling price and multiply by 100. A product with a 35 percent margin breaks even at 35 percent ACOS. Anything below that is profit, anything above it is loss.
What is a good ACOS on Amazon?
There is no universally good percentage. It depends on your margin and product stage. New products often run 40 to 50 percent while they build up reviews, established products 15 to 25 percent. Profitable sellers keep their ACOS 10 to 20 percentage points below their break-even.
Should I factor PPC into my profit margin per product?
Yes. A product that turns a profit on gross margin can be loss-making after ad costs, and in competitive categories PPC is needed to sell. Allocate the actual ad spend per SKU to your net margin, otherwise you steer on a margin picture that is wrong.
Further reading
- Real profit on Amazon FBA: a grip on your numbers
- Calculating profit per product on Amazon FBA
- Your real margin per product, channel and supplier
I am Ricardo Theijs of RNT Projects. I have sold on Amazon and cross-border myself and run operations across multiple channels, with a background in enterprise process management. I build the systems where standard tools fall short, and I say so honestly when that is not needed.
Running into this yourself?
I review your process and build the solution where a standard package falls short. Remote, with visible results in two weeks.
Let's talk