Churn Definition: Why Shifting Metrics Break AI Models
    Predictive AnalyticsHead of Growth

    Churn Definition: Why Shifting Metrics Break AI Models

    Your churn prediction model failed? It's not the algorithm. Unstable metric definitions are the cause. A Head of Growth's guide to fixing the architectural flaw.

    Executive Summary

    Pain

    Your churn prediction model is likely giving you unreliable forecasts because the definition of an 'active user' keeps shifting.

    Risk

    You risk making poor decisions on marketing spend and product strategy based on this data, which can affect your growth targets.

    Fix

    The fix isn't a better algorithm. It's getting Product, Marketing, and Finance to agree on a single, governed Churn Definition in a central system, like a Semantic Layer, where it can't be changed by accident.


    Why a good model can produce unreliable forecasts

    You may have spent a good deal on a modern data stack and have a team of smart data scientists. You have built a churn prediction model that is, on paper, excellent. Yet the forecasts don't feel quite right. The groups of customers it suggests for intervention don't respond as you'd expect, and your campaign return on investment is slipping. The board might be starting to ask why the numbers from last quarter don't seem to match the model's view of the past.

    In my experience, this isn't a failure of the data science team. It's a symptom of a deeper, and very common, structural problem I see in many growing companies. You have probably moved to the cloud and hired good engineers. But if the underlying process is messy, the new tools just help that messy process run faster. Automating a broken process just generates confusing results more quickly.

    The cause is usually an inconsistent metric

    The root cause is nearly always the same: your core business metrics haven't been properly agreed upon. The model is struggling because its most basic input, the definition of an 'active user', was constantly changing.

  1. In Q1, 'Active User' meant 'user login'. This was a simple, sensible definition for an early-stage company.
  2. In Q2, the product team shipped a new feature. The definition was updated in a planning meeting to 'user login AND feature_x_click'. This was noted on a Confluence page, but the main data pipeline was never changed to reflect it.
  3. In Q3, the finance team calculated it based on 'first subscription payment'. They did this in a spreadsheet to help with their revenue reporting.
  4. Your model is now trying to find patterns in three different datasets that just happen to share the same name. It's not predicting the future; it's just confused by an inconsistent history. The problem isn't the model itself. It's that the business has no reliable memory of its own logic. This is a classic sign of a weak Metric Definition process, and it can quietly hold back a company's growth.

    I have seen this sort of thing play out many times. I worked with a fintech scale-up once where the weekly trading meeting spent the first 30 minutes every Monday morning debating one question: 'Whose number is right?'. The debate only stopped when we got the teams to agree on a single definition and write it down in their Semantic Layer. The arguments stopped overnight.

    AI model churn: Shifting metrics break AI. Understand churn definition and its impact. Whiteboard infographic.

    A four-step plan to fix the definition

    Building a better model or hiring more analysts won't solve this. You need to fix the process that creates the data, not just patch the final report. The solution is to move the logic out of conversations and spreadsheets and into a central, governed system.

  5. Pause work on the model: It's best to stop any further development on predictive models that use this metric. To keep going is likely a waste of time and money.
  6. Get everyone to agree on the definition: This part is more about people than data. You need to get the Heads of Product, Growth, and Finance in a room to agree on one, unambiguous definition of 'Active User'. It's important to document the edge cases.
  7. Write the definition down in code: This is the most important step. The agreed logic must be written in code, perhaps in a tool like Looker's LookML or a dbt model. This becomes the Single Source of Truth. It's version-controlled, auditable, and visible to everyone. It is no longer a mystery.
  8. Rebuild your historical data: Once the definition is set in code, you can finally rebuild a clean, consistent history. Only then does it make sense to retrain your churn prediction model.
  9. The trade-off: a short-term slowdown for long-term speed

    I'll be honest: this process can be difficult. It is not a quick fix. Getting different departments to agree on a single metric means they have to give up the comfort of their own private spreadsheets and 'local' numbers. It requires a small culture shift, from 'my team's data' to 'the business's data'.

    You will probably have to slow down for a few weeks to get this right. You may meet some resistance, because you are replacing ambiguity with accountability. But this short-term slowdown is what buys you the confidence to move much faster for the next few years. It's the foundation of any sensible Data Governance strategy.

    By doing the hard work of writing your business logic down as code, you don't just fix a broken model. You build a stable foundation for every strategic decision you need to make in the future. Your board meetings will change from debating whether the data is right to debating the strategy it suggests. And that, really, is the entire point.

    Ready to Transform Your Data?

    Book your free clarity call today and discover how NorthStar Analytics can help you build a single source of truth.