Answer first
E-commerce teams should treat a conflicting feed value as a controlled data incident, not as a quick copy edit. Start by matching the affected SKU or variant to a stable internal identifier. Then compare the exact attribute across the approved product record, supplier evidence, current packaging or instructions where relevant, the commerce platform, the channel feed, the live landing page, and any structured data exposed on that page. Record what differs, which source is currently authoritative for that attribute, who can confirm it, and what downstream destinations must be refreshed.
The practical goal is not to force every system to contain identical text. A retailer may require a different field name, a marketplace may limit length, and a channel may only accept a fixed vocabulary. The goal is to preserve the same approved product fact after a documented transformation. When the evidence does not establish the value, pause publication or mark the field for clarification according to the channel workflow rather than filling the gap with a plausible assumption.
A product feed attribute conflict is therefore a disagreement between values that should represent the same product fact, such as an identifier, variant relationship, product title, dimension, material, pack quantity, image, price, availability, condition, or a channel-specific classification. Google warns that incorrect, missing, or conflicting website and data-source information can lead to display issues, limited eligibility, or disapprovals in Merchant Center. [1] The same control discipline is useful even when a team does not use that platform.
For B2B toy and smart-learning product ranges, no feed field should be treated as a general statement about a product family. The applicable detail depends on the exact SKU, approved sample, current instructions, packaging, supplier records, retailer rules, importer obligations, and destination-market review. That principle keeps a data correction separate from an unsupported product claim.
Build a conflict model before incidents arrive
A team detects conflicts faster when it defines the objects being compared before publishing. Create a field dictionary that gives each attribute an internal name, business meaning, data type, permitted units or values, source owner, evidence location, channel mapping, and change owner. “Dimensions,” for example, is too broad. Distinguish product dimensions from packaged dimensions, specify the unit, and name the record that supports the value. “Colour” needs its own controlled vocabulary and an explanation of whether it identifies a SKU variant or only describes an image.
Separate four layers: the approved SKU or variant master; the channel transformation; the outbound feed; and the customer-facing page, including its structured data. Google says that both Merchant Center feeds and on-page product structured data can provide product information, and that using both can help it understand and verify data. [3]
This model prevents a common mistake: treating the most recently edited channel field as the source of truth. A channel can be a useful signal, but it is rarely the correct place to invent a product specification. A feed may also contain local commercial fields that are deliberately channel-specific. Those should be labelled as such, with their own owner and effective-date logic, rather than copied back into the product master.
Decide what “same” means for each field
Use exact equality for identity values such as a GTIN. Use controlled equivalence when a channel maps an internal term to an allowed vocabulary, and normalisation when “12 cm” becomes “120 mm.” Preserve the original evidence and rule. Titles and descriptions may be shortened or reordered, but must not change an approved fact or add a claim.
Google’s specification illustrates why relationship fields deserve explicit rules. It calls for a unique product ID that stays the same through updates and recommends using the SKU where possible; its variant guidance also connects an item group with the properties that identify a variant. [1] Teams should build equivalent checks in their own data model instead of relying on a visual review alone.
Detect conflicts with repeatable comparisons
Detection combines automated checks with evidence-led human review. Automation is strong at identifying blank required fields, invalid formats, duplicated identifiers, values outside a controlled list, unexpected unit changes, broken mappings, and differences between two structured exports. Human reviewers are needed when a title changes meaning, an image depicts a different configuration, a variant is grouped incorrectly, or a field requires interpretation of supplied product evidence.
Begin every monitoring run with a defined comparison set. A useful minimum is: the approved master record; the latest supplier or internal evidence package; the current product-information-management or commerce-platform record; the generated channel file or API payload; the live page; and destination diagnostics. Do not treat a dashboard warning as proof that the feed is wrong. It states that a platform observed a condition that needs investigation. Preserve the warning, timestamp, SKU, channel, field, and existing value so the team can reproduce the case.
An e-commerce product data error can arise in the master record, a transformation rule, a manual override, an integration refresh, a valid local channel rule, or stale page content. Classify the alert before editing so the team fixes the source or logic rather than only its downstream symptom.
Use three complementary detection lanes
Schema and completeness checks test required fields, types, lengths, permitted values, companion fields, duplicate or missing parent-child links, and invalid quantities. Parameterise rules by channel and market: one retailer’s requirement is not automatically universal.
Cross-source comparisons match an immutable internal SKU first, then compare normalised master, feed, and page values. Normalise units, whitespace, punctuation, encoding, and controlled synonyms, but retain original values in the incident record so a transformation defect remains visible.
Change and exception monitoring highlights movement since the approved release, including identity, variants, specifications, included-item statements, images, mapping edits, overrides, and rejected items. Google says its automatic updates can use landing-page data for price, availability, and condition, but are not a replacement for regular accurate feed updates. [2] Treat remediation as a signal, not governed source data.
| Detection method | Best at finding | Evidence needed before correction | Common mistake to avoid |
|---|---|---|---|
| Rule-based validation | Missing, malformed, duplicate, or unpermitted values | Field definition, rule version, affected payload | Treating a pass as proof that the fact is correct |
| Master-to-feed comparison | Mapping, unit, and transformation differences | Approved master value and transformation rule | Comparing display text without normalising units or vocabulary |
| Feed-to-page comparison | Stale page data, markup drift, and publication lag | Page capture, structured-data output, feed payload | Assuming the visible page is always the authoritative source |
| Human evidence review | Meaning, configuration, image, and claim conflicts | Approved sample records, packaging, instructions, or supplier confirmation as applicable | Replacing an unknown value with a guess |
A retail feed data validation routine should produce an exception queue, not an uncontrolled stream of edits. Give each exception a severity, owner, evidence deadline, affected destinations, and next action. Identity and variant-linking failures usually demand immediate containment because they can connect data to the wrong item. A minor punctuation difference in a channel-limited description can normally wait, provided it has not changed the meaning or obscured a required field.
Need a B2B review path for product information that needs supplier clarification or channel mapping? Email info@toywink.com with the SKU list, target sales channel, and the fields that need review. Toywink can discuss product-data handover requirements for the relevant project; final use should still follow the approved SKU evidence, retailer rules, importer obligations, and destination-market review.
Triage an exception before changing any value
Protect the evidence and prevent propagation. Create one ticket for a linked incident group, capturing internal SKU, parent or variant relation, channel ID, field, old and observed values, sources, timestamp, release version, and payload or page capture where useful. Keep personal customer data out of the ticket.
Then contain, correct, or investigate. Contain by pausing an outbound update, removing an override, or keeping a field unpublished. Correct only where approved evidence supports the value and mapping is understood. Investigate disagreement, uncertain configuration, or missing evidence. A validator pass is not approval for a product-fact change.
A product attribute discrepancy can have more than one legitimate answer when teams have not defined the business context. “Pack quantity” may refer to items in the consumer unit, cartons in a shipping case, or components shown in a set. The correction is not to choose the familiar number. It is to identify the field’s definition, unit of trade, and evidence, then map that defined fact to each requested destination field. Where the requester’s definition remains unclear, log the ambiguity and request clarification.
Set priority from risk, reach, and reversibility
Prioritise by risk, reach, and reversibility. Risk covers identity, variants, transaction-facing fields, and potentially material representation; reach covers affected SKUs and destinations; reversibility covers rollback and retained payloads. A high-reach mapping error can outrank a visible single-row typo.
Assign owners clearly: the data steward owns definitions and evidence; the commerce or integration owner owns transformations and exports; the product owner validates meaning; and the channel manager interprets retailer fields. Route importer or destination-market questions to the responsible party; a field correction is not an approval.
Resolve at the source, then prove the propagation
Resolve in sequence: name the approved source; correct the master only when evidence and owner support it; repair the mapping or override; regenerate a traceable payload; verify diagnostics and the landing page; then record before-and-after values, evidence, approver, release, and residual exceptions before closure.
Avoid a bulk fix until scope is known. Test a deliberately varied set: standalone SKU, parent, child variant, channel override, recent change, and record without an optional field. Use actual feed cases and confirm that the repair does not alter IDs, variant links, images, descriptions, or other mappings.
For price, availability, and condition fields in channels that inspect landing pages, teams must also test page and structured-data alignment. Google describes mapping these fields to structured-data properties for its automations and notes that a frequent change can still result in a mismatch or disapproval rather than an update. [2] That does not dictate every retailer’s policy, but it demonstrates why feed-only testing is incomplete when a channel uses page data as another signal.
Use a reason code that distinguishes evidence correction, approved product revision, source-system defect, transformation defect, retailer requirement, and temporary channel exception. Do not make “urgent” a reason code. Each category needs a different follow-up. An evidence correction can trigger review of related attributes. A transformation defect needs regression tests. A temporary exception needs an expiry date, owner, and a decision about whether the master must remain unchanged.
SKU feed quality control checklist
Use this checklist before a scheduled feed release and after any material mapping or product-data change.
- Confirm that every outbound row maps to a stable internal SKU and, where applicable, a controlled variant or parent relationship. Preserve channel IDs as mappings, not replacement identities.
- Check required and conditional fields against the current destination specification for the relevant channel and market. Record the specification version used in the release.
- Compare selected high-risk attributes against their approved evidence. For product ranges, review the exact SKU rather than borrowing values from a related model, image, or earlier production record.
- Normalise and compare units, controlled vocabulary, punctuation, and character encoding before flagging a difference. Retain the unnormalised source and target values in the incident log.
- Test transformations after any change to a rule, taxonomy mapping, export template, API configuration, or manual override. Include boundary values and variant cases that can expose a hidden rule defect.
- Inspect the generated payload, destination diagnostics, and a proportionate set of live product pages or structured-data outputs. A successful file generation does not prove that the destination rendered the intended values.
- Document exceptions with an owner, rationale, evidence link, scope, expiry or review date, and reversal action. Remove expired overrides rather than letting them become an undocumented second source of truth.
- Retain an auditable release record: master-data version, mapping version, payload timestamp, approver, channels, and rollback point. This makes a later discrepancy traceable without guessing which data was live.
GS1 frames data quality as an at-source discipline and describes its Data Quality Framework as providing best practices and assessment tools for data governance. [4] The checklist applies that principle operationally: find the defect close to the record or transformation that created it, then use downstream checks to confirm that the correction travelled correctly.
Make the workflow durable across channels
Maintain field-level approval state, evidence, effective date, owner, and last verified date. Version a changed product fact rather than overwriting history. If a fact is unknown, mark it internally as unconfirmed and use the retailer’s incomplete-data method; do not turn uncertainty into consumer-facing detail.
Version and test mappings like source data. State whether each field is direct, calculated, conditional, manual, or unsupported, and describe the transformation clearly. Store a condition separately from its value so later reviewers can distinguish an intentional omission from a gap.
Review the exception queue regularly for repeated fields, channels, overrides, and false positives. Fix the cause instead of merely lowering alerts. Track exceptions opened and closed with evidence, ageing, recurrence by root cause, and rollbacks as workflow-health signals, not customer or channel-performance claims.
Frequently asked questions
What counts as a feed conflict if the title is different on a retailer page?
It is a conflict if the difference changes an approved fact, variant relationship, supported configuration, or required channel rule. A shorter title is not automatically a conflict. Check the title policy, evidence, definitions, and destination limits. Document a permitted transformation; investigate an unsupported addition or lost variant property.
Should a team automatically accept the value shown on the live product page?
No. The live page is vital evidence but may be stale or channel-formatted. Google says on-page structured data and Merchant Center feeds can both provide product information, so either can reveal a mismatch. [3] Check the approved master and SKU evidence, then correct the source or transformation that caused the variance.
What should happen when supplier records and packaging appear to disagree?
Open an investigation, preserve both sources, and seek clarification from the product-data owner. Identify the SKU, revision, market, and unit of trade. Packaging and instructions may be relevant evidence but are not universal answers. If unresolved, do not infer a detail; follow the destination’s incomplete-data procedure.
Can automatic channel updates replace feed governance?
No. Google says automatic updates do not replace regular accurate feed updates and scopes them to certain price, availability, and condition mismatches. [2] Treat automation as a signal or contingency, not a substitute for ownership, identifier and variant logic, evidence, change control, or verification.
How long should a temporary exception remain in a feed?
Only as long as its documented exception permits. Record owner, scope, reason, evidence, dates, and removal condition; recheck before release. If permanent, move the logic into a reviewed mapping or master rule instead of keeping an untracked override.
Who should approve a correction to a product fact?
The approver needs authority over underlying evidence, not merely the upload. Usually a product or data owner confirms the fact and an integration or e-commerce owner confirms propagation. Obtain responsible review for retailer, importer, or destination-market matters; an operational correction is not legal or compliance approval.
Reliable product data conflict resolution is a repeatable discipline: identify the exact item, preserve the conflicting values, validate the governing evidence, correct the source or mapping, and verify every affected representation. It protects the quality of product communication without turning a channel rule or a convenience edit into a product claim.
For a B2B discussion about SKU-specific product-data handover, retailer mapping questions, or an evidence-led review workflow, email info@toywink.com. Please include the relevant SKU references, target channel, and fields in question; Toywink can discuss the project requirements without making assumptions beyond the approved records and applicable review.