MDM for Product Data: Reconciling SKU Chaos

Master data management for product data and SKUs is the discipline of creating and maintaining a single, authoritative source of truth for product definitions across every sales and fulfillment channel your organization operates.

When I arrived at Nestle Purina to lead their product master data management program, we were managing over 18,000 SKUs across retail, e-commerce, direct-to-consumer, and wholesale channels—and nearly every channel had a different definition of what made a SKU “the same product.” A bag of dog food sold through Amazon looked like one SKU in our e-commerce system, a different identifier in our distributor portal, and yet another in our legacy retail order management system. The result: duplicate supplier orders, pricing misalignment, customer confusion, and a compliance nightmare when regulatory data (ingredient sourcing, allergen declarations) changed. That chaos is what this article addresses.

Introduction

Product data chaos is not a small problem. When SKU definitions diverge across channels, the downstream costs accumulate fast: incorrect inventory forecasts because no one knows which SKUs represent the same physical product, failed omnichannel customer experiences because product reviews, ratings, and availability don’t sync, supplier confusion leading to overstock or stockouts, and governance failures when your compliance team can’t track where a product attribute came from or who approved a regulatory change.

Unlike financial master data (where governance is often centralized) or customer master data (where identity resolution has well-worn tools), product information management sits in a unique space. Every channel—retail store systems, marketplace platforms like Amazon and Walmart.com, your own e-commerce site, wholesale and distribution partners—has incentives to define products slightly differently. A marketplace platform may require more detailed attribute coverage to compete on discoverability. Your wholesale partner’s order system may use a simplified SKU structure for ease of ordering. Your retail stores may care deeply about physical dimensions for shelf planning, while your e-commerce operation cares about shipping dimensions and digital imagery.

The goal of product master data management is not to force uniformity where it doesn’t belong. Instead, it is to establish a golden record product definition that serves all channels while respecting their specific requirements. This means reconciling what “the same product” means across systems, deciding which channel owns which attribute, managing the workflows that approve changes, and measuring whether your effort actually reduced chaos.

This article walks through that entire journey—from diagnosing SKU divergence to tooling choices to governance structures—using the specific challenges I’ve navigated in bringing order to thousands of products across wholesale, retail, and direct channels.

The Product Data Challenge in Retail and E-Commerce

Retail and e-commerce organizations manage product data at a scale and complexity that other industries rarely encounter. A single consumer product can exist as dozens of variants—different sizes, colors, formulations, packaging types—each of which may have different suppliers, different regulatory requirements, different wholesale versus retail pricing, and different inventory strategies.

The core problem is that no two channels share identical incentives around how to organize that data. A major e-commerce marketplace like Amazon requires specific product hierarchy (Department > Category > Subcategory > Brand > Product Type) to power search and recommendation algorithms. Your own e-commerce platform might use a different hierarchy. Your retail point-of-sale system may not care about hierarchy at all—it just needs a UPC code and a shelf location. Wholesale and distribution partners often use their own item master systems and will tolerate data only in the format their order management system expects.

When each channel maintains its own product master file independently, the result is MDM retail environments where the same physical product can have three to five different SKU identifiers, conflicting attribute values, out-of-sync pricing, and no single source of truth for regulatory or compliance attributes like allergen declarations, country of origin, or expiration date calculations.

I’ve seen this play out countless times. At Purina, we had 6,200 product SKUs in our primary retail system, 5,800 in e-commerce (with about 3,000 overlapping), 2,400 in our direct-to-consumer channels, and 4,100 in our distributor portal. Only about 2,000 of those 18,000 total identifiers were truly unique products; the rest were duplicates, variants, or channel-specific codes for the same underlying item. The data quality cost was severe: our marketing team couldn’t run consistent campaigns because they couldn’t trust which SKUs were active; our supply chain built forecasts on fragmented demand signals; and our compliance team couldn’t certify that ingredient changes had been applied everywhere.

The challenge isn’t purely technical—it’s organizational. Every channel owner believes their system is the source of truth. The e-commerce team argues that they need richer attributes (hero images, detailed descriptions, search keywords) because their customers require it. The retail team argues that warehouse dimensions and case-pack quantities are what matters on the dock. Wholesale teams want simplified data so their partners can order easily. Until those conversations happen at a governance level, a sku reconciliation tool—however powerful—will fail.

