The Right Metric, The Wrong Customers
A semantic layer can define “customer” and “revenue per customer” perfectly and still return wrong answers, because the same customer lives in five systems under three names and is counted once in each.
Three mid-size customers averaging $473K, when it is really one top account worth $1.42M.
Why Metric Definitions Can’t Fix Identity
A semantic layer defines what “active customer”, “revenue per customer” and “churn” mean, and makes every dashboard, notebook and agent use the same definition. That solves one problem: different formulas for the same metric.
It does not solve the other one. The layer cannot tell that “Acme Inc” and “ACME Incorporated” are the same customer. Customer counts come out too high, revenue per customer too low, and churn spikes whenever a customer is re-created under a new spelling. The definitions are right and the numbers are still wrong.
That is an entity resolution problem, not a metrics problem. Fix it once, below the semantic layer, and every metric above it inherits the fix.
Inflated Counts
One customer under three names is counted three times in active customers, accounts and segments.
Diluted Value
Revenue, lifetime value and wallet share are split across duplicates, so top accounts look ordinary.
Agents Disagree
An agent answering through the semantic layer inherits the same duplicates and repeats them at scale.
Put Identity Below The Metrics
Resolve entities once, in the data platform, before the semantic layer reads them. Every customer, account and product gets one stable key, and the semantic models join on that key instead of on each source system’s own ID.
Then every metric defined on top inherits the fix. “Active customers”, “revenue per customer” and “churn” count real entities, the same way in every dashboard, notebook and agent.
Counted once, the customer is a top account. Counted three times, it is three mid-size ones.
One Entity Key
A single key per real customer, shared by every source system.
Models Join On The Key
Semantic models use the resolved key as the entity, not system-specific IDs.
Metrics Inherit The Fix
Every metric built on the model counts real entities, everywhere it is used.
The Identity Layer Under AI & Data
Zingg runs as a workload inside your data platform and gives every entity one persistent ZINGG_ID. Everything above it reads the same resolved entities.
The same layer powersCustomer Analytics & MarketingFinancial Crime & RiskPrivacy & ComplianceSupply Chain & ProcurementProduct 360Master Data Management
Define Metrics On The ZINGG_ID
One Key For Every Entity
Zingg gives each customer, company or product one persistent ZINGG_ID across every source system.
Model On The ID
Join your semantic models on the ZINGG_ID instead of system-specific keys, so “customer” means one real customer everywhere.
Numbers That Hold Still
IDs persist across runs, so history does not shift when data is reprocessed. Incremental flow
Inside Your Platform
Resolution runs on the same platform as your semantic layer, under the same governance.
Semantic Layer Questions
Why does a semantic layer need entity resolution?
A semantic layer standardizes metric definitions, but it counts whatever rows it is given. If one customer exists under several names, every customer metric is wrong in the same consistent way.
Does Zingg replace my semantic layer?
No. Zingg sits below it. It resolves entities in your data platform and gives each one a ZINGG_ID, which your semantic layer uses as the entity key.
Will historical numbers change every time Zingg runs?
No. ZINGG_IDs persist across runs, and incremental runs only process new and changed records.
Does it work with AI agents that query the semantic layer?
Yes. Agents get the same resolved entities as dashboards, so they stop answering about duplicates.
Count Real Customers
Resolve identity below your semantic layer, in your own data platform.