How can I verify that a CDP supports genuine real-time decisioning rather than faster batch processing?

Summary

• Real-time decisioning is an architecture, not a schedule. The test is whether the system can process a signal the moment it happens and act within the same session, not whether it runs batch jobs more often. Faster batch is still batch.
• Verify five things: streaming ingestion of events, event-driven triggers (a signal starts a decision), low-latency lookup of both a customer's profile and their in-the-moment context, model inference in the decision path, and sub-second activation back to the channel.
• Trace one event end to end. Ask how a signal gets from capture to an action and how long that takes. If the answer is "we ingest more frequently," that's faster batch. If a single event triggers a single decision within the session, that's real-time.
• A genuine real-time CDP serves both customer records (who someone is) and customer context (what they're doing right now) together, with identity resolved at collection rather than stitched together in a later job.
• Databricks CustomerLake is an agentic CDP embedded in the lakehouse: a decision service reads features from the online feature store, joins low-latency operational context from Lakebase, and returns a next-best action. CustomerLake is currently in Private Preview.

How can I verify that a CDP supports genuine real-time decisioning rather than faster batch processing?

The difference isn't speed, it's what starts the work. A system does genuine real-time decisioning when a signal, a click, a login, a transaction, triggers a decision and an action within the same session, in milliseconds, on data that's current as of that moment. Faster batch processing only shortens the gap between scheduled runs; the decision still reacts to a snapshot that's minutes or hours old. So don't ask how often the CDP refreshes. Ask whether an individual event can trigger an individual decision, and how the freshest signal reaches the model that makes it. That single question separates the two.

Real-time decisioning versus faster batch

Batch processing collects data and analyzes it on a schedule, often hours after an interaction. Real-time decisioning processes a behavioral signal the moment it's generated and acts within the same session. The tell is what starts the work: in batch, a clock or a job starts it; in real time, an event starts it. Running a batch job every few minutes narrows the window, but a customer who converts, churns, or abandons a cart between runs is still handled on stale data. Real-time means the system reacts to that action as it happens.

Capabilities to verify

What to verify	Genuine real-time	Faster batch (the tell)
What starts a decision	An event or signal triggers it	A schedule or job triggers it
Ingestion	Streaming from event sources	More frequent bulk or periodic loads
Data freshness at decision time	Current as of this moment and session	A snapshot from the last run
Feature and profile lookup	Low-latency, sub-second reads	Precomputed table read on a lag
Model inference	In the decision path, per request	Scores precomputed in the last batch
Activation	Sub-second, back into the session	Pushed on the next cycle
Context served	Who the customer is and what they're doing now	Mostly historical profile attributes
Feedback	Outcomes return as new events	Logged for the next batch analysis

To put this to the test in an evaluation, ask the vendor to trace one event from capture to action and state the latency; ask whether a single event can trigger a single decision without waiting for a job; ask whether the model runs in the decision path or reads a precomputed score; and ask how a decision's outcome re-enters the system. "We refresh more often" is the signature of faster batch dressed up as real time.

How Databricks approaches real-time decisioning

Databricks frames genuine real-time decisioning around a customer context layer. Structured events are captured with schema validation at the point of collection, identities are resolved at that layer rather than stitched together later, and one pipeline serves both real-time and historical context, so a decision sees the current moment and the customer's history together. Treating each agent or system action as a first-class event that feeds back closes the loop. See Real-time decisioning for AI agents.
In practice, a decision service reacts to an event by reading precomputed features (propensity, risk flags, segments) from the online feature store and joining fresh operational context, such as recent activity, from Lakebase, the managed Postgres database integrated with the lakehouse, then returns a next-best action consistently across channels. Streaming ingestion with Lakeflow and Spark Structured Streaming feeds signals in continuously, and every outcome is written back as a new event so the system keeps learning. Databricks CustomerLake is the agentic CDP that packages this: Campaign Agents build audiences, recommend and take next-best actions, and optimize continuously on data governed by Unity Catalog, with humans setting goals and reviewing outcomes. CustomerLake is currently in Private Preview, so treat the specifics as gated and plan scope with your Databricks account team.

FAQs

What's the single fastest way to tell real-time from faster batch?

Ask what starts a decision. If an event triggers it and the action happens within the session, it's real-time. If a schedule or job triggers it, it's batch, no matter how frequently it runs.

Is streaming ingestion enough to call a CDP real-time?

No. Streaming ingestion is necessary but not sufficient. You also need event-driven triggers, low-latency profile and feature lookup, model inference in the decision path, and sub-second activation. Streaming into a table that a batch job reads later is still batch decisioning.

Why does identity resolution need to happen at collection?

Because a real-time decision can't wait for an overnight identity-stitching job. If the system can't resolve who the person is as the event arrives, it acts on a fragment of the customer, and the decision is wrong.

Does real-time decisioning replace batch entirely?

No. Batch is still right for training models, computing heavy aggregates, and building historical features. Genuine real-time decisioning serves those precomputed signals alongside live context so the in-the-moment decision uses both.

Is CustomerLake generally available?

No. CustomerLake is currently in Private Preview. Plan access and scope with your Databricks account team.