For retailers, wholesalers and brands with more than a few hundred lines

Product Data Integration: One Version of Every Product

Product information starts life in an ERP as a code, a cost and a description written for a warehouse. By the time it reaches a customer it needs a name people search for, accurate attributes, compliant claims, several images, channel specific categories and a price. Most businesses assemble that in spreadsheets, and most of the resulting problems trace straight back to it.

The symptom is familiar: the same product described three ways across the website, a marketplace and a trade catalogue, images that are current in one place and two seasons old in another, and a range review that takes a month because nobody can say authoritatively what the range is. This page covers where product data should live, how it should move, and what Australian law expects of every claim you publish.

Book a Product Data Call (03) 9003 0111

Realistic ROI

1 owner per field

Is the whole discipline in a sentence

Cost and code from the ERP, content from marketing, category from the channel team

40 to 120 fields

Per product in a typical retail range

Rough spread across categories; specialised ranges such as electrical or apparel sit at the top

Every channel differs

On categories, attributes and image rules

Assume no reuse of taxonomy between your store, each marketplace and each reseller

Weeks 4 to 10

To get a first publishing pipeline live

Longer where the current range has to be de duplicated before anything can be published

Four Things That Decide Whether Product Data Stays Clean

Product data does not decay for technical reasons. It decays because of four decisions that are usually never made explicitly.

Different fields have different owners

Nobody owns a product. People own fields. The ERP owns the code, the cost, the supplier and the pack configuration. Marketing owns the customer facing name, the copy and the images. Merchandising owns the category and the range status. Compliance owns the safety and origin claims. Write that down field by field and most product data arguments disappear, because they were really arguments about who was allowed to change what.

Enrichment needs a state, not a mood

A product moves through defined states: created in the ERP, enriched with content, images attached, claims checked, approved, published to selected channels, and eventually discontinued. If those states are not explicit, the practical definition of ready becomes whoever pressed publish, and half published products with no images or filler copy reach customers. The states also give you a usable answer to how many lines are actually ready to sell.

Every channel wants the same product differently

Your own store, each marketplace, a reseller catalogue and a print sheet all want different categories, different attribute names, different image dimensions, different title lengths and different mandatory fields. Maintaining a separate version of the product for each is how the data diverges. Maintain one enriched record and transform it per channel at publishing time, so a corrected description reaches everywhere from a single edit.

Published claims are legal statements

Under the Australian Consumer Law, a product claim on your website is a representation to the consumer, and misleading representations attract liability regardless of whether a supplier gave you the wrong text. Country of origin wording, safety and standards claims, warranty statements and comparative pricing all need a source and a review step. Product data governance is not administrative tidiness here. It is the mechanism by which you can show where a claim came from.

How Product Data Should Move

Six flows, in a deliberate order. Most of the pain in product data comes from running them in the wrong sequence.

ERP outbound

Creation in the operational system

A new line is created once, in the system that will buy it, cost it and count it, with its code, supplier, pack configuration, tax treatment and barcode number. Everything downstream keys on that code, so it must be stable. Products created first in the website and retrofitted to the ERP later are the most common origin of duplicate records that nobody can safely merge.

Content added

Enrichment and attributes

Customer facing names, descriptions, features, specifications and searchable attributes are added against the record rather than against a channel. Attributes need a controlled vocabulary, so colour is chosen from a list rather than typed, otherwise you end up with navy, Navy and midnight blue as three separate filter values and a site search that finds none of them.

Assets linked

Images and documents

Photography, line drawings, safety data sheets, installation guides and warranty documents linked to the product rather than emailed around. Each channel has its own rules on dimensions, backgrounds, file size and how many images it accepts, so the library holds a master asset and the publishing step derives what each channel needs.

Mapped taxonomy

Categorisation per channel

Your internal category structure is not the one your store menu uses, and neither is the one a marketplace demands. Hold your own taxonomy once and maintain a mapping to each channel’s tree. Category is what decides whether a marketplace listing is findable at all, so a bad mapping is invisible on your side and expensive on theirs.

Gate before publish

Approval and compliance check

A defined step where claims, origin wording, mandatory safety information and any regulated attribute are checked and recorded as checked, with the source of the claim retained. This is the step everyone wants to skip during a busy range launch and the one that matters if a claim is later challenged.

