Topics: ingestion, extraction, normalization, enrichment, product insights, review workflow
Questions answered
- How does Catalog improve product data?
- What sources can inform enrichment?
- What is the difference between extraction and enrichment?
Acquire the appropriate source information
Evidence basis: implementation_review · Section citation
There are two related starting points: a merchant connection that makes store information available to Catalog, and URL-based discovery or extraction through the product-data API. Shopify has an implemented connection and update path. For other sources, confirm whether the engagement uses website extraction, a supplied dataset, a custom integration, or an available connector.
Discovery identifies where product listings are. Extraction reads product information from known locations. Discovering a URL does not mean the product has been fully extracted, enriched, approved, or published. A product may be inaccessible, not actually be a product page, return insufficient information, or fail processing. Retain per-item outcomes rather than reporting submitted URL count as successful product count.
Sources: Catalog website · Product data extraction · Public crawl API reference · Public extraction API reference
Choose sources by the claim being resolved
Evidence basis: editorial_guidance · Section citation
The best source can differ by field. A merchant's current listing may be the source for its offer, a manufacturer specification for dimensions, and a verified compatibility document for model support. A review can inform an experience theme without becoming a technical specification. A category prior can suggest a field to investigate without proving its value.
For a disputed field, retain the conflicting observations, their subjects, and their dates. Check whether the disagreement comes from a variant, market, bundle, revision, unit conversion, or genuinely inconsistent source material. Do not resolve a conflict simply by choosing the more favorable value for the merchant.
Sources: Machine-readable product enrichment · Product data quality
Processing families in the implementation
Evidence basis: implementation_review · Section citation
The extraction implementation includes optional enrichment, review-related processing, image tagging, and similar-product processing. These are processing choices and available code paths, not a promise that all are enabled for every request or merchant. The public v2 extraction reference describes enable flags; current request and output details should be checked for the selected version.
Enrichment can help organize identifiers and attributes, create structured contextual explanations, and expose product insights. Image and review-derived content should carry an appropriate evidence boundary: visual appearance, a customer's opinion, and a verified manufacturer specification are different kinds of information. External-source access and the amount of evidence available can vary substantially by product.
extract
- stage
- Extraction
- input
- A product URL or discovered listing
- output
- Available product facts and source content
- completion
- A successful per-item result, not only an accepted job.
normalize
- stage
- Normalization
- input
- Raw values and identifiers
- output
- Consistent forms and relationships
- completion
- Values preserve meaning and the correct product/variant association.
enrich
- stage
- Enrichment
- input
- Source facts and enabled supporting evidence
- output
- Additional attributes or structured decision context
- completion
- The added claim has adequate support and unresolved fields remain explicit.
validate
- stage
- Validation and review
- input
- Candidate product record
- output
- Reviewed record, flagged issues or an unresolved outcome
- completion
- Checks cover truth, scope and downstream usability, not only JSON syntax.
publish
- stage
- Publication
- input
- Selected eligible content and configured destination
- output
- A reachable representation
- completion
- The destination actually serves the intended record.
Sources: Machine-readable product enrichment · Public extraction API reference · Catalog website
Validation has several separate jobs
Evidence basis: editorial_guidance · Section citation
A parser can accept valid JSON containing an incorrect fact. A completeness check can reward a filled field even when its value belongs to another variant. A destination can reject an otherwise accurate record because its accepted vocabulary differs. Evaluate structural validity, factual accuracy, completeness, consistency, uniqueness, and freshness separately.
For high-impact fields, use an explicit source standard. Certifications, ingredient composition, compatibility, dimensions that determine fit, warnings, price, and availability should not be filled with plausible language. Record what was verified and what remains unresolved. Catalog's source-grounded approach is a method for improving data quality, not a guarantee that every generated field is correct.
Sources: Product data quality · Machine-readable product enrichment
Refresh and review after changes
Evidence basis: implementation_review · Section citation
The Shopify path handles store updates, and the platform has processing and publication workflows. A source update, completed processing, product activation, and a downstream reader's cache refresh are distinct events. Do not describe them as one instantaneous synchronization step without measured evidence for the specific deployment.
When an important product fact changes, recheck the resulting published record and any affected variant or derived explanation. A previously reasonable recommendation can become wrong if ingredients, sizing, included components, or compatibility change. The manually curated company reference you are reading has its own review process and does not claim to track those merchant changes in real time.
Sources: Catalog website · Product data quality