Data Analysis

Anomaly Diagnosis

Metric Definition Alignment

Make the metric definitions behind dashboards, reports, SQL, tags, cohorts, and virtual properties clear at a glance, eliminating the internal friction of inconsistent data definitions across teams.

IndustriesAll industries

Agent · Skills Live

skill · loadedindustry+100

Run this Skill on my data

Segment breakdown

by group

SegmentShareARPPU

High62%$248

Mid31%$96

Low12%$18

Analysis readyevidence attached

Metric Definition Alignment is a data-governance capability in ThinkingAI's industry Skill library. It helps data analysts and business teams quickly align metric definitions in cross-team collaboration, ensuring consistent semantics across analysis objects like dashboard metrics, report definitions, SQL calculation logic, tag definitions, cohort rules, and virtual properties. This is ThinkingAI's decade of industry experience, packaged into ready-to-use Skills.

Live walkthrough

AgentSave as AgentExport session

analysis-metric-definition-alignment

The monthly review turned into an argument again: the operations dashboard shows a payment rate of 12.8%, product's own report shows 9.3%, and each side insists their number is the right one. Figure out how these two numbers are actually calculated, and who's right.

Identify the type and metric-definition source of the two analysis objects in a sample idle card game DEMO

Operations side is a dashboard metric card, product side is a local SQL report

Parse the implementation-layer logic of the dashboard's "payment rate"

Same-day payment_success users ÷ same-day active users = 12.8%

Parse the calculation logic of the product report's SQL

Same-day users triggering any payment event ÷ same-day new users = 9.3%

Trace the definition-layer semantics, compare across the four elements: numerator / denominator / population / time window

Scan downstream references of the product-side SQL metric definition

That SQL block is copy-referenced by 3 weekly reports

Generate a metric-alignment document and a naming recommendation

Figured it out: neither side miscalculated: 12.8% and 9.3% are simply not the same metric. One is the overall payment rate, the other is the new-user payment conversion rate, and the 3.5pp difference comes entirely from the metric definitions themselves.

1. Element-by-element comparison of the two definitions

Comparison item	Operations dashboard "payment rate"	Product report "payment rate"
Numerator	23,475 same-day `payment_success` users	3,878 same-day users triggering any payment event
Denominator	183,400 same-day active users	41,700 same-day new users
Value	12.8%	9.3%
Actual meaning	Overall payment rate	New-user payment conversion rate
Definition ownership	Registered in the metrics library	Local SQL, unregistered metric

2. Where the difference comes from

Three of the four elements differ: on the numerator, one counts only successful payments while the other also folds in payment attempts that didn't succeed; on the denominator, one divides by active users, the other by new users; on population, one looks at the whole base, the other only at new users. This is same name, different meaning, not a data-quality problem: each number answers a different business question, and what the review is really arguing about is "which question to look at."

3. A finding more worth worrying about than the argument

The product-side definition exists only in local SQL, never registered as a metric, and that SQL block has already been copy-referenced by 3 weekly reports, and every copy is another chance for the definition to drift, and once staff turn over, no one will be able to say what this metric's business meaning is. That's the real governance gap this investigation surfaced.

Recommendation

Three recommendations to unify the definitions: (1) rename and register both metrics into the metrics library, "Payment Rate (overall)" and "New-User Payment Conversion Rate," so the names remove the ambiguity; (2) have the product side's 3 weekly reports reference the registered metrics instead of local SQL; (3) source all review materials from the metrics library. The metric-alignment document is generated, with full definitions for both metrics and a downstream-reference list.

The metric-alignment document is synced to the project knowledge base; the metric renaming is pending confirmation from both teams before it's applied.

On your data

That was a simulated run

Leave your work email and we will run a live walkthrough on your real business data.

The problem

Inconsistent definitions are the most hidden and draining problem. The same "active user" or "paying user" may have four different definitions across operations, product, finance, and data teams, and teams spend an average of 2 to 3 hours a week arguing over definitions. Tag definitions and cohort rules are scattered in local SQL, and when staff change the meaning of a definition is lost, so newcomers can only reverse-engineer it from historical reports, which easily skews decisions.

What it does

Automatically identify the analysis-object type (dashboard/report/SQL/tag/cohort/virtual property) and pinpoint the source of the metric definition

Layered definition explanation: present the current implementation layer's calculation logic first, then trace back to the definition layer's business semantics as needed, avoiding confusion

Output a reusable metric-alignment document to give downstream analysis a unified semantic baseline

When to use it

Preparing aligned definitions before a cross-team data review

Helping a new analyst quickly understand the metric definitions of existing dashboards and reports

Assessing the impact scope when a tag or cohort rule's definition changes

Investigating definitions when business teams disagree on a metric's data

Systematically mapping out metric definitions and ownership in a data-governance project

In the field

Case

A game company · monthly review definition dispute

The operations dashboard showed a 12.8% payment rate and the product report 9.3%. The Skill parsed both reports' SQL: the operations definition was "same-day successful-payment users / same-day active users," while the product definition was "same-day any-payment-behavior users / same-day new users," one an overall payment rate and one a new-user payment rate. The Skill also output a metric-alignment document, and after the team unified the definition the review had no further disputes.

FAQ

What is the difference between metric alignment and data-warehouse modeling?

Data-warehouse modeling concerns the data structure and storage layer, while metric alignment concerns the semantic layer, that is, what a metric actually measures.

Does it only support AE analysis objects?

The current version is deeply adapted to AE dashboards, reports, SQL, tags, cohorts, and virtual properties, but the layered definition-parsing method also applies to other platforms.