Eliminate KPI Drift by 80 Percent With a Truth Pipeline

Your product analytics isn’t “messy.” It’s untrustworthy because every metric you cite has been hand-carried through Slack threads, ad hoc SQL, and screenshots that no one can reproduce two weeks later, then everyone pretends the drift is “normal.” It isn’t. It’s data laundering.

This playbook is about shipping a KPI truth pipeline: define metrics once, compute them the same way every time, and push them to the places decisions actually happen. No dashboards-as-theater. Just a system.

Tool comparison (and why these four belong together):
Supabase: The source of record that can take a beating. It holds events, accounts, and the computed KPI table you’ll actually trust, with Row Level Security when teams start arguing about access.
dbt (or SQL + scheduled jobs if you’re allergic): The metric compiler. You encode “Active,” “Churn,” and “Expansion” as versioned transformations, not interpretations.
n8n: The conductor that moves outputs into workflows. It schedules runs, detects anomalies, and routes alerts without begging engineering for a custom cron job.
Perplexity: The skeptic in the loop. It generates a metric definition draft, pulls edge-case considerations, and helps you pressure-test naming and calculation assumptions before you bake mistakes into queries.

Outcome: a weekly KPI packet that can’t lie.
Supabase ingests events. dbt computes a canonical kpi_snapshot table. n8n runs the job, checks deltas against thresholds, and posts a structured update to Slack/Email with links to the exact query version. Perplexity is used upfront to tighten definitions and later to draft plain-English explanations for spikes, but it never “decides” the numbers.

The point isn’t prettier reporting. It’s removing the social layer where metrics mutate to fit the meeting.

We tackled this at a B2B SaaS where “Active accounts” was the weekly knife fight. Sales counted any account that logged in. Product counted “created at least one project.” CS counted “had a ticket this month.” Same word, three dashboards, three realities. The drift wasn’t subtle. It was weaponized.

The messy part wasn’t the data. It was the transport. Someone would paste a SQL snippet in Slack. Another person would “fix” a join. Then a screenshot. Two weeks later, the CFO asks why Active dropped 18% and nobody can rerun the exact query. Because it lived in a thread. Because the timestamp filter was “last 30 days” and the timezone silently changed. Because the event table had duplicates from a retry bug and only one person remembered to add DISTINCT. Data laundering.

Implementation looked like this. Supabase became the source of record: raw events in event_log, accounts in accounts, and one computed table we could name and defend: kpi_snapshot with date, metric_name, value, segment, query_version. Row Level Security mattered the moment we added a customer segment column and someone asked, “Who’s allowed to see churn by enterprise vs SMB?”

dbt did the heavy lifting. A model for active_accounts_daily. Another for churned_accounts_monthly. Definitions in YAML, tests for uniqueness and not-null. And a big friction point: the first “correct” model was wrong because we used account.created_at instead of first_paid_at, which made trials look like paying customers. The packet went out. Leadership reacted. Then we had to admit it and backfill. Painful. Necessary.

n8n ran the job nightly. Trigger at 2:10am. Call dbt Cloud or run a container. Then query kpi_snapshot deltas: if Active changes more than 7% day-over-day, post to Slack with the metric, the segment, and the commit hash. If it’s bigger than 15%, open a Jira ticket automatically. Sounds strict. But otherwise, who notices slow drift?

Perplexity came in before we codified anything: “What edge cases break churn definitions in B2B annual contracts?” It helped draft definitions and the plain-English explanation when spikes happened. But it never touched the numbers.

And the uncomfortable question: when the metric is “right,” but the business feels “wrong,” what do you trust first?

Here’s the part people don’t like admitting: the “KPI truth pipeline” can absolutely become a new kind of theater. Not dashboard theater—pipeline theater. You get immaculate tables, versioned models, green dbt tests, pristine Slack packets… and the business still makes dumb calls because you’ve mistaken reproducibility for relevance.

I’ve watched teams scale this setup and hit three traps.

First, the pipeline calcifies. Once metrics are codified, changing a definition starts to feel like changing the law. So orgs keep legacy definitions long after the product changes, because nobody wants to relitigate Active v2. The system becomes a compliance artifact instead of a learning tool. You’ll hear, “We can’t change it, we’d lose comparability,” while everyone quietly stops trusting what “Active” means anyway.

Second, anomaly detection turns into alert spam or alert silence. The 7% threshold looks rational until seasonality, product launches, billing cycles, and backfills collide. Then n8n either pages you every day or you keep widening thresholds until nothing fires. The hard part isn’t wiring the check; it’s maintaining a living baseline model and deciding who is on the hook when anomalies happen. “Open a Jira ticket automatically” sounds clean until you’ve created a robot that manufactures busywork.

Third, RLS and segmentation make you feel safe while politics get sharper. The moment you segment churn by plan, region, or owner, metrics become performance reviews. People start negotiating definitions because the definition determines who looks good. Your “truth pipeline” will get pressure-tested socially, not technically.

If we’re honest, the scalable move is to treat metrics like product surfaces: they need owners, deprecation policies, migration plans, and release notes. Not just dbt models. If you can’t answer “Who is the PM for churn?” you don’t have a truth pipeline—you have a query factory with a Slack bot.

The uncomfortable question isn’t “is the number right?” It’s “what decision is this number allowed to make, and who pays when it’s wrong?”