Black Week in Merchant Center: plan sale prices properly

In 2026, Black Friday falls on 27 November and Cyber Monday on 30 November. Anyone who wants to show reduced prices in Google Shopping on these days is not just planning discounts but clock times: Google Merchant Center reads the sale price from the sale_price attribute and the sale period from sale_price_effective_date. If the time zone is missing there, Google calculates in UTC (Google Merchant Center Help), and for a German shop the feed runs one hour behind the sale. This guide shows how sale price, effective date and promotions work together in Merchant Center, where disapprovals arise during the sale days, and how a shop hands its Black Week prices to Google from a single source at exactly the right time.

Why Black Week starts in the feed

The sale days carry real weight in German retail. The German Retail Federation expected spending of €5.8 billion on reduced goods for Black Friday and Cyber Monday 2025 (HDE). According to the federation, just under half of online shoppers intended to buy reduced products on Black Friday and a good third on Cyber Monday (HDE). Some of these purchases do not start in the shop but with a product search, for example in Shopping ads on Google. The price shown there comes from Merchant Center.

The date follows the US holiday Thanksgiving, which falls on Thursday, 26 November in 2026 (OPM). Black Friday is the Friday after it, i.e. 27 November; Cyber Monday follows on 30 November. Many shops stretch the sale into a Black Week and start on the Monday before. For the feed this changes little: every sale has a start and an end time, and both have to match to the minute in the shop and in Merchant Center.

Merchant Center compares the prices in the feed with the product page and the checkout. The submitted sale price must match the sale price on the landing page and the checkout page (Google Merchant Center Help). If it differs, the item can be disapproved. For incorrect prices, Google describes a warning or the suspension of the account as the consequence (Google Merchant Center Help).

price, sale_price and promotions: three tools

Merchant Center offers three ways to represent a price campaign, and they are not interchangeable. The price attribute carries the regular price. sale_price reports the reduced price that counts as the current price during the sale; the matching sale period goes into sale_price_effective_date (Google Merchant Center Help). Anyone submitting sale_price also submits price with the full price, and the sale price has to be lower than that (Google Merchant Center Help). Promotions, on the other hand, are a separate program with their own data source. They describe discounts that only take effect in the cart or at checkout, such as a coupon code or a free gift.

Google keeps the two strictly apart: sale prices should not be submitted as promotions (Google Merchant Center Help). Conversely, discounts that are already included in the price on the product page are not allowed as a promotion (Google Merchant Center Help). For Black Week this means: if the price on the product page has already been lowered, it belongs in sale_price. If the discount only applies with a code in the cart, a promotion is the right route.

sale_price_effective_date: format and defaults

The sale period is a time interval according to ISO 8601. Google requires a start and an end with time and time zone in the format YYYY-MM-DDThh:mm[±hhmm] or YYYY-MM-DDThh:mmZ, separated by a slash (Google Merchant Center Help). The field holds 0 to 51 characters (Google Merchant Center Help); a complete period with offset as in the following example stays below that. For a sale from Friday at midnight to Monday at 23:59 German time, the entry in the XML feed looks like this:

<item>
  <g:id>SKU-4711</g:id>
  <g:price>129.00 EUR</g:price>
  <g:sale_price>99.00 EUR</g:sale_price>
  <g:sale_price_effective_date>2026-11-27T00:00+0100/2026-11-30T23:59+0100</g:sale_price_effective_date>
</item>

Two defaults decide what happens when the information is incomplete. Without a time, the sale price applies from 00:00 on the start date and ends at 23:59 on the end date (Google Merchant Center Help). Without a time zone, Google uses UTC by default (Google Merchant Center Help). Both rules sound harmless but act together: a field containing 2026-11-27/2026-11-30 only starts at 01:00 in Germany and ends at 00:59 on 1 December.

If the attribute is missing entirely, the sale price applies immediately (Google Merchant Center Help). That is the second typical error: the feed with the sale price is uploaded the day before so that it is processed in time, and Google shows the reduced price while the product page still carries the regular price.

• Give the start and the end with a time, even if the sale begins at midnight.
• Write the offset without a colon, i.e. +0100, or mark a UTC time with Z.
• Separate start and end with a slash; the examples for text and XML data sources contain no spaces.
• Generate the period for each item from the same timestamp the shop uses to switch its sale price.
• After the sale, remove sale_price and the period or set them to the next sale instead of leaving expired values in place.

CET, CEST and UTC: the missing hour

