Answer first
Retailers should treat an exception as a controlled decision, not a reason to improvise a listing. During onboarding, capture the SKU, marketplace, category, field, submitted value, validation message, source evidence, owner, decision, and review point in one record. Ask: Is the value missing, conflicting with an approved source, or in the wrong field or format? Does it require a decision from the brand, supplier, marketplace owner, or importer?
That discipline matters because a marketplace’s technical acceptance is not the same as a retailer’s approval of the information. Google states that inaccurate, missing, or conflicting product data can cause disapprovals, limited eligibility, incorrect displays, or other issues. Its examples include identifier, category, variant, image, and source-to-website conflicts. [1] An internal marketplace product data exception record gives the team a way to hold a questionable value away from routine publication while the right person establishes what can properly be supplied.
Start with a current, controlled baseline for each SKU. It should identify the version of the approved product record, the evidence behind each transferable field, the marketplace category being used, and any market-specific limitations. A value should not become “true” merely because it appears in an old feed, a spreadsheet, an image file, or a marketplace suggestion. If evidence is incomplete, log the absence plainly and route it for clarification. Do not fill a mandatory field with a plausible estimate, a copied value from another SKU, or promotional wording.
The working rule is simple: accept, correct, defer, escalate, or withdraw—each with a reason and evidence trail. The objective is a repeatable onboarding decision, not a superficial pass through a validation screen. It also keeps the commercial, product, content, and compliance roles clear when different marketplaces ask for different attributes.
Build one exception record around the SKU and channel
A reliable marketplace onboarding workflow begins before a file upload or portal entry. Make a row or ticket for every exception, using a permanent internal ID rather than a changing error code. Link it to the controlled SKU, channel, country or region, category, and listing attempt. This stops one field issue being mistaken for a catalogue-wide conclusion.
The minimum record should show what was submitted, what the marketplace requested or rejected, and what source supports the proposed response. Preserve a short plain-language description of the discrepancy; copy the diagnostic wording exactly where the platform provides it; and retain the date, data version, and attachments or links used in review. A screenshot can be useful context, but it should not replace the exact rule, field name, or source record.
Keep the reported problem separate from the remedy. “Attribute conflicts with an existing catalogue value” is a problem statement; “accept existing catalogue value” is an evidence-led decision. Amazon says product-attribute errors can arise when submitted attributes conflict with an existing listing and directs sellers to examine the attribute. [3] Verify identity and relationship before choosing to align, challenge, or create a distinct listing.
A practical record has four evidence columns: identity, product fact, channel rule, and decision authority. They identify the SKU, applicable source, marketplace requirement, and person entitled to approve the response. This stops an error message silently becoming product evidence.
For supplied goods, every value remains conditional on the exact SKU, approved sample, current instructions, packaging, supplier records, retailer rules, importer obligations, and destination-market review. Do not turn an unverified feature, language version, bundled item, label statement, or regulatory position into public copy.
Classify the exception before assigning a fix
Classification makes queues manageable because it identifies the evidence and authority needed. Use a small set of plain classes and allow more than one where appropriate. The aim is comparable cases, not forcing every message into one label.
| Exception class | Typical signal | First review action | Resolution owner or route |
|---|---|---|---|
| Missing required value | A required field is blank or rejected as incomplete | Check whether a current approved source contains the requested fact | Data owner; escalate if evidence is absent |
| Format or taxonomy mismatch | The value exists but does not meet the channel’s permitted format, unit, category, or vocabulary | Compare the approved value with the marketplace field rule; do not alter the underlying fact | Channel data specialist with product-data owner |
| Identity or relationship conflict | Identifier, parent-child relationship, or SKU appears linked to another product | Pause the change and confirm the exact product identity and relationship | Catalogue owner; marketplace support where needed |
| Content or asset discrepancy | Submitted title, image, description, or attribute does not match the controlled source | Compare versions and remove unsupported content from the proposed correction | Content owner with product-data owner |
| Permission or policy route | The marketplace requires an authorization, application, or policy-specific step | Preserve the message and send it to the authorised account or policy owner | Marketplace account owner or designated reviewer |
This classification turns a retailer data exception review into a sequence of decisions rather than a general request to “fix the listing.” It also prevents a data coordinator from taking responsibility for decisions that belong to product ownership, account permissions, or destination-market review.
Do not assume a field is optional because another marketplace permits it. eBay says item specifics vary by product, can be required for new or revised listings, and can be added over time. [5] Google also marks attributes as required or conditional by product or country. [1] Record the applicable category and market at review.
Verify the fact, not just the field syntax
A valid format is not evidence that a value is accurate. Check that the source applies to the exact SKU and version, then confirm that the approved fact can be represented in the requested field without adding meaning.
Begin with identity. Match the internal SKU, relevant identifier, and version to the product record. Amazon notes that a product-ID error may mean that the identifier entered is associated with a different product or that a new detail page is being created for an already listed product; it advises checking the exact GTIN on the barcode and reviewing the suggested match. [3] That is a useful operational principle for any channel: a proposed match is a prompt for investigation, not proof that two records describe the same sellable item.
Then inspect the fact source. Prefer the current approved product record. If it does not answer the marketplace’s question, mark the field unsupported. Request clarification with the precise field, rule, SKU version, submitted value, evidence needed, and decision required. Do not ask an open-ended question that cannot be audited.
A SKU listing data issue may also be a version problem. A title or image can be accurate for a previous packaging revision yet unsupported for the current item. State which version was checked and which record controls the response. If the marketplace displays a value from a different source than the feed, document the source-to-display mismatch instead of repeatedly overwriting the feed without understanding the cause.
Google says product-level issues can arise when supplied data does not match website information, fails the specification, or conflicts with policy requirements; they affect individual products rather than the entire account. [2] Fix or hold the individual SKU unless the same gap, mapping defect, or rule change affects a group of records.
Need a B2B evidence-led review of a marketplace data question for a Toywink SKU? Email Toywink’s team with the SKU, channel, field, and current evidence source. The team can discuss product information for the exact SKU; publication and destination-market decisions remain subject to the applicable retailer rules, importer obligations, and review.
Route each decision to the right owner
Not every exception should be fixed by the first person who sees it. State who can propose a correction, confirm a fact, approve public wording, take marketplace-account action, and close the record. In small teams one person can hold several roles, but the authority must remain explicit.
A data coordinator can normalize an allowed format after confirming the source; a product owner or supplier can clarify a fact; and a content owner can remove unsupported wording. Route destination-specific questions to the appropriate importer, legal, or compliance reviewer. No role should imply approval where evidence or authority is absent.
Escalate when an identifier may belong to another product, a variant relationship is unclear, the marketplace requests an unsupported value, or an existing catalogue value conflicts with the controlled record. Amazon says a SKU already associated with a different product should be replaced with a unique SKU through the appropriate process. [3] Do not reuse a relationship merely to clear an error.
For each product field exception, set a response standard: accept as submitted, correct from an approved source, supply an approved alternative representation, hold pending evidence, escalate for channel resolution, or remove/withdraw the proposed content. Capture why. A reviewer reading the record later should be able to distinguish a confirmed correction from a temporary hold and from a request that requires an external decision.
Set e-commerce onboarding controls that survive change
An e-commerce onboarding control is a check that prevents a known exception moving forward without evidence, ownership, or a recorded decision. It needs a trigger, owner, input, action, output, and recheck point.
Use three layers. Preventive controls include field mapping, vocabulary checks, evidence flags, and version confirmation. Detective controls include diagnostics, rejected-row reports, source-to-listing comparison, and a review queue. Corrective controls require a decision record, approved resubmission, hold, or escalation. Apply them across portal, file, integration, and partner routes.
Google advises correcting and re-uploading product data for product-level issues, with issue-specific guidance in its interface. [2] Treat that as a controlled change: retain before-and-after values, the addressed rule or message, approving role, and resulting status. A successful upload does not erase its basis.
Version the mapping as well as the product data. When a marketplace adds a field, changes a category rule, or alters an allowed value set, record the effective date and the affected SKUs. eBay notes that item-specific requirements may be added based on buyer search trends and surfaces “Required soon” notices for affected listings. [5] A scheduled check of channel requirement changes is therefore more dependable than discovering a change only when a listing fails.
GS1 describes its Data Quality Framework as an industry-developed guide for data-quality improvement and a continuously improving cycle for master data, with governance, management, assessment, self-assessment, and KPI resources. [4] Retailers can apply that direction pragmatically: trend recurring exceptions, correct the mapping or source process that produced them, and review whether the control reduced avoidable rework. Do not use a KPI merely to push records through; use it to identify where evidence and ownership break down.
Marketplace exception-control checklist
Use this checklist for each new exception and again before closure:
- Confirm the exact SKU, product version, channel, country or region, category, and listing route.
- Copy the marketplace field name, rule, message, and time of detection into the record.
- Classify the issue as missing data, format/taxonomy mismatch, identity conflict, content discrepancy, or permission/policy route.
- Locate the current approved source and state whether it applies to the exact SKU and version.
- Compare the proposed value with the source; do not add features, claims, variants, or interpretation that the source does not establish.
- Name the accountable decision owner and, where needed, the escalation route.
- Choose and record the action: accept, correct, approved alternative, hold, escalate, or withdraw.
- Submit only the approved correction or documented channel action, then retain the submission reference.
- Check the resulting status and determine whether a review, appeal, or further correction is required under the marketplace’s process.
- Close only when the result and evidence are recorded; reopen if a later source, SKU version, or marketplace rule changes the basis.
The checklist is deliberately evidence-led. It does not declare any SKU eligible for a market, compliant, available, or approved by a marketplace. Those conclusions, where relevant, depend on the applicable records, rules, authorised decisions, and destination-market review.
Measure patterns without confusing speed with quality
Use a compact scorecard: open records by class, age, marketplace, field, source, and owner; plus resolution route and repeated messages. It shows whether a recurring problem calls for a better source or mapping rather than repeated row-by-row fixes.
Test record quality through sampling. Another colleague should be able to see the submitted value, evidence, decision owner, and outcome without reopening old email threads. Separate simple formatting corrections from evidence gaps, identity conflicts, and permission routes; closure time alone can reward unsupported assumptions.
FAQs
What should count as a product data exception?
Count any condition that prevents the team from submitting, retaining, or confidently confirming a marketplace value against its controlled source and the relevant channel rule. It may be a blank required field, invalid format, category mismatch, conflicting identifier, unclear variant relationship, unsupported wording, rejected asset, or account-permission message. The key is to record the exact condition and not relabel every platform alert as a product defect.
Should a retailer copy a marketplace’s existing catalogue value to clear an error?
Only after confirming that the existing value belongs to the exact product and is supported for the retailer’s listing route. Amazon says matching conflicts can occur where an attribute conflicts with an existing listing, and its guidance offers actions that may align a value with the existing record. [3] That platform option does not remove the retailer’s responsibility to verify the identity, current SKU version, and authority for its own data decision.
When is an issue limited to one SKU rather than a wider feed problem?
Begin with the marketplace’s scope and then test for repetition. Google describes product-level issues as affecting individual products and account-level issues as affecting all products. [2] A single record can be contained when the evidence shows an isolated source or entry mistake. Escalate to a feed or mapping investigation when the same field, source, category mapping, or validation message appears across a defined group of SKUs.
Can a blank field be filled with an estimated value to finish onboarding?
No. A blank field is an evidence or rule question, not permission to estimate. Check whether the marketplace permits a truthful alternative representation, whether a current approved source can answer the field, or whether the listing should remain held while the accountable owner clarifies it. Record the chosen route. This protects the team from turning an operational deadline into unsupported public information.
How often should teams review marketplace requirements?
Set a recurring review that fits the channels and onboarding volume, and add a trigger for relevant diagnostic or category changes. Requirements can differ by category and market, and eBay says it can add required item specifics over time. [5] The review should update the field map, validation rules, affected-SKU list, and any open exception records rather than merely circulate a notice.
Who should close an exception record?
The record owner can prepare closure, but closure should confirm both the channel outcome and the evidence trail. The accountable owner for the relevant decision should be identifiable, especially where product facts, public wording, account permissions, or destination-market questions were involved. If the channel accepts a value but the evidence remains unresolved, keep the internal record open or mark it held; technical acceptance alone is not a substitute for governance.
Keep onboarding decisions explainable
Marketplace onboarding becomes more manageable when every exception has a stable record, a clear class, a verified basis, a named owner, and a controlled outcome. Use the exception queue to improve the source record and field mapping over time, while keeping uncertain values out of routine publication. The result is not a promise that every channel will accept every SKU; it is an accountable way for B2B teams to decide what they can support, what they must clarify, and who should act next.
For a B2B discussion about product information for a specific Toywink SKU and marketplace field, email info@toywink.com. Please include the SKU, marketplace, field, and available evidence so the inquiry can be routed appropriately.