When is a GDSN data pool not a data pool?

When is a GDSN data pool not a data pool?

You might be surprised to learn that there are now over 40 data pools around the world that claim to be GDSN‑compliant.  What exactly does that mean?  Does it matter?

Before we start, let’s first do a quick review, starting with the GDSN.

The Global Data Synchronization Network (GDSN), is a network of world-wide inter-connected data pools.  It was designed by GS1 to facilitate the efficient and cost-effective sharing of product master data between suppliers and retailers across various industry verticals.  The master data that is shared via this network is standardized, highly structured and validated using business rules agreed upon between industry participants within a vertical and geographical market.  Within the GDSN, product data is stored by a data pool which should be compliant with GS1’s GDSN standards for data synchronization.  When requested, the data pool syndicates this master data from the supplier to a data recipient (such as a retailer).  Compliance with GDSN standards is essential in ensuring system inter-operability between the following:

  • Source systems of a data supplier (manufacturers, importer or distributor)
  • Consuming systems of a data recipient (retailer, distributor or Healthcare Provider/GPO)

GDSN standards are very mature and GS1 Global has done a great job in developing and maintaining this framework.  Yet, the implementation of these standards by the various data pool operators is far from consistent.  This is typically true for data pools at the market-specific level.

Data pools are meant to be standards-based, online catalogue databases.  They are designed to facilitate the exchange of ‘trusted’ product master data between suppliers and data recipients in vertical industries such as CPG, Retail, DIY, Healthcare and Agri-business.   This master data should be well structured, detailed, accurate, valid, consistent and up-to-date.  When these product master data standards are met, the data can then be relied upon (or trusted) by all users in B2B e-commerce.

What is a GDSN-compliant data pool?

According to GS1 standards, GDSN-compliance is defined as:

  • Using GS1 XML message format for all subscription and publication messages. Any data pool that does not use GS1 XML is not compliant with GS1’s GDSN standards for message inter‑operability (e.g. proprietary XML message formats like eb_XML, cXML, 1WS_XML and others)
    • Why? Using non-GS1 message formats defeats one of the main objectives of using GS1 standards – interoperability between the systems used by data suppliers and data recipients.
  • Using standard GDSN attribute structures, i.e. Attribute_Value pairs and repeatable attributes
    • Why? Using proprietary, non-GDSN attribute types & structures inhibits ease of data exchange and data mapping.  An example of a proprietary attribute includes multi-value ‘Flex attribute’ types in some particular data pools that are not defined in the GS1 XML schema.
  • Use of GDSN attributes that are defined in the GS1 Participant’s data dictionary. Any data pool that uses non-GDSN attributes (i.e. product attributes not defined and approved in the GS1 Participant’s Dictionary) is not compliant with GDSN standards.
    • Why? Any attribute not defined in the GS1 data dictionary cannot be commonly and openly understood by business systems and software developers. Therefore, using non-GDSN attributes requires custom integration, contradicting a key goal of using GDSN standards for data exchange.
  • Use GS1 valid code lists. For example, GS1 country codes, UOM codes, packaging type codes, clinical sizes, etc.).
    • Why? Using non-GS1 code values requires custom data conversion/translation which is costly to implement and even more costly to maintain. It also introduces opportunity for misinterpretation and data corruption.  Again, this defeats a key goal of system interoperability which is to reduce the cost of data exchange and e-commerce.

In addition to data pools not fully complying with GS1’s GDSN standards, the following aspects of GDSN are challenging for companies using machine-to-machine (M2M) integration to synchronize product master data.  These relate to governance of how GDSN standards are implemented at the data pool level.

  • Use of standard GTIN hierarchies. The current GTIN hierarchy structure for item publication message is to order the GTIN records from lowest level to highest.  Some data pools use an inverted GTIN hierarchy which existed prior to MjR3 in 2016 (see below).  While this is acceptable under GDSN guidelines, it is not the de facto standard.  This inverted GTIN hierarchy is acceptable only because the GS1 specifications leave much latitude for data pools to implement this aspect of the GDSN standards.


  • Use of standard GDSN message choreography. This is important to ensure that the messaging workflow and protocol is standardized.  Where a data pool operator overloads the use of a particular message for multiple purposes (such as the CIP), this requires custom implementations for data suppliers and ultimately, added cost.

Below is a comparison of the differences between non-GDSN data pool implementations versus GDSN compliant.

Proprietary Data Pools GDSN Compliant Data Pools
Flex attributes that are Non-GDSN Standard GDSN data pools use AVP attributes
Proprietary XML Schemas for CIN (Catalogue Item Notification), CIP (Catalogue Item Publication) and Response messages that are non-GDSN Standard GDSN data pools use GS1 XML Schemas that are standard for all GDSN certified data pools.
Publication actions:

1. Publish (New)
2. Publish (Initial Load)
3. Republish (New)
4. Republish (Initial Load)

Standard GDSN publication actions:

1. Publish
2. Republish
3. Unpublish

Single transaction number for each Item hierarchy and must be structured from highest to lowest in a CIN (Catalogue Item Notification) One transaction number for each GTIN within a hierarchy and must be in order from lowest to highest level in a CIN (Catalogue Item Notification)
Limit of 100 Item hierarchies for each CIN (Catalogue Item Notification) Limit of file size that equates to 500 Items
Every CIN (Catalogue Item Notification) requires publishing to at least one trading partner CIN (Catalogue Item Notification) for an Item hierarchy can be submitted without the need to publish to a trading partner.

Publications are submitted separately in CIP (Catalogue Item Publication)