Why SKU Definitions Diverge Across Channels

Understanding why SKU definitions diverge is the first step to preventing it. The divergence is rarely malicious or even careless; it flows from legitimate differences in how each channel operates.

Channel-specific business logic. Retail stores need products grouped by physical location on the shelf. E-commerce needs products discoverable via search keywords and visual filters. A marketplace like Walmart.com needs products aligned to Walmart’s category taxonomy so shoppers can browse. A wholesale distributor’s system needs SKUs simple enough that small retailers can order without confusion. These aren’t compatible organizational structures; a product master file designed for one channel will look wrong in another.

Attribute coverage and validation. E-commerce requires imagery (front, back, lifestyle, hero images), rich descriptions, and search keywords that retail systems don’t touch. Retail requires aisle and shelf coordinates, pallet quantities, and case dimensions that e-commerce ignores. Regulatory and compliance systems need sourcing, allergen, and certification data that most ordering systems don’t validate. There is no single “complete” product record that serves all these needs equally.

Legacy system constraints. Many retail organizations operate with POS systems, inventory management platforms, and warehouse management systems built 10–15 years ago. These systems often have hard limits on SKU name length, attribute field counts, or data structure flexibility. To work within those constraints, teams create workarounds: abbreviating descriptions, using codes instead of clear labels, flattening hierarchies. When you later try to reconcile against modern e-commerce platforms with no such limits, the technical debt is severe.

Organizational ownership and incentives. When different business units own different channels, they often optimize locally rather than globally. The retail operations team is measured on store-level sales and inventory turns; the e-commerce team is measured on website conversion and search ranking; the wholesale team is measured on partner satisfaction and order accuracy. Each unit has budget, headcount, and KPIs tied to their own systems. Centralizing product data means each unit must share control and follow shared governance, which feels like losing autonomy. That political resistance is often stronger than the technical challenge.

Regulatory and localization requirements. If you sell internationally, products may have different attributes by country: nutrition facts labels in different formats, certifications specific to certain regions, ingredient sourcing policies that vary by market. A single global golden record product definition may not work; instead, you need a master record with channel-specific and region-specific overrides—which multiplies complexity.

At Purina, the biggest divergence came from a simple fact: we inherited two different product master systems after an acquisition. The legacy system organized pet food by ingredient type (protein source, grain, etc.); the newer system organized by pet type and life stage (puppy, senior, small breed, etc.). Neither was wrong, but they were incompatible. When we merged them, we couldn’t simply consolidate the SKUs; we had to decide which organizational logic would govern the master record, and then map both legacy approaches to it. That decision alone took six weeks of cross-functional negotiation.

Building a Product Master Data Strategy

Before touching any tool or reconciliation engine, you need a strategy that answers: What is product mastery for our organization? Who decides what data matters? How do we resolve conflicts when channel needs clash? How do we maintain this over time as new channels emerge?

A product master data strategy typically rests on four pillars:

Define scope and boundaries. Not every product attribute lives in the master record. Decide what belongs in product master data versus what lives in channel-specific systems. In my experience, master data should include attributes that drive business decisions across more than one channel: SKU identifier, product name, brand, category, pricing tier, supplier, regulatory compliance attributes, and core product specifications. Channel-specific attributes like search keywords, warehouse bin locations, or marketplace-specific category codes should live in channel systems and reference the master record, not live in it. This distinction prevents your master record from becoming bloated and channel-specific, which defeats the purpose.

Establish a single source of truth for each attribute. For every attribute in the master record, decide which channel (or system) is the authoritative source. Is brand maintained by the marketing team? Is pricing maintained by finance? Is regulatory data maintained by compliance? Or does the master data team own everything and channels consume it? The clearer the ownership, the easier the governance. At Purina, we decided that the supply chain team owned product specifications, marketing owned product descriptions and category assignments, finance owned pricing, and regulatory owned compliance attributes. But all of those fed into a shared product master record that was published to every channel system via API—not imported from channels back into a central file.

Design for multi-channel publication, not multi-channel input. This is a critical distinction. Your master data strategy should be publish-out, not pull-in. That is, you maintain a single product master record and publish it to all channels, rather than pulling product definitions from five different channel systems and trying to reconcile them into a single record. The latter approach creates an unstable master record that’s always chasing its sources. The former creates a stable source of truth that channels consume. This doesn’t mean channels can’t extend the master record with their own attributes—they should. But the core product identity and the attributes that drive business decisions should flow one direction: out from the master.

