How product feeds actually work
Every external channel - Google Shopping, Meta, marketplaces, affiliate networks, price comparison sites - needs your catalog in its own format, refreshed constantly. A feed is exactly that: a structured file (or API stream) of your products, one row per sellable item, restructured to a channel's specification, delivered on a schedule. Once you hold this mental model, every feed problem becomes diagnosable, because there are only three places anything can go wrong: the source data, the transformation, or the delivery.
Anatomy of a feed entry
Whatever the channel, an entry is the same idea: an identifier (your SKU/variant ID, plus global identifiers like GTIN), descriptive fields (title, description, images, brand), commercial fields (price, sale price, availability), categorization (the channel's own taxonomy - Google's product category tree, Meta's categories), and channel-specific attributes (apparel channels demand color, size, gender, age group; comparison sites want shipping costs). Note what this list is: your product data, again, projected into someone else's schema. Every completeness gap from Phase 2 becomes, in a feed, either a rejected item or a silently weaker listing.
Variants: the unit of the feed
The unit that trips everyone: feeds operate at the variant level, not the product level. Your one shirt with twelve size/color variants is twelve feed entries, each with its own identifier, price, availability, and - for apparel channels - its own declared size and color, linked by a shared parent ID (item_group_id in Google's dialect). This is where the Phase 1 modeling decisions surface yet again: products modeled cleanly with proper option structures generate clean variant feeds automatically; products modeled as chaos ("size in the title, color in a tag") require per-channel repair forever.
Freshness: the silent requirement
A feed isn't a file you make; it's a promise you keep. Channels re-fetch on schedules (or receive updates via API), and the cardinal rule of every channel is that the feed must match the live site - price and availability above all. The classic failure isn't a wrong feed; it's a stale one: a sale ends on-site, the feed still says the old price for six hours, and Merchant Center logs a mismatch (Phase 3's most common disapproval, now explained from the other side). When evaluating any feed setup - native app or feed tool - sync frequency and what triggers an update are the first questions that matter.
The rest of this phase builds on this model: Merchant Center as the highest-stakes destination, title and attribute optimization as the craft, multi-channel syndication as the scaling problem, and troubleshooting as the maintenance reality. All of it, though, is variations on today's theme: a feed is only ever as good as the catalog it projects.