Two Teams, One Metric Name, Two Numbers: Where the Gap Actually Comes From
When two people report different figures for the same named metric, the instinct is to look for a broken integration. Usually nothing is broken. There are three specific definitional gaps that produce this, and each one needs a different fix.
Two Teams, One Metric Name, Two Numbers: Where the Gap Actually Comes From
Someone says pipeline was 240 this month. Someone else says 310. Both pulled the number this morning, both from systems that are working correctly, and the meeting now spends twenty minutes on whose spreadsheet is wrong. Nothing is wrong with either spreadsheet. The metric has two definitions and nobody wrote either of them down.
Key takeaways
- Most same-metric disagreements are definitional, not technical - hunting for a broken integration is the wrong first move.
- The most common gap is time semantics: a metric measured as-of-now and the same metric measured within-a-window are different quantities that share a name.
- The second gap is which layer counts as the truth - payments, CRM, website events, or the ad platform's own claim all produce a defensible but different revenue figure.
- The third gap is derivation: one metric reconstructed two ways from the same inputs will not agree, and both reconstructions can look correct in isolation.
- The durable fix is that the definition travels with the metric - visible where someone picks it - rather than living in a glossary nobody opens.
Teams that treat this as a data-integrity problem keep auditing pipelines that are fine, and the disagreement returns the following month because the definitions were never the thing that got fixed.
Period metric: a count or sum of things that happened inside a date range. "Deals created in March" is a period metric; change the range and the number changes.
Snapshot metric: a state as of the moment you ask. "Open pipeline" is a snapshot; it has no date range, and the same question asked tomorrow returns a different number even if nothing happened in March.
Gap one: the same word for as-of-now and within-a-window
The operational pain this creates for anyone comparing two reports: period and snapshot metrics are not distinguishable from their names. "Pipeline" can mean the value of deals opened during the month, or the value of deals sitting open right now. Both are legitimate and useful, they answer different questions, and a report that does not say which one it used is genuinely ambiguous rather than wrong.
The reason this gap is so durable is that both people believe they are looking at the same measurement. The practical read: before debating the numbers, ask each side for the sentence that defines theirs - "deals opened between the first and the last of the month" versus "deals currently in an open stage". In most disputes that single question resolves it, and it does so faster than any audit. The same ambiguity applies to any metric with a duration or a stage in it: a stalled-deal count means nothing until "stalled" has a threshold attached, and an average cycle length means nothing until the start and end events are named. A related class of mismatch comes purely from the clock rather than the definition, and it is worth ruling out before assuming a semantic gap.
Turn scattered analytics into one clear picture
Every source in one brief. The whole picture. Your decision.
14-day trial after the call · no card required
Gap two: which layer counts as revenue
The ICP problem this creates for teams with a payment system, a CRM, website tracking, and several ad platforms all reporting money: there are four defensible revenue numbers in that stack and they will never match. The payment system knows what was actually charged. The CRM knows what was marked closed-won, on a date a human chose. Website purchase events know what fired in the browser. Each ad platform reports the conversion value it believes it caused, which is the weakest of the four because every platform claims as much credit as its own attribution window allows - and those windows overlap, so the platform figures sum to more than the business earned.
Which of the four is correct depends on the business, not on the data. An ecommerce operation generally treats the store as the truth because the charge is the event that matters. A B2B company with a long sales cycle generally anchors on closed-won in the CRM, because that is where a deal becomes real. The mistake is not picking the wrong one - it is blending them, or leaving the choice unstated so different people pick different ones. This is the internal-team version of a gap that also shows up between any two platforms measuring the same conversion.
Gap three: one metric, two derivations
The ICP problem this creates for anyone building a report from platform exports: a derived metric can often be reconstructed several ways from the same raw fields, and the results diverge. Clicks can be derived from spend divided by cost-per-click, or from impressions multiplied by click-through rate. Both are arithmetically sound. Both use real reported numbers. On live data they return different values, because the inputs are each rounded and each averaged over the period before you ever see them.
The fix is not to find the more accurate formula - it is to stop deriving the value at all where the platform reports it directly, and where derivation is unavoidable, to fix one precedence and use it everywhere. This is where a disciplined exploratory pass pays off: before interpreting any anomaly, check the denominator and check whether the same metric moves the same way in a second system. A ratio can shift because its denominator moved rather than its numerator - "click-through rate fell" often means impressions grew while clicks held steady, which is a reach story, not a creative one. Running those two checks first separates a real change from an artefact of how the number was built.
Prooflytics handles the three gaps structurally rather than by documentation. Every metric declares whether it is a snapshot, a period figure, or a trend, so the time semantics are part of the metric rather than a footnote, and each metric carries a one-line definition shown where you select it - win rate states that it is won divided by won plus lost for deals closed in the period, a stalled deal states its day threshold. Revenue source is a single explicit setting per organisation with four options - Payments, CRM won deals, Pixel purchases, or Ads-reported - and the layers are never blended into one figure: the organisation picks its truth and the others stay visible under their own labels. Where a value can be derived more than one way, one derivation is product-wide, so two screens cannot disagree.
Bottom line
- Ask for each side's defining sentence before auditing anything - most same-metric disputes end there.
- Separate as-of-now from within-a-window explicitly; a shared name for both guarantees the argument recurs.
- Pick one revenue layer deliberately and keep the others visible under their own labels rather than blending them.
- Where a metric can be derived two ways, fix one derivation product-wide; both formulas being defensible is exactly the problem.
- Book a walkthrough to see how Prooflytics puts the definition next to the metric and makes revenue source one explicit choice.
Frequently asked questions
Should we just write a metrics glossary?+
A glossary helps but rarely solves it, because the definition is in a document and the number is on a screen. The definition has to be visible at the moment someone reads or selects the metric, otherwise the glossary becomes a thing people cite after an argument rather than before one.
Who should own metric definitions?+
One named person or team, with the authority to decide and the obligation to publish. Shared ownership reliably produces the problem this article describes, because every team resolves the ambiguity in whichever direction suits its own reporting.
Is it ever correct for two teams to use different definitions of one metric?+
Yes - finance and performance marketing legitimately need different revenue views. What is not acceptable is using the same name for both. Give them distinct names and the disagreement disappears, because the two numbers are no longer claiming to be one number.
How do we tell a definitional gap from an actual data problem?+
Ask whether the gap is stable. A definitional gap produces a consistent difference that reproduces every time, often a steady ratio. A broken pipeline produces an erratic gap that changes between pulls, or a number that stops moving. Stable difference means check definitions first.
You can read independent reviews of Prooflytics on G2 and compare it to other marketing intelligence platforms in the category.
Turn scattered analytics into one clear picture
Every source in one brief. The whole picture. Your decision.
14-day trial after the call · no card required
Continue reading
Why Your Marketing Numbers Don't Match Across Platforms (It's the Timezone)
A campaign reporting 50 conversions in one platform and 47 in another isn't necessarily a tracking bug - each platform may be attributing the same conversions to a different calendar day. Here is how to find and fix a timezone mismatch before it wastes an afternoon of investigation.
Your Tracking Plan Was Written for Product Analytics. Marketing Needs a Different One.
Every tracking plan template you can download specifies event names and properties, because they were all written for product teams instrumenting a feature. A team buying media and attributing revenue has to specify four more things, and none of them appear on those templates.
Marketing Analytics Guide: From Scattered Data to a Unified View
Marketing analytics means joining data from all your channels - paid, email, CRM, and revenue - into a single view. This guide covers what it includes, where most stacks break down, and how to build one that gives reliable answers.
Marketing Data Latency: Why Yesterday's Dashboard Number Isn't Final Yet
Most marketing platforms backfill and revise conversion data for days after it first appears. Here is why the number you see this morning is a preliminary estimate, and how to avoid making a budget call on data that hasn't settled yet.