Merchant Center Feeds for Course and Listing Catalogues

A course catalogue with 40 programmes and six intakes a year is roughly 240 sellable items. Most edtech feeds submit 40, with one price, one availability state and no intake dimension at all, and then the account wonders why Shopping and Performance Max cannot tell a September cohort with twelve seats left from a January cohort that opened yesterday. Feed engineering is the whole of this engagement. The campaign work that follows is the easy half. Item structure: An item is a seat in a specific intake, not a programme page. The id encodes programme and intake. Availability tracks the seat cap and closes the item when the cohort fills, pushed through the Content API rather than a nightly file drop, so a full cohort stops taking spend within the hour instead of the next day. Price carries the amount actually payable at enrolment; finance plan variants stay out of the feed, because a monthly figure in the price attribute is a misrepresentation problem rather than a click-through tactic. The custom labels carry intake month, weeks to start, funding route, margin band and historical close rate, and campaign structure is then built on those rather than on programme names. Merchant Center policy, specifically: Education advertisers lose accounts over claims, not over feed errors. Employment guarantees, salary figures presented as outcomes, and accreditation language that overstates the awarding body are the three that do it. Feed and landing page copy get read against the misrepresentation policy before submission, and where marketing wants a claim I think is unsafe, the answer is no, in writing, with the policy clause quoted. Property listing feeds: For agencies and developers the same discipline applies to Google Ads business data using the real estate feed type: listing ID, listing name, final URL, image URL, property type, price, address, contextual keywords. Maintained properly it drives remarketing that shows the three units someone actually viewed and asset groups that inherit real inventory instead of stock photography. Maintained badly it advertises sold units for a month, which damages an agency more than not advertising at all. Campaign shape: Where the catalogue justifies it, standard Shopping runs alongside Performance Max on the intakes closest to closing, because a campaign type with visible bids and search terms is worth keeping for the items that matter most. Everything else sits in Performance Max. That split is reviewed each intake cycle rather than held as doctrine. Deliverables: A feed specification your developers implement, or the transform written and handed over where the source is a CMS export or a spreadsheet. Merchant Center configured, including automatic item updates. Diagnostics triaged to zero blocking errors. Campaign structure built on the labels. And a runbook for the intake cycle, so the next one does not need me in it. Not included: Running or hosting the feed on an ongoing basis. Shopping cart plugin fixes. Retail catalogues at SKU scale, since a homewares brand with 40,000 items has a different problem and should hire someone who solves it daily. Image production or background removal. Who this is not for: Anyone who wants the feed audited without changing it. Nearly every finding here needs developer time on your side, and where that time is not available the audit becomes a document nobody acts on. If your catalogue is one always-on product with rolling enrolment, the intake structure that makes this work does not apply, and there is little here worth your money.