Contents 11
In furniture advertising, one practical risk appears when the feed describes a product state that no one can actually buy on the site. Material, finish, size, modularity and shipping all have to line up across the catalog, Merchant Center, the landing page and checkout. That is why the work should start with a model of the assortment, and only then move on to creatives and campaigns.
A workable order looks like this: define what counts as a model, a variant, a module and a set; describe every SKU that can be purchased; separate product dimensions from package dimensions; verify price, availability and shipping on the landing page; set up purchase measurement. This playbook helps you run that review without assuming anything about future results.
Catalog model: what is actually being sold
Before mapping feed attributes, break the assortment down into operational entities:
- Product family. A shared line with a single name or design. It may be a navigation page, but it is not necessarily a separate product.
- Model. A specific item with a defined construction — a sofa of a particular shape, a wardrobe of a particular width.
- Variant. The same model in a different material, color, finish or stable size that can be bought on its own.
- Module. A separately sold section of a system: a corner element, a shelf, a cabinet or an ottoman.
- Set. A bundle sold as a single unit with a defined composition,
priceand item number. - Made-to-order configuration. An item whose parameters the buyer chooses in a configurator.
For each type, write down the rule: does it go into the feed, does it have its own SKU and URL, where price and availability live, which data is the source of truth. A configurable item does not automatically become a set of variants. Only stable configurations should go into the feed — ones that can genuinely be bought at the price you send and opened in the matching page state.
The Merchant Center data specification covers the base attributes id, title, description, link, image_link, price and availability. Requirements for other attributes depend on the product, the country and the display format. Do not extend a rule that applies to one category or market to the whole catalog without checking the documentation.
Variants and item_group_id
The item_group_id reference describes true variants as separate products with unique id values and a shared group identifier. Grouping has to match the choices available on the landing page. Every variant needs its own URL or a state with the attributes preselected.
Group variants together only when all of these hold:
- the buyer can purchase each variant separately;
- it has its own price and
availability; - the link opens the intended material, color, finish or size with no extra selection;
- the images and attributes in the feed match the state that opens;
- the group identifier is not in use for another model.
Do not group a sofa with a "sofa + pouf" set, different modules of one system, or an old and a new construction just because they share a collection name. A module is a separate product if it can be bought on its own. Its color executions may be variants, but the neighboring section serves a different function and needs its own group.
After a change to the ERP or the feed generator, check that id and item_group_id remain stable. Accidental regeneration makes diagnosis harder and can break correct grouping.
Product data: what to send
Title. Use a consistent pattern: product type, model or series, the variant attribute, size or seating capacity where that genuinely distinguishes the SKU. Do not add warehouse codes or promotional fillers such as "hit" or "best".
Description. Give the facts needed to choose: construction, frame material, finish, mechanism, filling, care and what is included. If a characteristic depends on the configuration, say so. Do not attribute to a whole series a property confirmed for only one variant.
Identifiers. Send brand, GTIN and MPN where they apply and have been provided by the manufacturer. Do not generate GTINs yourself. For own production, use real brand data and the manufacturer's part number in line with the current specification.
Material, color, finish. Keep the technical fabric name separate from the color a buyer will understand. The values in the feed, the variant name, the photo and the configurator all have to describe one and the same product state.
Images. The main shot shows the specific variant. Do not reuse a photo of one color across every SKU when the ad names a different one. Additional shots can be assigned roles: overall view, material detail, the item in a room, a dimensioned diagram, a modular composition.
Price and availability. The values in the feed must match the variant that opens and the purchase path. Wording like "from" does not substitute for the price of a specific configuration. For made-to-order items, send a status that reflects the actual ability to order that item.
Shipping: the product and the package have different dimensions
The attributes shipping_length, shipping_width and shipping_height describe package dimensions, not the size of the assembled product. For furniture the difference matters: a wardrobe can have one footprint in the room and ship in several flat packages.
An operational checklist:
- take weight and dimensions from the packing specification, not the marketing card;
- use consistent supported units;
- do not substitute approximate measurements for an item that has not been packed yet;
- document items with multiple shipping pieces separately;
- when packaging changes, update the source the feed is built from;
- do not confuse the dimensions used to fit furniture into a room with those used to calculate shipping.
Merchant Center shipping settings should stay as close as possible to the terms on the site. shipping_label lets you attach policies to groups of products, while package weight and dimensions support calculations that depend on those parameters. At the level of operational groups you can separate oversized, fragile, compact and made-to-order items — if different rules genuinely apply to them.
Keep the settings hierarchy in mind: shipping data at the product level can override account rules. An integration or the API can also overwrite a manual change. After a release or a sync, reconcile not just the feed but the actual policies in Merchant Center.
Do not promise shipping cost or speed in creative if they depend on the city, the floor, carry-in, assembly or configuration and have not been confirmed for the entire target assortment.
Landing page review
The Merchant Center requirements expect link to lead to the page of the specific product, with title, description, images, price, currency and availability consistent with the feed. The substantive experience must not differ by device, browser, location, cookies or user agent.
Check a sample from each product type:
- the URL opens the intended model, not a collection page or a search;
- material, color, finish and size are already selected;
- the image changes together with the variant;
- the price shown is for that exact state, not the minimum price of the series;
- availability does not contradict the feed;
- the way to buy or order is clear;
- the shipping block does not imply identical terms for every region when that is not the case;
- the configurator works on mobile, does not hide the price and does not reset the selection;
- a bot receives the same product and the same substantive data as a buyer;
- the intended variant survives redirects.
For products with regional logic, test the available scenarios separately. If the site resolves warehouse or shipping after a city is chosen, the feed has to lead to a state that does not contradict that logic.
Creative matrix and asset groups
Performance Max asset groups are collections of creative built around a theme or an audience, from which the system assembles ads. They are not separate campaigns and not independent bid controls. Build them as thematic libraries aligned with the products in the corresponding listing group.
For each theme, prepare several types of evidence-based creative:
- Room and context. Show the item in a real usage scenario without exaggerating the space.
- Material and detail. Give a close-up of the fabric, wood, hardware, stitching or mechanism.
- Scale and dimensions. Use a diagram or a clear reference point; the numbers must match the product card.
- Module and variant. Show the available compositions and clearly separate them from what the stated price includes.
- Neutral copy. Name verified characteristics without adding unconfirmed timelines, "lifetime" quality or universal compatibility.
Group assets by product type, room or a confirmed selection scenario. Your internal warehouse structure makes sense to the team, but it rarely gives the buyer useful context.
Measurement: purchases and separate inquiries
Conversion actions are bundled into Google Ads goals. A purchase goal can include several actions, and its composition affects optimization, bidding and reporting. Make sure product views, add-to-cart or contact reveals have not ended up inside the purchase goal.
A request for a consultation, a measurement visit or a configuration quote can run as a separate action if it genuinely carries value and does not duplicate a completed purchase. Do not merge an inquiry and a paid order under one name or one goal: the team needs to see at which stage the action ended.
For purchases, send a unique transaction ID generated by the backend or the e-commerce platform. It helps minimize duplicates when the confirmation page is reloaded. The same ID across different orders can cause undercounting, so a static value is unacceptable.
Reconcile returns, cancellations and refusals with the back office separately. Do not assume the ad system already knows about a post-purchase event: that depends on an import or adjustment actually being implemented.
Symptom, check, action
| Symptom | What to check | Action |
|---|---|---|
| Variants open the same state | URL, preselection, photo and attributes | Separate the states and re-verify item_group_id |
| The feed shows the minimum price of the series | The price of the specific purchasable SKU | Send only a stable configuration with the matching price |
| Shipping is more expensive on the site | Account policy, product-level override, calculator | Sync the rules and check the integration |
| An oversized item is counted as compact | The source of weight and package dimensions | Update the specification and shipping_label |
| Modules appear as interchangeable variants | The group logic | Give each module type its own group |
| More purchases in reports than orders | Tag re-firing and transaction ID | Send a unique ID from the backend |
| The system optimizes toward micro-events | The composition of the Purchase goal | Separate purchases from diagnostic actions |
Launch checklist
- The catalog is broken down into families, models, variants, modules, sets and made-to-order configurations.
- For each entity it is defined whether it is a separate product in the feed.
idvalues are stable, anditem_group_idlinks only true variants.- Titles, descriptions, identifiers and images match the specific SKU.
- Price and availability match the preselected state of the page.
- Package dimensions are not mixed up with the dimensions of the assembled product.
- Shipping policies and labels match the terms on the site.
- The configurator has been tested on mobile and in a clean session.
- Creatives show confirmed materials, dimensions and contents.
- The Purchase goal contains purchases, with consultations and measurement visits kept separate.
- The transaction ID comes from the backend and is unique.
Weekly review
| Area | What to check |
|---|---|
| Feed | New disapprovals, changes to SKUs, prices, availability and images |
| Variants | New products without a group, wrong preselection, reused groups |
| Shipping | Discrepancies with the site, products missing the right label, overwritten manual rules |
| Landing pages | Product cards after releases, the mobile configurator, regional states |
| Creatives | Outdated fabrics, contents, dimensions or claims |
| Measurement | Order reconciliation by transaction ID, goal composition, returns and cancellations |
Regular review is necessary because the assortment, packaging, site and integrations keep changing. When the team fixes the data source rather than a single symptom in Merchant Center, the next update is less likely to bring the same discrepancy back.