Retailer Data
What is retailer data?
Retailer data is everything a CPG brand learns about how its products actually sell at retail — portal exports, point-of-sale scans, EDI documents, and syndicated panels. The data is the problem and the opportunity: every retailer hands it over in a different shape.
Retailer data, defined
Retailer data is the set of feeds a brand uses to answer one question: what happened to my product after it left the warehouse? It covers the order the retailer placed, the shipment that fulfilled it, the invoice and the deductions, and — the part everyone actually wants — the units that scanned at the register.
It arrives from two directions. First-party retailer data comes straight from one retailer’s systems: a Retail Link export, a KeHE Connect report, an EDI 852 product activity file. Third-party retailer data is the same POS scans pooled across many retailers by a syndicated provider and sold back as a market view. A brand needs both — first-party data is granular and fresh but blind to the category; syndicated data sees the category but lags and generalizes.
The reason “retailer data” is worth treating as one topic is that it almost never arrives as one dataset. A brand selling into a dozen accounts is pulling a dozen portals, each with its own login, its own item identifiers, its own week definition, and its own idea of what a “store” is. The work is not getting the data — it is making it agree.
The kinds of retailer data
Four feeds do most of the work. They answer different questions, update on different clocks, and rarely share a format.
Retailer portal data
First-party data straight from one retailer's vendor portal — Walmart Retail Link, Target POL, Kroger Stratum, KeHE Connect, Whole Foods via 84.51°/Market6. The most granular and freshest view a brand can get, but scoped to a single account and formatted differently in every portal.
POS data
Point-of-sale scan data — the units and dollars that rang up at the register, by item, store, and week. POS data is the raw what-sold signal underneath both portal exports and syndicated panels. It tells you what moved; it does not tell you who bought it.
Syndicated data
POS data aggregated across many retailers by a third party — SPINS, NielsenIQ, Circana — and sold back as a normalized market view. Syndicated data is the only way to see your category and your competitors; portal data only ever shows your own shelf at one account.
EDI transactions
The operational data exchange that runs the trading relationship — purchase orders, advance ship notices, invoices, and remittances moving between a brand and a retailer as standardized EDI documents. Not sell-through data, but the backbone every other retailer feed depends on.
Portal data vs. syndicated data
The most useful distinction in retailer data is first-party portal data versus third-party syndicated data, because they fail in opposite directions.
Portal data is yours, at one retailer, in detail. Retail Link can show a brand store-level inventory and daily sales; KeHE Connect can show distributor movement down to the ship-point. It is the freshest and most granular view a brand will ever get — and it is completely blind to the rest of the category. A portal cannot tell you whether your 3% decline is a you problem or a category problem, because it only ever shows you.
Syndicated data trades granularity for context. SPINS, NielsenIQ, and Circana pool POS scans across thousands of stores and sell the aggregate, so a brand can finally see its share, its competitors, and the category trend. The cost is lag (syndicated weeks close later than a portal export) and generalization (projected panels, not a census). For a fuller treatment of the syndicated side, see What is syndicated data?
Neither one is the “real” data. A brand that plans off portal data alone over-rotates on its own shelf; a brand that plans off syndicated data alone is always a few weeks behind and never sees store-level detail. The teams that read retail well use portal data for the what-happened-here and syndicated data for the what-it-means.
The harmonization problem
Every retailer feed measures roughly the same thing — units, dollars, stores, weeks — and no two express it the same way. One portal keys on UPC, another on its own internal item number. One calls the week ending Saturday, another Sunday. One reports a store; another reports a distribution center that fans out to forty stores. Promotions are flagged in one feed and invisible in the next.
So the real cost of retailer data is not licensing — it is the analyst-hours spent reconciling it. Most CPG teams do this in a spreadsheet: a tab per retailer, a mapping table for item codes, a fragile set of formulas that one portal format change quietly breaks. The report is always a week late because the merge took a week.
This is the lane every page in this cluster comes back to. Whether the feed is Retail Link, KeHE Connect, raw POS data, or EDI transactions, the value shows up only after the feeds are made to agree.
Where Scout fits
Scout is the analytics layer that sits on top of retailer data. It is not a retailer portal and not an EDI gateway — it does not replace Retail Link or move purchase orders. What it does is the harmonization step: it ingests the portal exports, the POS files, and the syndicated panels a brand already has, normalizes the item codes and week definitions, and turns the pile of incompatible feeds into one queryable view.
The point is the week the spreadsheet was costing. Once the feeds are harmonized, velocity, distribution, and promo reads come out of one place instead of a manual merge — and the same data is ready for the planning work downstream, from supply chain analytics to the demand side of sales and operations planning.
Go deeper on retailer data
The rest of this cluster covers each feed in detail and the analytics that sit on top of them.
AI retail analytics platform
What an AI retail analytics platform does, how it differs from a BI tool, and the capabilities that decide whether it earns its seat.
Retail Link data
What Walmart's Retail Link portal gives a supplier, the reports that matter, and how to use it without living inside it.
KeHE Connect
The distributor portal natural and specialty brands use to read KeHE sell-through — what it shows and what it leaves out.
POS data
What point-of-sale data measures, what it cannot see, and how brands turn raw scans into velocity and distribution reads.
EDI transactions
The EDI documents that run a retail trading relationship — POs, ASNs, invoices — and why they are a data source, not just plumbing.
Supply chain analytics
How retailer data feeds the supply side — demand signal, on-shelf availability, and the analytics that keep a retail supply chain stocked.
Sales and operations planning
What S&OP is, why retail sell-through belongs in the demand plan, and how brands close the gap between the forecast and the shelf.
Tell us what you’re working on
A 30-minute conversation to scope fit. Pick a time that works for you.