The Markin ARPU report for B2C enterprisesRead now
MARKIN

COMPARE/Markin vs Adobe

MarkinvsAdobe logoAdobe

Markin vs Adobe Journey Optimizer: orchestration vs growth science

+17–35% ARPU against holdoutObserved range across Markin deployments, measured on treated cohorts.

Adobe Journey Optimizer orchestrates real-time journeys and offers on Experience Platform data. Markin sits before it: it investigates the base, generates and sizes revenue hypotheses across marketing, product and pricing, chooses one action per customer and measures the result against a randomised holdout.

The short answerLast updated: August 2026

Journey Optimizer is an orchestration and offer-decisioning engine of real depth, and it is very strong when the journey map is the plan. Markin questions the plan: it decides which opportunities deserve to be in the journey map at all, sizes them in money, and reports incremental ARPU rather than journey performance.

01

Adobe Journey Optimizer

Real-time journey orchestration and offer decisioning built on Adobe Experience Platform, with a decision engine that ranks eligible offers per profile.

Choose it when you are standardised on Experience Platform and need enterprise-grade orchestration across owned channels.

  • Built on AEP
  • Offer decisioning
  • Real-time journeys

02

Markin

An autonomous growth-science team that finds and sizes the revenue opportunities, chooses one action per customer, and reads every one against a control group.

Choose it when the limiting factor is the supply of proven revenue hypotheses, not orchestration capacity.

  • Writes the hypotheses
  • Sizes in money
  • Holdout on every action

Line by line

The same ten questions, answered for both.

Markin compared with Adobe Journey Optimizer across ten dimensions
DimensionMarkinAdobe Journey Optimizer
What it isAn autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds.An enterprise journey orchestration and offer decisioning application on Adobe Experience Platform.
What it decidesWhich commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing.Which eligible offer or journey step a profile receives, in real time, from a catalogue humans define.
Where hypotheses come fromGenerated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything.Authored by marketers and journey architects as journeys, offers and ranking rules.
Scope of actionMarketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue.Owned marketing channels and experiences orchestrated by Adobe.
How the work reaches the customerWritten back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface.Native real-time delivery across Adobe-managed channels and destinations.
How impact is provenA randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions.Journey and offer reporting in Customer Journey Analytics; control groups are configurable, not inherent.
Where the data sitsReads context where it already lives, warehouse, CDP, product and billing systems. No new system of record.Adobe Experience Platform profiles and the Experience Data Model.
Governance and controlEvery action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch.Enterprise consent, offer eligibility rules and approval workflows.
Time to a verified numberOne revenue theme, one channel, one holdout: a defensible incremental number inside 90 days.Substantial: AEP implementations are programmes, and value follows the schema work.
Best fitLarge B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent.Enterprises already committed to the Adobe experience stack.

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 numbers

The unsolved part

What orchestration does not decide

An orchestration engine executes the plan faithfully. It does not tell you the plan is wrong, that a segment is being over-contacted for a few euros of margin, or that a checkout defect is costing more than any campaign will recover.

  • The offer catalogue is a human artefact; nothing generates new candidate offers from the data.
  • Journey performance is measured, but incrementality is not the default unit.
  • Non-marketing causes of flat ARPU sit outside the tool entirely.
  • Prioritisation between journeys is governed by eligibility and caps, not expected value.

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.

Job to be done

The same work, at a different throughput.

Nothing below needs a tool that does not exist. It needs the work to happen continuously instead of once a quarter, and to be proven against a holdout instead of argued about.

