What Are the Differences Between GDSN Data Pools?

GDD Attribute GDSN Support

The GS1 Global Data Dictionary (GDD) contains thousands of attributes, including both basic and category-specific information, such as allergens for grocery, dosage for health care, and textile material for apparel. The GDD also features multimedia attributes, such as 360-degree and montage images.

While not fully comprehensive, these attributes are sufficient for many use cases, including supply chain, shelf planning, and basic ecommerce listings.

All GDD attributes, however, are not supported by every GS1-certified GDSN data pool. Although these data pools are required to maintain complete support, many function without.

‘Top-Off’ Attribute GDSN Support

For attributes not listed in the GDD, there is a method for communicating information: “top-off” attributes. The GDSN allows suppliers or manufacturers to submit non-GDD attributes to be included in messaging as key-value pairs. This top-off attribution support sends key-value pairs not covered by the GDSN standard across the network.

Retailers invested in the GDSN as a transmission mechanism frequently extend the GDD to fit use cases.

Supermarket giant Kroger is one example of a retailer that relies heavily on the top-off attribute support method. Take one of Kroger’s classes, “spices and extracts,” as an example. This class contains 22 attributes, but the GDD standard supports only three. Outside of attributes like “level of cooking” and “number of servings per package,” the majority of these attributes communicate GDD attribute requirements to the GDSN using key-value pairs.

Many of these top-off attributes contain the most essential consumer information, such as whether products contain certain ingredients, such as flour or whole grains. While Kroger requires this information, it’s not an official part of the GDD.

Top-off attributes can be applied to almost every industry. These capabilities allow brands to utilize the GDSN to its fullest capabilities. For example, it will enable industrial brands to send technical digital or online attributes. It also allows for image URLs, digital asset URLs, and more.

Some GDD attributes also allow relationship-dependent data (RDD), which are GDD attribute values specific to a single retailer, rather than new attributes not covered by the GDD.

Data pools vary in their ability and incentive to use the GDSN to its fullest capabilities. Some data pools may coach their customers into not using the GDSN for top-off attributes in lieu of additional services and products when the GDSN is fully capable of supporting all product content attributes.

GDD Attribute Validation Rules for GDSN Targets

Specific GDSN targets, such as retailers or distributors, may require any subset of desired GDD attributes. Following this logic, brands with GDSN data pools that support all GDD attributes should be able to publish to any target easily.

This is technically true: GDSN data pools that support all GDD attributes — and that support sending key-value pairs for non-GDD attributes — technically can publish any transmittable content. However, brands have no way of knowing whether this publication will succeed.

Imagine a brand is interested in listing its products on the Kroger website. Its GDSN data pool must first answer the following questions:

• How many characters does Kroger allow in the product title?
• Which GDD attributes are required?
• Which key-value pairs are required for non-GDD attributes?
• Which values are required for GDD attributes with RDD?

If the GDSN data pool lacks answers to these questions, the brand will then face an extensive trial-and-error process for every product:

• Step 1: The brand publishes the product information to Kroger using the GDSN.
• Step 2: Kroger reviews and rejects the information with a hard-to-decipher automated message.
• Step 3: The brand responds to the rejection message.
• Step 4: The brand adjusts the product information and publishes it again.
• Step 5: Kroger reviews and rejects the information a second time. (This often happens when there is a primary and secondary reason for the rejection.)
• Step 6: The brand repeats this process.

GDSN data pools that support all GDD attributes can publish any GDSN-capable content in theory. But in practice, lack of target requirement transparency results in complicated approval processes. This is a significant gap in the GDSN standard, as every target should make machine-readable data requirements public to avoid these complications.

The lack of public requirements is a significant factor for the increase in regional GDSN data pools. For example, the GS1 Sweden GDSN data pools know the requirements for Swedish retailers, but the U.S.-based 1WorldSync data pool doesn’t.

Every GS1-certified data pool should be interoperable, empowering GDSN trading partners to choose whichever provider suits their business needs best. Unfortunately, the GDSN hasn’t lived up to its full global potential.

There is a lack of interconnectivity, which means there may not be a clear publish path from every GDSN data pool to every other. Even for interconnected data pools, there may still be challenges if both lack complete GDD attribute support.

The interconnecting process itself is actually simple, as an exchange of connection details, such as Applicability Statement 2 (AS2) certificates, between GDSN data pools is all that is needed.

Data Movement Into and Out of GDSN Data Pools

GS1 outlines many GDSN standards, including data movement between data pools and data structure, such as category-specific attributes. It doesn’t, however, require a specific format for data movement into and out of GDSN data pools.

Brands use a variety of programmatic mechanisms to move data into and out of GDSN data pools, including:

• Extensible Markup Language (XML) document standard
• JavaScript Object Notation (JSON) interface
• Representational State Transfer (REST) interface
• GraphQL interface

Some data pools use the traditional XML document standard, while others like Attribytes, Alkemics, and Salsify use more modern software as a service (SaaS) interfaces, such as JSON over REST or GraphQL.

Many companies rely on web portals to do the majority of the work for GDSN-related content — regardless of programmatic mechanisms. These portals allow all content to be uploaded using comma-separated values (CSVs) or spreadsheets. Many 1WorldSync customers interface with its data pool using this method, uploading one product at a time versus multiple products in bulk.

