COMPARE/Category comparison
Customer decisioning vs. a CDP
+17–35% ARPU against holdoutObserved range across Markin deployments, measured on treated cohorts.
A CDP resolves identity and unifies customer data into profiles and segments. Customer decisioning sits above it and chooses which commercial opportunity is worth acting on for each customer, at what expected value. The CDP answers what we know; decisioning answers what we should do about it, and proves the answer against control.
What is at stake
A decision layer is not a tool line item. It moves ARPU on the whole base, every month.
Installed base
2.0M
customers at $24 ARPU / month
Addressable revenue
$259.2M
per year, reachable base
Verified ARPU uplift
+17% to +35% ARPU
on treated cohorts, against holdout
What that is worth
$44.1M – $90.7M
incremental revenue per year
Measured on treated cohorts against a randomised holdout, read over a full measurement window rather than the first weeks. Anonymised range across Markin deployments in large B2C bases; your own holdout is the number that decides. The figures above apply that range to the reachable share of the base on this page's assumptions; they are arithmetic, not a forecast for your business.
Run it on your own numbersWhat each one actually does.
01
Customer Data Platform
A system that ingests events and records from source systems, resolves them to a persistent customer identity and exposes profiles, traits and segments to downstream tools.
02
Customer decisioning
A layer that turns customer context into ranked commercial decisions: which opportunity exists per customer, what it is worth, which treatment is expected to move it and whether to act at all.
Side by side
The differences that change outcomes.
| Dimension | Customer Data Platform | Customer decisioning |
|---|---|---|
| Question it answers | Who is this customer and what do we know about them? | Which opportunity is worth acting on, for whom, and how? |
| Primary input | Events, transactions, CRM records, identity signals. | The same context, plus outcomes, costs, constraints and past experiment results. |
| Primary output | Unified profiles, traits, audiences and segments. | Ranked, sized opportunities and a chosen action per customer, including hold. |
| Usual owner | Data engineering, martech operations. | Growth, data science, revenue leadership. |
| How it's measured | Identity match rate, profile completeness, sync latency. | Incremental revenue and ARPU against control. |
The unsolved part
What a CDP still leaves open
A well-run CDP makes context available. It does not decide what that context is worth, and it has no opinion on which of the fifteen things you could send a customer this week is the one that actually adds revenue.
- Segments describe populations; they do not size the revenue at stake or rank it against other options.
- Audience membership is a rule, not an estimate of incremental effect. A customer can qualify for six audiences at once.
- There is no mechanism to decide not to act when no intervention has positive expected value.
- Downstream performance is reported as sends, opens and conversions attributed to the campaign, not as incremental revenue against a holdout.
The actual difference
Markin is not another decisioning engine.
Markin is not a decisioning engine. A decisioning engine ranks actions a human already defined. Markin works like a data science and growth team: it forms its own hypotheses about why ARPU is stuck, marketing, product, pricing or technical, sizes them, executes them inside the systems you already run, and reads each one against a holdout.
| A decisioning engine | Markin | |
|---|---|---|
| Where the hypothesis comes from | A human authors it. The engine chooses between options someone already approved. | Markin authors it. It reads the base, finds where revenue is leaking or unclaimed, and writes the hypothesis itself. |
| What it is allowed to question | Message, offer, channel, timing, inside the campaign surface it was given. | Anything that moves ARPU: onboarding friction, pricing and packaging, a feature nobody adopts, a payment failure spike, a broken deeplink. |
| Who does the analysis | Your analysts, before and after. The engine optimises; it does not investigate. | Markin does the analysis. Sizing, segment definition, experiment design and readout are automated end to end. |
| Where it stops | At the recommendation. Someone still has to build and launch it. | It launches. Markin executes inside your existing platforms and product surfaces, then closes the loop on the result. |
| Throughput | As many hypotheses as your roadmap has room for, typically a handful per quarter. | Hundreds in parallel, every one carrying a control group. |
| What happens when it is wrong | The programme keeps running until someone reviews it. | It is retired automatically. Failing to beat control is a normal, cheap outcome. |
A decisioning engine picks the best action from a list you wrote. Markin writes the list, and runs it in your stack.
Hypothesis space
Everything a human growth scientist would look at.
Most growth problems are not message problems. Markin is not restricted to the campaign surface: if something is holding ARPU back, it is in scope, and it gets tested the same way.
Marketing
The classic surface, but chosen per customer rather than per segment, and always against a holdout.
- Which offer this specific customer is worth making
- Channel and timing chosen per person, not per campaign
- Contact pressure and fatigue arbitrated across every programme
- Win-back economics: who is worth a discount and who is not
Product
Where the customer actually experiences the value, and where most silent revenue loss happens.
- Onboarding steps that lose customers before first value
- A feature with high retention correlation that half the base never discovers
- Paywall and upgrade prompt placement
- In-product surfaces used as a treatment arm, not just email and push
Commercial
Pricing, packaging and the shape of the offer itself, tested rather than argued about.
- Plan and bundle structure by cohort
- Discount depth against margin, not against conversion alone
- Annual versus monthly framing per customer
- Dunning and involuntary churn recovery sequences
Technical health
Anomalies nobody asked it to look for. This is the category no decisioning engine covers.
- A checkout error rate that rose on one device and one region
- Payment failures concentrated in a single issuer or method
- A broken deeplink quietly killing a high-value journey
- Latency or delivery degradation eating conversion before any message does
Think of Markin as a data science and growth team that never sleeps: it investigates, forms hypotheses, ships them into your own stack and proves each one against a control group, at a volume no human team can reach.
The loop
Execution is a step in the loop, not a hand-off.
- 01
Observe
Markin reads the behavioural, transactional and product signal you already collect, continuously.
- 02
Hypothesise
It writes the hypothesis itself, marketing, product, commercial or technical, and states the expected direction.
- 03
Size
Each opportunity is ranked by expected value, so the queue is ordered by money rather than by opinion.
- 04
Design
Segment, treatment, guardrails and a randomised holdout are set before anything ships.
- 05
Execute
It launches inside the systems you already run, your engagement platform, your product surfaces, your APIs. Nothing waits on a build queue.
- 06
Read
Results are measured against the holdout over a full window, so novelty is not mistaken for effect.
- 07
Scale or retire
What beats control is scaled across the base. What does not is switched off automatically.
Where Markin fits
Not a replacement. A growth-science team on top.
Markin reads from the profiles your CDP already maintains, and adds the decision. It generates hypotheses about where revenue is being left on the table, sizes them, chooses a treatment per customer and runs it against control before anything scales. Activation still happens in the tools you already use.
It consumes the CDP, it does not duplicate it
Identity resolution, consent and profile maintenance stay where they are. Markin reads context in place, and does not become a second source of truth.
Opportunities, not audiences
Instead of a segment of 41,000 customers, you get a sized opportunity with a revenue figure, a confidence level and a recommended treatment.
Every decision carries a control group
Uplift is measured, not attributed. The layer learns which treatments work for which cohorts and reallocates automatically.
Operating model
The constraint is not ideas. It is how many you can test.
| Today, with customer data platform | With Markin on top | |
|---|---|---|
| Revenue hypotheses tested per quarter | 4 to 8, whatever the roadmap had room for | Hundreds, generated and run in parallel |
| What can be hypothesised about | Messages, offers and audiences, the campaign surface | Marketing, product, pricing and technical health alike |
| From decision to live in the channel | A ticket, a build queue, a release window | Markin launches it in your existing platforms itself |
| Time from idea to a result you trust | 6 to 10 weeks of analysis, build and readout | Days, because sizing and design are automated |
| Share of decisions with a control group | The flagship programmes, when there is time | Every decision, by default |
| Coverage of the base | Top segments and the customers a rule caught | One decision per customer, across the whole base |
| Cost of testing the 500th hypothesis | Another analyst, another quarter | Effectively zero |
| What the team spends its time on | Pulling data, building lists, reconciling reports | Judgement: constraints, economics, what to scale |
Markin does not replace your data science team. It removes the ceiling on how much of the base that team can act on, and how fast it finds out whether it worked.
Evidence standard
Most of this category reports its own lift.
None of the major engagement, CDP or personalisation vendors publishes an independently verified uplift figure for its decisioning product. Where numbers exist, they come from vendor-commissioned studies or single-customer case studies with no disclosed holdout methodology. The most rigorous public research in the category is not flattering to anyone, including us, which is exactly why we build against it.
BCG reports that when organisations adopt rigorous incrementality testing, they typically find 20% to 40% of their active next-best-action programmes deliver marginal to negative lift.
Independent researchBCG, How Measurement Is Evolving in Next-Best Action (2026)The same research flags novelty effects, new programmes show inflated early results, and recommends 8 to 12 weeks before drawing conclusions.
Independent researchBCG, How Measurement Is Evolving in Next-Best Action (2026)Global-holdout, programme-level ROI measurements often overstate impact through halo effects, pull-forward effects and experiment contamination.
Independent researchBCG, How Measurement Is Evolving in Next-Best Action (2026)
How Markin holds itself to it
- Every decision Markin makes carries a control group. Uplift is reported against that holdout, not against the customers who did not qualify.
- Results are read over a full measurement window rather than in the first weeks, so novelty is not mistaken for effect.
- Programmes that fail to beat control are retired automatically. Killing decisions that do not pay is part of the loop, not an annual review.
- The one figure we quote about ourselves is a range, not an average: +17% to +35% ARPU on treated cohorts against a randomised holdout, across Markin deployments in large B2C bases. We publish no industry benchmark, because we could not source one we would be willing to defend. Your holdout is the number that matters.
Time to value
90 days to a number that survived a holdout.
No replatform, no data migration, no rebuild of the channels you already run. If the first cohorts do not beat control, nothing scales and you have lost a quarter, not a roadmap.
Weeks 0–2
Read the context you already have
Markin connects to the data and the channels you run today, customer data platform included. No migration, no replatform, no new source of truth.
Weeks 3–6
First sized opportunities in test
Opportunities are ranked by expected value, treatments are chosen per customer, and the first cohorts go live with a randomised holdout attached.
Weeks 7–12
First verified incremental revenue
Results are read over a full measurement window. What beats control scales; what does not is retired. Nothing scales on a number that has not survived a holdout.
When you don’t need Markin.
- You do not have usable customer data yet: fix ingestion and identity first, a decision layer cannot compensate for missing context.
- Your commercial model has a single product, a single price and no repeat purchase, so there is nothing meaningful to prioritise between.
- You need a system of record for consent and preferences: that is the CDP's job, and it stays the CDP's job.
Questions buyers ask.
Does customer decisioning replace a CDP?
No. A decision layer needs unified customer context to work, which is exactly what a CDP produces. Markin reads from the CDP and returns decisions to your activation tools; nothing about the CDP's role changes.
Can a CDP do decisioning with its built-in rules?
Rules can encode decisions someone already made. They cannot generate new hypotheses, size the revenue at stake, or measure incremental effect. As soon as several rules qualify the same customer, a ranking model is doing the real work.
What if we use a warehouse instead of a CDP?
That works the same way. Markin reads from the warehouse directly and does not require a CDP; the requirement is reliable customer context, not a particular product category.
Where does activation happen?
In your existing channels: engagement platform, CRM, product surfaces or contact centre. The decision layer chooses; the channel executes.
How is Markin different from the decisioning or AI already inside customer data platform?
A decisioning engine ranks actions a human already defined, inside the campaign surface it was given. Markin forms the hypotheses itself, marketing, product, pricing or a technical anomaly holding growth back, sizes them, executes them inside customer data platform and your product surfaces, and reads each one against a randomised holdout. It behaves like a data science and growth team, not like an optimiser.
Does Markin only test messages and offers?
No. Anything a human growth scientist would investigate is in scope: onboarding friction, feature adoption, pricing and packaging, dunning, and technical health issues such as a checkout error rate or a broken deeplink quietly killing conversion. Marketing is one of four hypothesis domains, not the boundary.
What is the business case for adding Markin on top of customer data platform?
On a large B2C base, a small move in ARPU is a large number in absolute terms, because it applies to the whole installed base every month rather than to a campaign. Across Markin deployments the verified range on treated cohorts is +17% to +35% ARPU against a randomised holdout. The point is not more messages: it is finding the highest-value action per customer, launching it, and proving it against control before it scales.
How long before it pays for itself?
First sized opportunities are in test within six weeks and the first holdout-verified result lands inside 90 days. Payback depends on your base, margin and programme cost, the calculator on this page computes it from your own numbers, after applying the 20% to 40% haircut BCG finds when next-best-action programmes are incrementality-tested.