The Cost of Not Agreeing on Reality

Three Dashboards. Three Truths 1 Part

The investigation moved from infrastructure into semantics. That shift is usually the moment when engineering problems stop feeling like engineering problems.

Once the pipelines, queries, and dashboards were confirmed to be technically correct, the only remaining explanation was that correctness had been applied to different definitions. In other words, nothing in the system was broken, but everything in the system was slightly misaligned.

The team started tracing the three revenue numbers back to their origin.

The finance definition originated from payment settlement data stored in the ERP system and replicated into BigQuery through scheduled batch imports. It was strict by design. A transaction only became revenue when money physically arrived in the company’s bank account and passed reconciliation rules. Anything reversible was excluded until it became irreversible.

The marketing definition originated from event-level tracking data coming from GA4 and AppsFlyer. These systems recorded user behavior long before money changed hands. A “purchase” in this context was a signal of intent and conversion attribution, not financial settlement. The model was intentionally optimistic because its purpose was optimization, not accounting.

The BI definition was the most complex. It was built as a reconciliation layer on top of both systems, attempting to harmonize transactional and behavioral data. It removed duplicates, filtered suspicious transactions, aligned time windows, and applied internal business rules defined years earlier when the company was significantly smaller. Over time, those rules had accumulated exceptions, patches, and adjustments, but no one had ever fully revalidated whether they still reflected current business reality.

Three definitions. Three valid intentions. Three incompatible truths.

The CTO summarized the situation in a way that changed the tone of the entire room.

“We do not have a data problem. We have a contract problem.”

That sentence reframed the entire investigation.

Because data problems can be solved with better engineering.

Contract problems require agreement between humans before any engineering becomes meaningful.

The next discussion was not about BigQuery optimization or pipeline redesign. It was about decision rights.

Who is allowed to define revenue?

Finance argued that only accounting-aligned numbers should be considered official. Marketing pushed back, explaining that their revenue model was essential for measuring acquisition efficiency. The BI team emphasized that executives needed a reconciled metric that reflected operational reality, not raw accounting or attribution data.

All three arguments were correct. That was exactly the problem.

The engineering team proposed a more structural approach. Instead of trying to force one number to represent everything, the platform needed to explicitly separate different “truth layers” and enforce them technically.

A revised architecture started to take shape.

First, a canonical financial layer would be defined as the official revenue source of truth, strictly aligned with settlement data. This layer would be immutable and auditable, designed for finance, reporting, and compliance.

Second, a marketing attribution layer would remain independent, preserving its role in measuring campaign performance without pretending to represent financial reality.

Third, a curated executive metrics layer would be explicitly defined as a derived product, not a primary truth. It would be documented, versioned, and governed, with clear lineage back to underlying datasets.

Technically, this meant restructuring BigQuery datasets into clearly separated domains with enforced access policies and transformation ownership. Dataform pipelines were refactored to reflect these boundaries. Looker models were updated to prevent accidental blending of incompatible definitions. Data Catalog entries were introduced to make metric ownership visible at the organizational level.

The most important change, however, was not technical.

It was procedural.

No new metric could be introduced into executive reporting without an explicit definition review involving Finance, Marketing, and Data Engineering. The goal was not to slow down development, but to prevent semantic drift—the slow divergence of meaning that had caused the original conflict.

Within weeks, the impact became visible.

Reports stopped contradicting each other because they were no longer pretending to measure the same thing. Executives no longer argued about which dashboard was correct. Instead, discussions shifted to which metric was appropriate for which decision.

Interestingly, the perceived complexity of the data platform decreased, even though the underlying architecture became more sophisticated. This is a common but counterintuitive outcome in mature systems. Clarity often increases when ambiguity is explicitly modeled rather than hidden behind simplified dashboards.

A final review was conducted three months later.

Revenue still had multiple representations in the system, but only one was used for financial decisions. Marketing attribution was still used for campaign optimization, but no longer confused with accounting. Executive dashboards still existed, but now clearly stated what each number represented and why it existed.

The three dashboards were still different.

But they were no longer in conflict.

They had become part of a defined system rather than competing interpretations of reality.

The CTO summarized the lesson during the final review meeting.

“BigQuery did not give us three versions of revenue. It faithfully gave us three answers to three different questions we never realized we were asking.”

Executive Takeaways

• Data inconsistency is often a governance issue, not a technical failure.
• Multiple “correct” metrics are acceptable only when their definitions are explicitly separated.
• A single dashboard does not guarantee a single truth if upstream semantics are inconsistent.
• Data platforms should enforce ownership of definitions, not just storage of data.
• Reducing ambiguity is often more valuable than improving accuracy.

One Question Every CTO Should Ask

“If every team is correct, but the company is still arguing, what exactly have we standardized: data, or interpretation?”