← Reading listDISTINGUISH A FRESH FILE FROM A REFRESHED PRODUCT
Text

Merchant Center catalog operations workshop / 5 MIN READ

Distinguish a fresh file from a refreshed product

Build a product-refresh control sheet with item-age evidence and intentional end dates.

Published by SNS Media Tech

AI-assisted research and analysis for the SNS Creative Fieldbook

Sources checked 2026-11-07

A scheduled job can run successfully while individual offers stop receiving useful updates. Monitor item freshness and deliberate expiration separately from transport health.

What you will leave with: Build a product-refresh control sheet with item-age evidence and intentional end dates.

Use this when

  • Products disappear after a feed job appears healthy.
  • Seasonal items need a controlled end of listing exposure.

Not a guarantee of exact-time removal or an instruction to refresh stale facts merely to keep listings alive.

Separate the lifecycle clocks

Google documents expiration after 30 days without refresh for products generally, with an exception for products added directly in Merchant Center and possible automatic refresh from validated website data. The expiration_date attribute can set an earlier end; Google cautions that taking effect may take several hours. Check the current rules for the actual ingestion route.

Track the business validity of the offer separately from the platform's refresh state. A record can be recently submitted yet describe discontinued stock. It can also be commercially unchanged but missing from a malfunctioning export. Add a deliberate campaign or assortment end date only when there is an approved business reason, not as a workaround for uncertainty about the source data.

Measure freshness at the item level

Capture the last source fact update, last export inclusion and last observed processed state where those are available. These timestamps answer different questions. If an integration does not expose one of them, mark it unknown rather than assigning the job's timestamp to every item.

Compare the current exported ID set with the expected active assortment. Alert on unexplained omissions as well as old timestamps. A file containing a handful of valid records can generate a reassuring success message while leaving the rest untouched. Use separate checks for empty files, sharp count changes and missing high-priority items. Set internal alert thresholds early enough for the responsible team to investigate before a commercially important deadline.

Design recovery around authoritative facts

When a freshness alert fires, determine whether the cause is transport, export selection, source availability or processing. Replaying the same stale file may extend an incorrect offer rather than repair it. Confirm current price, availability and intended assortment status with the systems that own those facts before resubmitting.

For a planned seasonal end, document the desired end time, relevant time zone, expected propagation and a manual verification owner. If exposure must stop by a hard operational deadline, do not rely on a field whose documentation allows delay as the sole control. Coordinate the supported account and campaign controls with their authorized owners and preserve accurate availability information throughout.

Test failure, not just the happy path

Rehearse a missing-item condition in a safe test copy or monitoring fixture. Check that the alert names the affected products and routes to someone who can act. A generic message saying feed unhealthy may not distinguish the pricing team from the integration owner. Include a link to the relevant evidence without distributing unnecessary catalog secrets.

After recovery, verify the intended item set and effective dates, then close the incident separately from any lost-delivery estimate. Review why the first useful signal arrived when it did. Improve the check that would have exposed the failure earlier, rather than increasing upload frequency without knowing which stage failed. Dependability comes from knowing what was refreshed and why it remains true.

Make the reasoning concrete.

A fictional garden supplier has a daily job that reports success. A filter bug exports only new items, leaving long-running products untouched while seasonal products retain an obsolete end date.

Increase job frequency

Opening: Run the same export every hour.

Hypothesis: More successful runs look reassuring.

Risk: The selection bug and obsolete dates remain unchanged.

Audit item inclusion and lifecycle

Opening: Compare expected IDs, processed freshness and approved expiration dates.

Hypothesis: The repair targets missing updates and incorrect end controls.

Risk: Current source facts must be verified before replaying records.

The team fixes the selection rule, confirms offer accuracy and checks the processed assortment. Its monitoring now distinguishes job execution, item refresh and intentional expiration.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

  1. Clock

    Which timestamp measures source truth, transport or processing?

  2. Assortment

    Which active items should appear in this update?

  3. Expiry

    Which end dates are intentional and approved?

  4. Alert

    Who receives item-level omissions before they matter?

  5. Recovery

    What evidence makes a replay safe and accurate?

Watch for the wrong conclusion.

  • Using a successful job as proof every product refreshed.
  • Refreshing obsolete facts to avoid expiration.
  • Promising exact-time disappearance from an expiration field.

Your next action

Compare one current export with the expected active item set and investigate unexplained omissions.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not Google instructions or measured business results. Sources support only the specifically attributed platform facts. Platform controls and eligibility can change; verify current account guidance before implementation.

  • Google Merchant Center: Expiration date →Primary platform documentation · Supports: Supports documented refresh and expiration behavior, the direct-entry exception, possible automatic refresh and delayed effect of explicit expiration. Monitoring design is original editorial analysis.