Job to be done, compared between With adobe journey optimizer alone and With Markin
Job to be doneWith adobe journey optimizer aloneWith Markin
Notice that revenue per customer is drifting in a segmentSomeone spots it in a dashboard review, weeks after it started.Detected as a signal the day the drift clears noise, with the segment already sized.
Explain why it is happeningAn analyst is pulled off the roadmap for a two-week investigation.An investigation runs automatically and returns the drivers with their evidence.
Come up with hypotheses worth testingA workshop produces the handful of ideas the room happened to think of.Hypotheses are written continuously across marketing, product, pricing and technical health.
Decide which hypotheses deserve budgetPrioritised by seniority and gut feel, with no size attached.Each one is sized in revenue and ranked before anything is built.
Choose the next best action for one customerSegment rules and campaign calendars decide, refreshed when someone has time.Chosen per customer, per moment, against everything else competing for that customer.
Actually launch itA ticket to the lifecycle team, then a slot in next month's calendar.Executed inside the systems you already run, with no new channel to adopt.
Prove it caused the revenueReported against non-qualifiers or a global holdout, if at all.Every decision carries a randomised control group; uplift is read against it.
Kill what does not workProgrammes survive because nobody owns retiring them.Failing to beat control retires the programme automatically.
Do all of it again next weekCapacity-bound: four to eight tests a quarter.Hundreds of hypotheses in flight in parallel, continuously.

Honest take

What Adobe Journey Optimizer does better.

A comparison that only flatters one side is not worth reading. These are the cases where we would tell you to stay where you are.

  • Real-time orchestration at enterprise scale

    Journey Optimizer handles complex, stateful, multi-step journeys with consent and eligibility built in. Markin has no orchestration engine and no ambition to build one.

  • Offer decisioning is genuinely capable

    Ranking a catalogue of eligible offers per profile in real time, with constraints and capping, is a hard problem Adobe has solved well. Markin's decisions can flow into that catalogue rather than compete with it.

  • If you own the Adobe stack, gravity is real

    Shared schema, identity and consent across Analytics, AEP and Journey Optimizer is worth a lot. A second system should only be added if it changes what gets tested, not just how it is delivered.

Where Markin fits

Not a replacement. A growth-science team on top.

Markin decides which opportunity deserves an experience and what it is worth; Journey Optimizer delivers it with the orchestration, consent and channel controls already in place.

Feeds the catalogue

Sized decisions arrive as profile attributes or events.

Adds the missing loop

Hypothesis, holdout, read, scale or retire.

Keeps Adobe in place

No change to delivery, consent or schema ownership.

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.

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.

  1. Weeks 0–2

    Read the context you already have

    Markin connects to the data and the channels you run today, adobe journey optimizer included. No migration, no replatform, no new source of truth.

  2. 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.

  3. 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.

Which one you should pick.

Choose Markin if

  • Your journey map is full and ARPU is still flat.
  • You want the offer catalogue itself to be generated and sized from data, not curated in workshops.
  • You need marketing, pricing, product and technical-health hypotheses to compete in one queue.
  • Incrementality against a control group has to be the reporting standard.
  • You want a defensible number in a quarter, not after a platform programme.

Choose Journey Optimizer alone if

  • You need real-time, stateful orchestration across owned channels.
  • Your priority is consolidating delivery and consent on Experience Platform.
  • The offers are set by merchandising or regulation and the job is to rank them.
  • Your team is mid-AEP implementation and needs it to land first.
  • Journey execution, not hypothesis supply, is the current constraint.

When you don’t need Markin.

  • You need journey orchestration itself: Markin does not provide it.
  • Your Experience Platform data foundation is not yet live.
  • The base is small enough that a quarterly plan covers it.

Questions buyers ask.

Does Markin replace Adobe Journey Optimizer?

No. Journey Optimizer keeps orchestration, consent and delivery. Markin decides which opportunity is worth an experience, sizes it, and hands the decision over as an attribute or event.

Adobe already has offer decisioning. Why add Markin?

Offer decisioning ranks a catalogue humans wrote, inside the experiences Adobe delivers. Markin creates and sizes the candidates in the first place, arbitrates them against non-marketing actions, and measures each against a holdout.

What does Journey Optimizer do better?

Real-time, stateful orchestration across owned channels, enterprise consent handling, and native delivery on Experience Platform.

Do we need AEP for Markin?

No. Markin reads context where it already lives. If your unified profile is in AEP, that can be the source.

How is Markin different from the decisioning or AI already inside adobe journey optimizer?

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 adobe journey optimizer 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 adobe journey optimizer?

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.