Out to channels

Publishing and syndication

The approved record is transformed into what each channel expects and sent: your online store, each marketplace, reseller feeds, comparison feeds and any trade catalogue. Publishing should be repeatable and logged, so you can answer what was live on a given date, and it should handle removal as reliably as it handles addition.

Product Data Before and After

Task	Traditional	Managed Product Data	Notes
New product to market	A spreadsheet emailed between four people	A record moving through defined states	The status question stops being a meeting and becomes a filter anybody can run.
Correcting a description	Edited on the site, stale elsewhere	Edited once, republished everywhere	The most obvious win, and the one that pays back on every range review.
Listing on a new marketplace	A fresh export built by hand	A new channel mapping on existing data	Effort moves from per product to per channel, which is the entire point.
Image refresh for a season	Uploaded per channel, inconsistently	Master asset replaced, derived per channel	Channel specific dimension and background rules handled at publishing time.
Supplier changes a specification	Noticed by a customer complaint	Flagged for review on the next feed	Supplier feeds should propose changes for approval rather than overwrite silently.
Discontinuing a line	Removed from some channels, not others	Withdrawn everywhere by status change	Orphaned listings on marketplaces generate cancellations and damage seller metrics.
Proving what a claim was based on	A search through old emails	Source and approver recorded on the record	Directly relevant if a representation is ever challenged under Australian Consumer Law.
Search and filtering on your own site	Free text attributes, unusable filters	Controlled vocabulary, working facets	Filter quality is largely a data problem wearing a front end costume.

Where Product Data Projects Go Wrong

Buying a tool before agreeing ownership

A product information tool is a filing cabinet with rules. If nobody has decided who owns which field, the tool becomes a second place to store the same disagreement, and within a year people are back in spreadsheets because the tool is not trusted. Spend the first fortnight on a field level ownership map and a definition of what ready to publish means. That artefact is useful even if you never buy anything.

Migrating the mess rather than fixing it

Most ranges contain duplicates created when the same product was set up twice, obsolete lines that were never marked as such, and inconsistent attribute values. Importing all of that into a new system preserves the problem and adds a licence fee. De duplicate and standardise the top selling portion of the range first, publish that properly, and work down. A partial range that is trustworthy beats a complete range that is not.

Supplier content accepted without review

Brand supplied copy, images and specifications save enormous effort and carry risk with them. Claims about performance, compatibility, origin or compliance become your representations once you publish them, and under Australian Consumer Law you cannot simply point at the supplier. Treat incoming supplier feeds as proposals: automatically flag changed claims for a human to accept, and keep the record of what was accepted and by whom.

Country of origin and mandatory information treated as copy

Origin claims, standards compliance statements, mandatory safety information and energy or water rating details are regulated, and for many categories the wording is prescribed rather than descriptive. These belong in structured fields with validation rather than inside a paragraph of marketing text, so they can be checked, reported on and corrected across the range in one operation when a rule changes.

Publishing that only ever adds

Plenty of integrations push new and changed products faultlessly and quietly fail to withdraw anything. The result is discontinued lines still listed on marketplaces, orders you cannot fulfil, cancellations and a slow decline in your seller ratings. Removal, suspension and reactivation need to be as reliable and as monitored as creation, and a periodic reconciliation should compare what each channel holds against what you intended to publish.

No record of what was published when

When a pricing or claim question arises weeks later, the useful answer is what the page actually said on the day. Without publishing logs you are reconstructing from memory and cached screenshots. Log every publish with the payload sent and the channel’s response, keep it for a sensible period, and you convert an argument into a lookup.

How Yes AI Approaches Product Data

Field level ownership mapped first

We work through your range with the people who maintain it and produce a map of which system and which team owns each field, plus a definition of ready to publish. It is the cheapest part of the project and the part that determines whether the result survives.

A pipeline, not a one off import

Creation, enrichment, approval and publishing built as a repeatable flow on a managed cloud automation layer we operate, so the second range launch is faster than the first rather than the same amount of manual work again.

Compliance built into the gate

Regulated attributes held as structured fields with validation, claim sources recorded, and an approval step that is enforced rather than encouraged. When a rule changes you can find every affected line in one query.

Honest advice on tooling

