Send packed shipping measurements rather than bare product dimensions

Establish what was measured

Google's shipping-dimension documentation describes package length, width and height for carrier-calculated shipping, requiring the complete set and consistent units. Its shipping_weight guidance covers weight-based calculations. Check current units, service support and limits before implementing the mapping.

Ask fulfillment to identify the actual dispatch configuration for the sold item. An assembled table's height is not its flat-pack carton height; a decorative pot's product weight excludes protective material. Record the measurement source, packaging version and what is included. Avoid copying the first dimension fields available in the product master merely because the export requires numbers. The values need the right operational meaning.

Keep product facts and parcel facts in separate fields

Maintain the dimensions useful to a buyer separately from those used for shipping. Label units explicitly and retain the original measurement alongside any converted value. Check whether a supplier uses an ordered dimension string and what order it follows before splitting it into three attributes.

Review items that ship in several parcels or require nonstandard service. Do not compress several boxes into an invented single cube without a supported method. Ask the shipping owner which configured rate approach represents those items accurately. The correct decision may be a separate shipping class or another supported rate setup, not filling standard fields with approximate numbers. Preserve that exception so the next importer does not replace it with a generic default.

Validate completeness, plausibility and the resulting charge

Check that the three dimensions are all present where used, share compatible units and describe one approved package configuration. Include weight and test for unit conversion errors. A millimeter-to-centimeter mistake can create a plausible-looking number that changes a dimensional calculation dramatically.

Use a sample of light bulky products, dense compact products, long parcels and ordinary items. Compare the resulting quoted shipping behavior with the approved checkout service for representative destinations. Separate an input-data discrepancy from a carrier-service or account-setting discrepancy. Matching the measured box does not establish that the selected service is correct, and changing the box dimensions to force a preferred quote would corrupt the underlying evidence.

Make packaging changes visible to catalog operations

A warehouse may adopt a new protective insert or consolidate packaging without changing the product SKU. That can alter shipping weight or dimensions while every customer-facing product specification remains true. Include catalog mapping in the packaging change handoff and give the measurement record a review trigger.

After release, inspect processed values and the relevant shipping output for the test sample. Keep previous measurements for diagnosis but clearly mark which version is active. Review exceptions rather than silently assigning an average parcel to the whole range. The useful outcome is a defensible connection between fulfillment evidence and shipping configuration, not a claim that the feed itself can predict every carrier surcharge or final delivery cost.

Make the reasoning concrete.

A fictional lighting merchant exports the assembled floor-lamp height into shipping_length. The lamp actually ships in a shorter disassembled carton with protective packaging and a separate verified shipping weight.

The team corrects the measurement source, tests an ordinary and a boundary shipping case, and leaves product dimensions intact for buyers. It does not manipulate measurements to obtain a desired rate.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Configuration

   What package or supported shipping treatment represents this offer?

2. Evidence

   Who measured it and which packaging version was used?

3. Units

   Do all dimensions and weight retain explicit, correct units?

4. Exception

   Does the product require multiple parcels or a nonstandard service?

5. Quote

   Does the resulting configuration agree with the approved checkout service?

Watch for the wrong conclusion.

• Using assembled dimensions for a flat-packed parcel.
• Combining multiple boxes into an unsupported fictional package.
• Changing measurements to force a preferred shipping charge.

Sources & scope

Workflows, worksheets and fictional examples are original editorial analysis, not Google instructions or measured business results. Sources support only the specifically attributed platform facts. Platform controls and eligibility can change; verify current account guidance before implementation.

• Google Merchant Center: Shipping dimensions →Primary platform documentation · Supports: Supports package dimensions, complete length-width-height submission and consistent units for carrier calculation. Measurement lineage and rate testing are original editorial analysis.
• Google Merchant Center: Shipping weight →Primary platform documentation · Supports: Supports shipping_weight for weight-based calculation and reviewing supported limits and shipping configurations.