Product Catalog Import Checklist: Resolve Data Conflicts

A recognized column is not a verified fact. An importer can recognize a price field without knowing which price is right.

Use this product catalog import checklist to decide which values can support editorial claims, which need a source, and which records should stay out of the import. A catalog does not need every cell filled. It needs clear boundaries around what is known.

That distinction matters when supplier exports and internal notes disagree. The editor should not have to turn an unexplained blank or conflicting row into a confident recommendation.

Define import readiness at the claim level

A structurally recognizable field has a label and values that a system can interpret. A factually reliable value also has a clear meaning, an identifiable product or variant, and a suitable source.

For example, a column called capacity may contain perfectly readable numbers. Those numbers remain unsafe for comparison if some mean internal volume and others mean maximum supported weight.

Separate problems into three groups:

• Structural problems: repeated identifiers, inconsistent field organization, or records that cannot be matched reliably to an item.
• Factual conflicts: sources disagree about the same property under the same conditions.
• Harmless gaps: an optional value is unknown, but the remaining facts still support the intended article.

The distinction depends on the assignment. Missing dimensions might not prevent a category overview, but they do prevent a recommendation that a product fits a particular shelf.

For the broader modeling decision, see why a better content engine starts with the catalog. Here, the task is narrower: decide what is safe to hand over before import.

Copy the pre-import worksheet

Use the following as a manual operator worksheet, not a built-in NichePressa screen. Copy it into your working document or spreadsheet and replace the illustrative entries with actual records, source references, dates, and named owners.

All products, identifiers, source documents, dates, and values in the examples below are fictional teaching examples. The worksheet columns are suggested working fields, not a required import schema.

Record the source precisely enough that another editor can find the same evidence: document name or location, supplier record reference, variant, and relevant date.

Keep the observation date separate from the effective date. “Downloaded on November 4” does not establish that a price became effective on November 4.

Use explicit manual decisions:

• Correct: evidence supports a replacement value.
• Preserve unknown: the fact is unavailable; no replacement is justified.
• Request a source: someone must obtain evidence before the claim can be used.
• Exclude a claim: other facts remain usable, but this assertion does not.
• Hold a record: identity or a critical relationship is too uncertain for editorial use.

Assign an owner to unresolved issues. A note saying “check later” without responsibility leaves the same decision waiting for the next editor.

Missing values: separate unknown, zero, false, and not applicable

These states are not interchangeable:

• Unknown: the value has not been established.
• Zero: the quantity is known to be zero.
• False: a defined yes-or-no property is known not to hold.
• Not applicable: the property does not apply to that item.

A blank cell tells you none of those things by itself. It may reflect an omitted export field, an unanswered supplier question, or a property that was never collected.

Illustrative example: the fictional BX-20 storage box has a blank maximum-load field. That does not mean its maximum load is zero. Nor does it justify inferring a load rating from its volume, material, or another box.

Operator action: preserve the value as unknown and request the relevant specification if load matters to the article. Exclude load-bearing recommendations until evidence arrives.

An optional unknown need not block the record. The box may still support a description based on its established internal volume and lid variant. But if the brief asks for boxes suitable for a specified load, that missing fact prevents its inclusion in that comparison.

Document these meanings before choosing a file representation. The supplied capability information does not establish how particular blank or null markers are handled, so do not assume a serialization convention is supported.

Inconsistent units and unclear fields: define the quantity first

Unit normalization is useful only after you know what was measured.

For each comparison field, establish:

• The measured quantity, such as internal volume or external height.
• The unit.
• The applicable variant.
• Relevant measurement conditions or qualifiers.
• Whether the value is measured, nominal, or a rated maximum, where the source distinguishes them.

Illustrative mixed-unit example: two entries for the same confirmed BX-20 variant list internal volume as 20 L and 20,000 mL.

The conversion is:

20,000 mL × (1 L / 1,000 mL) = 20 L

These values agree after conversion. This is a unit conversion, not a new measurement or an estimate of usable space. Preserve the original source value alongside the normalized value in your working records.

Operator action: confirm both entries describe internal volume for the same variant, then normalize them to the chosen unit.

Illustrative ambiguous-field example: an internal note says size: 40. The number has no established unit, dimension, or dimension order.

Operator action: request a definition and source. Do not relabel it as a 40 cm length because that interpretation seems plausible. Exclude shelf-fit and dimensional comparisons until the meaning is established.

Likewise, capacity: 20 cannot safely become “holds 20 kg” or “20 L.” If the quantity is unclear, conversion is not the next step. Definition is.

Duplicate identifiers: establish variant identity before merging

A repeated identifier can indicate an accidental duplicate, an update to an existing record, or distinct variants sharing an insufficiently scoped ID.

First establish what an identifier identifies. Is it unique within one supplier export, across the combined catalog, or only within a product family? Keep source identity available when combining files.

Illustrative example: two rows named “BX-20 storage box” share BX-20. One lists a flat lid; the other lists a hinged lid.

Matching names do not justify merging them. Neither does the shared identifier prove that one row is wrong.

Operator action:

