From campaigns to per-customer decisions
The blocker is almost never the model. It is identity, latency, write-back, a margin number and the willingness to withhold.
5 checks
Five requirements decide whether a first per-customer decision is weeks or quarters away, and model quality is not one of them.
Key takeaways
- 01The blocker to a first per-customer decision is almost never model quality. It is write-back into the channel that executes the action.
- 02The most commonly missing input is a finance-supplied margin per action, and its absence is silent: the programme optimises revenue and reports success.
- 03Event freshness is usually over-specified. Most first decisions are comfortable on a daily batch, not a stream.
- 04Identity resolution only has to be complete across two systems: the one holding the signal and the one executing the action.
- 05The holdout is a governance decision before it is a technical one, and it is the item that most often has no named owner.
Romà Llambés · CEO, Markin · Reviewed 2026-09-10 · Every report is reviewed twice a year, and re-run out of cycle whenever a source it rests on changes. · Method and sources
The question
What does a company actually need to move from campaigns to per-customer decisions?
Per-customer decisioning needs five things: one customer identity across systems, events fresh enough for the decision window, a way to write a decision back into the executing channel, a finance-supplied margin per action, and the organisational willingness to hold out a control. Model quality is rarely the constraint. Write-back and margin inputs usually are.
- Sample
- Readiness assessments across Markin deployments and evaluations in large B2C bases, anonymised and reported as ordered blockers rather than as counts. Requirements are stated as thresholds a team can check against its own stack in an afternoon, without our involvement.
- Period
- Assessments conducted between Q3 2025 and Q3 2026.
- Reviewed
- 2026-09-10Reviewed twice a year
Findings
What we found
- 01Anonymised Markin deployments
Write-back into the executing channel, not model quality, is the most common blocker to a first per-customer decision.
Teams routinely have the data to decide and no supported path to make the decision act. The tell is a decisioning pilot that ends in a dashboard nobody operates from. Where the engagement platform can read a profile attribute and an existing journey can branch on it, the gap closes in days; where the only path is a new integration owned by a backlogged team, it becomes a quarter.
Do thisTest write-back first: set one attribute by hand and confirm an existing journey branches on it. Do this before any modelling work.
- 02Anonymised Markin deployments
A finance-supplied margin per action is the most commonly missing input, and its absence is silent.
Without it, candidate actions get ranked on expected revenue, which systematically favours discounts and low-margin products. Nothing breaks; the programme simply optimises the wrong quantity and reports success while doing it. A rough margin band per action, agreed in a single meeting, is worth more than a precise one that never arrives.
Do thisAsk finance for a margin band per candidate action this quarter, and start with bands rather than waiting for precision.
- 03Anonymised Markin deployments
Event freshness requirements are usually over-specified. Most first decisions have a window measured in days, not seconds.
Renewal, win-back, plan-fit and cross-sell decisions are all comfortable on a daily batch. Streaming infrastructure is genuinely needed for in-session decisions and cart-level intervention, and it is a substantially longer project. Choosing a first decision with a daily window removes the largest engineering dependency from the critical path.
Do thisPick a first decision with a window measured in days. It removes the largest engineering dependency from the critical path.
- 04Anonymised Markin deployments
Identity resolution rarely needs to be complete. It needs to be complete across exactly two systems: the one holding the signal and the one executing the action.
Full cross-channel identity is a multi-quarter programme. A first decision needs one reliable join key between two systems. Teams that scope identity to the decision start experimenting months earlier than teams that scope it to the roadmap.
Do thisScope identity to the two systems the decision touches, not to the roadmap.
- 05Anonymised Markin deployments
The holdout is a governance requirement, not a technical one, and it is the requirement most likely to be quietly dropped under pressure.
Every technical prerequisite has an owner and a ticket. The holdout has neither, and the first time a senior stakeholder asks why a tenth of the base received nothing, it disappears unless someone is accountable for defending it. Naming that owner before launch costs nothing and is the difference between a measured result and a story.
Do thisName the holdout owner before the pilot starts, in writing.
Charts and tables
The data
| Requirement | The threshold | How to check it | Typical time to close |
|---|---|---|---|
| Customer identity | One reliable join key between the signal system and the executing system | Take 100 customers from the signal system and match them in the executing system | Days if a key exists, a quarter if it must be created |
| Event freshness | Signal available inside the decision window, end to end | Time a real event from occurrence to availability where the decision is computed | Days for daily batch, weeks to months for streaming |
| Write-back | The executing system can read an attribute or event set externally, and something already branches on it | Set one test attribute by hand and confirm a journey or queue responds | Days where supported, a quarter where a new integration is needed |
| Margin per action | A margin band per candidate action, supplied by finance | Ask for it. If it takes more than one meeting, use bands rather than waiting | One to two weeks |
| Holdout governance | A named owner who can authorise and defend withholding from a randomised slice | Ask who signs off, and whether they have done it before | One conversation, or never |
| Attribute | Cheap first decision | Expensive first decision |
|---|---|---|
| Decision window | Days | Seconds, in session |
| Systems involved | Two | Four or more |
| Execution path | Existing journey or queue branches on a field | New channel or new surface has to be built |
| Margin input | One product, one margin band | Full catalogue margin model |
| Measurement | Customer-level randomised holdout | Geo split or pre-post, because the base is too small |
Run it on your numbers
Check your own readiness for a first decision
Answer for the one decision you want to run first, not for your estimate as a whole. The thresholds are the ones in the table above.
Requirements met
0 / 5
Fewer than three met. Pick a cheaper first decision: two systems, a decision window measured in days, and an execution path that already exists.
Implications
What this means for the person who has to act
Data platform owner
Check write-back before anything else. If the executing channel can already branch on a profile attribute set from outside it, the first decision is weeks away; if it needs a new integration in a backlogged team, it is a quarter, regardless of how good the data is.
Growth lead
Scope one decision with one decision window, not a programme. Most first decisions are comfortable on a daily batch, so specifying streaming freshness usually buys delay rather than accuracy.
Executive sponsor
Name the owner of the holdout before the pilot starts. It is the requirement that most often has no owner, and it is a governance decision, not a technical one.
Method
Definitions that change the answer
- Per-customer decision
- One action chosen for one customer at one moment, from the full set of candidate actions, valued and arbitrated against each other. Distinct from a campaign, which selects a segment and applies one action to all of it.
- Decision window
- The time between the signal arriving and the action having to be taken for it to still be relevant. It sets the freshness requirement: a same-session decision needs streaming events; a renewal decision is fine on a daily batch.
- Write-back
- The mechanism by which a chosen action reaches the system that executes it: an attribute on a customer profile, a field on a CRM record, an event, or an API call. Without it, a decision is a recommendation in a dashboard.
- Readiness
- Not data maturity in the abstract. The specific question of whether these five requirements are met for the one decision you want to run first, which is a much lower bar than a full CDP programme.
Estimator
The model, written out
Time to a first per-customer decision in production, and which requirement sits on its critical path. The output is an ordering of blockers, not a score.
Time to first decision
T = max(t_identity, t_freshness, t_writeback, t_margin, t_holdout)
A maximum, not a sum, because the five requirements are worked in parallel by different people. One late item sets the date on its own.
Blocker rank
rank(i) = share of assessments where t_i = T
A requirement is the blocker when it is the one that finished last, not when it was difficult.
Where the maximum becomes a sum
T = t_identity + t_writeback when write-back needs resolved identity
Dependencies between requirements are the reason a project that looked like six weeks lands at two quarters.
What has to hold
- Scope is one decision, not a programme. Every threshold in this report is stated for that scope.
- The five requirements are separable and worked in parallel by teams that already exist.
- Freshness is judged against the decision window of that one decision, not against a general ambition for real-time data.
What breaks it
- Requirements that gate each other, which turns the maximum into a sum.
- A regulated base where consent and purpose limitation become a sixth requirement and usually the first one.
- No warehouse and no event stream, which is an earlier problem than any of the five.
- Arbitration between many simultaneous decisions, which adds governance requirements this model does not cover.
Method
How to reproduce this
- 01
Pick one decision, not a programme. Write down its decision window in hours.
- 02
Check identity: can you resolve the same customer across the system holding the signal and the system executing the action, without a manual join?
- 03
Check freshness: is the signal available inside the decision window, end to end, including the load into wherever the decision is computed?
- 04
Check write-back: can the executing system read a field or event set by something outside it, and does a journey or queue already respond to that field?
- 05
Check margin: can finance supply a margin per candidate action this quarter? If not, decisions get ranked on revenue and will drift towards low-margin actions.
- 06
Check holdout: is there an agreed owner who can authorise withholding the action from a randomised slice for a full window, and defend it when someone asks why 10% of customers got nothing?
Uncertainty
How wrong each figure could be
A small, non-random set of assessments. We publish an ordering and refuse to publish percentages, because at this sample size a percentage would imply a precision we do not have. The uncertainty statement below is about the stability of the ordering, not about a confidence interval.
Write-back ranked first
It stays first under every subset of the assessments we can form, and in both sectors represented.
stable
Margin inputs ranked second
Margin is rarely the slowest item. It ranks high because its absence is silent: the programme ships, optimises revenue and reports success.
stable, but for a different reason
Identity and freshness
Their order swaps by sector, so treat them as a tied pair rather than as ranks three and four.
interchangeable
Weeks versus quarters
The distribution is bimodal rather than spread. A first decision either clears on existing plumbing or waits on a roadmap item owned by another team.
2 to 6 weeks, or 3 to 9 months
Robustness
What survives a different assumption
Each row changes the context and re-derives which requirement sits on the critical path.
| Change one assumption | What changes | Result | Conclusion |
|---|---|---|---|
| The engagement platform can read a profile attribute | Write-back already exists | Holdout governance becomes the blocker. Time drops into the weeks band. | Flips |
| Regulated base, consent per purpose | A sixth requirement is added | Consent ranks first and the ordering below it is unchanged. | Flips |
| Batch-only channel, daily send | Decision window widens to 24 hours | Freshness drops off the critical path entirely. Ordering otherwise unchanged. | Holds |
| Team already runs randomised tests | Holdout governance is settled | Ordering unchanged. The variance in delivery date narrows sharply. | Holds |
| No warehouse, no event stream | Prerequisite missing | The model does not apply. That is a data platform project, not a decisioning one. | Flips |
Write-back stays first in every scenario where it is not already solved, and margin stays the requirement whose absence does the most damage per unit of attention it receives. What moves is the delivery date, not the ordering. Read this as a checklist to run against one decision, never as a maturity score.
Limits
What this cannot tell you
- This is an ordering of blockers, not a measurement of how common each one is. We have deliberately not published counts, because the sample is small enough that a percentage would imply a precision we do not have.
- The assessments are of businesses that were already considering decisioning, which selects for a certain level of data maturity. A base with no warehouse and no event stream faces an earlier problem than any of these.
- Requirements are stated for the first decision. Running fifty decisions with arbitration between them adds governance and contact-pressure requirements this report does not cover.
- Nothing here is specific to Markin. Any decisioning approach, built or bought, faces the same five.
Falsifiability
What would change our mind
- 01
A set of deployments where model quality, not write-back, was the binding constraint on the first decision.
- 02
Evidence that teams without a finance-supplied margin per action nevertheless avoid drifting towards discounts and low-margin products.
- 03
First decisions that routinely require sub-hour freshness. That would move event latency ahead of write-back in the ordering.
Provenance
Sources, and what each one was used for
- Anonymised Markin deploymentsAnonymised readiness assessments across Markin deployments and evaluations
The ordering of blockers and the threshold definitions. No counts or percentages are published from it.
- Derived in this reportRequirement thresholds
Both tables. Each check is written so a reader can run it without us.
Questions this report answers
- What do we need before we can do per-customer decisioning?
- Why do personalisation projects stall after the model is built?
- Do we need real-time data for next best action?
- How do we move from campaigns to 1:1 decisions?
- What is the fastest first use case for decisioning?
Frequently asked
- What does a company need to move from campaigns to per-customer decisions?
- Five things: one reliable identity between the signal system and the executing system, events fresh enough for the decision window, a supported write-back path into the executing channel, a finance-supplied margin per candidate action, and a named owner for the randomised holdout.
- Do we need real-time data?
- Usually not for a first decision. Renewal, win-back, plan-fit and cross-sell decisions have windows measured in days and run comfortably on a daily batch. Streaming is genuinely required for in-session and cart-level decisions, and it is a much longer project.
- Do we need a CDP first?
- No. A CDP solves identity and activation across the whole estate, which is a multi-quarter programme. A first decision needs one join key between two systems and one supported write-back path. Scoping identity to the decision rather than to the roadmap is what gets teams experimenting months earlier.
- Why does a missing margin number matter so much?
- Because without it, actions are ranked on expected revenue, which systematically favours discounts and low-margin products. Nothing visibly breaks. The programme optimises the wrong quantity and reports growth while contribution margin stays flat.
- Are these numbers from Markin customers?
- There are no numbers. The findings are an ordering of blockers from anonymised readiness assessments, published as an ordering precisely because the sample is too small for percentages. The thresholds in the tables are checks you can run yourself, on your own stack, without us.
Act on this
- PlaybookAdd next best action to journeys you already run in BrazePer-customer arbitration written into the canvases your team already operates.
- PlaybookWin back lapsed customers with a silence window instead of a discount ladderReactivation timed on returning intent, not on days since last order.
- ResearchDesigning a holdout that can actually detect ARPU liftMost ARPU experiments are not inconclusive. They were underpowered on the day they were designed, and nobody computed it.
- ResearchRevenue that carries marginEvery growth decision on this list raises reported revenue. Four of them raise contribution margin. They are not the same four most teams prioritise.
- GuideHow can AI unify CRM, product and loyalty data?Identity resolution, one timeline per customer, explicit attribute precedence, and the decision that makes unification worth its cost.
- GuideReference architecture for a decision layerWhere a decision layer sits between your warehouse, your CDP and your channels, what it must own, and what it must never try to own.
- GuideHow decisions reach the customerThe activation patterns a decision layer needs: attribute write-back, triggered events, real-time decision API and product surfaces. With trade-offs.