The GDSN is an exchange mechanism. Therefore, the ease of working with a GDSN data pool depends upon multiple factors, including the method for exchanging data within a data pool or responding to GDSN events.

This desire for ease of use has resulted in an entire category of software providers that do little more than move data into and out of specific data pools. (Lansa, acquired by 1WorldSync, is one example.) This software category represents another unnecessary expense — and potential point of failure — adding more complexity for brands using the GDSN.

Many product listings receive rejection messages because the information doesn't align precisely with the unique data validation rules of a GDSN target. The GDSN lacks a fully-specified error-messaging system, which is why these rejection messages — which are seldom machine-readable — are bespoke and created by every GDSN target.

Every GDSN data pool also has its own structure for relaying key user messages. Consider these features when analyzing messaging within a GDSN data pool:

• Does the data pool support email updates for rejection messages — or do users have to log on frequently to see these messages?
• Does the data pool offer a programmatic method for accessing messages, allowing them to automatically feed into product information management (PIM) or enterprise resource planning (ERP) workflows?
• Does the data pool generate reports showing average response times to track improvements over time?
• Does the data pool translate complicated system messaging into human-readable text — or do users have to call GDSN targets to clarify?

Data pools must empower brands to respond quickly to these messages, ensuring products make it to market without delay. However, some data pools have structures that may impact the quality of the brand's responses.

A significant portion of GDSN-related work happens within a data pool’s web portal, regardless of the completion-level of its programmatic interface. These web portals vary dramatically between the breadth of their features and ease of use.

Consider these factors when analyzing web portals for GDSN data pools:

• Is the web portal user-friendly?
• Does the web portal offer flexibility for its Microsoft Excel uploading capabilities? 
• Does the web portal have a workflow
• What is the process for uploading images?
• Does the web portal support 360-degree image spin uploads?

Outside of functionality specific to the GDSN, there is often additional work required to move data from PIM or ERP systems into GDSN data pools. Mapping data from the source system to the GDD is the most substantial of these tasks. GDD attributes with RDD or “top-off” attributes, for example, require separate input values for every unique GDSN endpoint.

From character length requirements for product titles to product identification, every target can have different attribute specifications. When loading this data from a source system, it must be mapped from the source system to the GDD — and even within the GDD, some data transformation may be required.

This process is why many larger customers of 1WorldSync have historically used Lansa alongside the 1WorldSync data pool. Lansa would load data from a manufacturer’s PIM or ERP system and transform it to meet specific endpoint requirements. However, this leads to additional licensing costs and systems to maintain. Brands who do not have a solution provider, such as Lansa, then face time-consuming and error-prone manual data entry processes.

Data pool flexibility for loading and mapping data will determine whether a brand needs additional systems for on-ramping to the GDSN.

When the GDSN was first established in 2004, there were several GDSN data pool providers. Through mergers and acquisitions, however, one major global player began to emerge on the market among the smaller players: 1WorldSync.

The issue: 1WorldSync was owned by GS1 U.S. at the time, leading to a strong perception in the market that its data pool was the risk-free, must-use option. This misconception about a 1WorldSync monopoly was most resilient among the largest brand manufacturers, many of whom had seats on the 1WorldSync board of directors.

Another issue that arises when a single provider runs 80% of a market is that data pool interoperability no longer matters.

GS1 recognized how competitive the market had become and sold 1WorldSync to Battery Ventures in 2019. This move was meant to encourage new GDSN data pool entrants and impact pricing models across the market.

From a cost perspective, GDSN data pools should be commodity offerings, priced using a cost-plus model. The substantial differences between GDSN data pools, however, leads to varying value-based pricing models.

Tying the cost of accessing a GDSN data pool to revenue is one example of a historic pricing model, which 1WorldSync uses, which isn’t aligned with service delivery costs or value.

The perceived monopoly position, overall size, and GS1 affiliation of the 1WorldSync data pool also enables it to charge based on the total revenue of brand manufacturers. This pricing model results in many contracts that approach $1 million annually for what is a commodity technology at its core.

Brands that are new, niche, or direct to consumer (D2C) opt-out of the GDSN altogether due to these costs, choosing to deal directly with retailers. Walmart stopped requiring GDSN capabilities from brands — and Amazon, W. W. Grainger, and The Home Depot have never required them.

The GDSN is a data standard, but data pools can differ considerably — making the selection process demanding. The current limitations of the standard force data pools to sidestep requirements, eschewing the best interests of brands.

When evaluating GDSN data pools, it’s important to consider the following questions for each data pool:

• How does it support GDD attributes?
• How does it support top-off attributes, including both key-value pairs and RDD?
• Is it interoperable with every other important data pool?
• What are the methods of communication?
• What features does its web portal provide?
• Does it allow bulk uploads?
• What is its pricing model?

The GDSN can work for the digital shelf: GDSN data pools must provide complete interoperability, GDD attribute support, and transparency into GDSN target requirements. They must also offer efficient data movement processes, clear messaging capabilities, streamlined user interfaces, and cost-plus pricing models.