1. Check source-specific identifiers and variant attributes.
2. Establish whether the rows describe the same sellable item.
3. If they are distinct variants, assign or map stable internal identities and retain their source references.
4. If they describe one item, reconcile field differences before consolidating.
5. Hold the affected records if identity remains uncertain.

Do not resolve the collision merely by appending a suffix. That makes identifiers distinct without establishing what the records represent.

The downstream consequence is substantial: an unresolved merge could attach one variant’s dimensions, price, or compatibility to another. When identity is uncertain, holding the record is safer than excluding only one field.

Conflicting prices: align the buying context

Two different prices are not necessarily contradictory. They may describe different quantities, markets, variants, or dates.

Before choosing a value, establish:

• Currency, explicitly rather than through an ambiguous symbol.
• Pack or billing basis, such as each, a pair, monthly, or annual.
• Exact variant.
• Effective date, distinct from retrieval date.
• Source authority for the intended purchasing context.
• Any relevant tax, shipping, promotion, or eligibility conditions available in the source.

Illustrative example: USD 24 for one flat-lid BX-20 and USD 44 for a pair are different offers, not conflicting unit prices.

For comparison only:

USD 44 ÷ 2 boxes = USD 22 per box

That calculated unit price does not establish that one box can be purchased for USD 22. Preserve the pair requirement.

Now suppose a supplier list says USD 24 each and a reseller list says USD 22 each for the same variant, but neither establishes an effective date. Choosing USD 22 because it is lower would manufacture certainty.

Operator action: identify which source governs the purchase being described and request current evidence with the necessary context. Until then, exclude exact-price and “cheapest” claims.

Authority is contextual. A supplier list may govern direct purchases; it does not necessarily establish a reseller’s current offer. “Use the newest file” is also insufficient if its price context differs.

Work through a small illustrative catalog

Apply the worksheet to the fictional BX-20 records as a set, rather than fixing cells independently.

Suppose the illustrative variant sheet resolves the flat-lid and hinged-lid rows as distinct products. It also confirms that the flat-lid version’s internal volume is 20 L. The maximum load remains undocumented, size: 40 remains unexplained, and neither price source supplies an effective date.

The manual decisions are:

• Flat-lid record: usable under a distinct internal identity, with its confirmed internal-volume claim.
• Maximum load: leave unknown and request a source. Exclude load recommendations.
• Size: exclude dimensional and shelf-fit claims until the field is defined.
• Price: exclude current-price and cheapest-option claims pending authoritative context.
• Hinged-lid record: keep separate. If its remaining source references cannot reliably identify it, hold that record.

The result is proceed with exclusions for the identifiable flat-lid record, not blanket approval of the merged file.

A statement about its confirmed internal volume is supportable. A recommendation that it fits a particular shelf, supports a particular load, or is the cheapest option is not.

Keep the unresolved evidence in the working worksheet. For the import copy, include only usable claim-bearing data and supported limitations. Do not rely on a buried “unverified” note to neutralize a contradictory value elsewhere in the input. See what to keep out of AI prompts for that input-boundary decision.

Hand off to Catalog Import & Schema Detection

After preparation, Catalog Import & Schema Detection is the handoff point for making the structured catalog usable for content work.

The supplied capability description supports CSV, JSON, and TypeScript catalog files. It describes scanning the uploaded file, reading available fields, and suggesting useful fields for articles, including product names, specs, categories, pricing notes, strengths, tradeoffs, and best-use cases.

It also describes reviewing, renaming, hiding, or prioritizing those fields before planning and generation.

That is field selection, not factual validation. The capability description does not establish automatic deduplication, unit normalization, source ranking, price-conflict resolution, or claim blocking. Do not delegate those worksheet decisions to detection.

Exact upload controls and handling of blanks, duplicate identifiers, and conflicting fields are not established by the supplied material. Confirm those behaviors before relying on them; this guide does not assume them.

The narrower benefit is still useful: you can review which prepared fields should inform content without manually rebuilding the catalog. Clear fields and consistent data make that handoff stronger.

Preparation also does not replace editorial review. The next responsibility remains reviewing whether the resulting claims are fit to publish.

Make the release decision

Run this manual release sequence on a small sample first, then apply it to the intended import set. These are operator actions, not automated product enforcement.

1. 1Resolve identity: establish identifier scope and separate distinct variants.
2. 2Define field meanings and units: confirm quantities, measurement basis, and price context.
3. 3Record unresolved facts: preserve unknowns, source references, dates, and owners.
4. 4Assign exclusions or holds: remove unsupported claims from the import copy and withhold records whose identity remains uncertain.
5. 5Release only the usable records for import, retaining the worksheet as the decision record.

Choose the release status according to the claims the intended article requires:

• Proceed: identity is reliable and the relevant claims have adequate definitions, context, and sources.
• Proceed with exclusions: useful claims remain, but specific fields or comparisons are unsupported. Make those exclusions explicit in the import copy and content briefs.
• Hold affected records: identity cannot be resolved, facts may belong to different variants, or missing evidence prevents the record from supporting the intended comparison.

Start with a small catalog sample and this worksheet before exploring NichePressa’s catalog import workflow. Release what the evidence supports—not every row that happens to parse.