Plan for governance, not just data. A master data strategy is a governance strategy as much as a data strategy. Who approves new SKUs? Who can change a product’s category or regulatory attributes? Who decides when a new variant should be a separate SKU versus an attribute of an existing SKU? What does approval for e-commerce publication look like if a product is sold through wholesale channels but not direct-to-consumer? These governance questions have to be answered before you implement a tool. A tool will enforce those rules, but the rules themselves must be decided by the business.

Defining Your Golden Record for Product Attributes

The golden record product is your single, authoritative version of each product. But what belongs in it? And what is a “product” when variants abound?

Start by deciding what you mean by a product. Is a “product” the highest-level item—say, “Dog Food, Protein-Rich Formula”—or is it the specific SKU, like “Dog Food, Protein-Rich Formula, 15-lb bag, chicken flavor”? The answer depends on how you want to organize your channels and how your supply chain operates.

At Purina, we defined a “Product” as the smallest unit of distinct offering with its own supplier, cost structure, and regulatory profile. That meant a 15-lb bag of chicken formula was a different product than a 15-lb bag of beef formula, because they had different suppliers and different regulatory sourcing data. Within that product, we allowed variant attributes (bag color, packaging region, etc.) that didn’t fundamentally change the cost or compliance profile.

Once you define a product, define the attributes that belong in the golden record. I recommend starting with these core categories:

Identity attributes ensure every system can find and match the product: SKU identifier, UPC/EAN, product name, alternate names, brand, supplier.

Organizational attributes allow you to navigate and categorize the product across channels: category hierarchy, subcategory, brand segment, business unit owner, go-to-market channel (retail vs. wholesale vs. direct).

Specification and description attributes allow customers and supply chain partners to understand what the product is: detailed product description, key specifications (size, weight, count, material), color, scent, or formulation attributes specific to your industry.

Regulatory and compliance attributes are non-negotiable: country of origin, allergen declarations, certifications (organic, non-GMO, Fair Trade), ingredient sourcing requirements, shelf-life calculations, and any attributes required by law in the markets where you sell.

Operational attributes support inventory and fulfillment: case pack quantity, weight and dimensions, supplier part number, lead time, cost structure, and shelf-placement rules.

Commercial attributes support pricing and sales: list price, discount tier, margin requirements, go-live date, discontinuation date, and channel-specific pricing rules.

Your golden record should include all of these—but not channel-specific overrides. Channel systems will reference the master record and layer on their own attributes (search keywords for e-commerce, aisle location for retail, order minimums for wholesale). The master record is the stable layer that all channels reference; channel systems are the consumption layers that may extend it.

One practical tool: create a product data governance matrix that lists every attribute in your master record, assigns ownership (which team or system maintains the source), defines validation rules (required vs. optional, allowed values), and specifies which channels consume it. This matrix is not theoretical—it becomes the basis for your governance workflows and your tool configuration. I strongly recommend using a template like the RACI matrix for data governance to make ownership unambiguous.

Matching and Survivorship Rules for Product Data

Once you have defined what belongs in a golden record, you face the immediate problem: you have thousands of existing product records across multiple channel systems, many of which represent the same physical product but with different names, identifiers, and attributes. How do you identify duplicates and merge them?

This is where MDM matching and survivorship enters. Matching is the process of finding duplicate records across systems and determining which ones should be consolidated. Survivorship is the set of rules that decide which attribute value “wins” when two product records conflict.

Matching products is harder than matching people. When matching customer records, you’re looking for the same individual—which is determined by name, email, phone, address, and other direct identity markers. When matching products, you’re looking for the same physical good—which requires matching on UPC, product name, supplier, and sometimes a combination of attributes. A product might have a different name in different systems (“Small Dog Kibble” vs. “Kibble, Small Breed”), a different case-pack quantity (either 6-pack or 12-pack of 1-lb bags), or a different supplier designation.

I’ve found that effective product matching usually requires a rules-based approach first, then a fuzzy-matching supplement. Start with exact-match rules: if two products have the same UPC in both systems, they are the same product—match them. If two products have the same supplier part number and the same supplier, match them. These exact rules eliminate the obvious duplicates quickly and leave you with a smaller set of ambiguous cases.