In Germany, the legal time is Central European Time; it is defined as Coordinated Universal Time plus one hour (EinhZeitG § 4). During summer time, Central European Summer Time applies, i.e. Coordinated Universal Time plus two hours (EinhZeitG § 4). Summer time ends on the last Sunday in October at 3 a.m. (SoZV § 2), which is 25 October in 2026. The whole of Black Week therefore falls into winter time, and the matching offset is +0100.

The trap lies in the planning. Anyone preparing the sale in early October and taking the offset from the current system time gets +0200 and starts the sale price on Google one hour too early. Anyone leaving the offset out starts one hour too late. Both errors go unnoticed in Merchant Center because the format is valid. They only become visible in the night the sale starts or ends, and then usually as a price mismatch.

Midnight in the shop: all price points switch together

The feed is only one of several places where the price appears. Google recommends checking that the price is identical in the data source, on the landing page, in the structured data and at checkout (Google Merchant Center Help). If the shop switches its sale price by rule at midnight, each of these places has to follow at the same moment.

• Product page: the original price and the active sale price must be clearly visible (Google Merchant Center Help).
• Structured data: the active price in offers.price, the regular price as a second price specification with priceType StrikethroughPrice (Google Search Central).
• Caches: the page cache and upstream caches must not keep serving the old price after the switch.
• Cart and checkout: the sale price must not change on the checkout page (Google Merchant Center Help).
• Feed: sale_price and sale_price_effective_date with the same start and end as the rule in the shop.

In Shopware, such prices can be controlled through advanced prices and rules, as described in the article on the Shopware Rule Builder for pricing rules and promotions. What matters is less the tool than the place where the point in time is defined. If the end of the sale is stored once in the shop rule and a second time by hand in the feed export, the two will drift apart sooner or later.

Structured data also knows a sale period. For the offer duration, Google names the properties validFrom and validThrough or priceValidUntil and recommends stating time and time zone in ISO 8601 format (Google Search Central). With priceValidUntil it is worth checking after the sale: if the date lies in the past, the listing may not be shown (Google Search Central). How Shopware outputs product data as JSON-LD is shown in the article JSON-LD in Shopware 6.7.9.0.

When Google updates the price itself

Merchant Center offers automatic updates that refresh price, sale price, availability and condition based on the landing page; they are switched on by default (Google Merchant Center Help). For Black Week this is a safeguard, but no substitute for a correct feed: Google describes the feature as a fix for sporadic mismatches on a small share of products, not as a replacement for regular updates of the product data (Google Merchant Center Help).

Two limitations matter for sales. Automatic updates may not work for products whose price or availability changes often, for example more than once a day; if Google detects a mismatch, the product may then be disapproved instead of updated (Google Merchant Center Help). And if a product page shows several strikethrough prices, the system may not be able to identify the correct comparison price (Google Merchant Center Help). Shops with hourly flash deals are therefore better off relying on a feed that knows the point in time itself.

Sale price annotations: the base price counts beforehand

If the sale price and the regular price meet certain conditions, Google shows both prices and a sale annotation, for example in Google Search, in Shopping ads and on the Shopping tab (Google Merchant Center Help). For Germany, Google names two conditions with figures: the discount must be greater than 5% and less than 90% (Google Merchant Center Help). In addition, the base price must have been valid on 30 not necessarily consecutive days within the last 200 days (Google Merchant Center Help).

For planning this means: the regular price against which the Black Week saving is shown must have been valid on at least 30 days within the 200 days before the sale starts. Anyone raising the base price only shortly before the sale to show a larger discount in November may lose the annotation and at the same time enters legally delicate territory.

Promotions: coupon codes and gifts

For discounts via a code, a promotion is the right route. Promotions are submitted through a separate promotions data source, as an XML file, a tab-delimited file or a Google spreadsheet (Google Merchant Center Help). Google reviews every promotion against the program policies and the editorial requirements before it is shown (Google Merchant Center Help).

The period goes into the promotion_effective_dates attribute. With promotion_display_dates, a promotion can be validated before its start date (Google Merchant Center Help). For Black Week this is a key lever, because the review then does not fall into the night the sale starts. A promotion is limited to six months (183 days), the promotion title to 60 characters (Google Merchant Center Help). Anyone creating promotions with the promotions tool in Merchant Center works in the account time zone; a different time zone has to be adjusted manually (Google Merchant Center Help).

• The discount is applied at checkout and clearly confirmed there, not already on the product page (Google Merchant Center Help).
• Discounts below 5% of the current price or below €5 in Germany are not allowed as a promotion (Google Merchant Center Help).
• Percentage discounts are whole numbers; decimals are not allowed (Google Merchant Center Help).
• A promotion must generally be available to all users; discounts limited to certain groups or payment methods count as too restrictive (Google Merchant Center Help).
• Shipping promotions need a valid coupon code (Google Merchant Center Help).

