How to pause losing products in catalog ads
A rule cannot fire on a SKU. Here is what it takes to pause losing products in catalog ads, and what the split costs you in signal.
A rule cannot fire on a SKU. Here is what it takes to pause losing products in catalog ads, and what the split costs you in signal.
400 SKUs sit in one catalog ad set at 300 euros a day. The month-end export says 12 products carry the account and the long tail behind them is bleeding, so you open the rule builder in Meta Ads Manager to write the obvious rule: if a product's weekly ROAS drops under 1.2, pause it.
Then you look at what the rule can be pointed at. Campaign. Ad set. Ad.
There is no product in that list. There never was.
Short answer: A rule fires on an entity, and a SKU is not one. Inside a catalog ad set the losing product is a slice of one ad's impressions rather than something a rule can address. Making it pausable means splitting the feed with custom labels into separate product sets and ad sets, which changes delivery.
The takeaways
Because automated rules act on the campaign structure, and a product does not live there. The rule builder walks down campaign, ad set, ad and stops. Your catalog sits beside that tree on the commerce side of the account, and the ad in a catalog campaign is a template filled with whichever products the delivery system thinks a person might buy.
So the losing SKU has no body. It is a share of the impressions belonging to one dynamic ad, and that share changes person by person. A rule can pause the ad, which pauses all 400 products along with it. It cannot reach inside.
This is why almost every automated-rules guide answers at ad level, with a spend floor and a cost-per-purchase ceiling. They answer a question about ads while an ecommerce buyer asks one about products.
You build the handle in the feed. The Custom Label fields exist for this: write a value onto each SKU, define a product set that filters on it, then run that set in its own ad set. Now there is an entity with a budget, a ROAS figure and a name a rule can point at.
The labelling is where the thinking goes. Margin band usually beats category, because the thing worth protecting is contribution and 2 products in one category can sit on opposite sides of profitable. A label per individual SKU works for nobody.
Google Shopping arrives at the same place through product groups defined in Google Merchant Center, and it carries the same catch: the subdivision that makes a segment biddable is the one that makes it thin.
Pooled delivery and pooled data, in one move. One ad set holding the whole catalog lets the system push impressions toward whatever converts this week without consulting you. 6 ad sets each get a budget you set, and it stays where you put it.
The second cost is the one that bites the rule you were writing. A week of conversions that read as one number is now 6 numbers, each roughly a sixth as thick. The weekly product ROAS you wanted a threshold on gets noisier at the exact moment you build the container that lets you threshold it.
Sometimes that trade is worth paying, because a group spending real money deserves its own budget anyway. The version to avoid is rebuilding an account to police 40 euros a week of waste.
Usually less than the rebuild. Pull last month's spend by product and sort ascending. The shape repeats across most catalogs I have worked in: 12 SKUs take most of the budget, a middle band takes a slice, the bottom 300 share a few euros a day.
That bottom group is where the losing products live, and where there is almost nothing to save. The restructure costs you hours, a round of learning resets, and however many weeks the new ad sets spend re-learning what the old one knew.
Run that arithmetic first. If the tail is expensive, split it and write the rule. If it is cheap, drop those products from the set and leave the structure alone.
On a group, and on a window wider than a week. A long-tail SKU might produce 2 orders in 7 days, and a ROAS built on 2 orders will cross any line you draw in both directions inside a month. Put the threshold where the volume is, on a group with enough conversions that the number moves for a reason.
Then decide what crossing the line does. Pausing an ad set stops every product inside it, including the ones that were fine, so the group has to be homogeneous enough for a group verdict to be fair. Removing one product from the set is the surgical move, and that is a catalog action rather than a rule.
And a paused product stops producing data. Whatever you switch off becomes a decision you have chosen to stop revisiting.
Adscalr sits on the same side of that wall. Its rules fire on 8 metrics (CPI, CTR, hook rate, hold rate, ROAS, spend, frequency, CPM), the only actions are pause and kill, and every evaluation is logged. They act on ads. There is no feed rule and no product-level threshold.
What the automation layer covers is the part people get wrong once a rule exists: a learning-phase lockout under 5 days or 200 euros, a ROAS floor that pauses a 1.5x ad instead of killing it, a CBO safeguard that never leaves fewer than 3 active ads, a frequency auto-kill at 3.5x, and a kill that stays reversible for 30 minutes. Full-auto is opt-in, and the default only recommends.
Whether a threshold deserves to exist at all is the subject of when to kill an ad, and the ways a sensible rule turns on you are in automated rules mistakes. For how the safeguards fit together, the automation pillar walks through it.
This is the thinking behind Adscalr.
See the product →