For the ambiguous cases, apply fuzzy-match rules based on multiple attributes. For example: if product names are 80% similar (Levenshtein distance), and suppliers are identical, and pack quantities are within 10% of each other, they are likely the same product. Fuzzy matching assigns a confidence score; you then review high-confidence matches manually and decide whether to merge.

Be conservative with fuzzy matching in the first pass. False positives (merging products that are actually different) are catastrophic: you lose inventory separation, pricing alignment breaks, and you corrupt the master record. False negatives (failing to match products that are the same) are fixable: you can match them in the next iteration or manually. At Purina, we matched on UPC first (3,200 obvious merges), then on supplier part number (1,400 more), then applied fuzzy rules on name and pack quantity with manual review for confidence scores above 85%. We left lower-confidence matches for manual review by subject matter experts.

Once you have identified matches, define survivorship rules. When merging two product records with conflicting attributes, which value do you keep? The standard approach is to rank your source systems by data quality or authority. For example: “If product name differs between retail and e-commerce, the e-commerce name is authoritative because it’s customer-facing and our e-commerce team has better content governance.” Or: “If pricing differs, use the highest valid price across all channels, because we never want to undersell.”

Your survivorship rules should reflect your organizational authority and data quality reality. If your regulatory team maintains allergen data more carefully than your marketing team, make regulatory data win in conflicts. If your e-commerce platform has richer product descriptions than your retail system, let e-commerce descriptions win. The key is to make these decisions explicitly, document them, and apply them consistently through your matching tool.

At Purina, our survivorship rules were specific by attribute. For product name, we used the retail system (it was our oldest system of record). For descriptions, we used e-commerce (richer). For regulatory attributes, we used a dedicated compliance database (most authoritative). For pricing, we used finance’s pricing system. This meant that when we merged two product records, the merged result was a hybrid—pulled from different sources for different attributes. That’s normal and actually the point: the golden record is an assembly of attributes from the best source for each one.

Workflows and Approvals for Multi-Channel Products

Once you have built a master record and reconciled existing duplicates, you face the ongoing challenge: how do new products get created, how do changes flow through the system, and who approves changes before they are published to channels?

Without clear workflows, you’ll see a repeat of the original chaos: product teams creating SKUs in their favorite system, changes getting made in one channel but not others, and no clear source of truth for when a change is “done.”

A product master data workflow typically involves these stages:

Request and creation. Someone (product manager, brand manager, supply chain planner) wants to create a new product or change an existing one. They submit a request that includes the key attributes: product name, specifications, supplier, pricing, regulatory data, and target channels for publication. This request enters a workflow—it’s not yet in the master record.

Validation and enrichment. A data governance specialist or product data steward reviews the request for completeness and validity. Do all required fields have values? Do they conform to naming standards? Is the supplier already in the system, or does that need to be created first? This stage often requires back-and-forth with the requester to fill gaps.

Cross-functional approval. Different attributes may require different approvers. Pricing requires approval from finance. Regulatory attributes require approval from compliance or quality assurance. Category assignment may require approval from merchandising or marketing. A mature workflow routes the request to the appropriate approvers in parallel (not sequential—parallel is faster) based on which attributes are being changed.

Publication and activation. Once all approvals are complete, the product is added to the master record with an effective date (often “now” for new products, or a future date for changes to existing products). The product is then published to channel systems via API or batch feed. The requester can track the publication status and see when the product is live in each channel.

Audit and exception handling. If publication to a channel fails (because the channel system rejects a required attribute or because of a technical connectivity issue), an alert notifies the data steward so they can fix it.

For a detailed look at how to structure these workflows, I recommend reading how to create efficient master data management workflows and approvals. The principles apply to product data as much as any other MDM domain.

In practice, I’ve found that workflows are only as good as their governance backing. If approvers are not clearly assigned, or if approvers don’t have clear criteria for approval, requests stack up and the system becomes a bottleneck. Make sure that:

Every approvable attribute has a named approver. That approver owns the quality of that data in the master record. If pricing is wrong, finance is responsible; if regulatory data is wrong, compliance is responsible.

Approval criteria are written down. What makes a product name acceptable? What makes pricing valid? If criteria are vague (“looks reasonable”), approval becomes arbitrary and slow.

