Despite the prevalence of GTINs (also known as EANs, article numbers, barcodes etc.) for consumer packaged goods it’s common to find retailer trading data expressed in terms of a retailer’s own product code (article number, MIN, PIN, TPNB, TPND etc.). Matching retailer codes to your own product codes is often essential for effective and actionable product performance insights; you can’t take action if you’re not sure which product requires attention!
At its simplest, product code matching is a problem of associating the code used by a retailer with the code used by the supplier of that product. But which ‘code’ do we mean? Product code matching is complicated by different types of product codes used at different stages in the Flow-of-Goods between supplier and shopper. Let’s quickly explore these.
How are my products encoded by my retail customers?
Consumer unit code matching
When you or I walk into a supermarket, select a product from the shelf and then purchase it at a till we expect to scan the product using the barcode printed on its packaging or, in the case of fresh produce, by selecting an item from a retailer-provided list. First, let’s focus on the printed barcode:
The printed barcode is a GTIN (Global Trade Item Number) which uniquely identifies the ‘consumer unit’ i.e. the item that the shopper can purchase at the till. GTINs are owned and allocated by the item’s manufacturer, according to policies and practices defined by GS1. This code allows all parties (retailer, supplier etc.) to distinguish between similar versions of the same product. For example, the 415g single can of Heinz Baked Beans will have a different consumer unit GTIN from the 4x415g pack (itself containing 4 single cans).
Retailers will match a supplier GTIN to an internal system product code on a one-to-one basis but may stray from this if the supplier provides a different GTIN on a special pack e.g. a promotional pack tied into an event, like the FIFA World Cup.
In principle, however, mapping consumer unit GTIN to retailer product code can be done through a row-by-row mapping table – managed by anything from a simple spreadsheet to a master data management platform.
This becomes more complicated when we consider fresh produce, in-store bakery and other multi-supplier or store-created items where the items purchased and sold by the retailer can have a many-to-many mapping.
Catering for traded units and logistics units
Things get a little more complicated when we consider cases, pallets and other traded and logistics units i.e. the way that a supplier sells consumer units. For example, a supplier might ship individual cans in a tray of 24 (laid out as 6 x 4) or 48 (6 x 8), whereas the same supplier might ship 4-packs (of individual cans) in cases of 6 (laid out as 3 x 2) or 12 (3 x 4) etc. These different cases now need a ‘product code’ so that the retailer can specify whether they are buying the larger or smaller case; GTINs also serve this purpose but it’s less common to see these printed on purchased cases – certainly, it’s less prevalent than on consumer packaging.
This is complicated further when trays/cases can be ordered by the pallet; again, GTINs can be used to define a logistics product (e.g. a pallet with 6 cases per layer, stacked 8 high) but this is an even less common use than for traded units.
In short, every retailer-supplier partnership uses GTINs in its own way, combining GTINs and alternative ‘product codes’ to describe what they are ordering and supplying. GS1, the international standards body for GTINs, defines how GTINs should be used across trading relationships but these rules are often broken through ignorance, simplification and pragmatism. The complexity involved can be seen most clearly in GS1 guidelines for GTIN assignment in fresh produce.
Matching and managing categories
A further consideration, beyond matching products bought and sold (and the creation of sold items from bought items!), is aligning the ways that retailers and suppliers categorise their products. There are multiple layers of complexity here (sorry!):
- Retailers and suppliers don’t see the world the same way.
Retailers often consider ‘merchandising categories’ in a way that reflects store layouts—so the ‘dairy’ category may be subdivided by the way that refrigeration was traditionally laid out in store, for example. Suppliers tend to categorise products based on the way that they expect consumers to consume them, or aligned to manufacturing processes. It’s rare to find complete agreement between a supplier of 100+ items and its multiple retail customers. - Innovation breeds subcategories.
Categorisation is rarely a simple, single-level affair—typically, each category will be subdivided into subcategories, e.g. Bevererages > Alcohol > Beer > Ale, Larger etc - Categorisation is not always consistent internally.
Even within a single CPG, it’s likely that different departments may organise products into different categories; finance, marketing, and warehousing may classify products differently according to their perspective.
It’s often necessary to classify and categorise products by two or three schemes, with the flexibility to combine and aggregate product performance data (sales, stock, service etc.) within and across category and subcategory.
It’s often necessary to classify and categorise products by two or three schemes, with the flexibility to combine and aggregate product performance data (sales, stock, service etc.) within and across category and subcategory.
Which tools can I use to simplify product matching?
It’s important to choose the right tool for the job; the right tool will depend on you, your team and your business. Small companies, with only a handful of product listings in a couple of grocers, can usually get by with a spreadsheet whereas large organisations with hundreds of items available through all major grocers will need automated team processes and audited workflows to keep their data current and matched. As always, whilst tools are important it’s a consistent approach to key processes that drive success; your preferred tool(s) should support robust, consistent and evolving processes.
Spreadsheets
A well-organised spreadsheet can prove effective for small and medium sized organisations – the key is that it is well-organised and that it’s maintained consistently. Most people will start with a single (“master record”) worksheet that lists all supplied items – with codes, descriptions and a range of product attributes including consumer unit size, pack size (for multipacks), brand, colour/ flavour/ variant etc.
Typical extensions include additional columns to represent retailer coding but this quickly becomes unmanageable. It is better to create additional worksheets for each retail customer and then record “look-ups” in these worksheets that map retailer codes to your own.
Best-practice will require you to:
- Track changes in master records over time, using from-to timestamps as a permanent record of change;
- Track changes in retailer coding and matching; this can be very useful for promotional ‘special event’ packs; and
- Produce a ‘current range’ summary that brings together the latest master records and retailer matches into a single list that describes your maximum current range.
This kind of best-practice often marks the transition from a spreadsheet solution into a dedicated reference data management tool.
Master Data Management applications
Many Enterprise Resource Planning (ERP) suites include Master Data Management (MDM) applications, enabling a single ‘master’ record for every item – against which, additional codes/ references can be held and maintained. A central, ‘single version of the truth’ for every item is highly desirable – if fully maintained and used as the only definitive source of product information.
The key to a successful MDM implementation is to control data flows in all your downstream business systems, requiring them to draw ALL item data from the MDM. Every time a local copy of product data is recorded in a single operational system, the MDM is weakened. Central control, with flexible evolution to support changes in dependent systems, is critical if your MDM approach is going to work.
Unfortunately, many MDM solutions don’t provide much flexibility for mapping internal master record product codes to those used by your retail customers. Whilst many support a simple one-to-one mapping (i.e. recording a single retail customer code against the master record) most fail to model many-to-many exceptions and very few enable a long-term record of change to accurately model the changing way that retail customers refer to your products.
Demand intelligence data mapping
Modern Demand Intelligence tool sets tend to take a hybrid approach that often brings a ‘best of both’ solution; product reference data is drawn from your ERP/ MDM applications and then matched to retail customer codes within the Demand Intelligence platform itself. Because these platforms are designed to manage change across multiple retail customers, they tend to model the slow-changing nature of product codes very well.
The best options will also provide a degree of automation and alerting to help you stay on top of the administrative tasks involved in managing your reference data and customer matching, including:
- Automated alerts when new codes are detected in retail customer data feeds;
- Data Quality KPIs that measure your match rate and the value of sales recorded against unmatched products;
- AI-assisted matching, whereby the system automatically suggests probable matches for all unmatched products.
Summary
Retailers and CPGs see the world differently and those differences manifest in different approaches to product classification, categorisation and coding. However well you manage your product reference data, and work to understand your retail customers’ perspectives, you’re always at risk of change and misalignment.
By developing a robust and pragmatic approach to product matching, supported by appropriate tools, you can minimise these risks; control the flow of information from your customers; and, gain valuable insights into shopper behaviours with minimal effort and cost.