A churn definition is not merely a SQL formula dividing cancellations by total users. Operationally, a lack of a standardised churn definition is the primary reason your Product VP claims retention is up while your CFO reports revenue is down. It is the silent friction that erodes trust in the data warehouse. If you cannot agree on precisely when a customer has left, you cannot agree on how to save them.
The Series B Trap: When Logic Diverges
In the early days, a customer was 'churned' simply when they hit the cancel button. As you scale to Series B, the complexity explodes. You encounter involuntary churn (failed payments), dormant users who haven't cancelled but haven't logged in, and partial downgrades.
The trap occurs when different departments hard-code their own logic into isolated dashboards. Marketing might ignore involuntary churn to inflate LTV, while Finance includes it to balance the books. The result is a fractured narrative where no two reports align, and the board loses confidence in the data.
Architecting a Unified Churn Definition
We do not solve this by building more dashboards. We solve it by auditing the underlying logic. The NorthStar approach involves stripping back the conflicting calculations found in Salesforce, Stripe, and your BI tool to establish a Single Source of Truth.
We codify the churn definition at the data modelling layer—usually within dbt—ensuring that `is_churned` means exactly the same thing for the Customer Success Manager as it does for the Board. This requires rigorous [data-governance] to maintain. Once the definition is locked and the schema simplified, we can move toward accurate [revenue-reconciliation] and true predictive modelling.