In addition, Google limits how many promotions can be active at the same time and how many can be submitted in a day (Google Merchant Center Help). For Black Week this means: rather a few promotions that cover many items through product filters or the promotion ID than a separate one for every item. Where a promotion URL is given, the details on that page must match the submitted promotion data (Google Merchant Center Help).

One source for all prices: the feed as an interface

Reliable preparation for Black Week starts with an architecture in which every sale is defined exactly once: with price, sale price, start and end in one time zone. Product page, structured data, cart and feed are all generated from this record. If the prices come from an ERP, for example through an integration with Microsoft Dynamics NAV, or the product data from a PIM system, the same applies: the feed does not recalculate anything, it translates.

Anyone transferring product data via the Merchant API sets the period as an object with start and end. The salePriceEffectiveDate field has the type Interval (Merchant API). An Interval has an inclusive start and an exclusive end (Merchant API), unlike the text data source, where the end is set to 23:59. Since the end of the Content API for Shopping, the Merchant API is the route for direct integrations; more on this in the article on the Content API sunset and the 2026 feed rules.

{
  "offerId": "SKU-4711",
  "contentLanguage": "de",
  "feedLabel": "DE",
  "productAttributes": {
    "price": { "amountMicros": "129000000", "currencyCode": "EUR" },
    "salePrice": { "amountMicros": "99000000", "currencyCode": "EUR" },
    "salePriceEffectiveDate": {
      "startTime": "2026-11-26T23:00:00Z",
      "endTime": "2026-11-30T23:00:00Z"
    }
  }
}

The times here are in UTC: midnight on 27 November in Germany is 23:00 UTC on the previous day, midnight going into 1 December is 23:00 UTC on 30 November. Because the end is exclusive, the sale price applies up to and including 23:59 German time.

Two further points belong in the interface. Products expire 30 days after their last update in Merchant Center (Google Merchant Center Help); a feed export that is frozen during a change freeze before Black Friday must therefore not rest indefinitely. And if prices change often, Google recommends managing product updates via the Merchant API (Google Merchant Center Help).

• price: regular price, identical to the comparison price on the product page.
• sale_price: sale price, identical to the product page and checkout.
• sale_price_effective_date: start and end with the offset +0100.
• Structured data: active price, StrikethroughPrice and validFrom and validThrough.
• promotion_id in the product data if a coupon promotion only applies to certain items.

Timeline up to 27 November

Between mid-October and Black Friday there are just over six weeks, enough for a clean process with Google review times planned in.

1. October: keep base prices stable and secure the price history; it carries both comparison calculations.
2. After 25 October: the system time is back at +0100. Now put a test item with a short overnight sale window into the feed and check in Merchant Center when the sale price appears.
3. Early November: submit promotions for coupon codes, with promotion_display_dates before the start, so that the review is completed in time.
4. Week before Black Friday: store sale prices with their period in the shop and the feed, test cache behavior at the switching time and check the settings of the automatic updates.
5. Night into 27 November: watch the switch and compare samples from the product page, structured data and Merchant Center.
6. 1 December: remove sale prices and periods, update priceValidUntil and evaluate the warnings and disapprovals of the sale week.

If a waiting room for traffic peaks runs in parallel, its schedule belongs in the same calendar; details are in the article Virtual waiting room for Black Friday. For dates beyond the sale week, the 2027 deadline calendar for online shops helps.

Typical errors during Black Week

• Time zone missing or taken from summer time: without one, Google calculates in UTC; with +0200 the sale starts one hour early.
• Sale price uploaded early without a period: without sale_price_effective_date, the sale price applies immediately (Google Merchant Center Help).
• Coupon discount reported as a sale price: if the discount is only available with a code, sale_price does not match the price on the product page.
• Page price reduced and also reported as a promotion: such promotions are not allowed under the policies (Google Merchant Center Help).
• Variants with a different price: the price in the feed must match the variant that is preselected when the page loads (Google Merchant Center Help).

Many of these errors only show up once disapprovals pile up in Merchant Center. A check of the product data therefore belongs in the preparation, not in the night of the launch. The basics of feed quality beyond prices are explained in the article Google Shopping feed optimization.

How we implement time-controlled sale prices

Our Google Merchant Center integration generates the feed from the shop and covers the integration of sale prices and the setup of a promotions feed. For Black Week this mainly means: one rule, one point in time, one offset.

If you would like to know where your prices could drift apart during the sale week, we will look at shop, feed and Merchant Center together with you. Write to us via the contact form.