Your product records say different things depending on the tool you open. The ERP shows one weight, the online shop shows another, and the feed sent to Google has a third version of the colour. Nobody lied: each tool was filled in by someone, at some point, with good intentions. Product master data is meant to fix this, but not in the way people often imagine.
I run projects where an ERP, a website and sometimes marketing tools have to share the same products. My view, after several integrations, is that the problem is almost never the tool. It is that nobody ever decided, field by field, which version is the reference. Here is how I go about it, and where the method stops.
01What product master data is, and what it is not
Product master data is the place where the trusted version of each core product field lives: its reference, name, unit, dimensions and variants. The other tools read that version; they do not reinvent it. The discipline that manages it is called MDM (master data management).
It is not necessarily software. In a small business, the reference system can perfectly well be the ERP, as long as everyone accepts that the ERP wins when there is a disagreement. Nor is it a one-off clean-up: a tidy file on Monday is messy again by Friday if two tools are still allowed to write the same field.
A video from IBM Technology sums up the stakes well, using a customer rather than a product: master data management is about establishing a single view of a person, place or thing. In it, the same customer exists under four names in four applications. IBM sells MDM tools, which is worth knowing as you watch, but the example holds. Swap the customer for a product and you have the situation of many online shops.
02Three fields that must be the reference: the SKU, the unit, the variant
Not all product data is equal. Three fields break everything when they diverge.
The SKU
The reference (the SKU) is the key that ties everything else together. The Google Merchant Center documentation is very clear on this: the ID must be unique, stay the same when you update your data and be identical across countries and languages. The same page says a guessed or incorrect GTIN gets the product disapproved. An empty field is better than a wrong one.
The unit
A product bought by the carton and sold individually has two units, and that is fine. What is not fine is letting each tool assume its own. Odoo offers a good model: each category of units of measure has a reference unit, and the software only converts between units in the same category. Dozens when buying, units in stock: the conversion is explicit and automatic.
The variant
A T-shirt in four colours and five sizes means twenty variants in Odoo, each with its own SKU, stock and price. On the search side, Google Search Central asks for the same thing in structured data: a unique ID per variant and a group ID, the parent SKU, with shared properties such as the brand held at group level. If your ERP and your website do not split variants the same way, no synchronisation will hold.
03What I have seen break when the reference was not explicit
On one project, two tools exchanged dimensions. One worked in centimetres, the other in millimetres, and nothing in the file said so. The result was not a small error on one record: a whole render came out distorted. It took us a while to understand, because each tool, taken on its own, was consistent. Since then I apply a simple rule: reference data must be explicit. A dimension without its unit written next to it is not data, it is a guessing game.
On an integration between an ERP and an online shop, the specification changed at almost every meeting. I kept it moving version by version, so everyone was talking about the same document. It is the same idea applied to paper: one version is the reference, and everyone knows which one. I wrote about that work in the article on the ERP and e-commerce integration specification.
At Moonworkers, my own company, the logic goes further for payroll calculations. An oracle written from HMRC's texts serves as the reference, and we replay the calculations against it. It found four one-penny errors caused by a rounding rule. That is not product master data, but it is the same reflex: write down somewhere what is true, then compare everything else with it. The method is set out in the article on testing a calculation with an oracle.
And for this blog, the article calendar is a versioned file that acts as the reference: status, planned date, keyword. The publishing tool reads it and keeps no copy of its own. When I change a date, I change it in one place.
04Building a first product reference system in five steps
This is the order I follow. For a catalogue of reasonable size it takes a few days of work, and it requires no purchase.
1. List the fields and the tools
A simple table: in rows, the product fields (reference, name, description, sales unit, purchase unit, weight, dimensions, variants, price, stock, images). In columns, the tools that hold them: ERP, website, ad feed, quoting tool. In each cell, a cross if the tool holds the field, and a W if it can write it.
2. Name a single owner per field
For each row, only one tool keeps the right to write. Often the ERP for the reference, unit, price and stock, and the website or a content tool for the description and images. Any row with two Ws is a conflict to settle in a meeting, not to let slide.
3. Write the format rules
The format of the reference, the allowed units and how they are written (mm or cm, never both), the list of variant attributes and their permitted values. One page is enough. It goes into the integration specification, under version control.
4. Clean once, from the owner
Export the owner's data, fix duplicates and empty fields, and do not fill in a GTIN you do not know. Then overwrite the copies from that version. Never clean in two tools in parallel.
5. Wire the sync in one direction only
The owner pushes, the others receive. The pace (immediate or in scheduled batches) is chosen field by field: stock needs to move quickly, a description much less so. I covered that choice in the article on real-time APIs versus batch feeds, and the concrete case of an Odoo and PrestaShop connector shows where it gets stuck.
05The limits: when MDM software is not the answer
This method has a cost: it forces decisions the organisation had been avoiding. Who is allowed to change a price? Can marketing rename a product without going through the ERP? These meetings are sometimes harder than the technical part, and I do not know a shortcut.
It also has a ceiling. When products come from dozens of suppliers with records in different formats, or when several subsidiaries each have their own ERP, a dedicated tool (a PIM or an MDM platform) can become worth it. I do not do ERP overhauls or roll out these heavy tools: they are long projects, with their own specialists.
What I advise against is buying the tool before doing steps 1 to 3. MDM software matches records according to rules. If nobody has decided those rules, it will match badly, only faster. And if you are still choosing the ERP itself, the reference question is one of the criteria, as I explain in the article on choosing an ERP for an SME.
06Where to start on Monday
Pick ten products at random, including at least one with variants. Open them in each tool and note the gaps: reference, unit, weight, colour. That small check tells you within an hour whether your problem is a detail or a deeper question.
Then draw the table from step 1, even if it is incomplete, and bring it to the next meeting with a single question: for each row, who wins when there is a disagreement? It is often the first time the question has been asked out loud.
If you would like an outside view on this kind of work, I run this sort of diagnosis in a few days, then the set-up with the team; my services and the projects I have worked on give an idea of how I work. Happy to talk it through.