Workflows are automated where possible. If a request triggers approval from five different teams, send approval requests in parallel, not one after another. Track the approval status in your workflow tool so the requester doesn’t have to chase approvers manually.

Escalation paths exist for deadlocked requests. If an approver doesn’t respond in 48 hours, escalate to their manager. If two approvers disagree, escalate to a steering committee. These paths should be defined in advance, not improvised.

At Purina, we implemented a workflow in Profisee (covered in detail in the tooling section below) that routed new product requests to the supply chain team for validation, then in parallel to finance (for pricing), compliance (for regulatory), and marketing (for category and description). We set a 24-hour approval window for each approver; after 24 hours, the request escalated to their manager’s manager. We published every successful approval to our main product catalog as an API feed, which every channel system subscribed to.

Tool Choices: Profisee, SAP MDG, and Custom Platforms

Choosing the right MDM platform for product data is critical—and there’s no one right answer. Different tools have different strengths, and the choice depends on your data volume, technical sophistication, budget, and ecosystem.

Profisee is a cloud-native MDM platform built specifically for product and customer data. It excels at product data workflows, attribute management, and multi-channel publication. Strengths: intuitive UI (business users can self-serve in many cases), out-of-the-box support for product hierarchies and variants, strong API for channel integration, configurable workflows without heavy coding, and solid data quality tooling. Weaknesses: it is not designed for financial or operational master data (general ledger accounts, cost center hierarchies); pricing scales with data volume, which can get expensive at enterprise scale; it requires dedicated resources to maintain and configure.

At Purina, we chose Profisee because we needed rapid time-to-value. The product team needed to be able to create new product records and see them flow through approvals without waiting for IT to build custom workflows. Profisee’s interface allows a non-technical product manager to create a product request, and the system automatically routes it to the right approvers. That self-service capability saved us months in deployment time.

SAP Master Data Governance (MDG) is part of the SAP ecosystem and integrates tightly with SAP ERP systems. It excels at centralized governance of master data across multiple SAP modules—materials, customers, vendors, cost centers—in a single system. Strengths: deep integration with SAP finance and supply chain modules, centralized governance across all master data domains, strong audit and compliance tracking, mature in large enterprises. Weaknesses: the UI can feel dated compared to modern cloud tools; MDG requires SAP ERP, so it’s not an option if you run best-of-breed systems; implementation is expensive and complex; it’s designed for enterprise governance, not product team agility.

For a detailed comparison, see the SAP Master Data Governance guide. If you are already running SAP ERP and need to govern product data in the context of your broader master data strategy, MDG is often the logical choice. If you need agility and self-service, Profisee or similar tools may be better.

Custom platforms built on open-source databases and APIs are less common for product data MDM but not unheard of. Strengths: complete customization, no vendor lock-in, can be integrated with any channel system, often cheaper than commercial tools at enterprise scale. Weaknesses: you own all the development and maintenance risk; you need in-house engineering talent to build and maintain workflows, matching logic, and data quality tooling; it takes longer to deploy than a commercial platform.

The deciding factor for us was speed. We needed product master data governance live in eight months. A custom platform would have taken 18 months. Profisee allowed us to go live in six months, with some initial configuration but no custom development. That speed had business value—every month we delayed meant continued chaos in the channel systems.

Your tool choice also depends on your channel ecosystem. If you sell primarily through SAP wholesale channels and SAP-based ERP, MDG may be overkill for product data alone, and a simpler Profisee integration might be better. If you sell through multiple e-commerce platforms (Shopify, WooCommerce, custom), Amazon, Walmart.com, and your own site, you need a tool that can publish APIs or feeds to all of those in real time. Profisee handles that natively. SAP MDG would require custom middleware.

When evaluating tools, ask for product data references—not just customer or financial data references. The vendors selling these tools will readily provide references, but make sure you speak with organizations that have implemented product MDM, not just customer MDM, and ideally in retail or e-commerce. The use cases and deployment patterns differ significantly.

Data Harmonization: Reconciling Channel-Specific SKUs

Even with a solid master record and matching rules, you will inherit legacy channel-specific SKU definitions that don’t map cleanly to your master record. A distributor’s system may use 4-digit item codes; your e-commerce platform may use 10-digit codes; your retail POS may use UPC only. How do you map all of these to a unified master record without breaking channel systems?

