CPG analytics software starts with product identity

The categories that show up in an evaluation are built for different jobs, and which one fits depends on how many places your sales history lives.

Kartik Deshpande··Updated ·6 min read

Searching for CPG analytics software returns products built for different jobs under similar language. A channel dashboard reports on one channel. A planning tool projects demand. A BI tool displays a model somebody has already built. A context layer joins the records and definitions those other tools expect to receive.

Two questions decide which category fits. How many places does your sales history live, and has anyone declared that a distributor case and a shelf unit are the same product? This article applies those questions to five categories, then shows where each category works and where it stops.

Why cross-channel CPG data needs a product map

One product can appear as four records: a variant ID in Shopify, an ASIN on Amazon Seller Central, a UPC on a grocery chain's point-of-sale feed, and a case pack at the distributor. Nothing joins those automatically because the conversion between a case and a shelf unit is a business rule. Someone has to declare that the records describe the same product and preserve that decision as codes change and variants launch.

Timing is the second problem. Marketplace settlements land weeks after the order, retailer point-of-sale feeds arrive on the retailer schedule (weekly is common, often with a week of lag), and direct orders are visible the moment they are placed. A single weekly sales number assembled from all three describes three different moments and reads as one.

The third problem is definition. Does a unit sold mean gross or net of returns? Does revenue include marketplace fees and chargebacks? Does trade spend reduce the top line or sit below it? Each answer can be valid, but a spreadsheet column can hold any of them without recording which rule was used. We have observed pieces of the same customer spread across 12 or more disconnected systems, and every added source creates another place for those definitions to drift.

These problems set the evaluation order. First determine whether a tool can connect the required sources. Then test whether it preserves product identity and business definitions. Only after those tests should visualization, forecasting, and workflow features decide the result.

One product across four systems, then one governed record
Four records, no join
  • Variant ID in Shopify
  • ASIN on the marketplace
  • UPC on the retailer feed
  • Case pack at the distributor
Units reconciled by hand each month
One product, declared once
  • Units converted to a common base
  • Net revenue defined once
  • Every figure traceable to source rows
Same answer next month
A durable product map lets every downstream tool use the same conversion and revenue rules.

The criteria that separate the categories

Ask the same two questions of every option: does it join the channels you need, and does it preserve your definitions? The answers expose the dependency each category otherwise hides.

CategoryJoins your channelsHolds your definitionsBest fit
Channel-native reportingNoNoA channel owner asks about one channel
Retail and syndicated portalsSell-through onlyNoYou need shelf visibility
BI and visualizationOnly what its data model joinsOnly if the model defines themA maintained data model already exists
Demand planningExpects joined historyForecast assumptions onlyProjecting units is the primary job
Context layerYesYes, as explicit rulesSources and definitions disagree

Five categories of CPG analytics software

Channel-native reporting

Channel-native reports describe activity inside one channel. They are best for a channel owner investigating that channel because the platform has the freshest local detail. They fail when the question crosses channels: product identities, timing, and revenue definitions still have to be reconciled elsewhere.

Retail and syndicated data portals

Retailer portals and syndicated data provide sell-through, meaning units purchased by shoppers rather than units shipped into the channel. They are best when shelf movement and competitive context are the question. They fail at joining that movement to your cost, trade spend, and direct demand, so account profitability still gets assembled elsewhere.

BI and visualization tools

BI tools render a data model into dashboards and reports. They are best when a maintained model already unifies the sources and definitions. They fail when that model has no owner, because the visualization can only display the version of the number it receives.

Demand planning and inventory tools

Demand planning tools project units and manage stock across locations. They are best when forecast and replenishment decisions are the job. They fail when the sales history is incomplete or inconsistent, because the projection carries those input gaps forward.

Context layers

A context layer connects source systems, resolves records, and preserves business definitions for the tools above it. It is best when product identities or metrics disagree across sources. It fails as a replacement for a planning engine or a specialist retailer dataset because it supplies governed inputs rather than those capabilities.

Permute resolves products and definitions

Permute is the context layer we sell between a business's source data and the AI and reporting tools its people already use. We connect systems such as Shopify and NetSuite, resolve their product records, and preserve the source rows behind each match.

Definitions such as units sold and net revenue are written once as explicit rules with effective dates. The dashboard, scheduled report, and plain-language answer then apply the same rule instead of rebuilding it in separate workbooks.

A commercial lead can ask which accounts grew last quarter net of returns and receive the answer with the contributing rows attached. We sit underneath Claude, ChatGPT, and Copilot so those assistants reason against the business's declared definitions rather than selecting one from conflicting files. What a context layer actually does explains that mechanism in more detail.

Find out whether your channels agree with each other

Connect two channels, write down what a unit sold means in your business, and ask for last quarter net of returns. If the two numbers disagree, that gap is worth closing before you buy a dashboard to display it.

Questions to put to each vendor

How does pricing change as access expands? Price the license at the headcount expected to use the answer, not only the initial pilot group. A per-seat model can make self-service more expensive as adoption grows.

Who maintains the product map after launch? Ask what happens when the same product carries four codes across four channels. Treat "you map them first" as an ongoing operating cost rather than a one-time setup step.

Can a user open the rows behind a number? A sell-through figure without provenance cannot be defended in a buyer meeting. Ask for the trace during the demo and treat its absence as a product limit.

Does a forecast expose its channel coverage and freshness? Ask which channels feed the model, when each last updated, and what happens when a retailer file arrives late. An accuracy claim cannot describe a channel that is absent from the history.

Forecasting and source correction stay elsewhere

We are not a forecasting engine. We supply governed sales history to the planning tool that produces the projection. We read from connected systems and do not write back, so a wrong product code is still corrected in Shopify or NetSuite. We surface the conflicting records and preserve their source. Syndicated data can be included as an input, but we do not sell it.

Access rules apply to people and agents, and how the data is handled explains that model. What it costs is public so implementation and software can be evaluated together.

Choose the category that owns the missing work

Choose channel-native reporting when the question stays inside one channel. Choose retail data for shelf movement, BI for a maintained model, and planning software for forecasts and replenishment. When sources disagree about products or definitions, resolve that layer before asking another tool to display or project the result. The category should own the missing work rather than hide it as an implementation dependency.

Test it on one product line

Connect two channels for a single product line, declare what a unit sold means, and ask for last quarter. The answer either matches the spreadsheet you keep or shows you exactly where it does not.

Questions consumer brands ask about analytics software

Who should own a CPG analytics implementation?

Give ownership to the role accountable for the definitions, with technical support for connections and access. Commercial teams can define sell-through and account grain, while finance should approve revenue and cost treatment.

Can analytics software coexist with an existing warehouse?

Yes. BigQuery, Snowflake, Databricks, and Microsoft Fabric can remain the governed storage layer when the model and its owner already exist. The evaluation should identify which product supplies the missing identity, definitions, and user access rather than paying to rebuild working infrastructure.

What should happen when two product records cannot be matched?

The tool should leave the match unresolved, show the evidence, and route the decision to someone who knows the product. A plausible automatic match is worse than an explicit unknown because every downstream metric inherits the mistake.

Should retailer and syndicated data replace internal sales data?

No. Retail and syndicated data describe shelf movement and market context, while internal systems carry shipments, cost, deductions, and direct sales. A useful model preserves the difference between those sources and joins them at an agreed product, account, and time grain.