Field note / Digital Systems & Commerce
The Hard Part of E-commerce Is Usually the Product Data
Supplier files become a systems problem when identifiers, variants, prices and stock disagree. A practical way to build a catalogue you can safely publish.
The instruction “just import the CSV” sounds like the last step of a small task. In practice, it can be the beginning of a much larger conversation about what a product record means.
Is that code the supplier’s identifier or the identifier used by the store? Does the price refer to one item or a pack? Is an empty stock field an unknown value, a temporary omission or a statement that nothing is available? Does a row describe a product family or a purchasable variation?
Working with catalogue imports, supplier information and marketplace operations has made the upstream data more interesting to me than the visible storefront. The examples below are illustrative and contain no supplier-specific records or private commercial figures. They describe the decisions I would make explicit before turning a file into published products.
Keep the incoming record intact
Preserve the source file and identify the import batch before transforming it. That gives a later error somewhere to point. If a product acquires the wrong dimension, I want to know whether the value came from the supplier, a transformation or a manual override.
This does not require a large platform. A small workflow can retain the original file, a timestamp, a mapping version and a report of what changed. The important property is traceability, not the size of the tooling.
Editing the only copy of the source until it resembles the destination schema is a poor starting point. That mixes correction with evidence. Keeping the original separate makes it possible to rerun an improved transformation and understand why the output differs.
A source record can also be incomplete without being useless. If a description is missing, I may still be able to identify the product and update a verified field. Whether partial updates are allowed should be a deliberate policy, with publication blocked when a required value is absent.
Identity comes before enrichment
A catalogue needs a stable way to distinguish a product from another product, a variation from its parent and a supplier offer from the item being sold. Those identities should not be collapsed into whichever column happens to be available first.
For an illustrative internal model, I might maintain an internal product ID, supplier-specific codes and channel-specific identifiers separately. A change in one supplier’s formatting should not automatically create a new product in every channel.
Leading zeros are a useful warning sign. An identifier that looks numeric is not necessarily a quantity. Treating it as a number can change its representation before any business rule runs. Preserve identifiers as text unless the identifier’s documented specification requires something else.
WooCommerce’s CSV importer documentation explains matching and update behavior, including the roles of product IDs and SKUs. Those rules are tool- and version-specific; an import should be checked against the installed version rather than inferred from a column name. My internal identity model should make that destination mapping explicit.
The cost of an identity mistake is easy to underestimate. A wrong description can be corrected. An update applied to the wrong product can change several otherwise valid fields while looking like a successful import.
Normalize meaning, not just formatting
Trimming spaces and standardizing column names are useful operations. They do not resolve ambiguity about units, packaging or ownership of a value.
Suppose a hypothetical file contains a width of 12, a price of 18.50 and a quantity of 6. Without definitions, those values are not ready for publication. The width needs a unit. The price needs a currency and a commercial meaning. The quantity could describe a pack, available stock or a minimum order.
I would model those meanings explicitly, even if the first implementation is a modest Python transformation. A normalized value should carry enough context to survive a change in channel or supplier.
A possible flow is:
source file → parsing → internal catalogue model
→ enrichment → validation → channel outputThe arrows represent responsibilities, not a requirement to deploy six services. In a small operation, one script with clear functions and a useful report may be more appropriate than a distributed pipeline.
Python’s CSV module provides readers and writers with support for dialect differences. It can handle the file format. It cannot decide whether two supplier categories mean the same thing or whether an omitted value should erase an existing description. Those remain application decisions.
Decide who owns each field
A recurring import becomes dangerous when every incoming value is allowed to overwrite every existing value. Supplier descriptions, edited storefront copy, derived prices and manually checked attributes may have different owners.
Field-level precedence needs to be documented. Perhaps supplier stock is authoritative for a specific availability calculation, while editorial descriptions are maintained internally. Perhaps an operator override remains in force until explicitly removed. The exact policy depends on the operation; the important point is that a new file should not silently decide it.
Blank values deserve their own rule. There is a difference between “the supplier did not provide this field” and “clear this field.” Treating both as an empty string can erase useful information during a routine update.
For derived prices, preserve the inputs and the rule version. A displayed selling price is easier to explain when the calculation can be traced. I would not embed confidential margin targets in a generic import report or expose them through channel payloads that do not need them.
This is also where product data becomes a collaboration problem. Someone has to resolve a disputed attribute, approve a description or explain an exception. Automation needs a destination for unresolved questions, not merely a way to skip them.
Validate before the catalogue becomes public
Structural checks and business checks answer different questions. A row can be valid CSV and still describe an impossible or incomplete product. A field can contain a decimal value and still use the wrong unit.
For a small import, useful checks might include duplicate internal identities, missing required attributes, inconsistent variation relationships and unexpected changes to important values. The checks should produce reasons a person can act on.
A dry-run report could distinguish new records, changed records, unchanged records and rejected records. For changes, I would show the previous and proposed values where doing so is safe. That makes a surprising mass update visible before it reaches a storefront.
Thresholds need context. A large change in stock might be entirely legitimate. A large change in a product dimension might indicate a unit conversion error. Thresholds work better as review triggers tied to a field’s meaning than as universal proof of bad data.
Testing a representative sample should include awkward cases: a variation, a missing optional value, a non-ASCII description, a quoted delimiter and a repeated record. The aim is to exercise the assumptions hidden by the cleanest row in the file.
Make repeat imports boring
A catalogue workflow rarely ends after one successful upload. Tomorrow’s file may contain the same products, corrections, new items or an incomplete subset. The import policy needs to say how each situation affects existing data.
An unchanged input should produce no unintended changes. A failed batch should leave a clear record of what was accepted and what was not. Re-running the whole file should not be the only recovery mechanism.
A missing product is particularly ambiguous. It may have been discontinued, temporarily omitted or excluded by a supplier export filter. Do not infer deletion from absence unless the source contract explicitly defines the file as a complete authoritative snapshot.
Images add another boundary. A valid URL does not prove that the asset is the correct image for the variation or that the operation has permission to use it. I would verify those concerns separately and avoid letting an image download failure conceal the state of the rest of the record.
The next challenge is distributing the normalized catalogue to several destinations. That is where marketplace adapters and reconciliation become useful.
The storefront inherits the quality of the model
A clean product page is the visible result of decisions made much earlier: identity, units, variant relationships, field ownership and update semantics. A storefront redesign cannot repair ambiguity in those decisions.
Start catalogue automation with a small, explainable transformation and a report someone can review. Expand it when repeated work justifies the change. The useful measure is whether the next import is understandable and recoverable, not whether the pipeline diagram looks sophisticated.
The real task is agreeing what its values mean, preserving that meaning through changes and refusing to publish what the system cannot yet explain.