Point of sale data analytics means something different when you sell the product instead of running the store. A retailer uses POS to close tills, manage inventory, watch labor, and run the business. A CPG supplier receives a narrower window. It sees some combination of item, store, period, units, and sales value from retailers willing to share those records.
That window can settle real arguments. It is also easy to overread. A sale proves that an item rang up. A blank row does not prove an empty shelf. A period-level selling price does not reproduce the tag a shopper saw on Tuesday afternoon. Strong supplier analysis starts by keeping those boundaries intact.
We are gmware, a software and data engineering firm in Austin, TX, with delivery centers in Bangalore and Mohali, India. We build the pipes and master-data layers that make retailer feeds usable. We also run Shield Suite Competitive Intelligence, retail intelligence for beverage-alcohol brands across 60,000+ storefronts. Shield Suite does not provide retailer-owned POS feeds. It covers physical shelf facts that a register record cannot see.
| Supplier question | POS can contribute | What else may be needed |
|---|---|---|
| What sold at this retailer? | Units and sales by item, store, period | A clean item and account map |
| Where did velocity change? | Comparable time series | Distribution and calendar context |
| Was the shelf empty? | A zero-sales signal | Inventory or shelf observation |
| Did the display appear? | Sales response, sometimes a flag | Dated evidence from the floor |
| What price did shoppers see? | Amount charged on sold units | The observed shelf tag |
If your retailer feeds exist but arrive in incompatible schemas, start with data analytics and business intelligence engineering to normalize items, locations, calendars, and corrections. If the missing fact is on the physical shelf rather than in the feed, evaluate Shield Suite Competitive Intelligence. It adds observed evidence; it does not manufacture retailer transactions.
Supplier POS analytics starts with a feed boundary
There is no universal supplier POS file. A direct retailer feed might be daily and store-level. Another retailer may send weekly totals by item and region. A syndicated product may standardize many participating retailers, mask their identities, and project a sample into a defined market. Those are different instruments, even when the dashboard labels all three “POS.”
The public NielsenIQ research documentation from the Kilts Center at Chicago Booth shows one useful example of the grain. Its scanner data is weekly by UPC and store, with units, price, price multiplier, baseline measures, and feature and display indicators. Store attributes include chain code, channel, and area. Retailer names are masked, and feature and display fields come from only a subset of stores.
A second Kilts dataset shows how much the shape can change. The PDI Skupos research data is daily, UPC-level transaction data from independent and small convenience-store chains. It includes quantity, unit price, discount, amount paid, basket value, loyalty ID, and payment type. Its published coverage varies by state and averages 10% of conventional convenience stores. More detail at a different channel and coverage boundary.
Before writing a query, put the feed contract next to the dashboard and answer six plain questions:
- Which retailers and stores are actually represented?
- Is the file a direct census of participating locations or a projected sample?
- What is the lowest usable grain: transaction, day, week, store, item, or market?
- Does an absent row mean zero sales, missing delivery, suppression, or “not carried”?
- Are returns, discounts, and corrections restated in earlier periods?
- Which retailer calendar defines a week and a year?
If the team cannot answer those questions, it is not ready for comparative analysis. The dashboard may still render. The conclusion will not survive a buyer meeting.
From register row to supplier decision
Join retailer items to the product master before measuring anything
Retailer item 184726, UPC 012345678905, supplier SKU TQ750, and “Tequila Silver 750” may describe one sellable unit. They may also describe different pack levels, a discontinued label, or a retailer-created bundle. A text match is not enough.
The supplier product master should provide one durable internal ID for each sellable item and preserve every external identifier as an alias with an effective date. Keep the retailer’s description, UPC or GTIN, pack, size, brand, flavor, and category beside the match. Then assign a status: matched, ambiguous, pending, or excluded. Never silently send an unmatched item to “other.” That hides the very launch and packaging changes the commercial team needs to see.
Pack conversion deserves its own rule. A retailer may report eaches while the supplier plans in cases. If a six-pack and a single bottle share a careless description match, unit velocity becomes fiction. Store the original quantity, the conversion factor used, and the normalized quantity as separate fields. That makes the arithmetic reviewable when somebody asks why the retailer portal and the warehouse differ.
The same care applies to product history. UPC changes, bonus packs, reformulations, and label refreshes can split one commercial product across identifiers. Sometimes that split should remain because the package is part of the analysis. Sometimes several records should roll into one brand-family view. Decide at query time through a hierarchy, not by overwriting source rows.
This is where point of sale data analysis software earns or loses trust. Charts are easy. A review queue for uncertain matches, effective-dated mappings, and pack-level controls is the part that keeps a quarter of history from changing without explanation.
Join locations to the account master with equal care
A store number is only unique inside the retailer that issued it. Store 104 for one chain has nothing to do with store 104 for another. Even within a chain, locations close, move, reopen, and change banners. Build the account ID from retailer context plus the retailer’s location identifier, then map it to the supplier’s account hierarchy.
That hierarchy usually needs more than a store name. Keep physical address, banner, parent account, channel, market, distributor territory, sales territory, and effective dates where the source provides them. A supplier asking “Which distributor territory lost velocity?” needs the store-to-territory bridge that POS never supplies on its own.
Global identifiers can help when trading partners use them consistently. GS1 US defines a Global Location Number as a 13-digit identifier for organizations, parties, and physical or functional locations. In practice, many feeds still arrive with retailer-specific store numbers. Preserve both. A common identifier is useful; a retailer alias table remains necessary.
Do not merge two locations because their names look alike. “Main Street Market” and “Main St Mkt” might be one store, two stores, or a renamed account. Match on stable identifiers first, address components second, and send uncertain cases to review. The cost of a false merge is high because it contaminates every store-level trend built on top.
The two joins that decide whether the numbers tie
What POS can prove for a supplier
At its strongest, POS proves that a reported item sold in a reported location or market during a reported period, at the grain and coverage defined by the feed. From that base, a supplier can calculate useful measures.
Sell-through trends show whether units are accelerating or slowing inside the covered stores. Store and item comparisons reveal local exceptions hidden by a market total. Realized sales value divided by units can show the average amount collected per sold unit, provided the treatment of returns, discounts, multipliers, and taxes is understood. A direct feed with stable store coverage can support pre-period and post-period comparisons around a promotion.
The wording matters. “Sales rose after the promotion” is supported by the observed sequence. “The promotion caused the rise” needs a credible comparison, such as untreated stores with similar prior behavior, and control for distribution, price, seasonality, and other events. POS supplies an outcome. It does not supply causation by itself.
A supplier can also use POS to prioritize questions. A run of zero-unit days in a previously productive account deserves investigation. A sharp drop after a package transition points the item-mapping team toward a possible break. A retailer whose realized price moved away from peers may need a pricing review. These are leads for action, not final diagnoses.
For a deeper look at the source itself, including participant coverage and projected panels, read our scan data explainer. If you are reconciling consumer takeaway with cases shipped into accounts, the separate depletion data guide covers that boundary without repeating it here.
What POS cannot prove
A register sees a sale. It does not see the shelf between sales. We keep finding the same four mistakes in supplier reports.
First, zero sales does not prove an out of stock. The item may be present but slow. The store may never have authorized it. The record may be late. The location may be closed. A retailer inventory field helps, but its definition and update rules still matter. Direct observation can show whether the product was physically present at a given time.
Second, realized POS price is not always the current shelf tag. A weekly average can blend regular and promoted transactions. Basket discounts or loyalty rules can change the amount charged without changing the printed tag. If the commercial question is “What did sold units ring at?”, use POS. If it is “What offer did the shopper see at this store today?”, observe the tag.
Third, sales do not prove a display, feature, facing count, or shelf position. Some datasets carry feature and display flags, but the NielsenIQ research documentation says those fields are available only from a subset of stores. A flag also does not create dated visual proof that an agreed display appeared on the floor.
Fourth, POS cannot explain a competitor’s physical move. A competitor may gain sales because it gained facings, moved into a cold box, cut price, ran a display, or simply drew more demand. The transaction outcome does not choose among those causes.
Two instruments, two kinds of evidence
How shelf observation complements retailer feeds
The clean join is item, location, and time. Match an observed SKU and storefront to the same product and account keys used by POS, then align the observation timestamp to the appropriate sales window. Do not pretend a Monday photo describes the whole week. It describes Monday at that store.
Once joined, the pair supports better questions. Sales fell and the product was absent during a visit: investigate replenishment or a distribution problem. Sales fell while the product was present at the expected price: look at demand, competition, and placement. POS price dropped but the observed tag did not: inspect discount mechanics or timing before claiming price drift. A planned display has sales movement but no floor evidence: do not mark execution complete from the sales response alone.
This is the role of Shield Suite Competitive Intelligence. It records competitor shelf presence, pricing by market, promotion and display evidence, and changes at the storefront. It does not deliver a retailer’s owned transactions, shopper baskets, or unit sales. For brands that already have POS, it adds the physical context needed to interpret a result. For stores outside the feed, it supplies a different kind of evidence rather than inventing sales.
Choosing POS data analysis software as a supplier
Start with the feed, not the demo. Software cannot recover stores the retailer did not share or fields the contract does not include. Ask a vendor to load a real sample and show five things before discussing dashboard polish:
- the unmatched item and location queues;
- the raw-to-normalized quantity calculation;
- the retailer calendar and restatement rules;
- the store coverage denominator behind every comparison;
- the path from one chart value back to its source rows.
Then test a known hard period, such as an item transition or a store closure. If the system smooths the break away, sends it to “other,” or cannot explain the mapping used at that time, it is not ready for supplier decisions.
A spreadsheet can carry one clean feed and a modest product list. Buy software or build a warehouse when retailer formats multiply, mappings need effective dates, corrections arrive after close, or account teams need the same governed result. Our data analytics and BI practice handles that integration layer when a brand has outgrown manual reconciliation. Bring one source schema, the current product and account masters, and a closed reporting period. We can scope the ingestion, matching queues, replay rules, and governed output before anyone commits to a larger platform.
What we’d recommend
Keep the retailer POS feeds you can obtain. They are the strongest evidence of what sold inside their stated coverage, and direct retailer data should be treated as an asset, not dismissed because it has boundaries. Build the item and account masters before piling on calculated metrics. Put coverage, grain, and missing-row rules where every analyst can see them.
Then list the decisions that still depend on a physical fact: availability, shelf tag, facings, placement, display execution, or competitor presence. Cover those with direct observation. Do not make POS impersonate shelf data, and do not make shelf data impersonate transactions.
That combination is especially useful in beverage alcohol, where retailer feeds and store coverage vary. We work with beverage-alcohol suppliers and distributors on the reconciliation underneath both sources. Send us a sample POS schema, your product master, and the shelf questions your account team keeps asking. We’ll give you a straight answer on which joins belong in your warehouse, which questions Shield Suite can cover, and which claims neither source can support.