Use the sheet before patching a feed outside the primary product system.
Ecommerce template
Supplemental Feed Planning Sheet
Use the sheet before patching a feed outside the primary product system.
Quick answer
Supplemental Feed Planning Sheet gives ecommerce teams a reusable structure for product-feed cleanup work that needs an owner, evidence, and review result.
Topic, affected product or campaign, current issue, and the decision the team needs to make
A reusable table structure for a feed fix, product QA pass, escalation note, or weekly review.
Why this matters in a real store
Supplemental Feed Planning Sheet matters because ecommerce growth work usually breaks down in the handoff between a number, a platform warning, a campaign idea, and the person who has to make the next decision. A store team may know something is wrong, but still lose time because the issue is not written in a way that connects the symptom to a next action.
Use this page as a practical translation layer. The goal is to slow down the first reaction, name the business risk, and give the team enough context to decide whether the next move is a calculation, a feed change, a campaign QA step, or a page update. The tables and checklists are there to make the work repeatable, but the judgment comes from understanding why the issue appears in the first place.
Template fields
| Field | Why it matters | Example |
|---|---|---|
| Affected products | Defines the scope of the fix | Item IDs, SKUs, or product family |
| Warning or task | Keeps the work tied to the real issue | Mismatched value [price] |
| Field changed | Prevents vague status updates | sale_price_effective_date |
| Owner | Makes follow-through clear | Feed manager or store admin |
| Review result | Shows whether the change worked | Cleared, still pending, or returned |
How to use it
- Copy the template into the team's working sheet.
- Add one row per issue group instead of one vague row for the entire catalog.
- Assign an owner and due date before changing data.
- Update the result after Merchant Center review.
- Keep unresolved rows visible until the next weekly review.
What good looks like
A good feed template does not just list tasks. It preserves the reasoning behind a change so the next person can tell whether the team fixed a source value, a page mismatch, an app rule, or a review timing issue.
The template should also make reversibility obvious. If a bulk edit creates new warnings, the team needs to know what changed, why it changed, and where to roll it back.
Methodology and limits
Copy the fields into a spreadsheet or ticket, fill in one row per product set or issue type, and update the status after review.
A template only improves the handoff if the team fills in exact product IDs, field names, and review outcomes.
Reusable download
Use the related CSV as a working file for the calculation, checklist, or planning step covered on this page.
Common questions
Should this be fixed in the feed or on the product page?
Start by comparing both. If the page, checkout, structured data, or policy text disagrees with the feed, changing only the feed may not clear the warning.
Can this be applied to the whole catalog at once?
Only after a sample clears review. Bulk feed changes can create new warnings when the root cause is variant logic, app sync timing, or page data.
What should be saved after the fix?
Save the affected item IDs, original warning, field changed, reason for the change, owner, date, and review outcome.