Black Friday & seasonal catalog ad templates

The Black Friday problem in catalog advertising is not a creative problem. It is a logistics problem with a deadline. When you run a seasonal sale, you want every product image in the catalog to carry the sale styling for the window, and then revert cleanly the moment the window closes. Done by hand, that means re-exporting hundreds or thousands of JPEGs on the Thursday night, then re-exporting all of them again on the Tuesday to undo it. Nobody does that reliably at 2am with the campaign already live. The image either goes up late, comes down late, or one batch gets missed and a "-30%" badge is still showing in December.

A feed-bound image template with a scheduling window solves the operational half of this. You design the sale variant once, set it to auto-activate for the window, and it auto-reverts when the window closes. No manual swap, no manual undo, no forgotten batch. Emberfeed schedules the image template. You still own the sale itself: the sale_price and effective-date feed fields, the campaign, the budget, and the actual discount. This article is about the boring half that breaks under deadline, and the one accuracy trap that turns a Black Friday into a Q4 disapproval if you get it wrong.

Where a sale badge is allowed, per platform

Read this table before you design anything, because it dictates the entire workflow. The question is narrow and specific: can you burn a sale badge into the primary image_link for this surface, or not? The answer is not the same across channels, and the most common, most expensive mistake is assuming it is.

The one-line rule worth memorising: a burned-in sale badge is Meta-safe and Google-unsafe on the main image. On Google, the sale lives in the sale_pricefield; on Meta, it can live on the creative. The same designed "sale image" cannot be pushed to both channels. That single fact shapes everything below.

Why this is operational, not creative

The reason a sale swap is hard at scale is the same reason any catalog image work is hard at scale: there are too many products to touch by hand. Feed binding removes that. A feed editor renders every product through one template at request time, so a "sale variant" is a single design, not N images. You are not restyling a thousand photos for Black Friday; you are flipping one template, and the thousand renders follow. The deeper render mechanic, one template producing a unique image per product on-demand, is covered in AI-designed catalog images, and the same Google-versus-Meta overlay split shows up again in multi-image catalog ads.

Once the design is one template instead of N images, the problem collapses into a scheduling problem: turn the sale styling on for a date range, then turn it off. That is the part a scheduling window automates, and it is the rest of this article.

The scheduling-window workflow

Emberfeed templates carry an optional scheduling window: activeFrom and activeTo timestamps. Set them, and the template auto-activates at the start of the window and auto-reverts at the end. The workflow is three steps:

• Design the sale variant. Build a separate template for the promotion (Meta: badge on; Google: clean variant, see the split below). Preview-render it against real products so you know it looks right before the window opens.
• Set the window. activeFrom at the sale start, activeTo at the sale end. From that point you do not touch it again.
• Let it revert. When activeTo passes, the sale template deactivates and the catalog renders the regular (non-sale) image again. No manual undo, no forgotten batch.

Two mechanical caveats decide whether that swap actually reaches a shopper, and skipping either is how a scheduled flip silently fails.

The swap only reaches Meta because the URL changes

Meta caches catalog images aggressively. Its own rule: if you change the image for an item, the new image must use a different URL than the old one in your data feed. Same URL means Meta keeps serving the cached old pixels. This is exactly why Emberfeed appends a ?v= cache-buster to every served image_link, keyed to max(product.updatedAt, template.updatedAt). The moment a template activates or deactivates, template.updatedAt bumps, the ?v= value changes, Meta sees a new URL, and it re-fetches fresh pixels. Without that URL change Meta would keep showing the old (non-sale, or stale-sale) image straight through the window. The scheduled flip reaches the shopper only because the served URL changes underneath it.

Fetch cadence is the latency floor

A scheduling window does not put the sale live the instant the clock ticks over. The ad platforms fetch your feed on a schedule: Meta scheduled fetches run hourly, daily, or weekly, and Google Merchant Center fetches on its own schedule (daily by default, configurable). Live-latency is roughly the fetch interval plus processing time, and for a first-time render Meta's initial approval can take 24 to 48h. So do not set a sale template to activate at 00:00 on Black Friday and expect it live at 00:01. Set the window to activate a fetch-cycle early, or trigger a manual fetch (Commerce Manager then Data sources then Fetch now), so the sale render is live and approved before traffic peaks.

The platform split in practice

