Real-Time Decisioning: What It Is, Latency Budgets, and Where Rules Beat ML

Real-time decisioning is software that picks the best action for one customer at the moment of an interaction: an offer, message, content block or no action at all. It combines current context, eligibility rules, scoring models and business constraints, and answers fast enough for the channel, from under 100 milliseconds on a web page to a few seconds for push or email. It usually reads profiles from a customer data platform (CDP).

Who this is for: architects, marketing technology leads, data scientists and risk owners. You will get the decision loop, a latency table by channel, a rules-versus-ML comparison, audit requirements, vendors and a checklist. More explainers: the Learn hub.

The decision loop

Whatever a vendor calls its parts, an engine runs the same seven steps:

1. Context. A request arrives with identity, channel, placement and live signals (page, cart, session, last event). Profile and features are fetched by key.
2. Eligibility. Hard rules decide which candidate actions are allowed: consent, product holds, suitability, regulatory suppression. Adobe describes decision rules as constraints applied to a profile to determine eligibility 3.
3. Scoring. Models estimate propensity, value or risk for each eligible action. Pega describes predictive and adaptive models scoring thousands of possible actions against a customer's context 1.
4. Arbitration. Eligible, scored actions are ranked into a winner. Pega says its engine weighs each eligible action against relevance, value and configured limits 1; Medallia describes built-in arbitration that ranks decisions by propensity 5; Adobe ranks eligible offers by priority 3.
5. Constraints. Frequency caps, quiet hours, budgets and conflict rules trim the result. Adobe documents total caps and per-profile caps 3. Products differ on whether constraints run before or after ranking.
6. Delivery. The answer returns by API or SDK, or triggers a send.
7. Feedback. Impressions, clicks, conversions and non-responses return to update models, caps and logs. Pega says its adaptive models learn from real-time data 2.

Latency budgets by channel

No standard sets decisioning latency. Budgets come from user-experience thresholds and channel behaviour. Jakob Nielsen's long-cited limits are 0.1 seconds for a system to feel instantaneous, 1 second for flow of thought to stay uninterrupted and 10 seconds for attention 8. Core Web Vitals add that a good Largest Contentful Paint is 2.5 seconds or less 9 and a good Interaction to Next Paint is 200 milliseconds or less 10, so a decision call in the rendering path draws on a shared budget. Pega claims answers in under 200 milliseconds 1 and SAS claims milliseconds 7; both are vendor statements, not benchmarks.

These are starting points to agree as service-level objectives, not standards. Measure p95 and p99, not averages. Time usually goes to the network round trip, profile and feature reads, model scoring, rules evaluation and logging. Keep profile and features to one key-value read, precompute heavy features, log asynchronously and return a default action on timeout.

Rules, machine learning and hybrid arbitration

Where rules win

Google's Rules of Machine Learning opens with the advice not to be afraid to launch without machine learning, and not to use it until you have data 12. Rules win on:

• Eligibility and compliance: deterministic, testable, easy to explain.
• Cold start and low volume: no outcome data to learn from.
• Explicit policy: never offer product X to segment Y.
• Specific reasons: Regulation B requires adverse-action reasons that relate to the factors actually considered or scored 14, and the CFPB says creditors may not use complex algorithms if they cannot give specific, accurate reasons 13.

Where machine learning wins

Ranking many candidates, adapting to feedback and capturing interactions no rule author would write. The same Google guide notes that a complex heuristic becomes unmaintainable and recommends machine learning over one 12.

The hybrid pattern

Production systems combine them: rules gate eligibility, models rank, rules enforce constraints, and business weights tune the final order.

Open-source rules engines include Drools, part of Apache KIE under the Apache 2.0 licence with DMN support 15, and the MIT-licensed GoRules ZEN Engine, written in Rust, which claims microsecond evaluation (unverified here) 16.

Feature freshness

A feature is a value computed from customer data, such as orders in the last 30 days or failed logins in the last 10 minutes. Decide each feature's maximum age. Nightly batch suits slow attributes; seconds-level features need a stream processor and an online store.

Warehouses help but have limits: Snowpipe Streaming reports ingest-to-query latency as low as 5 seconds 18, and dynamic tables have a 60-second minimum target lag 19 (see composable vs packaged vs private). Feast, an open-source feature store, serves historical features for training from stores such as Snowflake and BigQuery, and online features for inference from stores such as Redis, DynamoDB and Cassandra 17. Using one definition for both avoids training-serving skew. If a feature is older than its maximum age, drop it or fall back to a default, and log the feature timestamps used.

Explainability and audit of decisions

A decision log should capture: decision ID and time; identity and channel; input and feature snapshot with timestamps; candidates considered; rules fired and constraints applied; scores and model version; the winner; and the outcome. Pega says each decision records what was chosen, what was rejected and why 1; FICO says each decision is logged, traced and explained 6. Both are vendor claims, so test them in a pilot.

Regulation sets the stakes:

• GDPR Article 22: people have the right not to be subject to decisions based solely on automated processing, including profiling, that have legal or similarly significant effects; where an exception relies on contract or explicit consent, safeguards include human intervention and the right to contest 20. Most marketing offers fall outside it; credit, insurance and employment decisions may not.
• EU AI Act: marketing personalisation is not high-risk by itself, but credit scoring and life or health insurance pricing are listed in Annex III 21. Regulation (EU) 2026/1744 moved stand-alone high-risk obligations to 2 December 2027 21.
• US credit: Regulation B and the CFPB position above 1314.

See explainable AI for customer decisions and the EU AI Act for marketing and customer decisioning. An immutable, append-only store is the right shape for decision evidence, because entries cannot be quietly edited later.

Where decisioning runs: SaaS API or inside your own environment

| Embedded engine in your service | Drools or GoRules plus your model server and a feature store 151617 | Full control; in-process latency | You build arbitration, logging, UI and governance |

SaaS is the right answer for marketing-led web and app personalisation without residency limits and with a small operations team. Run decisioning inside your own environment when the data cannot leave (balances, clinical context, self-exclusion flags), when latency is tight, or when sovereignty applies. In a customer-owned deployment such as PrivyCDP, profile data and the audit ledger stay in your environment, so an engine running beside them adds no external data hop.

Vendors and landscape

For orchestrating what happens after a decision, see customer journey orchestration; for banking and gambling examples, see next-best-action inside the bank and responsible gambling interventions.

Implementation checklist

• Define one decision, one placement and a p95 and p99 latency objective.
• List candidate actions and owners; write eligibility rules first.
• Make consent and suppression a hard gate and test it with withdrawn consent.
• Start with rules and a priority order; add machine learning when outcome data exists.
• Give every feature a maximum age and a fallback.
• Set a default action and a timeout so failure degrades gracefully.
• Log every decision with inputs, candidates, rule trace, scores and versions.
• Keep a holdout group so lift is measured, not assumed.
• Load-test at peak and with stale features.
• Review credit, insurance and employment decisions against Article 22, Regulation B and the AI Act.
• Decide where it runs (SaaS or your environment) before choosing an engine.