Concept
Decisioning chooses the next action for a customer, and it contains four separable things: the definitions of the audiences and signals it runs on, the policy that sets frequency, eligibility and suppression, the arbitration that picks one action when several qualify, and the execution that sends it. Asking whether decisioning belongs in the CDP or the CEP treats those four as one block. The more useful question is where each of them should sit, and the answer is often split. Definitions belong close to the governed customer data, execution belongs in the channels, and arbitration belongs wherever the most complete context meets the freshest state at the moment the decision is made.
Why it matters
Arbitration pulls in two directions. It wants context, meaning the full customer history, propensity scores and value models, which usually live in the data layer. It also wants reflexes, meaning up-to-the-second journey state, recent contacts across every channel and the timing of the current session, which usually live in the engagement layer. Each pattern resolves that tension differently. In a suite, both sides share one profile and the arbiter can sit on top of it. In a CEP that carries its own data, the arbiter has excellent reflexes and only the context the CEP ingests. In a standalone or composable CDP with a separate CEP, context and reflexes live in different systems and something has to carry scores one way and contact history the other. A dedicated decision engine, Pega’s Customer Decision Hub being the long-standing example, is a fourth answer: arbitration as its own product, called by every channel. Any of these can work, provided each customer moment has exactly one arbiter.
A simple example
A bank wants to present one next-best action when a customer opens its app: a credit card upgrade, a savings offer, a retention call-back or nothing at all. The warehouse computes propensity scores each night and publishes them as attributes, which is the definitions part. A contact policy owned by the marketing operations team says no more than one offer a day and none within a week of a complaint. The engagement platform holds the arbiter, which reads the scores, applies the policy, checks what the customer received today in every channel and chooses at the moment the app opens, and the call-centre desktop asks the same arbiter through an API so that the agent’s script agrees with the app. The failing version of the same bank has the data team excluding complained customers from the upgrade audience in the CDP while the CRM team runs a separate retention journey in the CEP, so on a bad day both fire and nobody can say which system was supposed to decide.
The architecture view
Definitions can live near the data and execution in the channels. Arbitration needs one home per customer moment.
The criteria for choosing among the patterns are in Part 2 of the CDP and CEP patterns, and real-time need is one of them. Where decisions have to react within seconds to what the customer is doing, the arbiter sits most comfortably next to the state it reads, which usually means the engagement layer, as event, state and transition explains. Where decisions are about value and eligibility over weeks, it can sit closer to the data.
The mistake I often see
The recurring error is arbitration by accident. Nobody decides where arbitration lives, so it ends up in two places at once: priority encoded as audience exclusions in the CDP, and priority encoded again as journey conditions in the CEP, each partly right and neither aware of the other. The symptom is customers receiving two offers that were each designed to be the only one. A quieter version of the same error is assuming that a real-time CDP decides in real time. Fast profile updates tell every downstream system what is true about a customer quickly, and they leave the choice between competing actions to whoever owns arbitration, which may be nobody.
Go deeper
Start from what decisioning is and what a CEP is if you have not read them. The three patterns and their trade-offs are in Part 1 and Part 2 of the CDP and CEP architecture decision, and the Field Notes on Adobe Journey Optimizer show decisioning built as its own capability inside a suite. For the forces that pull a stack towards one pattern or another, read The Four Gravities Shaping MarTech Decisions.