Because a baked-in badge is Meta-safe and Google-unsafe, "run a sale on both channels" is two designs, not one. Here is how each side gets its sale visual.

Meta: put the badge on the creative or the image

Meta gives you two compliant ways to show a sale. The first is Meta's own dynamic overlays, launched April 25, 2025: sticker labels for current price, strikethrough sale price, percentage off, and free shipping, toggled independently and customised, or AI-auto-applied by campaign context. These render on the ad-creative side; you do not bake them into the feed image. Delivery at launch was Facebook feed. The second way is a badge baked into the rendered image_linkitself. Meta's old 20%-text rule is gone, so a "Black Friday" or "-30%" badge burned into the render is Meta-safe (text-heavy creatives can still hurt delivery cost, but that is a performance signal, not a rule). A baked-in badge is also the reliable path across Instagram, Stories, and Reels, where the ad-side overlay coverage is less certain than on the Facebook feed.

Google: clean image, sale in the feed

Google's policy on the "Text on image" page is unambiguous and current: product images must not contain promotional text or watermarks that obstruct the view of the product, and the policy groups promotional text and overlays together as obstruction with no "price text is fine" carve-out. So on Google the product image stays clean, and the sale comes from the feed:

• sale_price plus the original price. Submit sale_price alongside the original price and Google (when eligible) renders the original struck through, often with a Sale badge, all from feed data, not from the image. Keep submitting the real base price in price; both prices must show on the landing page and match the feed, or Google treats the sale price as the regular price and no strikethrough appears.
• sale_price_effective_date is itself a window. The sale_price_effective_date attribute time-boxes the sale with a START/END range (for example 2026-11-27T00:00:00-05:00/2026-11-30T23:59:59-05:00). The sale price applies only inside the window and reverts automatically after, a feed-level auto-revert that parallels the image-template scheduling window.
• Promotions and Sale events for store-wide offers. The Promotions feature surfaces a Special offer tag; Sale events are a related store-wide type that can use discount ranges (for example "Up to 40% off") without per-product mapping and must be time-bound. Google's own example titles for sale events include "Black Friday sale."

If you want both channels styled for the sale, that is two served feeds. Use the Duplicate button on the feed page: clone the feed (same source URL, independent rules and template), point the copy at Google, and give it the clean, overlay-free sale template while the original carries the badge for Meta. This is the same duplicate-feed pattern the cross-linked articles use for the everyday overlay split; a seasonal sale is just the version of it with a deadline.

The honest boundary

The Q4 prep checklist

Calendar anchor for 2026: Thanksgiving falls on Thursday, November 26; Black Friday is Friday, November 27; Cyber Monday is November 30. "Black November" deal-creep means many retailers start promotions in early-to-mid November, so treat these as the peak, not the start. Work the checklist backward from the window.

• Early November, design the sale variant. Build the sale template (Meta: badge on; Google: clean). Preview-render against real products. Do not design under deadline on the 26th.
• Early-to-mid November, wire the feed sale fields (your job). Populate sale_price and set sale_price_effective_date to the exact window. Confirm both price and sale_price show on the landing page and match the feed, or Google drops the strikethrough. Set up a Promotion or Sale event for any store-wide range offer.
• About a week before, set the template window. activeFrom at the sale start, activeTo at the end. Account for the fetch-cadence floor: set activation slightly before the moment you want it live, and plan a manual fetch, since neither platform goes live at 00:01.
• About a week before, verify the cache-bust. Confirm the served image_link carries a ?v= that will change when the template flips, so Meta re-fetches. Same URL means a stale image straight through the window.
• Before peak, split-test the variant if time allows. Test the sale design against the baseline on CTR or CPC ahead of the window. The scheduling window can time-box the test arm; the method is in A/B testing catalog image templates.
• The day before, force a fetch. Trigger Meta (Commerce Manager then Data sources then Fetch now) and Google to pull fresh, so the sale render is live and approved before traffic peaks. Initial Meta approval can take 24 to 48h, so do not leave a first-time render to the morning of.
• After the window, confirm the auto-revert. The scheduling window auto-deactivates the sale template; verify the next fetch shows the reverted regular image and that sale_price_effective_date has lapsed so Google drops the strikethrough. No manual undo is needed, but confirm it actually happened.

For broader Meta catalog context, the dynamic-overlay surface and the Advantage+ mechanics live in Meta Advantage+ catalog ads.