GOOGLE SHOPPING FEED TEMPLATE: WHICH COLUMNS TO KEEP

When people ask me for a google shopping feed template, what they usually want is a spreadsheet with every possible column already in it, ready to fill. I've learned to do the opposite. The template I actually start from on a new account has far fewer columns than the specification allows, because in my experience a feed fails far more often from carrying columns it doesn't understand than from missing an exotic one. The question that matters isn't "which columns exist," it's "which columns do I keep."

That distinction is the whole point here. Google's product data specification lists dozens of attributes, and a template that mirrors all of them looks thorough but is a maintenance trap: empty fields you forget to populate, headers you mistype, and a wall of unused columns that hides the one required attribute you actually left blank. A lean template flips that. You keep the columns every product needs, add the ones your catalog triggers, keep a short list of high-value optional ones, and drop the rest until a real need appears.

So I'll walk through the template the way I build it on a live account: start lean, lock in the core columns, layer on the conditional ones your products force, decide which optional columns earn a slot, cut the dead weight, and adapt the whole thing into a google ads custom feed template you can maintain without dread.

Why I start from a lean template, not a full one

The instinct when you first build a feed is to grab a template with every column and treat blanks as harmless. They usually aren't neutral. A column that's present but empty can push a wrong default: leave identifier_exists in the sheet and forget it, and Google assumes the product has identifiers when it might not. A header you misspell is silently ignored, so you think data is submitted when nothing is being read. And the more columns you carry, the slower it is to spot that one apparel line is missing size, because it's buried among forty fields you never use.

My rule is simple: a column earns its place in the template only if a product actually uses it. That keeps the file honest. Every column present is a column I can explain, which means when a disapproval lands I'm auditing ten meaningful fields, not sixty mostly-empty ones. This is also why I treat the template as an extension of the wider google shopping feed setup rather than a separate artifact, because the setup decides which columns your catalog will ever need, and the template should reflect exactly that and nothing more.

It helps to remember what a feed really is. Each column header maps to a Merchant Center attribute, and each row is one item. Understanding what a google shopping feed carries makes the column decisions obvious: the header names aren't yours to invent, they have to match the official attribute names exactly, so "customizing" a template is entirely about which columns you keep and how you fill them, never about renaming fields.

The core columns every feed keeps

There's a floor that goes into every template before I think about the catalog at all. Seven columns are required for essentially every product: id, title, description, link, image_link, price, and availability. Miss any one and the product can't serve. On top of those, brand is required for most new products, and you need one identifier column, either gtin or mpn, so I always keep both headers even when only one is populated per row.

Two of these carry more weight than their single column suggests. The id has to be unique and stable, ideally the SKU, and it must never change between exports, because Google reads a changed id as a brand-new product and quietly resets its history. And title is doing double duty: it satisfies a requirement and it's the text a shopper sees, so I treat that column as a campaign asset, not a box to fill. A present-but-weak title is a slow, invisible loss.

The other quiet requirement is consistency, not just presence. availability and price both have to match the landing page, so these columns aren't "done" the moment they're filled; they're done when they agree with what a shopper sees at checkout. That's why my core template also reserves sale_price as an optional-but-frequent column: the day a promotion runs, I don't want to restructure the file, I want the column already sitting there ready.

The conditional columns to add only when your catalog triggers them

This is where a template has to bend to the catalog instead of the other way around. A set of columns is conditionally required, meaning they apply only because of what you sell and where. The clearest example is apparel: for clothing targeted at Brazil, France, Germany, Japan, the UK, and the US, Google requires color, size, gender, and age_group. None of these belong in a homeware feed, so I don't carry them there. The day a client adds a clothing range, those four columns switch on together, and a template that didn't anticipate them disapproves the whole apparel line at once.

The other conditional column I always plan for is item_group_id. Any product sold in variants needs it to tie the versions together, and the variant-defining column (color, size, and so on) has to actually differ between rows. Get that wrong and disapprovals cascade across a whole variant group, not one item. So my logic is: no variants, no item_group_id column; variants present, it's mandatory and non-negotiable. Country is the multiplier here, because the same category can pick up new required columns purely from a new target market, which is why I map columns per category and per country rather than once.

