An established CPG team rarely lacks data. It lacks agreement about which source should settle which question.
The category team has syndicated measures. Sales has retailer portals and distributor files. Finance trusts invoices. Revenue growth management has price and promotion extracts. Field teams have photos, forms, and notes. Each source can be accurate and still disagree with the others because it recorded a different event, at a different grain, on a different calendar.
That is the real CPG analytics problem. Buying another dashboard before sorting out those boundaries creates one more place for the disagreement to appear.
We’re gmware, a software and data engineering firm in Austin, TX, with delivery centers in Bangalore and Mohali, India. We build the warehouses and reporting layers that connect commercial feeds. We also run Shield Suite Competitive Intelligence, which observes the physical shelf for beverage-alcohol brands across 60,000+ storefronts. It fills one specific gap in a larger stack. It is not the larger stack.
| Data layer | Event it records | Best commercial use | Built-in blind spot |
|---|---|---|---|
| Syndicated data | Purchase or register activity in a measured universe | Category, share, shopper context | Accounts outside the instrument |
| Distributor data | Product shipped to a downstream account | Distribution, sell-in, depletions | What happened after delivery |
| Shelf observation | Product, tag, or display seen in a store | Availability, price, execution | Units sold between visits |
| Internal data | Your order, invoice, spend, or plan | Margin, targets, account economics | Competitor and category activity |
The stack works when every layer has a job and none is asked to impersonate another.
If the unresolved question is a physical shelf condition in US off-premise beverage alcohol, start with Shield Suite Competitive Intelligence. If the sources already exist but product codes, account hierarchies, calendars, and measures do not reconcile, start with data analytics and business intelligence engineering. One route buys missing evidence. The other makes contracted evidence usable.
Start with decisions, not software categories
A search for CPG analytics tools produces an awkward mix: data subscriptions, BI products, trade-promotion systems, forecasting software, retailer portals, field-sales apps, and consulting firms. Comparing all of them in one feature grid is useless. They do different work.
Start with a decision register. Write down the recurring commercial decisions that need better evidence, who owns each one, when it is made, and what action follows. A mature team might include:
- category reviews and assortment proposals
- market and account prioritization
- distributor performance reviews
- price and promotion analysis
- out-of-stock and distribution-void work
- display and feature verification
- demand planning and financial forecasting
Then write the observable event behind each decision. “Pricing performance” is too vague. Do you need the shelf tag a shopper saw, the average price paid at the register, the net price on your invoice, or the distributor’s price to the retailer? Those are four different fields. A polished CPG retail analytics interface cannot make them interchangeable.
Choose the sensor before the screen
Layer 1: syndicated data for the market outside your walls
Syndicated data is research collected and standardized for sale to multiple subscribers. That describes the commercial arrangement, not one collection method. Consumer panels, retailer measurement, and some route-to-market datasets may all be syndicated while observing different events.
Household panels can add buyer and basket context that internal order records cannot. NIQ describes Homescan as a longitudinal consumer panel with UPC-level product detail (NIQ). Retailer measurement, by contrast, is built from participating retail transactions and is used for category and market reads. If your question is share, category growth, buyer profile, or repeat behavior, this is the likely layer.
Its weakness is fit. Coverage, geography, channel definitions, category trees, projection, and release timing were designed before your team arrived. Fine cuts can become less useful even when the national view is sound. Before contracting, ask for the measured universe and methodology at the exact grain used in your decision. A national category total does not prove that your priority independents, club stores, convenience accounts, or regional chains are represented the way you assume.
We cover the collection methods and their blind spots in our syndicated data guide. For stack selection, the point is simpler: use syndicated data to understand the market and shopper. Do not force it to serve as a store worklist unless the purchased grain and rights genuinely support that job.
Layer 2: distributor and route-to-market data for movement into accounts
Distributor data records movement between commercial parties. In beverage alcohol, depletion data generally means cases shipped from a distributor to a retail or on-premise account. WSWA says SipSource is based on item-level transactions between distributors and retailers and reports volume in nine-liter case equivalents (WSWA). Other CPG routes may use wholesaler shipments, direct-store-delivery records, orders, invoices, or inventory feeds.
This layer is good at telling an established team where product moved, which accounts ordered, and how distributor activity changed. It is often the most actionable source for a sales organization because it carries an account and a product code.
It stops at delivery. A shipment into a store can sit in the back room, reach the shelf, sell through, or be returned. The shipment record alone cannot distinguish those outcomes. Beverage teams that need the mechanics can use our depletion data field guide rather than treating depletions as retail sales.
The hard work here is identity. The same item may have a manufacturer GTIN, distributor item codes, retailer item codes, and internal finance codes. GS1 defines the Global Trade Item Number as the identifier for trade items (GS1), but a GTIN does not automatically repair every historical file or account hierarchy. Your stack still needs crosswalks, effective dates, and an owner for exceptions.
Layer 3: retail shelf observation for physical conditions
Shelf observation records a state at a store at a moment: whether an authorized item is present, the price printed on the tag, whether a display appears, or what competing products occupy the shelf. Field audits can capture this during scheduled visits. Repsly, for example, describes field execution around planogram compliance, on-shelf availability, and competitor tracking (Repsly). Other observation models use different collection operations, so buyers should examine the evidence and coverage rather than assuming the methods are equivalent.
This layer answers questions that money records cannot. An invoice does not prove a display reached the floor. A derived average selling price is not the same thing as the tag visible during a visit. A depletion does not show whether an authorized SKU is absent today.
Observation has a clean limit: it does not count sales. A shelf image cannot establish category share or household repeat. It also creates a sampling question. A finding applies to the store and time observed; extending it beyond that requires a defensible design.
Shield Suite sits here, specifically for beverage alcohol. Shield Suite Competitive Intelligence covers competitor shelf activity, while the suite also covers out-of-stock and distribution-void reporting, observed price to consumer, and marketing monitoring. A general CPG brand outside that scope should choose an observation method suited to its category. A beverage-alcohol team should still keep its syndicated, distributor, POS, and internal systems. Shelf evidence complements them.
Layer 4: internal sales, finance, and planning data
Internal data is the only layer built around your economics. Orders, invoices, deductions, trade plans, promotional commitments, product cost, targets, and account ownership live here. This is where the company knows what it intended to happen and what it paid.
It is also where definitions multiply. Finance recognizes revenue according to accounting rules. Sales recognizes an account against a territory. Category teams group products for a buyer conversation. Supply planning groups them for production. None of those hierarchies is inherently wrong, but putting one unlabeled “sales” field on a dashboard invites a fight.
Keep the source transaction and its business definition. Then publish governed measures for specific uses. Microsoft’s Power BI guidance makes the same modeling distinction: dimension tables support filtering and grouping, while fact tables support summarization, with a consistent grain inside each fact table (Microsoft). The lesson applies beyond Power BI. A consumer packaged goods analytics model needs stable product, customer, market, and calendar dimensions, plus facts that do not quietly mix cases, units, dollars, and observations.
Build the reconciliation layer before the executive dashboard
Four feeds do not become a stack because they share a login. They become a stack when a product, account, location, and period mean the same thing across them, or when the differences are explicit.
The reconciliation layer
Keep raw files unchanged. Transform them in a separate layer. Attach source, extraction time, coverage status, projection status, and unit to every record where those attributes matter. When a provider restates history or an account changes banners, effective-dated mappings let you rebuild the report without overwriting what was known before.
Then create exception workflows, not just charts. If shelf observation finds an authorized item absent, who receives the store list? If distributor shipments rise while syndicated takeaway stays flat, who checks buy-ahead and inventory? If finance and sales totals disagree, which definition governs the meeting? A metric without an owner and a next action is decoration.
This is where data analytics and business intelligence work earns its keep. The useful part is rarely drawing another line chart. It is preserving source meaning while giving commercial teams one place to investigate an exception.
Test the joins with your own exceptions
A stack evaluation should test reconciliation rather than replay a vendor’s general product demo. Use a reporting period your team has already closed. Include a package change, an account that changed banners, a late restatement, two calendars, and a store or item that should remain unmatched.
Ask the implementation to produce a source-to-report trace for each case. The output should show the original record, mapping version, conversion rule, coverage state, correction history, and governed measure that reached the report. Unknown records must stay in an exception queue. They should not disappear into “other” or become zero.
Then test replay. Correct one mapping and rebuild the affected period without editing the raw files. If the result cannot be reproduced, the stack has a lineage problem rather than a dashboard problem. This is the proof that matters before wider integration work.
A buying process that exposes weak data
Where established teams overspend
The first pattern is overlapping subscriptions. Two platforms may repackage the same underlying feed with different interfaces. Ask who originated the data and whether you are buying a new instrument or a second delivery layer.
The second is enterprise breadth without operating depth. A global platform can look economical until the team discovers that a priority market, channel, or store class is missing. Coverage needs to be evaluated against revenue and decisions, not a map colored by country.
The third is dashboard duplication. If category, sales, finance, and leadership each commission a separate view before measures are governed, the business pays several times to debate the same definitions.
The fourth is buying shelf data as though it were scan data, or scan data as though it were shelf evidence. No commercial term fixes a method mismatch.
Do not cut a source merely because another total is close. Agreement at an aggregate level can hide opposite store-level stories. Cut it when its decision has disappeared, another source records the same event at the required grain, or nobody acts on the output.
What we’d recommend
For an established team, do not follow the maturity sequence written for a small brand. You already have systems, contracts, users, and political ownership. Replacing everything at once turns a measurement problem into a migration program.
Choose one costly recurring decision where the current sources disagree. Document the event behind it. Inventory which existing feed observes that event, then fix the product, account, calendar, and unit mappings needed to reconcile the answer. Only after that should you decide whether the missing piece is data, software, or operating ownership.
Keep syndicated data for market and shopper context. Keep distributor or route-to-market data for movement into accounts. Keep internal records for your plan and economics. Add shelf observation where the unanswered question is physical availability, visible price, competitor presence, or in-store execution.
For beverage-alcohol teams, tell us the decision your current stack cannot settle and the feeds already under contract. We’ll give you a straight answer on whether Shield Suite fills the shelf-observation gap or whether the real problem is reconciliation. Sometimes the right purchase is no new data at all.