Snowflake
BigQuery
DatabricksBraze
- Markin
- Decides which customer deserves which action, when, and proves it against a holdout.
- Stays yours
- Owns the channel: sending, templates, deliverability and the canvases your team already built.
Moving to Markin
Keep your stack. Change what it decides.
No rip and replace, no migration project, no contract to unwind. This page sets out exactly what gets touched, what does not, and in what order.
Last updated: September 2026
Stays yours
SnowflakeBigQueryDatabricksSegment
orders48.2Mread-only
sessions312Mread-only
subscriptions6.1Mread-only
support_tickets2.4Mread-only
No copy, no migration
Most teams looking for an alternative do not need another platform.
Four reasons enterprise teams start shortlisting Braze, Iterable or Salesforce alternatives, and why a decision layer answers each one without a migration.
- 01
The platform sends well, but nobody decides what to send
Braze, Iterable, Adobe and Salesforce Marketing Cloud are execution engines. Segments, offers and timing still come from a human backlog, so throughput is capped by headcount, not by the tool.
Replacing one execution engine with another moves the same backlog to a new UI. Adding a decision layer above it removes the cap.
- 02
Campaign volume grew, incremental revenue did not
More sends against the same handful of segments produce attributed numbers that finance quietly discounts, because nothing is measured against a control group.
Markin attaches a randomised holdout to every action, so the number reported is incremental revenue rather than attribution.
- 03
The data team is the bottleneck on every experiment
Cohort building, test wiring and result reads consume the analytical hours that were supposed to go into finding revenue opportunities in the first place.
Markin automates the volume, generating, ranking, shipping and retiring hypotheses, and leaves definitions, guardrails and judgement with your team.
- 04
A migration was quoted and the business flinched
Marketing automation migrations mean re-templating, re-warming domains, re-certifying compliance and a quarter without shipping. The renewal deadline rarely justifies the risk.
Markin needs read access and scoped API credentials. Nothing is re-templated, no domain is re-warmed and no contract has to end.
What stays the same, and what actually changes.
Untouched
- Your execution platform
- Braze, Salesforce Marketing Cloud, Adobe, Iterable or whatever sends today keeps sending. Markin writes into it; it does not replace it and does not need its contract to end.
- Your warehouse and CDP
- Snowflake, BigQuery, Databricks, Segment or Tealium stay the system of record. Markin reads in place, on your compute, under the row-level security your data team already set.
- Your data team
- The people who own the models, the definitions and the governance keep owning them. Markin adds analytical throughput, not a second source of truth.
- Consent, suppression and brand rules
- Frequency caps, exclusion lists, consent state and legal copy approvals are enforced at decision time, before an action can reach a customer.
- Your reporting
- Decisions, holdout assignments and outcome reads land as tables in a schema you own, joinable to the dashboards finance already trusts.
- Your identity and access model
- SSO, roles and approval chains come from your side. Markin inherits them rather than asking you to maintain a parallel user list.
Genuinely different
- Who decides the next action
- Instead of a quarterly campaign calendar, each customer gets a decision derived from their own signal, ranked by expected revenue and refreshed as behaviour moves.
- How hypotheses get produced
- Hypotheses stop being limited by analyst hours. Markin generates, prioritises and retires them continuously, and shows the reasoning behind each one.
- How impact is proven
- Every action ships with a randomised holdout, so what reaches the board is incremental revenue rather than an attributed before-and-after.
- What the growth team spends time on
- Less manual segment building and campaign QA, more deciding the guardrails, the offers and which categories of action agents may launch alone.
The order of entry, in phases rather than dates.
Every account moves at the speed its own access reviews allow, so we do not quote durations. The sequence, however, never changes.
01
Read the signal, change nothing
Markin connects read-only to the warehouse, the CDP and product events, and reconstructs the revenue picture per customer: what they pay, what they use, where they drift. Nothing is launched and nothing is copied into a new system.
- Markin needs:
- Read access to existing tables and event streams, plus the definitions your team already uses for ARPU and churn.
- You decide:
- Which segments are in scope and which data is off-limits.
02
First hypotheses, behind a holdout
A small set of revenue opportunities is turned into candidate actions and shipped to a fraction of the base, each against a randomised control group. The point of this phase is a readable number, not volume.
- Markin needs:
- One motion to start with, usually onboarding activation, upgrade or dunning recovery, and a named reviewer.
- You decide:
- The guardrails: discount ceilings, frequency caps, excluded audiences, and what needs approval.
03
Execution inside your own platform
Approved actions are written into the tool that already owns the channel, with your templates, your sending reputation and your compliance copy. Customers receive something that looks exactly like it always did.
- Markin needs:
- API credentials scoped to the campaigns or audiences Markin is allowed to touch.
- You decide:
- Which action types agents may launch alone and which stay behind human approval.
04
Widen by segment, on evidence
Motions that clear the incrementality bar expand to more of the base and more of the lifecycle. Motions that do not are retired. Scope grows because a number justified it, not because a rollout plan said so.
- Markin needs:
- Agreement on the bar an experiment has to clear to scale.
- You decide:
- Where to widen next, and when to pause anything.
The internal team
Your data team keeps the judgement. Markin takes the volume.
The bottleneck in ARPU growth is rarely ideas, it is how many hypotheses a small team can build, ship and read in a quarter. That ceiling is what Markin removes.
Existing models keep running
Propensity, LTV or churn scores your team already built become inputs Markin can use. It does not demand that they be rebuilt, and it does not hide them behind a black box.
Analysts move up the stack
The repetitive work, building cohorts, wiring tests, reading results, is what gets automated. Defining what is worth testing and what the business will accept stays human.
Everything is inspectable
Each action traces back to the signal, hypothesis and expected value that produced it, and forward to the measured result. Your team can audit or overrule any of it.
Nothing is locked in
Decisions and holdout assignments live in your warehouse. If Markin were switched off, the history, the segments and the platform your team operates would all still be there.
Tool by tool: what Markin adds, what the tool keeps.
Salesforce Marketing Cloud
- Markin
- Supplies the ranked next best action and the expected value behind it.
- Stays yours
- Journeys, subscriber management and the enterprise governance already signed off.
Adobe Journey Optimizer
- Markin
- Generates and retires hypotheses continuously instead of per campaign cycle.
- Stays yours
- Orchestration, offer delivery and the Adobe data layer.
Snowflake
- Markin
- Reads history in place and writes decisions and outcomes back as tables you own.
- Stays yours
- System of record, cost controls and row-level security.
Segment
- Markin
- Uses the event stream as signal and can trigger on it in near real time.
- Stays yours
- Collection, identity resolution and downstream syncs.
Amplitude
- Markin
- Turns product behaviour into revenue opportunities rather than dashboards.
- Stays yours
- Product analytics and the funnels your PMs live in.
Teams that kept their stack and still moved ARPU.
Nomad
Runs on Snowflake · Segment · Braze
How Nomad turns customer signals into growth across dozens of markets
+22% ARPU
YuppTV
Runs on BigQuery · Web and mobile SDK · Braze
How YuppTV detects churn intent early enough to change the outcome
+18% retention
Exclusive Traveler Club
Runs on Snowflake · Salesforce Marketing Cloud · HubSpot
How Exclusive Traveler Club gives every member a next best action
3× cross-sell
Young
Runs on BigQuery · Amplitude · Braze
How Young made onboarding an always-on experimentation programme
+31% activation
Vitalis
Runs on BigQuery · Segment · Braze
How Vitalis found the revenue hiding inside its subscriber base
+19% subscription ARPU
The objections, answered.
- We are evaluating Braze alternatives. Where does Markin fit?
- Markin is not an alternative sending platform. If the gap is deliverability or channel coverage, another execution tool is the right answer. If the gap is that nobody can decide, at customer level, which action is worth taking next, Markin sits above Braze and supplies that decision, no replacement, no migration.
- Is this a marketing automation migration project?
- No. There is no re-templating, no domain re-warming and no re-certification of compliance copy. Markin reads the data already in the warehouse and writes approved actions into the platform your team already operates.
- Do we have to leave Braze, Salesforce or Adobe to use Markin?
- No. Markin is a decision layer that executes through the platform you already run. Your contract, your templates and your sending reputation stay exactly where they are, Markin decides what deserves to be sent and the platform sends it.
- Does our data have to move to Markin?
- No. Markin reads from the warehouse, CDP and product events already in place, on your compute, and writes decisions and holdout assignments back into a schema you own. Nothing is copied into a new system of record.
- Does this replace our data science or growth team?
- No. It removes the ceiling on how many hypotheses that team can produce, test and retire. The team keeps owning the definitions, the guardrails and the judgement calls; Markin does the analytical volume a pod that size could never reach manually.
- What happens to the models we already built?
- They become inputs. Existing propensity, LTV and churn scores can feed Markin's ranking, and Markin's own outputs land as tables your team can inspect, join and challenge.
- Who approves an action before it reaches a customer?
- You do, at the level you choose. Each deployment declares which action types agents may launch alone, which need a named reviewer, and which are off-limits, per channel and per audience.
- Can we start on one motion instead of the whole lifecycle?
- That is the default. Most accounts start with a single motion, onboarding activation, upgrade or dunning recovery, behind a randomised holdout, and widen only once the number clears the bar you set.
- What if we need to stop it?
- Any campaign, agent or the whole deployment can be paused instantly, with in-flight actions stopped at the execution boundary. Because execution lives in your platform and the history lives in your warehouse, stopping Markin leaves your stack working as before.
- How do we know the lift is real and not attribution?
- Every decision carries a randomised control group. What gets reported is the difference between the treated cohort and that holdout over a full measurement window, not a before-and-after comparison.
- Does Markin need our customer PII?
- Only the identifiers required to act. Data stays in EU regions, consent and suppression state are enforced at decision time, and the controls are documented on the security page.
- How long does the first phase take?
- It depends on how quickly read access and guardrails are agreed on your side, so we do not quote a fixed timeline. What is fixed is the order: read signal first, prove one motion against a holdout second, execute in your platform third, widen on evidence last.
Next step