This is the core of data harmonization—bringing data from disparate sources into a unified format and definition. For product data, this means creating a translation layer between your master record and each channel system.

The standard pattern is to maintain a SKU mapping table that links every master record SKU to every channel-specific SKU. That is:

When you publish a product from the master record, you look up the appropriate channel SKU from this mapping table and send the data in the format that channel expects. If a channel doesn’t yet have a SKU mapping, you generate a new one in your master system and provision it to that channel.

This approach preserves the existing channel SKU identifiers—you don’t force retailers or distributors to change their internal SKU codes, which would break their entire inventory and order history. Instead, you create a unified master record that all channels reference, and maintain mappings that preserve channel autonomy.

For a deeper treatment of this pattern, see data harmonization best practices. The principles of harmonization—creating a unified layer while preserving source systems—apply well to product data reconciliation.

At Purina, we maintained the mapping table in Profisee and exposed it as an API that channel systems could query. Our retail system would ask: “What is the master SKU for my retail item 456789?” and get back “PURINA-PF-001”. Our e-commerce system would ask the inverse: “What is the e-commerce SKU for master SKU PURINA-PF-001?” and get back “PS-DOG-001”. This bidirectional mapping allowed all channels to stay in sync without any channel having to change their native identifiers.

The mapping table also served as a reconciliation tool. We ran weekly reports that compared mapping table entries against actual inventory and order data in each channel. If a mapped SKU had zero activity in a channel for 90 days, we flagged it for review—it might indicate a product that should be discontinued, or a mapping that had fallen out of sync.

One practical challenge: what do you do when a master SKU has no mapping in a channel system yet—because the product is new, or because that channel hasn’t yet been onboarded? In our Profisee setup, we used a staging table. When a new product was approved in the master record, it was published to a staging table in each channel system’s database. Channel IT teams had 48 hours to map the new master SKU to their native SKU code, or the system would auto-generate a new SKU and use that. This created accountability: channel teams knew they had 48 hours to claim ownership, or the master system would move forward without them.

Governance Roles and Stewardship for Product Data

Master data doesn’t govern itself. Someone has to own it, track quality, handle exceptions, and iterate on the system as new channels and business needs emerge. That’s the role of product data governance and data stewardship.

A typical product data governance team includes:

Product data steward. This person (often titled “Master Data Manager” or “Data Steward”) owns the day-to-day operation of the master record. They monitor data quality, handle matching and merge requests when duplicates are discovered, investigate and resolve exceptions (e.g., a channel failed to publish), and work with channel teams to resolve data conflicts. This is often a full-time role for mid-market companies and a team of 2–3 for enterprise organizations. The steward should have both technical knowledge (understanding how your MDM tool and channel systems work) and business knowledge (understanding product taxonomy, regulatory requirements, channel operations).

Product governance committee. This is a cross-functional group that meets regularly (monthly or quarterly, depending on your product velocity) to review governance issues, approve policy changes, and resolve escalations. Typical members: head of product, head of supply chain, head of e-commerce, finance, compliance, IT. Their role is to make policy decisions that the data steward then implements.

Channel data owners. Each major channel system (retail, e-commerce, wholesale) has a designated owner who is responsible for that channel’s consumption of the master record. They ensure their channel system is correctly configured to receive product data from the master, they investigate quality issues specific to their channel, and they provide feedback on what additional attributes or features their channel needs.

Subject matter experts (SMEs). Depending on your product type, you may have SMEs in regulatory compliance, quality assurance, packaging, or supply chain who validate or approve product attributes in their domain.

For a template to formalize these roles, see the RACI matrix for data governance. It’s designed to help you explicitly assign responsibilities for data governance tasks.

The data steward is the most critical role. I’ve seen organizations implement sophisticated MDM platforms with clear governance policies and then stumble because they didn’t hire or resource a dedicated steward. The steward needs time to:

