Building a Custom Churn Prediction Model With Your Data

Teams often start with the built-in analytics in their subscription tool, like Stripe Billing or Chargebee. These show your historical churn rate but cannot tell you *who* is about to churn next week. They report on the past. They do not predict the future for individual accounts, which is what your customer success team needs to act.

A B2B SaaS company uses ProfitWell, which flags accounts with low login frequency. But their biggest churn signal is a sudden drop in API call volume for a key integration, a metric ProfitWell cannot ingest from their production database. Their customer success team wastes hours calling accounts flagged for low logins, while the real at-risk accounts go unnoticed and churn at renewal, costing them a 3% dip in MRR last quarter.

These off-the-shelf tools rely on generic, one-size-fits-all features. They assume churn is driven by login counts and payment failures because that is the data they can easily access. They cannot be customized to look for your business's unique churn indicators, because they do not have access to your application database or your proprietary usage metrics.

Syntora's approach begins by connecting directly to your data sources via API or read-only database replicas. We would pull 12-24 months of history from relevant systems such as Stripe for subscriptions, Segment for user events, and your production Postgres database for application-specific usage. The data unification process would leverage Python with pandas to join these disparate sources into a single event timeline for each customer, carefully resolving identity across platforms.

From this unified data, Syntora would engineer a robust set of features, typically around 75, such as 'time since last key action', 'ratio of support tickets to active days', and 'change in monthly usage volume'. The model training would typically employ a LightGBM gradient boosting model, valued for its ability to capture complex feature interactions more effectively than simpler models.

The final trained model would be serialized and deployed as a FastAPI service, often on serverless platforms like AWS Lambda, which helps manage hosting costs effectively. The deployed API would expose a single endpoint, accepting a customer ID and querying the latest features from a pre-calculated cache in a database like Supabase. It would then return a churn probability score from 0.0 to 1.0, designed for efficient response times.

A nightly batch job would update the churn score for every active customer and write it back to a custom field in your CRM (like HubSpot or Salesforce) or a Google Sheet. Your customer success team would then receive a simple, ranked list of at-risk accounts each morning. Operational aspects would include structured logging with tools like structlog, with API errors or data pipeline failures configured to trigger immediate Slack alerts.