Demand Signal Repository

AMR Research defined the demand signal repository (DSR) as a robust centralized database that stores large volumes of demand data—such as point-of-sale (POS) data, inventory movement, promotional data, and customer loyalty data—to feed the applications that support demand-driven supply networks (DDSNs).

A successful DSR is designed for ease of data loading and data extraction with the need for partitioning and management of hierarchical data models. The typical horizon of data storage in a DSR is two or three years of history for demand data. Companies have a choice in the level of granularity of the data, which greatly affects sizing requirements.  This is covered in greater detail at the end of this document.

The DSR contains item attributes, store attributes, and demand insight data from retailers. It provides item, location, and calendar harmonization for disparate data types: POS data from stores, ERP data, and syndicated data from ACNielsen and IRI. It is the source of retail-specific information for retail forecasts, store withdrawals, shipments, and planograms, providing demand insight data on why the customer bought within the category.

This includes promotion and turn data, weather and other causal factors, demographic data by store cluster, and market basket insights. It should also include CP company shipments, forecasts, hierarchies, and master data. Longer term, the DSR should integrate and harmonize downstream POS data with internal data and syndicated data to give you a complete picture of inventory, sales, competitive landscape and supply chain insights.


The demand signal repository accomplishes three primary goals:

       Centralized database for consistent reporting across all retailer POS—It is the central database for all demand data: syndicated data, POS data, internal ERP data such as shipments, forecasts, and supply chain, and retail store loyalty data.

Store level inventory management and alerts—This is the ‘big bang for the buck’, allowing you to increase revenues by pin-pointing inventory issues before they cost your company a bundle. A properly designed DSR will give you insight into store level inventory for each item.  This includes stock-outs and pre-emptive alerts for low inventory levels. 

       Cross-functional reporting and analysis—With a harmonized source of data, the DSR supports cross-functional reporting and analysis.

Support for enterprise applications—It serves as the “hub” to facilitate the integration of demand data to applications across the organization. 


CP companies have unique characteristics:

Category captain roles—A unique relationship within the CP industry is the concept of category captain. When a retailer designates a CP supplier as category captain, it has the responsibilities of designing the shelf and establishing the planogram for the category. To support this type of analysis, a company with category captain status needs access and database support for all of the data in the category.

Richness of data becoming more mainstream—Mega retailers Wal-Mart and Target have a rich set of downstream data that is unique to this industry. Other retailers in the drug and grocery channels are beefing up their data offerings.  This trend will continue as retailers demand suppliers manage store level inventories.

Syndicated data—Unlike many industries, the CP industry has rich syndicated data sources that allow the CP manufacturer to see retail movement of its products versus competitive products or the market basket factors of its category versus another category. The primary problem with this data is its two-week lag, complexity and cost of the data, and the effectiveness of this data as it pertains to inventory management and store level insights.

Disparate data sources—Data from the various retailers come in a variety of formats and data points. Wal-Mart and Target data can be pulled via browser, while others will only provide data through EDI or flat files. Some can be assessed daily or multiple times per day, while EDI and flat file feeds are typically weekly imports of daily level data.

Data harmonization requirements—Each of the data feeds requires data cleansing and validation. All retailer POS is then harmonization for item, location (store/DC), and calendar (retailer calendars along with your fiscal year calendar) to make the information useful for both internal decision support or enterprise reporting, and external reporting to the retail account.

Why investment in a demand signal repository?

       Changes in syndicated data—In July 2001, Wal-Mart stopped sharing POS data with syndicated data providers of Information Resources (IRI) and ACNielsen. For many CP companies, this represents 20% to 40% of volume that was no longer available in the syndicated data pools.


       Focus on new product launch and store compliance—It is becoming increasingly important to bottom line revenue to monitor the execution of new product launch. DSR deployments should know if new products are selling in all authorized stores and alert you to which stores appear to be problematic. Since 50% of new product launch failures are related to store execution, this closed-loop sensing has become a critical component of new product launch strategies.


       Execution of product promotions—The high demand error on promotional items, often 80%, has required companies to become more demand sensing (to sense actual product movement based on analysis of store point of sale and warehouse withdrawal information) and move to pull-based supply chain strategies. In addition, some innovators moved to pay-for-performance incentives for trade promotions.


How large is a DSR?


The size is determined by the required data granularity, the attribute-level required detail, and the number of retailers, and the density of items at each of the retailers.


Variables affecting DSR size:


·         Is the data daily or weekly?  Daily data is 7 times as large as weekly.

·         How many retailers do you wish to include?  Think about the 80/20 rule. 80% of your overall sales is made up of your top 5, 10, 20...retail accounts.  Cover the 80% first, then do the remainder in a 2nd phase.

·         You will likely want the data at the store level.  If so, how many stores per retailer.

·         How many active (not total UPC’s) items/UPC’s do you have on average at each retail store? 

·         Here’s the calculation:

Let’s say you have 50 active UPC’s but, on average, any 10 will sell on any given day.  You are calculating for a retailer that has 3000 stores and you receive daily level POS data from the retailer.


·         Remember to take into consideration disk required for development.