Plenty of Australian businesses do not need a dedicated product information platform. If your ERP or store can hold the enriched record adequately and the real gap is publishing and governance, we will say so and build that instead of adding a licence.

From Spreadsheets to a Publishing Pipeline

Five steps. A first channel is normally publishing from the new pipeline within two to three months.

Audit the range and the channels

How many live lines you actually have, how many are duplicates or dead, which channels you publish to, and what each channel demands in categories, attributes and images.

Agree ownership and states

A field level ownership map, a controlled vocabulary for the attributes that matter to search and filtering, and an explicit definition of the states a product passes through before it can be sold.

Clean the priority range

De duplicate, standardise attribute values and fill gaps for the lines that carry the majority of revenue first, so the pipeline goes live against data that is worth publishing.

Build the publishing flows

Channel mappings, image derivation, approval gates and withdrawal handling, built against official interfaces with logging of every payload sent and every response received.

Reconcile and extend

A periodic comparison of what each channel holds against what you intended, alerting on divergence, then the remaining range and any new channels brought onto the same pipeline.

FAQ

What is product information management and do we need it?

Product information management is the practice of holding one authoritative version of each product’s content and attributes, moving it through enrichment and approval, and publishing it to every channel that needs it. Whether you need a dedicated tool is a separate question from whether you need the practice. A business with two hundred stable lines and one sales channel can run the practice inside its existing systems. A business with several thousand lines, seasonal turnover and four channels usually cannot, and the spreadsheets become the bottleneck on how fast it can launch anything.

Should product data live in the ERP or somewhere else?

Split by field rather than by system. Operational data belongs in the ERP: the code, cost, supplier, pack configuration, tax treatment and barcode. Customer facing content is a poor fit for most ERP systems because it needs rich text, many images, per channel variations and an approval workflow that ERP product records rarely support well. The workable pattern is the ERP as the origin of the record and the owner of operational fields, with content held wherever it can be properly managed, and the two joined on a stable product code.

How do we stop the same product existing three times?

By making creation single threaded and matching strict. One system creates products and everything else receives them, so a line cannot be born in the website and then invented again in the ERP. Matching should be on a stable identifier such as your internal code or the barcode number, never on the product name, because names get edited. For the duplicates you already have, resolve them deliberately rather than by bulk rule: pick a survivor, redirect the retired record, and keep a record of the merge, because order history and stock movements are attached to both.

What does the Australian Consumer Law require of product content?

In broad terms it prohibits misleading or deceptive conduct and false or misleading representations about goods, which includes claims about performance, composition, origin, standards compliance, availability and price. The practical consequences for product data are that a claim needs a traceable source, that origin wording is regulated and should be held as a structured field rather than free text, that comparative or was and now pricing has to reflect genuine prior prices, and that you cannot fully transfer responsibility to a supplier who gave you the text. This is general information rather than legal advice, and regulated categories often carry additional specific obligations.

How do we handle supplier provided product content?

Take it gratefully and treat it as a proposal rather than a fact. Bring supplier feeds in automatically, compare them against what you currently hold, and route changes to descriptive or claim bearing fields to a person for acceptance while letting purely operational changes such as pack dimensions flow through. Keep the record of what was accepted, when and by whom. This gives you the labour saving without inheriting whatever the supplier’s marketing team wrote for a different market.

Do we need a separate digital asset library for images?

Only if the volume warrants it. What you always need is that images are attached to the product record rather than living in shared drives and email threads, that there is one master file per shot, and that channel specific versions are derived at publishing time rather than maintained separately. A dedicated asset platform earns its place when you have large volumes of photography, rights or usage periods to track, or several teams producing assets. Below that, structured storage plus a disciplined naming and linking convention does the job.

How long does it take to get product data under control?

Getting a publishing pipeline live for a priority portion of the range usually takes between one and three months. Getting the whole range clean takes longer and should be treated as ongoing work rather than a project with an end date, because new lines and supplier changes arrive continuously. The most useful thing you can do early is sequence by revenue: clean and publish properly the lines that earn the money, prove the pipeline works, and let the long tail follow. Attempting the entire range before publishing anything is the reliable way to stall.

One Product Record, Published Everywhere

Book a call. We audit your range and your channels, map field ownership, and give you a priced plan. The audit and the ownership map are yours either way.