A feed can break without a dramatic outage. A theme update changes availability markup, a pricing rule changes currency, or a scheduled sync runs after a promotion ends. Without a change log, the team sees the result but not the cause.
The minimum change-log fields
| Field | Example |
|---|---|
| When | UTC timestamp and local business date |
| Owner | Person or team responsible |
| Surface | Store source, mapping, transformation, destination, or page |
| Change | What changed and why |
| Sample | Five product IDs, including edge cases |
| Result | Processed, eligible, rejected, and visible counts |
| Rollback | Condition that triggers reversal |
Use a before-and-after sample
Save old and new values for ID, title, price, availability, link, image, category, GTIN, and variant attributes. Include a best seller, a variant product, an out-of-stock item, and a previously problematic product.
Connect the log to processing
Do not mark a change successful when only the code or feed file was saved. Record the next processing event and compare issue counts with the baseline.
Set rollback rules before peak traffic
Useful triggers include a sudden drop in processed items, a spike in disapprovals, a price or availability mismatch, or a destination becoming ineligible.
This complements a feed health score: the score shows risk, while the change log explains why it moved. Start with the product data quality framework.