When to plan shopping feeds risk scenarios for your catalogue

What to take away

Risk scenarios are short written plans for the feed failures that cost sales, not general worries about the economy.
The usual triggers are a data protection complaint, a product data rejection spike and a channel rule change.
Each scenario needs an owner, a trigger and one action that can start within a working day.
Review the set quarterly and after peak season, because feed rules and internal teams both move.
Scenarios that are never rehearsed tend to fail when they are needed.

Start from what changed recently

Feed work has become more compliance-heavy. Google's description and structured description attributes now carry more weight in how a product is matched, so thin or duplicated copy is a commercial risk, not a cosmetic one.

Data protection rules tightened in parallel. Any feed carrying customer data into a marketing platform needs a lawful basis recorded before sending begins, and the ICO's guidance on choosing your lawful basis for direct marketing explains how to document that choice.

Scenario planning therefore belongs in the feed calendar, not in a general risk register. Our shopping feeds outlook for England in 2027 maps the changes likely to affect catalogue teams over the next few planning cycles.

The four scenarios worth writing

Scenario one: a product data rejection spike

A single attribute change can cause hundreds of items to be disapproved overnight. Name who checks diagnostics each morning, how quickly a corrected file is pushed, and who contacts the channel if the fix does not clear.

Four feed risk scenarios

Product data rejection spike

Trigger: Attribute change disapproves items
Owner: Diagnostics checker
First action: Push corrected file
Timeframe: Overnight fix

Lawful basis gap

Trigger: Customer identifiers shared
Owner: Sign-off owner
First action: Confirm lawful basis
Timeframe: Before sending begins

Channel rule change

Trigger: Channel updates attributes
Owner: Change log monitor
First action: Rewrite attributes
Timeframe: Before enforcement starts

Supplier data failure

Trigger: Supplier stops accurate data
Owner: Fallback definer
First action: Pause category
Timeframe: Immediate pause

For example, a retailer with 4,000 SKUs might see 12 per cent disapproved after a supplier changes a size format. The response is a bulk correction, not a manual edit of each item.

Scenario two: a lawful basis gap

If a feed shares customer identifiers with an advertising platform, confirm the lawful basis, the retention period and who signs off new data fields. The ICO's UK GDPR guidance and resources cover the records to keep if a complaint arrives.

Scenario three: a channel rule change

Channels update attribute requirements at short notice. The scenario should say who monitors the change log, who owns the rewrite and how much time the team has before enforcement starts.

Scenario four: a supplier data failure

When a supplier stops sending accurate stock or price data, the feed can advertise items that cannot be sold. Define a fallback: pause the affected category, or switch to a manual override list.

Build the checklist before the incident

Build the checklist

Name one owner per scenario, with a deputy.
Write each trigger in plain language, such as "more than 5 per cent of items disapproved".
Record the first action and the time within which it should happen.
List the people to notify internally and the channel contact externally.
Keep a current export of the catalogue so a rebuild is possible.
Store lawful basis records alongside the feed documentation.
Set a quarterly review date and a post-peak review date.
Rehearse one scenario a quarter with a real data sample.

Automation shortens response times. Our guide to shopping feeds AI applications in England explains where machine checks help and where a person still has to decide.

Pre-incident feed checklist

Name one owner per scenario, with deputy
Write each trigger in plain language
Record first action and timeframe
List internal and external contacts
Keep current catalogue export for rebuild
Store lawful basis records with feed docs
Set quarterly and post-peak review dates
Rehearse one scenario a quarter

Decide when to trigger a review

Book a review when a channel announces a rule change. The same applies when a complaint arrives about marketing data, a supplier changes its data format, or the catalogue grows by more than a fifth in a quarter.

Do not wait for the annual planning cycle. A scenario written in September may be stale by November, especially if a new channel or fulfilment partner is added.

Keep the scenarios short

One page per scenario is enough. A long document will not be read during a live incident, and a short one will. Store them where the feed team already works, not in a folder nobody opens.

Common questions

How many risk scenarios does a catalogue team need?

Four to six covers most situations: data rejection, data protection, channel rule changes, supplier failure and a platform outage. Add more only when a specific dependency justifies it.

Who should own shopping feeds risk scenarios?

The feed or catalogue manager usually owns them, with the data protection lead signing off anything involving customer data. A named deputy keeps the plan alive during leave.

How often should the scenarios be updated?

Quarterly is a sensible baseline, plus a review after peak season and after any channel rule change. A scenario that has never been rehearsed is untested.

What is the first action when a feed fails?

Check the channel diagnostics for the affected items, confirm whether the cause is internal or supplier-side, then apply the pre-agreed fix. Log the incident so the scenario can be improved.