• Manage the matching backlog. As you bring new channel systems online or discover new duplicates, someone has to review matches and decide whether to merge. This is often manual and time-consuming. If no one owns this, matches pile up and the master record remains fragmented.
• Investigate and resolve data quality issues. When a product attribute is invalid or incomplete, who looks into it? Was the approval workflow flawed? Did the requester provide wrong data? Did the channel system reject the publication because of a mapping issue? A steward handles these investigations.
• Manage the governance communications. Stewards are often the point of contact for channel teams, data owners, and approvers. They communicate data quality findings, escalate conflicts, and educate the organization about governance policies.
• Monitor adoption and iterate. Does the current workflow work, or is it creating bottlenecks? Are channel teams publishing their own products through back doors (spreadsheets, manual imports) instead of using the master system? A steward monitors these adoption issues and works with leadership to iterate.

At Purina, I hired a full-time product data steward and also established a product governance committee that met monthly. The steward handled day-to-day matching, quality investigation, and channel escalations. The committee made the policy decisions—for example, deciding whether a new product variant should be a new SKU or an attribute of an existing product. That split between operational (steward) and strategic (committee) worked well.

One more role often overlooked: the metadata librarian or data catalog manager who documents the master record schema, maintains the data governance policies as living documents, and ensures that the organization understands what each attribute means and who owns it. A data catalog tool can automate some of this, but someone still needs to maintain it.

Measuring Success: Quality Metrics for SKU Alignment

You can’t improve what you don’t measure. But what should you measure to determine whether your product master data management effort is working?

Start with data completeness: what percentage of required attributes are populated in your master record? For a baseline, this is often 60–70% when you first consolidate legacy systems. For a mature program, target 95%+. Track completeness by attribute and by data domain (regulatory attributes should be 100% complete; marketing attributes might be 90%).

Duplicate rate measures whether products are still diverging across channels. Calculate this as: (total SKU identifiers across all channels - unique master products) / total SKU identifiers. When you start, this might be 40–50% (meaning 40–50% of your channel SKUs are redundant). Target 5–10% (acknowledging that some channel-specific SKUs will always exist for operational reasons).

Timeliness measures how quickly products go from request to publication. Track average days from request creation to master record approval, and average days from approval to publication in each channel. Benchmark against your internal SLA (e.g., “new products should be live in e-commerce within 3 business days”). This metric reveals workflow bottlenecks.

Channel publication success rate measures how many product updates successfully publish to each channel versus how many fail. Aim for 99%+; anything below 95% indicates technical or data quality issues that need investigation.

Regulatory compliance is critical: track what percentage of products have complete regulatory attributes (ingredients, allergens, country of origin, certifications) by product category and market. This should be 100% for any product offered in a given market; if it’s not, you have a compliance gap.

Stakeholder adoption measures whether people are actually using the system. Track: percentage of new products created through the master data workflow versus through channel-specific workarounds, adoption by channel team, adoption by product teams. If product managers are still uploading SKUs via spreadsheet to their channel system rather than using your master data workflow, adoption is low and you need to address why.

Cost of poor data quality is worth calculating to justify continued investment. Track: how many supply chain planning runs need to be rerun because of SKU duplicates? How many customer support escalations are due to incorrect product information? How many warehouse replenishment orders are created in duplicate because two systems don’t know they’re ordering the same product? Quantifying the cost of chaos helps make the case for continued governance investment.

At Purina, our north-star metric was SKU convergence: the trend toward having a single master product identifier with clean mappings to all channel systems. When we started, we had 18,000 total SKU identifiers representing about 6,500 unique products. After 18 months, we had consolidated to 6,100 unique master products with clean mappings to retail, e-commerce, and distributor systems. That convergence—moving from 18,000 to 6,100 identifiers—drove real business value: simpler supply chain planning, fewer duplicate orders, faster new product launches, and better regulatory compliance.

We also tracked data steward efficiency: how many hours per week was our steward spending on manual tasks like matching, versus how many hours on strategic tasks like process improvement? When we started, it was 70% manual, 30% strategic. We invested in automating the matching rules and the workflow approvals, and by month 12, it was 40% manual, 60% strategic. That shift meant the steward could focus on improving the governance system rather than just keeping up with exceptions.

The Bottom Line on Reconciling Product Data Chaos

The core lesson I learned at Purina is that SKU chaos is rarely a technology problem—it’s a governance problem. You can implement the most sophisticated MDM platform in the world, but if your organization hasn’t agreed on what product mastery means, who owns what data, and how changes flow through the system, you’ll end up with a sophisticated tool managing bad governance.

