Google's Deal Ends badge reads straight from a feed field merchants have always treated as optional

Merchant Center has started stamping a countdown badge, “Deal Ends,” under a product’s price in Shopping ads and free listings. Google generates that badge from promotions and sale price [sale_price] submissions, and sale price effective date [sale_price_effective_date] is the attribute that decides when the countdown runs out. Both are feed fields almost every merchant already submits.¹ Search Engine Roundtable spotted Google’s new help page for the feature and reported it on August 6.² Back in July, Google added schema.org properties for category and sale duration to merchant-listing markup, and I wrote then that sale_price_effective_date was the useful half of that update, provided a merchant avoided one specific trap. For years, sale_price_effective_date has been an optional attribute a merchant could leave blank, back-date, or copy unchanged across a dozen variants, with no consequence beyond a Merchant Center warning nobody reads. Google just wired that same field to a badge a shopper sees at the exact moment they decide whether to click.

Price, availability, and condition mismatches auto-correct from a page’s schema.org markup. sale_price_effective_date has no schema.org field to check against at all.

What is the Deal Ends badge, and where does its data come from?

Deal Ends is an automatically enabled Merchant Center feature that adds a real-time urgency label, phrases like “3 days left” or “5 hours left,” directly beneath a product’s price on Shopping ads and free listings.¹ Google’s help page says the feature works “globally, except for EEA+, Switzerland, and the United Kingdom,” and generates the badge entirely from feed data.¹ Beyond the sale_price and sale_price_effective_date attributes a merchant already sends, nothing new is required, and no separate markup or submission is involved.

Google gates the badge with eligibility rules that shift by season.¹ Outside the holiday window, a deal must discount at least 5% off the post-deal price, must represent the lowest effective price in the last 15 days, must be scheduled to expire within seven days, and must sit at least 15 days from the merchant’s last Deal Ends on that offer. From October 15 to January 5, the bar rises: a 10% minimum discount, a 60-day lowest-price lookback, and a 60-day interval between deals.¹ None of those four checks touches anything on the product page itself. Every one of them compares feed data against feed data.

Can a merchant opt out, or see how the badge is performing?

No, not yet, on either count. Directly asked whether merchants can opt out, Google’s own FAQ gives a four-word answer: “Not at this time.”¹ Asked about reporting, Google says specific reporting on Deal Ends “won’t initially be available,” because the company treats the badge as “an improvement upon existing sales and promotions” rather than a new attribute worth its own dashboard.¹ Whether a specific product qualified, or whether the countdown a shopper is seeing is accurate, is something a merchant has no Merchant Center screen built to confirm.

Why does an optional feed attribute suddenly matter this much?

Because a merchant could always afford to be careless with sale_price_effective_date, and the badge removes that affordance overnight. The attribute is optional, and Google’s own product data specification says what happens if you skip it: without it, the sale price simply always applies, with no expiration at all.³ That is the behavior that has let merchants leave the field blank, set an end date months out and forget it, or copy the same date range across every size and color in a run. None of that trips a policy violation, because the field carries no compliance check beyond a valid ISO 8601 date range.³

In feed-audit work, sale_price_effective_date is consistently one of the least-populated optional attributes, and where it is populated, the end date is often a single far-future placeholder carried across an entire product line rather than a genuine per-sale value. That is a practitioner observation, not a measurement, and it describes a pattern that produced no visible symptom before this badge existed. It produces one now.

Does fixing your on-page schema protect you from a bad badge?

No. The badge is generated entirely from the feed, and sale_price_effective_date has no schema.org equivalent, so there is nothing on the page for Google to check it against.⁴ Once you know Google added sale-duration properties to schema.org in July, the instinct is to reach for those properties: validFrom, paired with either validThrough or priceValidUntil, all living on the Offer node and together capable of expressing a real start-to-end sale window.⁴

Two facts are true here at once, and they deserve to be kept separate. First, schema.org’s own definition of priceValidUntil is narrow: “the date after which the price is no longer available,” an end date with no companion start.⁵ Second, and this corrects a framing worth correcting, Google’s current merchant-listing documentation does not lean on that narrow property alone. Per its Sale duration guidance, Google instructs a merchant to pair validFrom, defined as “the date when the item becomes valid,”⁶ with either validThrough, “the date after when the item is not valid,”⁷ or priceValidUntil, on the same Offer node, with the start date preceding the end.⁴ Read narrowly, schema.org is not stuck expressing an end date only. Google’s own guidance already asks for a full window.

Beneath the vocabulary layer, the real gap sits in automation, while the definitions themselves hold up fine. Because it reads a page’s schema.org price, priceCurrency, availability, and itemCondition properties, Automatic Item Updates will silently rewrite the matching feed attributes when they drift from what the crawler finds.⁸ sale_price_effective_date sits outside that mapping entirely. There is no row in Google’s own automations table for it, and none for priceValidUntil, validFrom, or validThrough either.⁸ If a merchant implements validFrom and validThrough perfectly on every page, nothing changes about whether Deal Ends fires on a stale feed date, because the badge was never reading the page.

Google Merchant Center Help documents the four auto-corrected attributes; sale_price_effective_date is absent from that same table.

What does this look like on a real product page today?

Three on-sale product pages checked for this piece on August 7, all from a single retail host, carried zero instances of priceValidUntil, validFrom, or validThrough in their Product structured data, in any form. Three pages from one host make an anecdote rather than a market rate, and should be read as exactly that. Where the feed carries a full sale window, the illustration still shows on-page sale-duration markup can be absent; how common that gap is remains unmeasured.

What should a merchant check in their own feed right now?

Confirm two counts, and neither needs anything beyond the feed file itself. Check how many active rows carry a non-blank sale_price_effective_date, then check how many of those end dates already sit in the past relative to today, the direct feed-side proxy for a Deal Ends badge that could be showing a shopper an expired or nonsensical countdown. Because the attribute’s format is fixed, start and end separated by a slash, in ISO 8601, checking it is a spreadsheet formula or a five-line script away.³

It fits a pattern worth watching across the rest of this feed-is-the-storefront pillar. Google increasingly acts directly on feed data without waiting for a merchant to catch up, whether that means writing Shopping ad copy itself or approving a listing that still never gets shown to anyone. A badge built on an unaudited date field is the same pattern with a countdown timer attached.

What would change this read?

Two developments would soften this read on Deal Ends. If Google adds sale_price_effective_date, or an equivalent property, to the schema.org mapping table Automatic Item Updates reads, a bad feed date would gain the same self-correcting check price and availability already have. And if the promised Deal Ends reporting actually ships, a merchant could at least see which products triggered the badge and audit the dates behind them, rather than inferring it from a shopper’s screenshot.

Until either happens, the honest posture is the boring one. An attribute that was always optional now has a customer-facing consequence, and nothing on the page side is watching it.