Affiliate Product Feed Freshness: When Should Publishers Hide an Offer?

Affiliate product feed freshness should determine which claims a publisher can safely display. Refresh changed feeds, validate them before publishing, and stop showing precise prices or availability claims when the supporting data becomes too old. A failed download alone does not prove that a product is unavailable.

For retailers and affiliate publishers, the practical question is what happens between a merchant changing an offer and the publisher receiving that change. The following approach suits comparison pages, curated product collections and deal listings. It proposes operating rules rather than a universal refresh deadline.

1. Define what counts as fresh

A feed connects a merchant's catalogue to a publisher's product listings. Awin's publisher feed guide describes product details and direct product links, and documents a feed list with last update times. Publishers can use those times to identify changed feeds instead of repeatedly downloading unchanged files.

Keep separate records for the source update time, the last successful download and the last successful publication. These answer different questions. A download completed this morning may contain data that the merchant last updated several days ago. Equally, a fresh file may still be waiting for your import process to finish.

Define freshness at the level where it affects the customer. A descriptive buying guide can remain useful while a price beside its purchase button becomes unreliable. A short promotion may need a tighter review window than a stable product description.

Agree an acceptable age with each merchant or network contact, based on how often prices, promotions and stock change. Document what happens when that age is exceeded. Do not present a locally chosen deadline as a network requirement.

2. Establish an offer record before importing

Start with a consistent identity for each merchant product and variant. Keep the merchant identifier, product identifier and relevant variant details together. A navy mouse and a grey mouse may share a product family but have different availability. Matching on the product name alone can join the wrong records.

Awin's advertiser product feed FAQs list mandatory fields including product ID, name, price, image URL, destination URL, category and description. The page explicitly applies to Awin Classic. Treat those requirements as the starting point for that platform, then confirm which additional fields your publisher experience needs.

Your internal offer record should also capture currency, availability, promotion expiry where supplied, and the source version. Preserve the network-provided affiliate destination separately from the product identity. Rebuilding links during a catalogue refresh can introduce tracking errors, a related issue covered in preserving affiliate campaign data through redirects.

Distinguish an empty field from a confirmed state. Missing stock information means availability is unknown. It should not quietly become an "in stock" badge because a template needs a default value.

3. Choose a display action for each failure

Use a written decision policy so merchandising staff and developers handle the same evidence consistently. The table below proposes review criteria for publisher displays. These are not platform-mandated rules.

Choose the fallback according to the page's purpose. A comparison table built around exact prices may need to hide an uncertain offer. An editorial review might retain a clearly labelled link to check current details, provided the destination and partnership remain valid.

Never silently substitute another product behind a specific product recommendation. If an alternative is useful, identify it as an alternative and make its differences visible.

4. Check availability at the variant and destination level

Google's availability documentation distinguishes in-stock, out-of-stock, preorder and backorder states. It also requires the submitted availability to match the landing page and checkout, including the particular variant. Those requirements apply to Merchant Center submissions. Other affiliate placements need their own network specifications, although the distinctions are useful when designing a publisher's catalogue.

For a publisher, the review should follow the exact offer being promoted. Does the destination select the advertised colour or size? Can the buyer order it in the intended market? Is the item available now, or does the merchant accept orders for later delivery?

A successful page load answers none of those questions by itself. It establishes that the destination responded, not that the advertised variant is purchasable. Use permitted merchant data and targeted manual checks to investigate discrepancies. Avoid treating an automated fetch failure as definitive stock evidence, especially where a site blocks automated access.

Keep preorder and backorder wording distinct from immediate availability. Where the source lacks enough detail to support an availability claim, omit that claim rather than supplying a guessed date.

5. Publish validated snapshots and monitor the gaps

Download new data into a staging area before replacing the live catalogue. Check required fields, duplicate identifiers, usable destinations and unexpected changes in record counts. A large reduction should trigger review against that merchant's normal pattern. It should not automatically erase live listings.

Confirm whether each delivery is a complete snapshot or an incremental update. An absent product in a complete replacement may signal removal. An absent product in an incremental update may simply be unchanged. Agree these semantics before implementing deletion rules.

Publish a validated version together so visitors do not see a partially imported catalogue. Keep the previous validated version available for recovery, subject to the same freshness limits. Recovery should restore a known version without resetting its source timestamp.

Monitor the age of live claims as well as whether the import job ran. Useful operational measures include offers beyond their freshness window, rejected records, publication delays and unresolved destination mismatches. Assign someone to investigate each alert category.

Ask publishers how their own refreshes work, too. A merchant-side correction does not confirm that every partner has fetched it or cleared cached pages. Establish an escalation route during publisher onboarding and retention planning so urgent withdrawals reach the people who control the display.

6. Use a practical checklist and avoid misleading fixes

Before relying on a feed-driven listing, work through this checklist:

• Identify the merchant, feed, market and variant keys.
• Record source update, download and publication times separately.
• Agree freshness windows and the display fallback for expired data.
• Confirm complete-feed versus incremental-update behaviour.
• Validate the incoming version before replacing live records.
• Check representative destinations, including unavailable variants.
• Test that an expired promotion loses its promotional wording.
• Name the owner who can suppress an offer and restore it after review.

Common mistakes include calling every successful import "fresh", converting unknown availability into available, and deleting products after an incomplete transfer. Another is attaching a recent "checked" timestamp when the system has only downloaded an unchanged file. Describe what the timestamp measures.

Hiding an uncertain price can be a sensible temporary action, but review every place that price appears. Comparison sorting, savings badges, cached cards and promotional banners may still depend on it. Removing one visible number does not resolve the underlying record.

Start with one merchant and one product collection. Trace a changed price, an unavailable variant and a failed refresh through to the published page. Write down the resulting display decisions and have the affiliate manager and website owner approve that policy. Expand it once both teams can explain what visitors will see when the next feed update fails.