The successful approach starts with conversations, not tools: What is a product in our business? What attributes matter across all channels? Which channel owns product names, descriptions, pricing, regulatory data? Only after those conversations can you design a tool configuration and a workflow that will actually work.

Then comes the hard part: execution at scale. Matching 18,000 legacy SKUs down to 6,000 unique products takes discipline, manual review, and sustained focus. Building approval workflows that don’t become bottlenecks requires clear criteria and escalation paths. Training channel teams to consume from a master record instead of maintaining their own requires patience and repeated communication.

The payoff is substantial. In my experience, organizations that implement product master data management see 20–30% reduction in SKU counts (eliminating true redundancy), 90%+ improvement in data completeness for regulated attributes, and significantly faster time to market for new products and variants. The e-commerce team can launch products confidently, knowing that retail and wholesale have current definitions. The compliance team can certify that regulatory attributes are current everywhere. Supply chain can plan accurately without duplicate demand signals.

But this only works if someone owns it. Hire or designate a dedicated steward, establish a governance committee, document your policies, and measure progress. The technology amplifies good governance; it doesn’t create it.

Frequently Asked Questions About Master Data Management for Product Data and SKUs

What is the difference between product master data management and product information management?

Master data management (MDM) focuses on creating and maintaining a single, authoritative source of truth for core product attributes—SKU identifiers, specifications, suppliers, regulatory data, and operational definitions. Product information management (PIM) is broader and often includes rich content like images, detailed descriptions, marketing copy, and channel-specific messaging. In many organizations, MDM and PIM work together: MDM establishes the authoritative SKU definition and regulatory attributes, while PIM enriches that core data with content for customer-facing channels.

How do I decide whether a product variant should be a new SKU or an attribute of an existing product?

A good rule of thumb: if the variant has a different supplier, different cost structure, different regulatory profile, or different inventory management strategy, it should be a separate SKU. If it’s a variation that doesn’t change the operational profile—for example, color or packaging size—it can be an attribute of the same base product. The key is consistency: define the rule once and apply it across your entire product portfolio.

What’s the typical timeline for implementing product master data management?

For a mid-market organization with 3,000–10,000 SKUs, expect 6–12 months from project start to go-live (business users actively using the system). For enterprise organizations with 50,000+ SKUs, 12–18 months is more realistic. The bulk of the time is spent on legacy data remediation, stakeholder alignment, and channel integration, not on the technology setup itself.

Can we implement product MDM without a dedicated tool like Profisee or SAP MDG?

Technically yes, but practically, I would advise against it at scale. A manual approach with spreadsheets and database scripts can work for 500–1,000 SKUs but becomes unmaintainable at 5,000+. A commercial tool gives you workflow automation, data quality monitoring, versioning and audit trails, and API publication to channels—capabilities that are expensive and error-prone to build yourself.

How do we prevent new SKU chaos if we launch a new sales channel?

Establish a clear onboarding process for new channels before they go live: Do they consume product definitions from your master record via API, or do they maintain their own and need mapping back to master? If they consume from master, what attributes do they require, and which can they extend with their own? Require channel IT and product teams to sign off on data governance policies before launch. Without that upfront alignment, new channels will create their own master files and you’ll repeat the original problem.

What should we do about legacy channel systems that can’t consume from a master record?

That’s common, especially with older retail POS or warehouse management systems. The answer is usually a translation layer: you maintain master data centrally and publish it to a staging table or file in the legacy system’s database. The legacy system reads from that staging area rather than maintaining its own master file. This approach has worked for decades in ERP and supply chain environments. It’s not elegant, but it works.

How do we handle products with regional or market-specific variations?

Create a global master record with the core product definition (name, base specifications, supplier, primary regulatory attributes), then use attributes to handle market-specific variations (regulatory language, certifications, pricing, availability). For example, a single dog food product might have different allergen labels and certifications in the US, EU, and Asia Pacific. Rather than maintaining three separate SKUs, maintain one master product with market-specific attribute overrides that publish to each region.

What compliance and audit capabilities should our product MDM system have?

At minimum: audit trails showing who changed what attribute and when, approval workflows that document who approved each product or change, versioning so you can retrieve historical product definitions, and export capability for regulatory audits. Many organizations have to certify that certain attributes (allergens, country of origin, certifications) have been validated by specific teams. Your MDM system should provide that audit trail automatically.