RESOURCES/Architecture
Reference architecture for a decision layer
A decision layer sits between the data plane and the activation plane. It reads customer context from the warehouse or CDP, produces one ranked and sized decision per customer, and writes that decision into the systems that execute. It owns the decision log and the experiment state, and it owns nothing else.
Definition
Decision layer
The component of a customer stack that turns unified customer context into a single committed action per customer, ranked by expected value and recorded with the experiment state needed to judge it later.
Most stacks have a hole in the middle
The modern B2C stack is well provisioned at both ends. There is a warehouse, usually a CDP, and a mature set of channels. Between them is a gap where the actual commercial choice is made, and in most companies that gap is filled by eligibility rules, frequency caps and a planning meeting. Nothing in the stack owns the sentence 'this customer should get this, and it is worth this much'.
- The warehouse knows everything and decides nothing.
- The engagement platform decides how, never whether.
- Rules encode last year's decisions and are never retired.
- No system holds the counterfactual, so nothing can be judged.
Four planes
Keeping these separate is what makes the stack replaceable. Collapsing any two of them is how organisations end up unable to change vendors.
01
Read, do not migrate
The decision layer subscribes to context where it already lives. Any architecture that requires a data migration before the first decision has put a year between you and the revenue case.
02
Decide on a window, not on every event
Most B2C decisions are daily or hourly, not per-event. Real-time decisioning is genuinely required for in-session surfaces and rarely required for lifecycle ones, and paying for it everywhere is a common and expensive mistake.
03
Commit one decision per customer
Arbitration only means something if the output is singular. Emitting a ranked list and letting each channel pick from it recreates the original problem in a new place.
04
Log the counterfactual with the decision
Holdout assignment is part of the decision record, not a reporting afterthought. If assignment is reconstructed later, the measurement plane cannot be trusted.
05
Execute through the systems already in place
The decision layer should reach the customer through the channels the business already runs, rather than becoming a new channel with its own governance, templates and compliance surface.
Responsibilities, and what breaks when they are merged
| Plane | Owns | Must not own |
|---|---|---|
| Data plane | Identity, unified profiles, event history, outcomes. Warehouse, CDP, product analytics. | Commercial priority. A profile store that ranks actions becomes impossible to reason about. |
| Decision plane | Candidate generation, expected-value ranking, arbitration, guardrails, holdout assignment, the decision log. | Identity resolution or creative production. Owning either turns it into a platform migration. |
| Activation plane | Delivery, channel governance, creative, send-time and deliverability. Engagement platform, product surfaces, care tooling. | Cross-channel priority. Each channel optimises itself and nothing arbitrates between them. |
| Measurement plane | Holdout integrity, windows, readouts, the record of what was true. | The incentive to report favourably. It should be readable independently of the decision plane. |
Architecture review questions
Run these against your current stack, whoever supplies it.
- Which single system can answer 'why did this customer get this, last Tuesday'?
- Where is cross-channel priority resolved today, and is it resolved by value or by cap?
- Can the stack emit 'no action' as a first-class decision?
- Is holdout assignment recorded at decision time or reconstructed at reporting time?
- If you replaced your engagement platform next year, what percentage of decision logic would have to be rebuilt?
- Does anything in the stack write back what actually happened, so the next decision is better than the last?
Two things a decision layer must never become
- A second source of truth. If it starts resolving identity or storing canonical profiles, you now have two systems that disagree and a migration you did not plan.
- A channel. Once it owns templates, sending reputation and compliance review, it competes with the engagement platform instead of directing it.
- A replacement for the warehouse. Analytical workloads and decisioning workloads have different shapes; merging them makes both slower.
- A rules engine with a model bolted on. If the candidate set is human-authored, the architecture is fine and the ceiling is still human.
Markin is an autonomous growth-science team for large B2C businesses. It investigates why revenue per customer is stuck, forms its own hypotheses across marketing, product, pricing and technical health, chooses the next best action for each customer, launches it through the systems the business already runs, and proves every one against a randomised holdout.
Decisioning tools choose between the actions your team already built. Markin decides what to build.
Questions people ask
- Does a decision layer replace a CDP?
- No. A CDP resolves identity and unifies profiles; a decision layer consumes those profiles and chooses actions. They solve different problems and the boundary is clean: if a component is deciding what should happen to a customer, it belongs in the decision plane, and if it is deciding who the customer is, it belongs in the data plane.
- Do we need real-time decisioning?
- For in-session surfaces such as a paywall, a checkout or an in-app placement, yes. For lifecycle decisions, a daily or hourly decision window is usually indistinguishable in outcome and considerably cheaper to operate. Buying real-time for everything is one of the most common overspends in this category.
- Where should the decision log live?
- In the decision plane, and readable from the warehouse. Every decision should carry the customer, the chosen action, the alternatives considered, the expected value, the guardrails applied and the holdout assignment. Without that record, nothing downstream can be audited or improved.
- How does the decision layer avoid conflicting with journey logic already in the engagement platform?
- By becoming the entry signal rather than a parallel sender. The decision layer writes an attribute or fires an event, and the existing journey picks it up. Channel governance, frequency rules and creative stay where they already are, which is also what keeps the integration reversible.