The authoritative, attribute-by-attribute source for which columns are required, "it depends," or optional for each category is Google's product data specification, the document I keep open while building the template. If you want the same logic framed around what silently blocks products, I've written it up separately under google shopping product feed requirements, because the conditional columns are exactly the ones that don't show up on a generic checklist.

The optional columns that earn their slot

Not every useful column is required, and this is where good feeds separate from merely compliant ones. A handful of optional columns won't disapprove anything but genuinely change performance, so they stay in my template by default. The two I never skip are google_product_category and product_type. The first overrides Google's automatic guess, which matters for ambiguous items the algorithm might file under the wrong branch entirely. The second is your own taxonomy, and it's the field Shopping campaigns use to organise bidding and reporting, so leaving it out costs you a clean way to structure the account later.

The other optional keeper is the custom_label_0-4 set. These are invisible to shoppers, but they're the lever I use to segment products by margin, season, bestseller status, or clearance, and that segmentation is what lets a Shopping campaign be steered rather than left to run flat. I keep at least one or two custom label columns in every template because adding them retroactively across a live feed is more friction than reserving them up front.

Descriptive optional columns follow the same test: keep it if it helps Google understand the product or gives you a real campaign lever. A rich description up to its character ceiling gives the algorithm more text to match a query against, and additional_image_link adds context images beyond the required main one. Both are optional, both quietly help, so both earn a column. My rule of thumb: required columns are the price of entry, and this short list of optional ones is where the performance actually lives.

The columns I drop until something needs them

Everything outside the core, conditional, and high-value optional sets is column bloat by default, and I leave it out. The specification includes attributes for energy efficiency classes, unit pricing measures, installment and subscription plans, loyalty programs, 3D model links, marketplace seller IDs, and detailed shipping dimension fields. Every one of them is real and occasionally essential, but for the average catalog they're empty columns that add maintenance risk and hide the fields that matter.

The reasoning is consistent with everything above: an empty column is not free. It's a header to keep spelled correctly, a default I might trip over, and a line item between me and the attribute I'm actually auditing. So I treat these as on-demand columns. The day a client sells appliances into the EU, the certification column goes in. The day they run installment pricing, installment goes in. Until then, the template stays lean and the file stays readable.

This is also where the "custom" in a google ads custom feed template really means something. Customizing isn't adding more, it's subtracting to fit. A generic template that ships with sixty columns is a starting point to trim, not a standard to meet. The version I hand off has exactly the columns that account will use and not one more, which is what makes it maintainable by whoever inherits it after me.

Turning it into a google ads custom feed template

Once I know which columns stay, building the actual google ads custom feed template is mechanical, and I usually do it in a Google Sheet for anything but the largest catalogs because a sheet is easy to edit, version, and audit. The header row uses the exact attribute names, underscores and all, one row per item, and the values match the landing page. For fast-changing or very large catalogs I'll move to a connector or scheduled fetch, but the column decisions are identical either way, the template just describes the shape of the data whatever the source.

The customization that matters is populating, not restructuring. I map each kept column to a source in the catalog or the connector, so that a title comes from the product name field, a price from the price field, and so on, and the whole thing regenerates cleanly on every export. When a value is wrong, I fix it at that mapping rather than editing one row, because a column-level issue almost always affects a group of products and patching one item just gets overwritten on the next refresh. That discipline is what separates a template you maintain from one you keep firefighting.

My workflow: build lean, then let diagnostics grow it

The habit I'd most like to pass on is to let the account tell you which columns to add, rather than front-loading every possible field. I start every template from the same lean base, upload, and then read Merchant Center's diagnostics. If a required column is missing for a category, the Issue Details will name the exact attribute and the products affected, which turns "add everything just in case" into "add exactly this column because these forty SKUs need it." The template grows in response to real signals, not guesses.

That approach ties back into treating Google Shopping as a system rather than a one-off file: the feed template, the diagnostics, and the campaign structure are one loop, and the columns you keep are the interface between them. Custom labels feed your bidding structure, product_type feeds your reporting, and the required columns feed eligibility, so a well-chosen column set is really a design decision about how the whole account will be steered.

The practical takeaway is short. Build your google shopping feed template from the core columns every product needs, add the conditional columns your specific catalog and target countries trigger, keep the handful of optional columns that improve understanding or give you a campaign lever, and drop everything else until a real need appears. Keep the values consistent with the landing page and fix issues at the mapping, not the row.