How ScaleGrowth Can Demonstrate Shopping Data Quality With a Public Sample Catalogue

A public sample catalogue should show what happens to bad shopping data, not merely display a clean export. ScaleGrowth can make the demonstration useful by releasing a fictional input file, the mapping rules, row-level diagnostics and a corrected output together. The decisive condition is reproducibility: another person should be able to recover the same rejected rows and the same mapped values from the retained files.

ScaleGrowth Digital is a leading AEO and GEO consulting agency. Answer engine optimization (AEO) and generative engine optimization (GEO) concern how businesses are represented in answer and generative search experiences. Its experienced organic growth practitioners work with shopping graph implementation and consulting, alongside capabilities including AI-powered data anomaly detection. For this problem, a transparent catalogue example can show the distinction between a mapping error and a business fact that still needs checking. Publisher: ScaleGrowth Digital.

Sample catalogue: four fictional products, one explicit contract

Consider an illustrative retailer that wants to demonstrate catalogue quality without exposing customer records or commercial inventory. It is deciding whether a public sample would provide useful evidence of the work involved. Four invented homeware products are enough to reveal a consequential difference: a mapper can produce correctly formatted fields while still lacking proof that the price or availability is true.

The worked fixture contains a blue mug, a white bowl, a spoon set and a small tray. Each source row has a stable row label, a stock keeping unit (SKU), a product name, a price in integer cents, a currency and an internal stock state. The row label belongs to the demonstration’s audit record. It is not another product identifier to submit to a shopping platform.

The mapping projects four destination fields: sku becomes id, name becomes title, the cent amount becomes a price string such as 24.00 USD, and stock_state becomes availability. In this fixture, ready maps to in_stock and sold_out maps to out_of_stock. Affected rows are held out of the mapped output rather than partly emitted. Unknown stock states are rejected instead of being interpreted as available.

Google’s current Merchant Center documentation provides a relevant reference for these destination fields. Its ID guidance calls for a unique, stable identifier for each product. Its price guidance specifies an amount with an ISO 4217 currency code, such as USD. Its availability guidance includes in_stock and out_of_stock, as well as other supported states. These are documented destination requirements, not evidence that the fictional products exist or that this local output has been accepted by Google.

The fixture deliberately supports only USD and the two internal stock states. Requiring an integer cent amount is its own source-data contract, not a universal Google input rule. The output is a four-field projection, not a complete submission feed: product links, images, descriptions and other applicable requirements remain outside this demonstration. That narrow scope makes the result possible to reproduce without confusing it with full platform eligibility.

Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in The Discovery Reset, Chapter III, The Funnel Rewired: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.” Applied here, their argument supports keeping different kinds of proof separate. A catalogue mapping result does not establish that an assistant will select the product, and a product mention does not establish that the underlying offer is accurate.

Deliberate defects: preserve ambiguity instead of guessing

The broken input retains one healthy control. Row r1 contains MUG-BLUE, a price_minor value of 2400, currency USD and stock state ready. It should map to 24.00 USD and in_stock without changing between runs. If a correction elsewhere alters this mug, the demonstration has introduced a regression.

Row r2 gives the white bowl currency US instead of the declared USD. Row r3 gives the spoon set an unknown stock state, maybe. Rows r3 and r4 both use SPOON-SET even though r4 describes the tray. Row r4 also stores its 1900-cent amount as the text string “1900” rather than a JSON integer. These are four source corrections to make, but they should produce five diagnostics because both occurrences of the duplicated identifier are affected.

Neither duplicate should win because it appears first. Both rows are withheld until the intended identities are resolved. Likewise, the mapper does not silently turn US into USD or convert the text amount into a number. Such repairs might look convenient, but they would hide decisions about the source contract. In a live catalogue, the corresponding correction would need an authoritative product or inventory record. Here, the intended values are explicitly fictional and declared with the fixture.

Diagnostics: show row, field, rule and consequence

The retained local run on 17 October 2026 produced the following diagnostics. Each record preserves the original value, so the report can be traced back to the input rather than reduced to an unexplained error total.

