Eight hundred SKUs, prices that move every Monday morning, and a client who wants the sale badge to appear and disappear on its own. It always opens as a design request. Can we get a red sticker on the discounted items? Then somebody asks what happens when an item stops being discounted on Thursday, and the room goes quiet.

Short answer: An automatic price overlay in catalog ads is a template bound to feed fields and rendered when the ad serves, so it updates whenever your catalog updates and never sooner. The design work is one template. The accuracy work is feed hygiene, and feed hygiene is where these break.

The takeaways

The overlay is a binding to a feed field. You style one label, the value is read from the catalog at delivery, so 800 products cost one design decision.
A live price is as live as your last sync. Cut a price at 9am and the creative carries the old number until the next scheduled catalog upload lands.
A third-party render layer adds a second clock. Generated images can go stale while the feed is current, and nothing warns you, because to the ad platform the creative is only a URL.

How does an automatic price overlay get onto the image?

By binding, at delivery. You do not export 800 images. You pick a label type, style it once (font, colour, shape, corner), and the ad system stamps in the value it holds for that item as the ad renders. Search Engine Land's writeup of the launch lists 4 label options for Meta's dynamic overlays: current price, a struck-through sale price, percentage off, and free shipping.

That shift moves the work somewhere else. The badge is a rule plus a field name, so the question stops being what should this look like and becomes which field is this reading, and is that field right today. Your designer owns the first half for about an hour. Everything after that is feed work.

Why is "real time" the wrong word for a live price?

Because the overlay reads your catalog, and your catalog is a copy of your shop that refreshes on a schedule. Meta picks up changes to a catalog file on the next scheduled upload, so a price you cut at 9am on Monday reaches the creative when that upload lands. Every impression in between carries the old number.

It is the same lag that lets out of stock products keep spending, pointed at the price field instead of the availability field. What differs is the cost. A stale availability value wastes budget quietly. A stale price is a commercial claim sitting on a picture, and the shopper who clicked a €39 badge and landed on €49 does not file that as a sync issue. They file it as bait.

What can the built-in overlay set express, and what can't it?

Whatever exists as a field in your feed. Price, sale price, a percentage calculated from those two, shipping: all feed-backed, so a label can render them. A star rating living in your review app, a competitor's price, a scarcity nudge like only 3 left: none of that is in the catalog, so no built-in label can say it.

Everything past that line means generating the images yourself from the feed with a template tool and handing Meta the finished image URLs. Real build, real bill, worth naming before somebody promises it in a meeting.

One thing to check rather than assume: open the placement preview and confirm which placements render the label. Overlay availability moves, and the preview is the only honest answer on the day you ship.

Where does the second staleness clock come from?

From the render layer, the moment you add one. Built-in overlays run on one clock, your catalog sync. A third-party image generator runs on two, because the picture is produced on its own cadence and then cached somewhere. Now a price can be correct in your feed, correct in Meta's catalog, and wrong on the image being served.

Nothing fires for that. To the ad platform your creative is a URL returning an image, and an image with an old number is a perfectly valid image. Feed diagnostics stay green, because the feed is fine.

So the regeneration cadence becomes something you monitor as seriously as the feed schedule. Ask the vendor how often images rebuild and how long the CDN holds the previous one. Then check one discounted SKU with your own eyes, in the live ad, the day after a price change.

What breaks when one template covers 800 products?

Binding errors, not design errors. A design mistake announces itself the first time anyone looks at the ad. A binding mistake (sale price mapped to the wrong column, a missing currency, a decimal format for a market you do not sell to) renders cleanly across every item and looks deliberate, which is exactly why it survives review.

The other failure is fit. A label that sits beautifully over a bright square product shot can be illegible over a dark lifestyle image, and a four-digit price under a long title behaves nothing like €9.99. You approved 6 previews. The other 794 were never seen by a human.

Spot check at the extremes instead of the middle: cheapest, most expensive, longest title, darkest photo. Ten minutes, and it catches the class of error a template quietly multiplies.

What should you check before you switch it on?

Three things. Which field each label reads, and whether that field is right today. Your worst-case lag between a price change and the next catalog upload. And where the label lands, because a badge parked on the spot the eye goes first is buying attention from the product it was meant to sell.

That last one is answerable before spend. Every static in my own pipeline gets a DeepGazeIIE pass, a neural saliency model predicting a per-pixel heatmap and scan-path order, with the flags sitting beside the draft for a person to judge. Advisory, statics only.

Adscalr does no catalog, feed or overlay work and cannot set one up for you. It composes creative in the 4 native formats per placement rather than cropping, and predicts where attention lands before you pay for it. That is the creative half of the loop. Whether the price belongs on the creative at all is a separate question, worth settling before you automate the answer.

Automatic price overlays in catalog ads