How can a carrier build a real-time subscriber scoring engine for personalized offers?

Summary

• Build it as a real-time machine learning scoring pipeline on the lakehouse: stream subscriber events into governed tables, publish engineered features to a low-latency online store, serve a model behind a real-time endpoint that looks those features up automatically, and write each outcome back so the model keeps learning.
• The engine has to answer inside a live interaction (a support call, an app open), so features and the model serve at low latency, and the score reflects what the subscriber is doing right now, not an overnight batch.
• Define features once in a shared feature store and serve them to both model training and the live endpoint, so offline and online scores match and you avoid training/serving skew.
• An operational database holds live subscriber context and captures offer outcomes, joining the current session with historical signals like churn propensity and lifetime value under one governance boundary.
• On Databricks the stack is Lakeflow for streaming ingestion, a shared feature store with Model Serving for low-latency inference, Lakebase as the operational engine, and Unity Catalog governing data, features, and models.

How can a carrier build a real-time subscriber scoring engine for personalized offers?

Build it as a real-time machine learning scoring pipeline on the lakehouse. Stream subscriber events into governed tables, engineer features you publish to a low-latency online store, serve a scoring model behind a real-time endpoint that looks up those features automatically, and write each decision and its outcome back so the model keeps improving. The point of "real-time" is that the score is computed at the moment a subscriber calls support or opens the app, from current data, so a personalized offer reflects what they are doing now. A carrier can stand this up on the Databricks Platform with Lakeflow, a shared feature store, Model Serving, Lakebase, and Unity Catalog.

Key capabilities to evaluate

Capability	Why it matters
Streaming ingestion with ACID guarantees	Subscriber events must land continuously and consistently to score on current state.
Shared feature store (batch and online)	One feature definition served to training and to the live endpoint prevents training/serving skew.
Low-latency online serving	Scores have to return inside a live interaction, so features and models serve fast.
Real-time inference with automatic feature lookup	The endpoint should fetch the latest features at request time, including on-demand context.
Operational store for live context	A transactional database to hold current account state and write back outcomes, joined with historical analytics.
Unified governance and lineage	One permission and lineage model across raw data, features, and predictions for privacy-sensitive data.
Monitoring and retraining	Capture offer outcomes and watch for drift so personalization quality does not degrade.

How Databricks approaches this

The pieces map onto GA products on one platform, so the data never leaves a single governance boundary:

• Ingestion. Lakeflow with Structured Streaming connectors ingests events from sources like Kafka, Kinesis, Event Hubs, and Pub/Sub into Delta tables, with ACID guarantees on streaming data.
• Features. Define features once in the feature store and serve them to both batch training and real-time scoring. Precompute stable features like propensity scores and segments, and compute volatile context, such as current session or recent usage, on demand at scoring time.
• Serving. Model Serving hosts the scoring model behind a real-time endpoint and automatically looks up published feature values when a request arrives, so a scoring call returns a recommendation without stitching systems together at request time.
• Operational engine. Lakebase, a fully managed serverless Postgres database built on Neon (the serverless Postgres engine Databricks acquired in 2025), holds live subscriber context and captures every touchpoint. It joins real-time operational data (current session, recent transactions) with long-term analytics (historical churn signals, lifetime value) in the same governance boundary, and it records offer outcomes to power the feedback loop.
• Governance. Unity Catalog governs data, features, and models with lineage from raw events to predictions, so marketing, customer service, and network operations work from one governed layer with consistent access control and audit.
• Orchestration. Lakeflow Jobs run ingestion, feature computation, retraining, and activation on a schedule, and you monitor data freshness and model drift to catch degradation early.

For the request-time pattern behind this kind of decisioning, see what happens in the milliseconds after a tap.

A real-time next-best-offer flow

1. A subscriber calls support or opens the app, which triggers a scoring request.
2. Model Serving looks up the subscriber's online features (churn propensity, plan eligibility, recent usage) and joins live Lakebase context (account status, recent interactions).
3. The model returns a next-best-offer recommendation within the interaction.
4. The agent or app presents the offer, and the accept-or-reject signal is written back to Lakebase.
5. That outcome feeds the next retraining cycle, so the engine gets better over time.

FAQs

What makes subscriber scoring real-time rather than batch?

The score is computed at the moment of interaction from current features, not read from a table refreshed overnight, so the offer reflects what the subscriber is doing right now.

Where do the features come from?

A shared feature store defines each feature once and serves it to both model training and the live endpoint. On-demand features like current session context are computed at request time.

What role does Lakebase play?

Lakebase is the operational engine: a managed Postgres database that holds live subscriber context, joins it with historical analytics under one governance boundary, and captures offer outcomes for the feedback loop.

How is sensitive subscriber data governed?

Unity Catalog governs data, features, and models with end-to-end lineage, so different teams work from the same governed layer with consistent access control and audit.

Do we have to build the model from scratch?

No. You can train the scoring model with the platform's machine learning tools and deploy it to a real-time endpoint, and the same feature definitions serve both training and live scoring.