TDLinx: the universal store code, explained

What TDLinx is

TDLinx is a NielsenIQ store-location database organised around a universal code for every physical retail and on-premise outlet. NielsenIQ describes it as "the industry's universal store identifier, connecting retailers, brands, distributors, and suppliers," and as "a dynamic catalog of retail and on-premise location data" that assigns "a universal code to every store and account," updated daily.

The reason a CPG or retail analyst learns the name is almost never the database itself. It is the moment two files that should describe the same 340 stores turn out to describe 326 of them and disagree about the rest.

What a TDLinx code actually is

The code is defined in the TDLinx data dictionary, which describes the store and outlet code field (STDLINXSCD) as a "Seven-digit computer-generated number assigned to the physical location of the store/outlet," and adds that "this number remains with the location regardless of changes in ownership or trade channel."

Both halves of that second sentence carry weight for anyone joining data.

• It is keyed to the building, not the business. When a store is sold, the banner changes and the code does not. That makes a TDLinx code the right key for a like-for-like store comparison across a period when ownership moved, and the wrong key if what you actually meant was "stores this account operated in 2024."
• It survives a channel reclassification. A site that moves between trade channels keeps its number, so channel is an attribute of the record rather than something encoded in the key.

Around the code sit the attributes that make it useful. NielsenIQ says the data carries "store, banner, ownership, and channel definitions," runs to specifics from "ACV to selling square feet," and supports "rollups of store data across ownership, banner, and account hierarchies."

USDA's Economic Research Service, which licenses the data for food-access research, records the same picture from the outside: the retail channels available are "grocery, drug, mass merchandisers/dollar, wholesale club, and convenience"; each location gets "a channel and a subchannel based on industry-accepted retail channel classifications"; and the records carry "individual food store names and owner relationships (i.e., names of parent companies)" alongside USPS standardized addresses, geocodes, FIPS codes, and flags for whether items such as gas, liquor, wine, beer and pharmaceuticals are sold at a location. ERS also notes that the database is continuously updated to reflect "openings, closings, changes in owner, banner, supplier, or other store characteristics over time."

On scale, published figures come from partners rather than from NielsenIQ's own product page. Andavi Solutions, a NielsenIQ connected partner in beverage alcohol, states the database provides "universal coverage and unique codes for every store in retail trade channels and for every outlet in on-premise trade," covering "over 770,000 stores/outlets and more than 9,800 accounts."

Why the store-matching problem exists

Every system that touches a store gives it a different name. Here is one physical location as four systems see it.

Only one of those four is stable across companies, and the fourth is the one most teams end up matching on. Name-and-address matching on 340 stores at 96% accuracy leaves 14 stores unresolved, and those 14 do not fail quietly: their volume either drops out of the total or lands under the wrong banner. At an average $1.4M a year per store, that is $19.6M of sales sitting in the wrong row of a chain summary, and the summary still foots.

That is what a universal store identifier buys. Match once to the TDLinx code, store the mapping, and every subsequent join is exact rather than fuzzy. It is also why the code shows up as a column in distributor and syndicated files that have nothing else in common.

What TDLinx is not

TDLinx is store master data. It is not sales data. The code tells you a store exists, where it is, what channel it is in, who owns it and roughly how big it is. It does not tell you what sold there. Movement comes from the retailer's own POS, a distributor feed, or a syndicated service such as Circana, and the TDLinx code is the key you use to attach those to a location rather than a substitute for them.

It is also not a free or open identifier. Access is licensed, which is the practical reason many operators and smaller brands end up doing address matching anyway.

Where Scout fits

Store matching is real work in any ingest that combines a retailer's own POS with distributor files, and Scout does that join on every account it onboards. Where a file already carries a TDLinx code, that column is the cleanest key available and is worth carrying through the load untouched. Where it does not, the mapping gets built once against the retailer's own store list and then held, rather than re-derived from names and addresses every week. Scout does not license or resell TDLinx data, and nothing on this page is a NielsenIQ product we sell.

The short version

• TDLinx is NielsenIQ's store-location database and the universal store identifier that sits at the centre of it.
• The store code is a seven-digit computer-generated number tied to the physical location, and it stays with that location through changes of ownership and trade channel.
• Records carry banner, ownership, channel and subchannel, addresses, geocodes and size attributes, and roll up across ownership, banner and account hierarchies.
• Its value is the join. Fuzzy name-and-address matching at 96% still misplaces 14 stores in 340, and their volume lands somewhere wrong.

Sources: NielsenIQ, "TDLinx"; TDLinx Data Dictionary (Nielsen, via Environics Analytics); USDA ERS, "Using Proprietary Data"; Andavi Solutions, "Technologies".