Ask two analysts at the same company how many customers churned last quarter and there is a fair chance you will get two numbers. Usually neither of them is wrong. They are counting different things under the same label. Shared data definitions are the unglamorous fix for this, and they sit underneath almost every DataOps practice that teams care about, from testing to lineage to self-service analytics. The questions below are the ones data engineers and analytics leads raise most often when they start treating definitions as part of the pipeline rather than a side document.

Why do two correct queries return different numbers?

Because a business word compresses several decisions, and each query makes those decisions differently. “Churned customer” hides at least four choices: what counts as a customer (paying account, user, household), what counts as leaving (cancellation, non-renewal, inactivity past some window), which date the event belongs to (request date, effective date, billing date), and how edge cases are handled (paused plans, refunds, reactivations).

Two engineers can answer each of those reasonably and still disagree. When the logic is buried in separate SQL files, dashboards or notebooks, nobody sees the divergence until a number appears in a board pack and someone asks why it does not match last month’s slide. The evidence of the problem is almost always the same: reconciling numbers takes longer than computing them.

Is this really a DataOps problem, or a business problem?

Both, and that is the point. The meaning of “churn” is a business decision. The consistent application of that meaning across every pipeline, model and report is an engineering problem. DataOps lives at the join. If definitions stay purely in business documents, engineers reimplement them by guesswork. If they stay purely in code, business owners cannot read or approve them. A working approach puts the definition in a form both sides can see and links it to the code that implements it.

Which terms deserve a formal definition first?

Not all of them. Teams that try to define every column in the warehouse stall within weeks. A more defensible approach is to rank terms by how much damage a misunderstanding causes.

• Terms that reach executives or regulators. Revenue, active customer, retention, headcount. A mismatch here costs credibility.
• Terms that drive automation. Fields used for pricing logic, eligibility rules, model features or alert thresholds. A mismatch here costs money or customer trust quietly.
• Terms that cross team boundaries. Anything produced by one domain and consumed by another. These are where meanings drift fastest because nobody sees both ends.

In practice, a fairly short first list tends to cover most of the arguments an analytics team actually has. The rest can wait until someone trips over them.

What does a good definition actually contain?

A label and a sentence are not enough. The definitions that hold up in practice tend to include:

1. Plain-language meaning written for a business reader, one or two sentences.
2. Inclusion and exclusion rules spelled out, especially for the edge cases that caused the last argument.
3. Time logic: which timestamp governs, which time zone, and how late-arriving data is treated.
4. Grain: per account, per user, per order line. Mixing grains is one of the most common silent errors.
5. A reference implementation, usually a model or view in the transformation layer, that every downstream report should use instead of recomputing.
6. An owner who can approve changes, plus a short change history.
7. Worked examples: a few real records that are in, and a few that are out, with the reason.

The worked examples matter more than teams expect. They turn an abstract rule into something people can test their own intuition against.

Who should own a definition?

The person accountable for the decision the number supports, not the person who writes the SQL. Finance usually owns revenue. A product lead might own active user. The data team owns the implementation and the quality of the pipeline that produces it, but not the meaning.

This split avoids two failure modes. When engineers own meanings, definitions drift toward whatever is easiest to compute. When nobody owns them, every quarter brings a new debate. Naming an owner also gives the data team a clear escalation path: if a consumer wants “active” to include trial accounts, there is one person to ask.

Where should definitions live?

Close to the data and close to the people using it. A catalog or glossary tool is the common home, with each term linked to the tables and columns that implement it. Teams without dedicated tooling often start with definitions in version-controlled YAML or markdown next to their transformation code, which at least keeps meaning and logic reviewed together. For an overview of what catalog tooling offers here, see this explainer on how a data catalog organises and surfaces dataset information.

Whatever the home, the test is simple: when someone looks at a field in a dashboard, can they reach its agreed meaning in one or two clicks? If the answer is no, the definition exists on paper only.

How do definitions connect to data contracts and tests?

Directly. A data contract formalises what a producer promises a consumer: schema, freshness, and often semantic expectations. A shared definition is what gives those expectations content. “Status will be one of these values” is a schema rule. “A status of closed means the customer has been refunded in full” is a semantic rule, and only a shared definition can supply it.

Once a definition is written down, parts of it can become tests. If active customer excludes internal test accounts, a check can fail the pipeline when test account IDs appear in the output. If revenue is recognised on the effective date, a check can flag records where the two dates diverge in unexpected ways. The guide to data contracts between producing and consuming teams covers the mechanics in more depth.

Do formal definitions slow delivery down?

At the start, slightly. Someone has to spend an afternoon writing inclusion rules and chasing an owner for approval. The time is usually recovered the first time a stakeholder questions a figure and the answer is a link instead of a week of investigation. There is also a quieter gain: engineers stop rebuilding the same logic in slightly different ways, so new reports get faster to produce because they start from a reference model rather than a blank query. The teams that find definitions slow are usually the ones trying to define everything at once, or debating wording without real records to test against.

What happens when a definition needs to change?

It will, and that is healthy. Businesses change pricing, launch products and reorganise. The goal is not a frozen glossary but a controlled one. A sensible change process looks like this: the owner approves the new wording; the data team updates the reference implementation; affected dashboards and models are identified through lineage; consumers are told what changed and from which date; and historical figures are either restated or clearly marked as using the old definition.

The worst outcome is a silent change, where a number shifts and nobody can say whether the business moved or the meaning did.

How can a team tell whether this is working?

Look for evidence in behaviour rather than in the glossary itself. Signals that shared definitions are taking hold include:

• Fewer meetings spent reconciling two versions of the same figure.
• New dashboards built on the reference models instead of fresh SQL.
• Analysts citing a definition by name when they disagree, rather than arguing from memory.
• Questions from business users shifting from “which number is right?” to “why did this number move?”

That last shift is the clearest sign. It means people trust the meaning and are now interrogating the business.

Where can data teams build these habits?

Much of this is learned on the job, but structured training shortens the path. DataOpsSchool is a DataOps training and consulting provider whose programmes for engineers and analysts include data quality and governance, the two disciplines that depend most heavily on agreed, owned definitions. Pairing that kind of grounding with a small internal pilot, perhaps the five terms that cause the most arguments, tends to produce visible results quickly.

Governance is the wider frame for all of this, and the piece on what data governance covers and how it is measured sets definitions in that larger context.

What is the smallest useful first step?

Pick the one metric that caused the most recent argument. Get the owner, an analyst and an engineer in a room for an hour. Write the definition with inclusion rules, time logic, grain and three worked examples. Point one dashboard at a single reference implementation. Then wait for the next time someone quotes that number and see whether the conversation is shorter. In most teams it is, and that small win is usually enough to justify doing the next five terms.