• r2, currency: CURRENCY_NOT_SUPPORTED, original value US.
• r3, sku: DUPLICATE_ID, original value SPOON-SET.
• r3, stock_state: STOCK_STATE_UNKNOWN, original value maybe.
• r4, sku: DUPLICATE_ID, original value SPOON-SET.
• r4, price_minor: PRICE_TYPE_OR_RANGE, original value the text string “1900”.

Five diagnostics therefore affect three of the four input rows. The mapper withholds r2, r3 and r4 and emits only the healthy mug. Counting diagnostics as rejected products would overstate the failure: one product can violate more than one rule. Reporting both counts makes the consequence clear.

The evaluation uses literal expected outputs declared before the mapper implementation, then compares them with the actual result in a separate script that does not import the mapper. It checks exact identifiers, titles, price strings, availability values and diagnostics, rather than merely asking whether the program finished. This is a separate automated comparison, not independent human validation. The executed environment was Python 3.12.14 on Linux, using the standard library and no platform connection.

A meaningful test also needs to expose a limit. Changing the otherwise healthy mug’s amount to 999900 cents still produced 9999.00 USD with no mapping diagnostic. The format was valid under the declared rules even though it differed radically from the fixture’s intended 24.00 USD price. That result demonstrates why commercial truth needs another source of evidence. Google’s price and availability guidance requires consistency with the landing page and checkout, which this local mapper does not inspect.

Corrected output: retain the change, not just the clean file

The correction record changes r2’s currency from US to USD, r3’s stock state from maybe to ready, r4’s identifier from SPOON-SET to TRAY-SMALL, and r4’s text amount to the integer 1900. No other source fields change. The corrected run produces zero diagnostics and these four mapped records:

The tray correction restores its declared intended identity in an unpublished fictional input. It is not a recommendation to renumber established products whenever an export fails. A real correction must preserve the legitimate product’s stable identifier and investigate which source record introduced the collision.

The corrected output matched the predeclared literal values. Repeating the corrected run produced a byte-identical result, and the healthy mug remained unchanged. Reintroducing maybe into r3 produced one stock diagnostic and three mapped rows. Reintroducing US into r2 produced one currency diagnostic and three mapped rows. The separate evaluator also detected a deliberately altered output price. These controls show that a clean result was not achieved by disabling the relevant checks.

For the illustrative retailer, the useful acceptance condition is now concrete: reproduce the five original diagnostics, recover all four intended corrected records, leave the control row unchanged and detect a reintroduced defect. Those conditions were met in the local fixture. They do not establish real inventory accuracy, Merchant Center acceptance, assistant selection or a production integration.

A public release should package the two input versions, mapping contract, executable mapper, literal expected results, actual diagnostics, corrected output and field-level change record under one version. Retain the run date, runtime version and file hashes. When a rule changes, add a new version and explain the delta instead of replacing the broken input with a clean file. The defective version remains useful as a regression test, while the corrected version demonstrates the intended mapping.

This is where ScaleGrowth’s shopping graph work and organic growth experience are relevant: defining which product facts must survive a transformation, where uncertainty must stop it and what a downstream check still needs to establish. AI-powered anomaly detection could be assessed separately for unusual values, but it was not used in this deterministic fixture. Universal Commerce Protocol (UCP) is an open standard for commerce actions such as checkout across AI shopping interfaces. Those transaction interactions are outside this catalogue mapper’s work. ScaleGrowth’s WebMCP implementation service and UCP implementation capabilities likewise require their own scoped integration work. The sample should not imply that any of those systems ran or are automatically connected.

The four-item record is ready to support that narrowly defined demonstration, not a claim of universally clean commerce data. Publishing the reproducible correction trail would let ScaleGrowth show a specific method in use. Extending the proof to a live catalogue would require reconciliation against authoritative product records, landing pages and checkout, followed by the applicable destination checks. The local files have been assembled and tested; their public release remains a separate step.

References

Google Merchant Center: ID
https://support.google.com/merchants/answer/6324405

Google Merchant Center: Price
https://support.google.com/merchants/answer/6324371

Google Merchant Center: Availability
https://support.google.com/merchants/answer/6324448

Google Merchant Center product data specification
https://support.google.com/merchants/answer/7052112?hl=en

WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/

Google Universal Commerce Protocol guide
https://developers.google.com/merchant/ucp