Data Platforms Teams Actually Trust
How I set up tracking, pipelines and dashboards so the numbers survive the first argument: a tracking plan treated as a contract, one definition per metric, and pipelines that fail loudly.
A dashboard nobody trusts is worse than no dashboard. With no numbers, people argue about the decision. With numbers nobody believes, they argue about the numbers, and the decision waits.
Trust in data is not a tooling problem. Every platform I have seen lose it had good tools. It lost trust because two people could get two answers to the same question, and nobody could say which was right. Here is how I set things up so that cannot happen, or at least so that it is caught the same day.
Start from the decisions, not the events
Before any tracking is written, I ask for the five decisions the data has to support this quarter. Not metrics, decisions: whether to keep a feature, where to spend the next sprint, which market to open. The metrics fall out of those. Everything that does not serve a decision is logging, and logging is cheap to keep and cheap to ignore.
This sounds obvious and is skipped constantly, because it is easier to instrument every button than to agree on what matters. The platform that instruments every button has ten thousand events and no answers.
The tracking plan is a contract
Events are named by what happened in the business, not where the click was: order_placed, not checkout_button_clicked. Each event has typed properties, a version, an owner and a description a new analyst can read. The plan is reviewed like an API, because it is one: the front-end, the back-end and the warehouse all implement it, and a silent change in any of them breaks the other two.
At ingestion, events are validated against the plan. Invalid events are rejected and counted, not coerced into shape and quietly stored. A rejection count that rises after a release is the earliest warning the platform can give, and it is worth more than any dashboard.
One definition per metric
"Active user" has one definition, written in one place, owned by one person. Dashboards read that definition; they do not carry their own SQL. The semantic layer is the single most effective thing I have done for trust, and the least glamorous: it is a repository of metric definitions with tests, and a rule that nothing on a dashboard bypasses it.
When a definition has to change, it changes with a version and an announcement, and the old series stays available next to the new one. People can live with a metric changing. They cannot live with a metric changing silently.
Pipelines that fail loudly
A pipeline that fails quietly is a pipeline that produces a confident, wrong number. Every load is idempotent, so a rerun never double-counts. Every model asserts what it knows: row counts within a range, null rates below a threshold, freshness within an hour of the schedule, keys unique. Late-arriving data has a defined window, and backfills are a first-class operation with the same tests as the daily run.
When an assertion fails, the pipeline stops and the owning team is paged, not the data team. The team that owns the source owns its failures. That single rule halves the number of broken sources within a few months, because the cost of a sloppy change finally lands where the change was made.
Model in layers, keep the raw forever
Raw events are kept as they arrived, untouched, for as long as the law allows. On top of that, a cleaned layer applies the tracking plan: types, deduplication, sessionisation. On top of that, marts answer the questions the decisions need. Each layer is rebuildable from the one below, which means a bug found in May can be fixed back to January. Incremental models keep the daily cost sane; a full rebuild stays possible for the day it is needed.
Privacy and retention by design
Personal data is classified in the tracking plan, at the property level, before the first event ships. It is pseudonymised as early as the use allows, and retention windows are part of the model, not a later cleanup. Doing this at the start is a week of work. Doing it after an audit is a quarter.
Fewer dashboards, each with a decision attached
The platform ends with dashboards, but not many. Each one states the decision it supports at the top and shows the three numbers that inform it. Releases are annotated on the time axis, because half of all "what happened on Tuesday" questions are answered by "we shipped on Tuesday". A wall of forty charts is a sign that nobody agreed on the questions.
The weekly ten minutes
Trust is kept by routine, not by heroics. Once a week, someone checks freshness across the marts, the rejection counts, the drift in one or two key metrics, and reads one definition out loud to confirm it still means what people think it means. Ten minutes. The platform stays trusted because somebody looks, on purpose, before anybody has to ask.