# Markin — full content export > 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. Index: https://markin.ai/llms.txt · Canonical site: https://markin.ai Generated: 2026-08-23 --- --- title: Markin — numbers you can cite url: https://markin.ai/stats updated: 2026-08-20 license: CC BY 4.0 --- # Numbers you can cite > Every figure Markin is willing to see repeated, with the method that produced it, the source and the date it was last verified. Anything not on this page is not a Markin number. | Figure | Statement | Method | Source | Verified | | --- | --- | --- | --- | --- | | +17% to +35% ARPU | Markin deployments in large B2C bases have delivered +17% to +35% ARPU on treated cohorts, measured against a randomised holdout over a full measurement window. Markin publishes the range rather than an average, because the spread between deployments is the honest part of the result. | 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. | Markin deployment readouts, anonymised | 2026-08-20 | | 100% | Every decision Markin makes carries a randomised control group. Uplift is reported against that holdout, never against customers who did not qualify for the action, which is the most common way personalisation results are overstated. | Product invariant: an action without an assigned holdout cannot be launched by the decisioning loop. | Markin product specification | 2026-08-20 | | 4–8 → hundreds | A capacity-bound growth team typically tests four to eight revenue hypotheses per quarter. With Markin writing, sizing and running them, hundreds are in flight in parallel, across marketing, product, pricing and technical health. | Baseline from Markin discovery interviews with enterprise B2C growth and data-science teams; the upper bound is the design throughput of the decisioning loop, not a customer average. | Markin discovery interviews and product design targets | 2026-08-20 | | 20–40% | 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. Most personalisation budgets are therefore defending decisions that do not pay. | Independent research, not vendor-commissioned. | [BCG, How Measurement Is Evolving in Next-Best Action (2026)](https://www.bcg.com/publications/2026/measuring-incrementality-in-next-best-action-programs) | 2026-08-20 | | 8–12 weeks | The same BCG research flags novelty effects in new programmes and recommends waiting eight to twelve weeks before drawing conclusions. Reading a decisioning result in its first weeks systematically overstates it. | Independent research, not vendor-commissioned. | [BCG, How Measurement Is Evolving in Next-Best Action (2026)](https://www.bcg.com/publications/2026/measuring-incrementality-in-next-best-action-programs) | 2026-08-20 | | 0 | No major engagement, CDP or personalisation vendor 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. | Markin review of public vendor material across the engagement, CDP and personalisation categories, rechecked at the date shown. | Markin category review | 2026-08-20 | ## How to cite Markin, "Numbers you can cite", markin.ai/stats, accessed 2026-08-20. Markin is an autonomous growth-science team for large B2C businesses. It investigates why revenue per customer is stuck, writes its own hypotheses across marketing, product, pricing and technical health, chooses the next best action for each customer, launches it in the systems the business already runs, and proves every one against a randomised holdout. Founded by Romà Llambés and Román Via-Dufresne. ## FAQ **Can I cite Markin's ARPU uplift range?** Yes, with its method attached: +17% to +35% ARPU on treated cohorts against a randomised holdout, read over a full measurement window, as an anonymised range across Markin deployments in large B2C bases. It is not an industry benchmark and not a forecast for any particular business. **Does Markin publish an industry-wide uplift benchmark?** No. Markin could not source one it would be willing to defend, so it publishes none. For category-level evidence it cites BCG's independent research on incrementality in next-best-action programmes instead of a vendor figure. **How often are these numbers rechecked?** Every figure on this page carries the date it was last verified, and each one has a named internal owner and a review date in Markin's claim register. Figures that cannot be re-evidenced are removed rather than restated. Source: https://markin.ai/stats --- ## 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 | Your stack today | With Markin | | --- | --- | --- | | Notice that revenue per customer is drifting in a segment | Someone 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 happening | An 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 testing | A 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 budget | Prioritised 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 customer | Segment rules and campaign calendars decide, refreshed when someone has time. | Chosen per customer, per moment, against everything else competing for that customer. | | Actually launch it | A 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 revenue | Reported 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 work | Programmes survive because nobody owns retiring them. | Failing to beat control retires the programme automatically. | | Do all of it again next week | Capacity-bound: four to eight tests a quarter. | Hundreds of hypotheses in flight in parallel, continuously. | --- --- title: Growth Optimization url: https://markin.ai/solutions/growth-optimization description: Campaigns and journeys pick the wrong moment for each B2C customer. Markin's agents run 1:1 next best action decisioning to lift ARPU, continuously. --- # The next best action engine for every customer, every moment. > Markin runs continuous next best action decisioning across your live campaigns, journeys and product surfaces, picking eligibility, timing, channel, offer and message per person, and coordinating contact pressure across programs. Every decision measured against control, reported as incremental ARPU. ## In one line Make every growth motion you already run perform better ## Key numbers - **+18%** — incremental ARPU on optimized motions - **-32%** — contact pressure at higher revenue - **100%** — of decisions run against control ## How it works 1. **Read the programs you already run.** Markin ingests active campaigns, journeys and treatments, then measures who actually responded, who was going to convert anyway and who was over-contacted. 2. **Decide per person, per moment.** For each customer, agents pick the eligible action with the highest expected incremental ARPU (or decide to hold), using propensity, uplift, survival or sequence models depending on the decision. 3. **Experiment, scale, retire.** Every decision runs against control. Wins are scaled, losses are stopped, learnings from one motion feed the next. ## What it does - **Eligibility, not segments.** Models score every customer for every candidate action in real time, replacing fixed segments and rule trees with live 1:1 eligibility. - **Timing, channel, offer, pressure.** Every lever tuned per person: the moment, the surface, the incentive depth and the total contact pressure across all campaigns. - **Coordinated across campaigns.** One decision layer arbitrates all active journeys, so no customer is hit by conflicting or duplicated actions. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Eligibility fix | Users receiving offers they'd take anyway | 34.7K users | €1.2M ARR | 91 | | Pressure release | Fatigued high-LTV base | 22.1K users | €780K ARR | 86 | | Channel fit | Push-first users on email calendar | 18.4K users | €520K ARR | 82 | | Offer depth | Over-discounted winback cohort | 9.6K users | €340K ARR | 79 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Ana G. (Retail · Loyalty Gold) | Push | Sat 10:14 local | Held 48h | | Tom R. (Fintech · Payroll active) | In-app | Payday +2 | 3.8% APY | | Marc P. (Telco · Contract T-18d) | Call | Weekday 6pm | Loyalty plan -10% | | Priya S. (Travel · MAD→LHR) | Email | T-72h | Comfort seat | ## Use cases - **Move new users to first value** (Agent · Onboarding). Personal 7-day paths tuned per signup, replacing the static welcome drip. - **Rank offers per account** (Agent · In-app). Uplift ranks every candidate offer per person and picks the one that actually moves this customer. - **Save only what's worth saving** (Agent · Contact center). Agents trigger the exact intervention (or silence) that maximises retained ARPU, not raw save rate. - **Wake dormant customers** (Agent · Email). Behavioural, lifecycle and price signals unified into one reason-to-return per user. ## FAQ **How is growth optimization different from a campaign tool or CRM?** Markin is not a channel and not a rule engine, and it is not a decisioning engine that ranks actions you already wrote. It does the work of a growth data science team: it forms its own hypotheses, marketing, product, pricing or a technical anomaly holding growth back, sizes them, launches them inside your existing CRM, product surfaces or contact center, and reads each one against a control group. **What models are behind Markin?** A stack of proprietary deep-learning and causal models (propensity, uplift, survival, sequence, embeddings) orchestrated by reasoning agents. The right method is picked per decision, retrained continuously on your data. **Do we need to move our data?** No. Markin reads from your warehouse, product events, CRM and operational systems in place. Nothing is copied, nothing gets locked in. **How is impact measured?** Every decision runs against a control group. Impact is reported as incremental ARPU, revenue and margin, not opens, clicks or engagement proxies. **Can Markin decide to do nothing?** Yes. When no intervention has positive expected value, Markin holds. Silence is a valid, auditable decision. **What about data security and compliance?** SOC 2, ISO 27001, ISO 42001 and GDPR ready. Least-privilege access, per-tenant encryption, audit logs on every decision and finding. ## Related industries - [retail](https://markin.ai/industries/retail) - [fintech](https://markin.ai/industries/fintech) - [telco](https://markin.ai/industries/telco) - [streaming](https://markin.ai/industries/streaming) - [travel](https://markin.ai/industries/travel) Source: https://markin.ai/solutions/growth-optimization --- --- title: Revenue Discovery url: https://markin.ai/solutions/revenue-discovery description: Most revenue upside hides in cohorts your dashboards never surface. Markin's agents mine signals into ranked hypotheses to grow ARPU, continuously. --- # Revenue opportunity discovery, running 24/7 on your entire customer base. > Markin investigates every customer, transaction and product event for anomalies and unexplained behaviour, generates and sizes hypotheses with uplift modeling, and proves them with causal experimentation. The work of a growth data science team, always on, surfacing ARPU no dashboard has queried. ## In one line Find the ARPU your team has not defined yet ## Key numbers - **€8.4M** — ARR opportunities surfaced / quarter - **60%+** — outside existing campaigns - **24/7** — investigation loop ## How it works 1. **Detect the signal.** Agents surface anomalies and unexplained behaviour across the base: a duration that doesn't fit the customer, a drop in a specific micro-cohort, a pattern no journey covers. 2. **Generate and investigate hypotheses.** Multiple explanations are proposed and tested against transactional, behavioural, support and operational data. Agents can pull external context: competitor offers, local pricing, market conditions, product alternatives. 3. **Size, act, learn.** Each opportunity is sized on incremental margin. Candidate interventions (some outside the current CRM) are tested against control. Validated discoveries become reusable growth motions. ## What it does - **Search the whole base.** Agents scan every customer, transaction and product event for anomalies and unexplained behaviour, not only cohorts an analyst has already defined. - **Hypotheses, not dashboards.** For every signal, agents generate multiple explanations, investigate them with internal data and external context, and rank them by expected ARPU. - **Prove it against control.** Candidate interventions are sized on margin, tested against control groups, and only scaled once the causal effect is confirmed. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Anomaly | eSIM buyers with mismatched trip length | 12.3K users | €1.9M ARR | 94 | | Unexplained drop | Micro-cohort of premium annuals silent 21d | 6.4K users | €820K ARR | 88 | | Pricing gap | Family accounts on solo plans | 9.1K users | €1.1M ARR | 87 | | Substitution risk | High-LTV shoppers browsing competitor-heavy categories | 4.8K users | €540K ARR | 83 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Cluster · eSIM long-stay (12.3K users · +€1.9M ARR) | In-app + Email | T+1 after 7d activation | Trip-matched plan | | Cohort · Silent premium (6.4K users · +€820K ARR) | Push | Prime-time | Content unlock | | Segment · Family fit (9.1K users · +€1.1M ARR) | SMS | Weekend | Family bundle | | Cohort · Substitution risk (4.8K users · +€540K ARR) | Email | Now | Price match | ## Use cases - **Anomaly to hypothesis** (Agent · Intelligence). Every unexplained pattern becomes a set of ranked, sized hypotheses agents can test. - **Read the market** (Agent · Web). Agents pull competitor offers, local pricing and product alternatives to explain what internal data alone cannot. - **Size before you act** (Agent · Decisioning). Every candidate intervention priced against margin and incentive cost before any customer sees it. - **Prove the cause** (Agent · Experiments). Treatment and control on every discovery. Only causal wins become new growth motions. ## FAQ **How is revenue discovery different from a campaign tool or CRM?** Markin is not a channel and not a rule engine, and it is not a decisioning engine that ranks actions you already wrote. It does the work of a growth data science team: it forms its own hypotheses, marketing, product, pricing or a technical anomaly holding growth back, sizes them, launches them inside your existing CRM, product surfaces or contact center, and reads each one against a control group. **What models are behind Markin?** A stack of proprietary deep-learning and causal models (propensity, uplift, survival, sequence, embeddings) orchestrated by reasoning agents. The right method is picked per decision, retrained continuously on your data. **Do we need to move our data?** No. Markin reads from your warehouse, product events, CRM and operational systems in place. Nothing is copied, nothing gets locked in. **How is impact measured?** Every decision runs against a control group. Impact is reported as incremental ARPU, revenue and margin, not opens, clicks or engagement proxies. **Can Markin decide to do nothing?** Yes. When no intervention has positive expected value, Markin holds. Silence is a valid, auditable decision. **What about data security and compliance?** SOC 2, ISO 27001, ISO 42001 and GDPR ready. Least-privilege access, per-tenant encryption, audit logs on every decision and finding. ## Related industries - [travel](https://markin.ai/industries/travel) - [streaming](https://markin.ai/industries/streaming) - [fintech](https://markin.ai/industries/fintech) - [marketplaces](https://markin.ai/industries/marketplaces) - [gaming](https://markin.ai/industries/gaming) Source: https://markin.ai/solutions/revenue-discovery --- --- title: Product & Customer Diagnosis url: https://markin.ai/solutions/product-diagnosis description: Silent drop-offs and broken flows quietly bleed ARPU. Markin's agents diagnose product and customer friction and prioritize fixes by revenue, continuously. --- # Churn prevention starts with diagnosing what's actually breaking ARPU. > Not every retention problem is a marketing problem. Markin correlates behavioural shifts with product usage, payments, support and operations to find the friction, technical errors and service issues quietly driving churn, then routes each finding to the owning team, sized in ARPU at stake. ## In one line Not every revenue problem is a marketing problem ## Key numbers - **€6.1M** — ARR unlocked by non-marketing fixes / yr - **3.8x** — faster detection vs. monitoring - **100%** — findings routed with owner + evidence ## How it works 1. **Correlate behaviour with systems.** Agents unify product events, payment attempts, support tickets, operational logs and customer behaviour to spot where value delivery breaks down. 2. **Diagnose and classify.** Each finding is classified: product friction, technical error, service issue, operational bottleneck, or a genuine growth opportunity. Promotional actions are suppressed on customers with unresolved issues. 3. **Route to the right owner.** Findings ship to product, engineering, support, operations or commercial with sized impact and evidence. Post-fix impact is measured against baseline. ## What it does - **Behaviour to root cause.** When a cohort's behaviour shifts, agents investigate the product, technical, payment and support systems behind it, not only the campaign that touched them. - **Marketing vs product vs ops.** Markin distinguishes when the correct answer is a message, a human callback, a product change, a technical fix, an operational change or no action at all. - **Sized in revenue at stake.** Every diagnosed issue is quantified in ARPU and margin impact, then routed to the owning team with the evidence needed to act. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Failed payments | Card declines on renewal, specific BIN range | 7.4K users | €1.4M ARR | 96 | | Broken onboarding | New users stuck on step 4, Android 14 | 11.9K users | €680K ARR | 91 | | Service issue | Unresolved complaints, high-ARPU cohort | 3.2K users | €910K ARR | 93 | | Product friction | Feature confusion after redesign | 18.6K users | €1.2M ARR | 89 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Finding · Card decline BIN (7.4K users · +€1.4M ARR) | Product / Engineering | Now | No customer touch | | Finding · Onboarding step 4 (11.9K users · +€680K ARR) | Product | This sprint | Suppress promo | | Cohort · Open tickets (3.2K users · +€910K ARR) | Support | Now | Human callback | | Segment · Redesign confusion (18.6K users · +€1.2M ARR) | Product + In-app | This week | In-context help | ## Use cases - **Silent revenue leaks** (Agent · Payments). Detect declines, retry failures and dunning gaps invisible in the standard funnel. - **Where users stop reaching value** (Agent · Product). Identify the exact step, device and cohort where activation breaks. - **Suppress promos on open tickets** (Agent · Orchestration). Never upsell a customer with an unresolved complaint. Route to Care instead. - **Recurring issues by device or route** (Agent · Ops). Surface patterns affecting specific products, destinations or fulfilment paths. ## FAQ **How is product & customer diagnosis different from a campaign tool or CRM?** Markin is not a channel and not a rule engine, and it is not a decisioning engine that ranks actions you already wrote. It does the work of a growth data science team: it forms its own hypotheses, marketing, product, pricing or a technical anomaly holding growth back, sizes them, launches them inside your existing CRM, product surfaces or contact center, and reads each one against a control group. **What models are behind Markin?** A stack of proprietary deep-learning and causal models (propensity, uplift, survival, sequence, embeddings) orchestrated by reasoning agents. The right method is picked per decision, retrained continuously on your data. **Do we need to move our data?** No. Markin reads from your warehouse, product events, CRM and operational systems in place. Nothing is copied, nothing gets locked in. **How is impact measured?** Every decision runs against a control group. Impact is reported as incremental ARPU, revenue and margin, not opens, clicks or engagement proxies. **Can Markin decide to do nothing?** Yes. When no intervention has positive expected value, Markin holds. Silence is a valid, auditable decision. **What about data security and compliance?** SOC 2, ISO 27001, ISO 42001 and GDPR ready. Least-privilege access, per-tenant encryption, audit logs on every decision and finding. ## Related industries - [telco](https://markin.ai/industries/telco) - [fintech](https://markin.ai/industries/fintech) - [streaming](https://markin.ai/industries/streaming) - [gaming](https://markin.ai/industries/gaming) - [media](https://markin.ai/industries/media) Source: https://markin.ai/solutions/product-diagnosis --- --- title: Customer Decisioning url: https://markin.ai/solutions/customer-decisioning description: Customer decisioning for B2C enterprises: turn signals into ranked revenue opportunities and route them to the CRM, CDP and channels you already run. --- # The customer decisioning layer your stack is missing. > Markin turns signals into ranked revenue opportunities and then launches them inside the tools you already run. It hypothesises like a data science team would, across marketing, product, pricing and technical health, not only across the campaigns someone already planned. ## In one line The decision layer between your customer data and your channels ## Key numbers - **+16%** — incremental ARPU on prioritized opportunities - **-41%** — programs built that never had a positive case - **100%** — of decisions measured against control ## How it works 1. **Read the signals already in your stack.** Warehouse tables, product events, CRM history, billing and care records are read in place. No migration, no copy of the customer base. 2. **Generate and size candidate opportunities.** Agents form hypotheses about retention, expansion, loyalty and offer policy, then size each one in customers reachable and revenue at stake. 3. **Prioritize, test, route, measure.** The portfolio is ranked by expected incremental value against cost and contact budget. Winners are routed to the executing system; every one carries a control group. ## What it does - **A layer, not a replacement.** Data foundation (warehouse or CDP) → Markin decides and launches → your CRM, lifecycle, product and channel systems. Existing investment stays in place. - **Opportunity before treatment.** Most decisioning starts once the campaign is chosen. Markin decides which opportunity deserves a campaign at all, and what it is worth. - **Governed and auditable.** Eligibility, suitability, contact policy and control-group design are explicit inputs, and every decision carries its provenance. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Retention | High-value contracts near renewal | 28.9K accounts | €2.1M ARR | 92 | | Expansion | Single-product households | 46.3K accounts | €1.6M ARR | 88 | | Offer policy | Discount-insensitive buyers | 12.7K accounts | €610K margin | 84 | | Contact policy | Over-contacted base | 31.5K accounts | €430K margin | 80 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Laura M. (Retail · Loyalty tier 2) | Push | Sun 11:20 local | Non-monetary | | Iván T. (Telco · Contract T-30d) | Call | Weekday 7pm | Value-matched | | Sofia R. (Fintech · Single product) | In-app | Post-deposit | No discount | | Daniel K. (Streaming · Payment risk) | , | , | None | ## Use cases - **Rank the opportunity portfolio** (Layer · Decisioning). Every candidate opportunity scored on reachable base, expected incremental value and cost to serve. - **Make policy explicit** (Layer · Policy). Eligibility, suitability and contact policy expressed as inputs to the decision, not buried in campaign rules. - **Execute where you already execute** (Layer · Routing). Decisions land in the CRM, lifecycle tool or product surface that owns the touch. - **Report incremental value** (Layer · Measurement). Impact expressed as incremental revenue against control, not opens or clicks. ## FAQ **Is Markin a CDP, a CRM or a customer engagement platform?** None of them. A CDP unifies customer data, a CRM stores the relationship and an engagement platform delivers the message. Markin is the growth-science layer between them: it decides which revenue opportunity to pursue, for whom and what it is worth, and then launches the action inside those systems, against a holdout. **Do we have to replace Braze, Salesforce, Adobe or Pega to use it?** No. Markin complements an existing stack. It reads from the data foundation you already have and drives the systems that already own execution, launching each treatment there rather than handing over a recommendation. **What is the difference between decisioning and next-best action?** Next-best action usually selects a treatment for an individual once the program exists. Decisioning as Markin defines it starts one step earlier: selecting and prioritizing the revenue opportunity that justifies a program in the first place. **How do you avoid a black-box decision?** Every decision carries its provenance: the signals used, the hypothesis, the model class, the policy constraints applied and the control-group design. Decisions are auditable after the fact. **Do we need to move our data?** No. Markin reads from your warehouse, product events, CRM and operational systems in place. **What about data security and compliance?** SOC 2, ISO 27001, ISO 42001 and GDPR ready. Least-privilege access, per-tenant encryption, audit logs on every decision and finding. ## Related industries - [telco](https://markin.ai/industries/telco) - [retail](https://markin.ai/industries/retail) - [fintech](https://markin.ai/industries/fintech) - [streaming](https://markin.ai/industries/streaming) - [travel](https://markin.ai/industries/travel) Source: https://markin.ai/solutions/customer-decisioning --- --- title: Next-Best Action url: https://markin.ai/solutions/next-best-action description: Next-best action for enterprise B2C: pick the treatment per customer and rank the revenue opportunity behind it, every decision measured against control. --- # Next-best action, one layer higher. > Classic next-best action picks the offer, channel and moment for one customer. Markin does that, and decides which revenue opportunity across the base is worth pursuing at all, measured incrementally. ## In one line Next-best action for enterprise growth teams ## Key numbers - **+21%** — incremental value per contacted customer - **-38%** — duplicated touches across competing programs - **100%** — of actions run against a control group ## How it works 1. **Assemble the action inventory.** Every treatment your teams can actually deliver, offers, saves, upgrades, service interventions, with its cost, channel and policy constraints. 2. **Score value per customer, per action.** Propensity, uplift, survival and sequence models are combined into an expected incremental value for each eligible action. 3. **Arbitrate, deliver, learn.** One layer arbitrates across all active programs so customers are not double-contacted, then measures what the action actually added. ## What it does - **Action value, not engagement.** Each candidate action is scored on expected incremental value net of cost, not on predicted opens, clicks or response. - **Propensity, uplift, eligibility.** Propensity says who is likely. Uplift says who is persuadable. Eligibility and suitability say who may be contacted, and with what. - **Contact policy as a constraint.** Frequency, fatigue and channel caps are constraints on the optimization, not an afterthought applied by a separate team. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Treatment selection | Multiple eligible offers | 24.8K users | €890K ARR | 90 | | Persuadability | Sure things | 17.3K users | €520K margin | 87 | | Timing | Wrong-moment contacts | 38.1K users | €740K ARR | 83 | | Channel | Channel mismatch | 15.9K users | €360K ARR | 78 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Nuria B. (Retail · Lapsing) | Push | Sat 10:05 local | No discount | | Pau S. (Telco · Data-capped) | In-app | Pre-renewal | Plan change | | Elena V. (Fintech · Payroll active) | In-app | Payday +2 | 3.6% APY | | Jonas W. (Streaming · Heavy viewer) | , | , | None | ## Use cases - **One decision across all programs** (Agent · Arbitration). Competing campaigns resolved into a single action per customer per moment. - **Spend where you change the outcome** (Agent · Modelling). Uplift separates persuadable customers from those who convert regardless. - **Respect eligibility and suitability** (Agent · Policy). Regulatory and brand constraints applied as hard limits inside the optimization. - **Report incremental lift** (Agent · Measurement). Every action carries a control group; results are read as incremental revenue. ## FAQ **What is next-best action?** Next-best action is the practice of selecting, for each individual customer, the single most valuable action to take next across all available offers, messages and channels, rather than executing campaigns segment by segment. **What is the difference between propensity and uplift?** Propensity estimates how likely a customer is to take an action. Uplift estimates how much the action itself changes that outcome. Optimising on propensity alone spends margin on customers who would have converted anyway. **What do eligibility, suitability and contact policy mean here?** Eligibility is whether a customer may receive an action at all. Suitability is whether it is appropriate for them. Contact policy caps how often and through which channels they may be reached. All three are constraints on the decision, not filters applied afterwards. **How is this different from a rules engine?** You do not author segments or decision trees. Actions are scored per customer on expected incremental value, and the ranking updates as behaviour and results change. **How is impact measured?** Against control. Impact is reported as incremental revenue and margin, not opens, clicks or engagement proxies. **Can the system decide to do nothing?** Yes. When no eligible action has positive expected value, holding is the decision, and it is recorded as one. ## Related industries - [telco](https://markin.ai/industries/telco) - [retail](https://markin.ai/industries/retail) - [fintech](https://markin.ai/industries/fintech) - [streaming](https://markin.ai/industries/streaming) - [gaming](https://markin.ai/industries/gaming) Source: https://markin.ai/solutions/next-best-action --- --- title: Retention Decisioning url: https://markin.ai/solutions/retention-decisioning description: Retention decisioning for enterprise B2C: go beyond the churn score by matching customer value, churn reason and save cost to retained revenue. --- # Retention decisioning starts where the churn score stops. > A score names who is at risk. Markin matches customer value, churn reason and intervention cost, then tests which response actually retains revenue, net of what the save costs. ## In one line Choose the right intervention before churn, not after the score ## Key numbers - **+13%** — incremental retained revenue net of save cost - **-29%** — save budget spent on non-retainable accounts - **100%** — of interventions run against control ## How it works 1. **Separate risk from reason.** Survival and sequence models estimate when, while diagnosis attributes why: price, friction, service, competition or natural end of need. 2. **Match against the intervention inventory.** Each available intervention carries a cost, a channel, a policy constraint and evidence of where it has worked. The matrix is explicit. 3. **Test, then scale what retains revenue.** Interventions are trialled against control by value band and reason, and only the economically positive ones scale. ## What it does - **Prediction is an input.** Risk scores enter the decision alongside customer value, churn reason and what it would cost to intervene. - **Save what is worth saving.** Retained revenue net of intervention cost, not raw save rate. Some at-risk customers are not economically retainable. - **Reason-matched interventions.** Price, product friction, service failure and competitive loss demand different responses. A single save offer answers none of them well. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Reason mismatch | Service-failure churn | 11.4K accounts | €1.1M ARR | 91 | | Value banding | Low-value at-risk base | 42.6K accounts | €680K margin | 85 | | Timing | Late-cycle contacts | 19.2K accounts | €950K ARR | 82 | | Silent churn | Disengaged but active | 26.7K accounts | €1.3M ARR | 79 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Marta L. (Telco · High value, price-driven) | Care | T-30d | Value-matched | | Hugo D. (Streaming · Friction-driven) | Support | On detection | None | | Rita N. (Fintech · Low value) | , | , | None | | Andreu C. (Retail · Lapsing loyalty) | Email | Post-decay | No discount | ## Use cases - **Attribute the churn reason** (Agent · Diagnosis). Price, friction, service and competition separated before an intervention is chosen. - **Size the save** (Agent · Economics). Retained revenue net of intervention cost, per value band. - **Map the interventions** (Agent · Inventory). Every available save action with its cost, channel and evidence base. - **Prove the intervention** (Agent · Experiment). Holdouts by value band and reason so the save is attributable. ## FAQ **Is this a churn prediction model?** Prediction is one input. Retention decisioning is the layer that turns a risk score into a specific, costed intervention choice, or into a deliberate decision not to intervene. **Why is save rate the wrong metric?** Save rate can be raised by discounting customers who were never going to leave. The economically meaningful measure is revenue retained net of intervention cost, measured against a control group. **How do you decide the churn reason?** Behavioural, billing, service and product signals are attributed to reason classes. Interventions are then matched to the reason rather than to the score alone. **Do you replace our retention campaigns?** No. Existing campaigns and care flows remain the execution surface. Markin decides which customers enter them, with which intervention, and measures the result. **What if no intervention is worth making?** That is a valid outcome. When expected retained revenue does not cover the cost of intervening, holding is the recorded decision. **How is impact measured?** Against control, as incremental retained revenue over the measurement window rather than immediate cancellation avoidance. ## Related industries - [telco](https://markin.ai/industries/telco) - [streaming](https://markin.ai/industries/streaming) - [fintech](https://markin.ai/industries/fintech) - [media](https://markin.ai/industries/media) - [gaming](https://markin.ai/industries/gaming) Source: https://markin.ai/solutions/retention-decisioning --- --- title: ARPU Expansion url: https://markin.ai/solutions/arpu-expansion description: ARPU expansion for large B2C bases: discover where headroom sits, rank it against cost and cannibalization, and prove the lift against control. --- # ARPU expansion is a discovery problem, not an offer problem. > Markin finds where expansion headroom actually sits across the base, ranks it against cost and cannibalization risk, and turns it into experiments with control groups. ARPU is read together with retention, never on its own. ## In one line Find the next ARPU opportunity across your customer base ## Key numbers - **+19%** — incremental ARPU on tested expansion branches - **-24%** — incentive depth removed with no loss in conversion - **100%** — of expansion tests run against control ## How it works 1. **Map the ARPU opportunity tree.** The base is decomposed into the drivers that can actually move: product holding, usage tier, price realisation, attach rate and retention. 2. **Prioritize by expected incremental value.** Each branch is sized on reachable customers, expected uplift, margin cost and the risk of cannibalizing existing revenue. 3. **Run experiments, keep what compounds.** Top branches become controlled experiments. Results feed back into the tree, so prioritization improves each cycle. ## What it does - **Potential, not averages.** Expansion headroom estimated per customer and per cohort, so the number points at an action rather than at a dashboard. - **Priced without indiscriminate discounting.** Incentive depth is a variable to test. Uplift shows where a discount buys nothing and margin can be recovered. - **Cannibalization aware.** Expansion that shifts revenue between products is separated from expansion that adds it, before the program scales. ## Example opportunities surfaced | Opportunity | Segment | Size | Revenue | Score | | --- | --- | --- | --- | --- | | Attach | Single-product households | 52.4K accounts | €1.9M ARR | 90 | | Tier fit | Capacity-constrained users | 21.8K accounts | €1.4M ARR | 86 | | Price realisation | Legacy pricing cohorts | 14.3K accounts | €860K ARR | 81 | | Cannibalization | Bundle switchers | 9.1K accounts | €400K at risk | 77 | ## Example 1:1 executions | Customer | Channel | Timing | Action | | --- | --- | --- | --- | | Clara F. (Fintech · Single product) | In-app | Post-activity | No discount | | Óscar J. (Telco · Over-cap usage) | Email | Post-cycle | Plan change | | Aina P. (Retail · High frequency) | Push | Post-purchase | Non-monetary | | Lukas H. (Streaming · Bundle candidate) | , | , | None | ## Use cases - **Build the opportunity tree** (Agent · Discovery). Decompose ARPU into the drivers that can be moved, and size each one. - **Rank offers per account** (Agent · Cross-sell). Uplift ranks candidate offers and picks the one that adds revenue for this customer. - **Match the plan to the usage** (Agent · Upgrade). Tier moves grounded in the customer's own consumption rather than in a campaign calendar. - **Separate net new from shifted** (Agent · Measurement). Cannibalization measured explicitly before a winning test is scaled. ## FAQ **What is ARPU expansion?** ARPU expansion is the deliberate discovery and prioritization of opportunities that raise average revenue per user, attach, tier fit, price realisation and retention, rather than the broad pushing of additional offers to the whole base. **How is this different from cross-sell campaigns?** Cross-sell is one execution path. The work here is deciding which expansion opportunity is worth a campaign at all, what it is worth net of margin cost, and whether it adds revenue or merely shifts it. **Can ARPU be a misleading metric?** Yes. An average can rise because low-value customers churned, which is not growth. ARPU is read alongside retention, base size and customer-base health so the number is interpreted correctly. **How do you avoid discounting away the gain?** Incentive depth is treated as a variable to test. Where uplift shows a discount buys no additional conversion, the discount is removed and the margin recovered. **How is cannibalization handled?** Expansion tests measure net new revenue against control, so revenue displaced from an existing product is separated from revenue genuinely added. **How does this relate to Revenue Discovery?** Revenue Discovery finds and sizes opportunities across the whole base. ARPU Expansion is the applied program for the subset of those opportunities whose objective is raising revenue per customer. ## Related industries - [fintech](https://markin.ai/industries/fintech) - [telco](https://markin.ai/industries/telco) - [retail](https://markin.ai/industries/retail) - [streaming](https://markin.ai/industries/streaming) - [marketplaces](https://markin.ai/industries/marketplaces) Source: https://markin.ai/solutions/arpu-expansion --- --- title: Markin for Retail url: https://markin.ai/industries/retail description: Turn every session into ARPU --- # Turn every session into ARPU. > Markin unifies commerce, loyalty and CRM data, then executes the next best offer for every shopper, across app, web, email and store. Unify commerce, loyalty and CRM data. Agents pick the next best offer per shopper, from re-engagement to premium upgrade, and act across every channel. ## Key numbers - **+22%** — ARPU lift in 90 days - **3.4x** — conversion on re-engagement - **-28%** — voluntary churn on loyalty base ## What is holding ARPU back - Commerce, loyalty and CRM live in separate silos, so no channel sees the whole shopper. - Broadcast campaigns burn margin on shoppers who would’ve bought anyway. - Rules and segments age fast, and nobody owns the tree. - Loyalty engagement stalls once the welcome offer is spent. ## Use cases - **First-purchase, faster** (Agent · Onboarding). Agents personalize the first 7 days across email, push and app, moving new signups to their first order without discounting the base. - **Grow basket, not friction** (Agent · In-app). Real-time recommendations tuned per customer: complementary SKUs, bundles, and premium tier, placed at the exact moment intent peaks. - **Reward the right behavior** (Agent · Loyalty). Move members up tiers with 1:1 challenges and offers. Agents decide who gets what, when, and where, no rule trees to maintain. - **Bring dormant shoppers back** (Agent · Email + Push). Detect drop-off before it becomes churn and craft a personal reason to return, with the offer, channel and copy tuned per user. ## Solutions for this industry - [growth-optimization](https://markin.ai/solutions/growth-optimization) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) ## FAQ **How fast can we see impact in retail?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/retail --- --- title: Markin for Fintech url: https://markin.ai/industries/fintech description: Grow deposits. Deepen every account --- # Grow deposits. Deepen every account. > Activate new accounts, cross-sell cards and lending, and retain the customers that matter most, with 1:1 decisions on real-time product signals. Activate accounts, cross-sell cards and lending, retain the ones that matter. Agents decide on real-time signals from every product surface. ## Key numbers - **+31%** — activation on new accounts - **+2.1** — products per active customer - **-24%** — attrition on primary bank users ## What is holding ARPU back - New accounts stall before they become the primary bank. - Cross-sell into card, savings or lending relies on generic drips. - Attrition on primary accounts is spotted after the balance already left. - Compliance friction slows every experiment in personalization. ## Use cases - **From signup to primary bank** (Agent · Onboarding). Agents guide each new user through the actions that matter, direct deposit, card use, first transfer, with nudges tuned per profile. - **Right product, right moment** (Agent · In-app). Card, savings, lending, invest, Markin picks the offer with the highest expected ARPU per customer, then executes across app and email. - **Save the accounts that matter** (Agent · Contact center). Predict attrition weeks ahead and trigger the intervention that actually works, rate match, waived fee, human callback, or nothing at all. - **Wake dormant balances** (Agent · Email + Push). Personal reasons to move money in, timed to salary, tax dates and life events, without spraying incentives across the whole base. ## Solutions for this industry - [growth-optimization](https://markin.ai/solutions/growth-optimization) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) ## FAQ **How fast can we see impact in fintech?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/fintech --- --- title: Markin for Telco url: https://markin.ai/industries/telco description: Cut churn. Lift ARPU per line --- # Cut churn. Lift ARPU per line. > Markin predicts churn 30 days out and personalizes plans, add-ons and family bundles, across app, web, contact center and retail. Predict churn 30 days out and personalize plan upgrades, add-ons and family bundles across app, web, call center and retail. ## Key numbers - **-33%** — voluntary churn on postpaid - **+€3.80** — ARPU per line / month - **42%** — of upsells accepted 1:1 ## What is holding ARPU back - Voluntary churn spikes at contract end, with no lead time to react. - The contact center runs as a cost line, not a retention channel. - Plan ladders are static, upsell take-rate stays flat. - Family and add-line opportunities die in generic promo blasts. ## Use cases - **See churn 30 days out** (Agent · Contact center). Agents score every line in real time and trigger the right save, plan match, device offer, network priority, or a human call back. - **Move lines up the plan ladder** (Agent · In-app). Personal upgrade paths for data, roaming and 5G, with the offer tuned to actual usage, not marketing segments. - **Grow the household** (Agent · Email + SMS). Detect the moment a plan is under-utilized by a family and offer the exact add-line, tablet or watch bundle that fits. - **Save the call, save the customer** (Agent · Contact center). Route high-risk callers to the right agent with the right offer already loaded, turning contact-center spikes into retention wins. ## Solutions for this industry - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) - [growth-optimization](https://markin.ai/solutions/growth-optimization) ## FAQ **How fast can we see impact in telco?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/telco --- --- title: Markin for Media url: https://markin.ai/industries/media description: From reader to subscriber, personally --- # From reader to subscriber, personally. > Personalize paywall, offer and re-engagement in real time. Markin moves every reader from free, to premium, to annual, with the right message at the right moment. Personalize paywall, offers and re-engagement in real time. Agents move each reader from free, to premium, to annual. ## Key numbers - **+46%** — paywall conversion - **+18%** — annual plan mix - **-27%** — voluntary cancels ## What is holding ARPU back - One paywall for every reader leaves conversion on the table. - Cancel spikes right after the intro price ends. - Newsletter fatigue kills daily habit before it forms. - Annual plan mix stays low, ARPU stays flat. ## Use cases - **The right paywall per reader** (Agent · Web). Timing, price, and message tuned per user, from meter to hard stop, protecting engagement while lifting conversion. - **Move premium to annual** (Agent · In-app). Detect readers ready to commit and offer the annual plan with the exact incentive that clears their hurdle. - **Save the cancels that matter** (Agent · Email). Predict cancels weeks ahead and trigger content, discount or human touch, only for the readers worth saving. - **Grow habit, not fatigue** (Agent · Email). Agents decide who gets which newsletter, when, building daily habit without burning inbox. ## Solutions for this industry - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) - [growth-optimization](https://markin.ai/solutions/growth-optimization) ## FAQ **How fast can we see impact in media?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/media --- --- title: Markin for Travel url: https://markin.ai/industries/travel description: Fill seats. Raise basket. Return the trip --- # Fill seats. Raise basket. Return the trip. > Markin triggers the right ancillary, upgrade or return-trip nudge at the exact moment intent peaks, across booking, in-trip and post-trip. Trigger the right ancillary, upgrade or return-trip nudge at the exact moment intent peaks, across booking, in-trip and post-trip. ## Key numbers - **+€14** — ancillary revenue per booking - **+21%** — return-trip rate at 90 days - **+9pt** — premium cabin mix ## What is holding ARPU back - Ancillary revenue capped by static merchandising rules. - Return-trip rate depends on generic newsletters. - Loyalty tiers reward frequency, not real economics. - Disruptions burn loyalty because recovery is one-size-fits-all. ## Use cases - **The right add-on, timed right** (Agent · In-app). Bags, seat, lounge, insurance, each offer tuned per traveler and per moment in the journey, from booking to gate. - **Sell premium at the right price** (Agent · Email + Push). Agents price and offer cabin upgrades per user, per route, per moment, turning empty premium seats into ARPU. - **Return the trip** (Agent · Loyalty). Personal reasons to book again, tied to destinations, seasons and status milestones the traveler actually cares about. - **Turn disruptions into loyalty** (Agent · Push + Email). When flights slip, the right proactive gesture, voucher, upgrade, human message, protects the next booking. ## Solutions for this industry - [growth-optimization](https://markin.ai/solutions/growth-optimization) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) ## FAQ **How fast can we see impact in travel?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/travel --- --- title: Markin for Gaming url: https://markin.ai/industries/gaming description: Lift LTV per player, without burning the base --- # Lift LTV per player, without burning the base. > Onboarding, first purchase and live-ops in one loop. Markin personalizes offers and re-engagement 1:1, protecting engagement while growing revenue. Onboarding, first purchase and live-ops in one loop. Agents personalize offers and re-engagement without cannibalizing engagement. ## Key numbers - **+36%** — D7 retention on new installs - **+22%** — payer conversion - **+18%** — LTV on top decile ## What is holding ARPU back - D7 retention is fragile, and the onboarding funnel is the same for everyone. - Monetization leans on whales, the payer base stops growing. - Live-op impact is measured too late to steer. - Lapsed players get generic push blasts, not personal reasons to come back. ## Use cases - **From install to habit** (Agent · Onboarding). Personal missions and rewards for the first sessions, moving new players to the moment they stop being fragile. - **First purchase, no whales-only** (Agent · In-app). Agents pick the store offer, timing and price per player, expanding the payer base without discounting whales. - **Events that actually convert** (Agent · Live-ops). Personal event slates, offers and bundles, auto-tuned per player segment as the live-op is running. - **Win the lapsed player back** (Agent · Push). Detect drop-off and craft the exact reason to come back, content, offer, or friend nudge, per player. ## Solutions for this industry - [growth-optimization](https://markin.ai/solutions/growth-optimization) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) ## FAQ **How fast can we see impact in gaming?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/gaming --- --- title: Markin for Streaming url: https://markin.ai/industries/streaming description: Convert trials. Prevent cancels. Keep watching --- # Convert trials. Prevent cancels. Keep watching. > Markin identifies at-risk viewers in real time and triggers content, plan and win-back moments that keep them watching, and paying. Agents identify at-risk viewers and trigger content nudges, plan changes and win-back moments that keep them watching, and paying. ## Key numbers - **+41%** — trial-to-paid conversion - **-29%** — voluntary cancels - **+12%** — annual plan mix ## What is holding ARPU back - Trials cancel silently at day 7, with no personal reason to stay. - Cancel spikes track content gaps, but nobody acts in time. - Plan mix skews toward the cheapest tier by default. - Win-back sprays discounts and burns future ARPU. ## Use cases - **Convert trials, per viewer** (Agent · Onboarding). Personal onboarding, content nudges and offer timing, moving each trial to paid without leaning on price alone. - **Save the viewer, not just the sub** (Agent · Email + Push). Predict cancels weeks out and trigger content, plan or price, only for viewers whose LTV justifies it. - **Right plan per household** (Agent · In-app). Move viewers to annual, family, or ad-supported based on real behavior, not marketing segments. - **Personal reasons to return** (Agent · Email). New season, new content, new price, Markin picks the message that matches why they left. ## Solutions for this industry - [growth-optimization](https://markin.ai/solutions/growth-optimization) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) ## FAQ **How fast can we see impact in streaming?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/streaming --- --- title: Markin for Marketplaces url: https://markin.ai/industries/marketplaces description: More GMV per active user, on both sides --- # More GMV per active user, on both sides. > Markin matches, cross-sells and reactivates on both sides of the marketplace, every session, every inbox, every push. Match, cross-sell and reactivate on both sides of the marketplace, every session, every inbox, every push. ## Key numbers - **+27%** — GMV per active user - **+19%** — repeat orders at 90 days - **-24%** — supply-side churn ## What is holding ARPU back - Supply and demand teams run on disconnected data. - Repeat-purchase stalls after the first order. - Users stay locked in one category, cross-category growth is manual. - Supply-side churn is only visible in the monthly review. ## Use cases - **The right match, faster** (Agent · In-app). Agents rank and message the offers most likely to convert per user, turning browsers into repeat buyers. - **Keep sellers active** (Agent · Email). Detect at-risk sellers and trigger the exact support, leads, price help, human touch, that keeps them earning. - **Grow categories per user** (Agent · In-app). Move a single-category user into new verticals, with proof-driven, 1:1 recommendations. - **Wake dormant users** (Agent · Push). Personal reasons to come back per user, on the right channel, no more one-size-fits-all promos. ## Solutions for this industry - [growth-optimization](https://markin.ai/solutions/growth-optimization) - [product-diagnosis](https://markin.ai/solutions/product-diagnosis) - [revenue-discovery](https://markin.ai/solutions/revenue-discovery) ## FAQ **How fast can we see impact in marketplaces?** Most teams run a first pilot in 30 days on a single motion (e.g. churn or cross-sell) and see measurable ARPU lift inside 90 days. **Do we need to move our data?** No. Markin reads from your warehouse, CDP or product events directly, nothing gets copied, nothing gets locked in. **How does Markin fit our existing CRM, app and contact center?** Markin executes into the systems you already have, Braze, Iterable, Salesforce, Twilio, your own app SDKs and contact-center tools, via native integrations. **How is this different from a rules engine or campaign tool?** You don’t author segments or rule trees. Agents decide per person, per moment, and are evaluated against ARPU, not opens or clicks. **What about data security and compliance?** Markin is SOC 2, ISO 27001 and GDPR ready, with least-privilege access, per-tenant encryption and audit logs on every agent decision. Source: https://markin.ai/industries/marketplaces --- --- title: Customer decisioning: what it is, and what it still does not do url: https://markin.ai/guides/customer-decisioning author: Romà Llambés, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: customer decisioning, decisioning platform, decision layer, customer decisioning software --- # Customer decisioning: what it is, and what it still does not do > Customer decisioning is the practice of choosing, for each individual customer, which action is worth taking next, and what it is worth. It sits between customer data and the channels that deliver, ranking candidate actions by expected value rather than by campaign calendar. It answers what to do, not how to send it. **Customer decisioning** — Choosing, per individual customer, which action carries the highest expected value, then arbitrating that choice against every other action competing for the same customer, before any channel executes it. ## The problem decisioning was invented for A large B2C business does not suffer from a shortage of things it could do to a customer. It suffers from the opposite. Twenty programmes are live, a customer qualifies for six of them in the same week, and the tie is broken by a frequency cap rather than by which one adds the most revenue. Decisioning exists because eligibility is not the same as priority. - Campaign reporting is per programme, so nothing tells you the effect of everything a customer received. - Eligibility rules answer 'may we contact this person', never 'should we'. - Doing nothing is rarely an available output, even when it is the profitable one. - Priority is resolved by whoever built their programme first. ## The four things a decisioning layer has to do Vendors differ enormously in how many of these they actually own. The word 'decisioning' is used for products that do only the third one. 1. **1. Assemble context.** Read behavioural, transactional, product and service history for the individual, from wherever it already lives. A decision layer consumes context; it does not try to become the system of record for it. 2. **2. Enumerate candidate actions.** Build the set of things that could legitimately happen to this customer right now, including hold. This is where most products stop being interesting: the candidate set is whatever a marketer created in the campaign tool. 3. **3. Rank by expected value.** Score each candidate by expected incremental revenue, net of margin, contact cost and fatigue. Ranking by likelihood of engagement is a different, weaker objective, and it systematically over-contacts people who were going to convert anyway. 4. **4. Arbitrate and commit.** One decision per customer per window, written back to the channel that will execute it, with a control group attached so the decision can be judged later. _Where decisioning sits relative to the systems next to it_ | Layer | Question it answers | Primary output | | --- | --- | --- | | CDP or warehouse | Who is this customer, in one consistent view? | Unified profiles and audiences | | Decision layer | Which action is worth taking for this customer, and what is it worth? | One ranked, sized decision per customer, including hold | | Engagement platform | How is this delivered, in which channel, with what creative? | Delivered messages and journey state | | Experimentation platform | Did version A beat version B on this surface? | A verdict on a specific variant test | ## What the evidence actually supports Decisioning is a well-established practice, but the uplift figures attached to it in vendor material are usually attributed rather than measured against a control group. The gap between the two is the single most useful number in this category. - When next-best-action programmes are tested for incrementality, a meaningful share of the reported lift does not survive: BCG finds that 20% to 40% of measured uplift disappears once a randomised control is applied. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) - Engagement-platform AI positions its decisioning around choosing content, channel and timing for a customer inside the journeys the platform itself delivers, which is a narrower scope than choosing which opportunity is worth pursuing. [Vendor page: Braze, BrazeAI product page](https://www.braze.com/product/brazeai) ## Diagnose your own stack in an afternoon None of this needs a vendor. Pick one week and one segment of your base, and answer these from your own systems. - For a random sample of 50 customers, list everything they received last week. Count how many were arbitrated against each other rather than sent independently. - Find the most recent decision where the correct answer was 'contact nobody'. If there is not one, your system cannot produce that output. - Take your best-performing programme and ask who holds the control group. If the answer is nobody, the reported lift is attribution, not incrementality. - Count hypotheses tested last quarter. Divide by the number of distinct revenue problems you know you have. - Ask what happens to a programme that underperforms. Automatic retirement, or a quarterly review nobody has time for? ## When you do not need a decision layer - Fewer than roughly 100,000 active customers: the arbitration problem is small enough that a good analyst and a prioritised roadmap will beat any system. - A single product with a single price and one meaningful lifecycle moment. There is not enough of a candidate set to arbitrate. - No reliable outcome data. Decisioning ranks by expected value, and expected value needs history to be worth anything. - Acquisition-led growth where the constraint is new customers, not revenue per existing customer. ## FAQ **What is the difference between customer decisioning and a CDP?** A CDP unifies customer data and distributes it. Decisioning consumes that data and chooses what to do with it. They are complementary and sit at different points: a CDP answers 'who is this customer', decisioning answers 'which action is worth taking for them'. Owning a CDP does not give you a decision layer, and a decision layer does not require you to replace your CDP. **Is decisioning the same as next best action?** Next best action is the output; decisioning is the process that produces it. A next-best-action programme that ranks by propensity to click is decisioning with a weak objective function. Ranking by expected incremental revenue, net of margin and contact cost, is what makes the output worth acting on. **Can my engagement platform's AI do this?** Partly. Engagement-platform AI is genuinely good at choosing channel, timing and creative for a message it was asked to send. What it does not do is question whether the message should exist, compare it against a pricing change or a product fix, or author the hypothesis in the first place. Those live upstream of the channel. **How long does it take to see a result from decisioning?** First decisions can be live within weeks, but a result you should trust needs a full measurement window against a randomised holdout, which for most B2C businesses means 8 to 12 weeks from the first live cohort. Anything faster is a read on novelty rather than on effect. ## Related - [Customer decisioning vs. CDP](https://markin.ai/compare/customer-decisioning-vs-cdp) — The architectural boundary, side by side. - [Reference architecture for a decision layer](https://markin.ai/architecture/decision-layer-reference-architecture) — Where it sits and what it must never own. - [How to evaluate a decisioning platform](https://markin.ai/guides/decisioning-platform-buyers-guide) — Twelve questions and the answers that should worry you. - [How Markin measures incrementality](https://markin.ai/methodology/incrementality-measurement) — The holdout design behind every number. Source: https://markin.ai/guides/customer-decisioning --- --- title: How to evaluate a decisioning platform url: https://markin.ai/guides/decisioning-platform-buyers-guide author: Román Via-Dufresne, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: decisioning platform, next best action software, decisioning platform evaluation, customer decisioning vendors --- # How to evaluate a decisioning platform > Evaluating a decisioning platform comes down to four things: who authors the candidate actions, what objective the ranking optimises, whether the system can execute without a human build step, and whether every decision carries a control group. A product that fails any of the four is a rules engine with a model attached. ## Why demos are a bad evaluation instrument Every decisioning demo looks the same: a customer profile, a ranked list, a confident number next to each row. The differences that matter are not visible on that screen. They show up three months in, when someone asks where the candidate actions came from, why the winner was the one with the highest click probability, and who is holding the control group. - A ranked list proves nothing about how the list was assembled. - Engagement objectives look excellent in a demo and over-contact people who would have converted anyway. - 'Real time' usually describes the API, not the decision. - Uplift on the slide is almost always attributed, not measured against a holdout. ## Twelve questions, and the answers that should worry you Ask these in the order below. The first four are disqualifying; the rest are trade-offs you can live with once you know about them. | Question | The answer that should worry you | What good looks like | | --- | --- | --- | | Who writes the candidate actions? | "Your team configures them in the UI." | The system proposes actions you did not think of, and can explain the evidence behind each one. | | What does the ranking optimise? | Propensity to open, click or convert. | Expected incremental revenue, net of margin, contact cost and fatigue. | | Can it decide to do nothing? | Hold is a suppression rule you configure. | Hold is a first-class candidate that wins on expected value, routinely. | | Who launches the winning action? | It exports a recommendation; your team builds it. | The platform executes inside the systems you already run, without a build queue. | | Where does the control group live? | "You can set one up per campaign." | Randomised holdout attached to every decision by default, not per campaign. | | What is in scope beyond messaging? | Message, offer, channel, timing. | Pricing, packaging, onboarding, in-product surfaces and technical anomalies too. | | How many hypotheses can run in parallel? | A number bounded by seats or by campaign slots. | Bounded by the base and by statistical power, not by human capacity. | | What happens to a losing programme? | It appears in a quarterly review. | It is retired automatically when it fails to beat control. | | How is uplift reported? | Conversions attributed to the journey. | Incremental revenue against a randomised holdout, over a full window. | | What data does it need to own? | A full migration into their profile store. | It reads your warehouse or CDP and owns only the decision log. | | How are guardrails expressed? | Frequency caps only. | Margin floors, contact economics, brand and legal constraints, per-segment eligibility. | | What does the pilot prove? | Engagement metrics on a hand-picked segment. | A holdout-verified revenue number on a segment you chose. | ## Two things to verify independently - Ask for the incrementality-tested number rather than the reported one. BCG finds 20% to 40% of measured next-best-action uplift disappears once a randomised control is applied, so the two figures are not interchangeable. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) - Check who funded any performance study you are shown. The quantified economic-impact research published for BrazeAI Decisioning Studio, for instance, is a Total Economic Impact study conducted by Forrester Consulting and commissioned by Braze, which is a different evidence class from independent analyst research. [Vendor-commissioned: Forrester TEI, commissioned by Braze (May 2026)](https://tei.forrester.com/go/braze/aidecisioningspotlight/) ## What to demand in the pilot contract A pilot that cannot fail is not a pilot. Write the failure condition down first. - You choose the segment, not the vendor. - A randomised holdout of a size you agree in advance, held for the full measurement window. - One primary metric, stated before the pilot starts, expressed in revenue rather than engagement. - A stated stopping rule and a stated failure condition, both written down before launch. - Access to the decision log: for any customer, why that action, what it was worth, what happened. - No migration as a precondition. If the pilot requires you to move your data first, it is not a pilot. ## Reasons to walk away from the category entirely - Your outcome data is unreliable or heavily delayed. Fix measurement before buying decisioning. - Your constraint is delivery capacity, not decision quality. Buy execution capacity instead. - You cannot obtain a randomised holdout for organisational reasons. Without one you will never know whether it worked. - The commercial case rests on a small base. Below roughly 100,000 active customers, the arithmetic rarely justifies the programme. ## FAQ **What is the single most important question to ask a decisioning vendor?** Who writes the candidate actions. If the honest answer is that your team configures them and the system only ranks them, the product's ceiling is the imagination and capacity of your team. Everything else, models, real-time APIs, channel coverage, is downstream of that limit. **How much should a decisioning pilot cost?** The number that matters is not the fee but the ratio between the fee and the incremental margin the pilot has to produce to justify itself. Write that threshold down before the pilot starts and express it in incremental revenue against a holdout, not in engagement metrics. **Should we build this in-house?** Building the ranking is the easy part and most good data science teams can do it. The parts that consume years are activation into every channel, guardrail management, automated experiment design and readout, and keeping it all running when the schema changes. Evaluate the build against those, not against the model. **Do we need a CDP before we buy decisioning?** No. A decision layer needs access to reliable customer context, which can come from a warehouse, a CDP, or a mixture. Requiring a CDP first is a sequencing preference, not a technical dependency, and it delays the revenue case by a year in most organisations. ## Related - [Customer decisioning: the guide](https://markin.ai/guides/customer-decisioning) — Definitions and the architectural boundary. - [Markin + Braze](https://markin.ai/compare/markin-and-braze) — How a decision layer works alongside an engagement platform. - [ROI and incrementality calculator](https://markin.ai/roi-calculator) — Size the pilot on your own numbers. - [Our evidence standard](https://markin.ai/trust/evidence-standards) — The bar we hold our own claims to. Source: https://markin.ai/guides/decisioning-platform-buyers-guide --- --- title: The operating model behind sustained ARPU growth url: https://markin.ai/guides/arpu-growth-operating-model author: Romà Llambés, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: arpu growth, increase arpu, revenue per user growth, growth operating model --- # The operating model behind sustained ARPU growth > ARPU stalls because decision throughput is fixed, not because the ideas run out. A team can plan, build and read a handful of revenue experiments per quarter, so the base is served by a few large programmes rather than by a decision per customer. Raising throughput, not headcount, is what moves the number. ## The plateau is arithmetic, not talent Most B2C businesses reach the same ceiling. Acquisition works, the lifecycle programme works, and then ARPU flattens for six quarters while the team keeps shipping. The reason is rarely a bad idea. It is that every idea has to pass through the same narrow pipe: someone has to size it, define the segment, brief it, wait for a build slot, launch it, and wait again to read it. - Four to eight meaningful revenue experiments per quarter is a normal ceiling for a strong team. - Each one takes 6 to 10 weeks from idea to a number anyone trusts. - Most of that time is not thinking. It is pulling data, building lists and reconciling reports. - So the base gets a handful of programmes, and everything else stays untested. ## What actually changes The operating model shift is narrow and specific. Only one variable moves; everything else follows from it. 1. **Move from segments to decisions.** A segment is a compromise made because you cannot afford a decision per person. Once decisions are cheap, the compromise stops paying for itself. The same base, decided individually, has a materially higher ceiling than the same base split into five segments. 2. **Make hold a real option.** Contact economics are asymmetric: the cost of contacting a customer who was going to buy anyway is invisible in attributed reporting and very visible in a holdout. An operating model that cannot output 'do nothing' will overspend permanently. 3. **Let failure be cheap.** If a failed test costs a quarter, teams only test things they expect to win, which is exactly the set of hypotheses with the least information in them. When failure costs nothing, the interesting hypotheses get run. 4. **Keep judgement human.** Constraints, margin floors, brand and regulatory limits, and what deserves to scale are human calls. Throughput is not. _The scheduled model against the continuous one_ | Dimension | Scheduled growth | Continuous growth | | --- | --- | --- | | Unit of planning | The quarter, and a roadmap of programmes | The customer, and a decision per window | | Who authors hypotheses | Analysts and growth managers, between other work | The system, continuously, ranked by expected value | | Hypotheses tested per quarter | 4 to 8 | Hundreds, in parallel | | What can be hypothesised about | Mostly campaigns and offers | Marketing, product, pricing and technical health alike | | Cost of the 500th hypothesis | Another analyst, another quarter | Effectively zero | | Share of decisions with a control group | The flagship programmes, when there is time | Every decision, by default | | What the team spends its time on | Producing analyses | Setting guardrails and deciding what scales | ## Sizing the opportunity honestly ARPU maths is seductive because it applies to the whole base every month. That is also why it is easy to overstate. - Any projection should be haircut before it is presented: BCG finds 20% to 40% of measured next-best-action uplift does not survive a randomised control test, so the planning number should sit below the reported one. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) ## Measure your own throughput this week Five numbers. If you cannot produce them quickly, that is itself the finding. - How many revenue hypotheses were tested last quarter, end to end, with a readout? - What was the median time from idea to trustworthy result? - What share of those had a randomised holdout? - How many were about something other than a message or an offer? - How many programmes currently running have never been checked against a control? ## When this model is the wrong priority - Product-market fit is not settled. Continuous optimisation of a proposition that is still moving wastes the measurement. - The business runs on a handful of high-value accounts. Per-customer decisioning is built for large bases. - Margin is negative at the unit level. Increasing revenue per user makes the problem larger, not smaller. - Data on outcomes arrives months late. Throughput cannot exceed the speed of feedback. ## FAQ **How do you increase ARPU without increasing churn?** By ranking actions on expected incremental revenue net of margin and contact cost, rather than on conversion. An upsell that converts but raises churn risk has a negative expected value once retention is priced in, and it should lose to a cheaper action or to no action at all. This only works if churn effects are read in the same holdout as the revenue effect. **Is ARPU or LTV the right target?** ARPU is the right operating metric because it can be read monthly against a control group. LTV is the right strategic metric but it is a forecast, and forecasts are easy to move by changing assumptions. Use ARPU for decisions and LTV for planning. **How many experiments should a large B2C business run?** As many as the base can support statistically, which for a multi-million customer base is far more than any team can plan. The practical constraint should be statistical power and contact economics, not the number of people available to write briefs. **What is a realistic ARPU improvement to plan for?** Plan on a haircut version of whatever your first holdout-verified cohort produces, and refuse to plan on a number that has not survived a control group. Across Markin deployments the verified range on treated cohorts is +17% to +35% ARPU against a randomised holdout, which is a range across deployments in large B2C bases rather than a forecast for any specific business. ## Related - [Where the hypotheses come from](https://markin.ai/methodology/hypothesis-generation) — How throughput is actually produced. - [How Markin measures incrementality](https://markin.ai/methodology/incrementality-measurement) — Why the haircut exists. - [ROI and incrementality calculator](https://markin.ai/roi-calculator) — Run the arithmetic on your own base. - [Markin and your growth team](https://markin.ai/compare/markin-and-your-growth-team) — What the team does once throughput is not the constraint. Source: https://markin.ai/guides/arpu-growth-operating-model --- --- title: How Markin measures incrementality url: https://markin.ai/methodology/incrementality-measurement author: Román Via-Dufresne, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: incrementality measurement, holdout testing, incremental revenue measurement, next best action measurement --- # How Markin measures incrementality > Markin measures incrementality with a randomised holdout attached to every decision, read over a full measurement window against a pre-declared primary metric. A result that has not beaten its control does not scale. Reported uplift, attributed conversions and post-hoc comparisons are not accepted as evidence at any stage. ## Why attribution is not measurement Attributed reporting answers a question nobody should care about: of the people who converted, how many touched this programme first. It counts customers who would have converted anyway, and it counts them in favour of whichever programme reached them. That is why programmes that look excellent for years often disappear when someone finally holds a control group. - Attribution measures correlation with an outcome, not the outcome caused. - The customers most likely to convert are also the easiest to reach, which biases every attributed number upwards. - Contacting someone who would have bought anyway has a real cost that attribution reports as a win. ## The design, step by step 1. **Randomise at the customer, before the decision.** Assignment happens before Markin chooses an action, not after. Assigning after the decision leaks the decision into the control group and quietly destroys the comparison. 2. **Hold out a stable share of the eligible population.** The holdout is drawn from the customers who were eligible for the decision, not from the base at large. Comparing treated customers against the whole base compares two different populations and produces a number that is always flattering. 3. **Declare the primary metric before launch.** One primary metric, expressed in revenue, fixed before any data arrives. Secondary metrics are recorded but cannot be promoted to primary after the fact. 4. **Read over a full measurement window.** The window is set by the business cycle being affected, not by impatience. A subscription upsell read at seven days measures novelty. Reading it across a billing cycle measures effect. 5. **Apply the stopping rule.** Stopping rules are set in advance. Peeking at a running test and stopping when it looks good manufactures significance, and it is the most common way a good measurement practice quietly becomes a bad one. 6. **Scale or retire.** A result that beats control across the window scales to the rest of the eligible population. A result that does not is retired. There is no third outcome where a programme keeps running while someone thinks about it. _What counts as evidence, and what does not_ | Evidence | Accepted | Why | | --- | --- | --- | | Randomised holdout, full window, pre-declared metric | Yes | Measures the effect caused by the decision. | | Pre/post comparison on the same cohort | No | Cannot separate the decision from seasonality or anything else that changed. | | Treated group against the unexposed rest of the base | No | Different populations. Selection alone produces a positive result. | | Attributed conversions from the delivery platform | No | Counts customers who would have converted anyway. | | Model-predicted uplift | No | A forecast, not a measurement. Useful for ranking, never for reporting. | | Holdout stopped early because the result looked good | No | Optional stopping inflates the effect size. | ## Why the haircut exists - BCG finds that when next-best-action programmes are incrementality-tested, 20% to 40% of the measured uplift does not survive. Markin applies that haircut to projections before they are shown, rather than after a customer discovers it. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) ## Audit one of your own programmes Pick the programme with the best-looking numbers. That is where the surprise usually is. - Was a control group defined before the first send, or reconstructed afterwards? - Was the control drawn from eligible customers, or from everyone else? - Was the primary metric written down before launch? - Was the reported window chosen in advance, or chosen once the data was in? - Was the test stopped at a pre-agreed point? - If you removed attributed conversions and used only the holdout comparison, does the programme still pay for itself? ## Where holdouts are the wrong instrument - Legally or contractually mandatory communications. You cannot withhold them, so there is no control group to hold. - Effects that spill across customers, such as referral or network mechanics, where the control group is contaminated by the treatment. - Very small eligible populations, where the test would never reach power and the honest answer is to decide on judgement. - One-off structural changes with no repeatable unit, which belong in a before/after analysis with all its caveats stated. ## FAQ **How large should a holdout be?** Large enough to detect the smallest effect that would change your decision, at the significance level you are willing to act on. For large B2C bases that is usually a single-digit percentage of the eligible population, which is cheap. The right way to choose it is a power calculation on the minimum detectable effect, never a round number picked because it feels safe. **How long should a measurement window be?** As long as the business cycle the decision affects. For a monthly subscription that means at least one full billing cycle, usually two, so that a pulled-forward purchase is not counted as an incremental one. Reading a revenue effect at seven days measures novelty. **What is the difference between uplift and incremental revenue?** Uplift is usually the difference between treated customers and everyone else, which is contaminated by selection. Incremental revenue is the difference between a randomised treated group and a randomised control group drawn from the same eligible population. Only the second one supports a business case. **Can you measure incrementality without a holdout?** Sometimes, with quasi-experimental methods such as geographic splits, switchback designs or synthetic controls. They are legitimate when randomisation is impossible, and every one of them rests on assumptions that a holdout does not need. Use them as a fallback, state the assumptions, and do not present the result as equivalent. ## Related - [Our evidence standard](https://markin.ai/trust/evidence-standards) — What we allow ourselves to publish. - [ROI and incrementality calculator](https://markin.ai/roi-calculator) — The haircut, applied to your numbers. - [Where the hypotheses come from](https://markin.ai/methodology/hypothesis-generation) — What gets measured in the first place. - [Experimentation vs. continuous decisioning](https://markin.ai/compare/experimentation-vs-continuous-decisioning) — Two different measurement cultures. Source: https://markin.ai/methodology/incrementality-measurement --- --- title: Where the hypotheses come from url: https://markin.ai/methodology/hypothesis-generation author: Romà Llambés, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: hypothesis generation, growth experimentation at scale, automated experimentation, revenue opportunity detection --- # Where the hypotheses come from > Markin generates its own revenue hypotheses instead of waiting to be given them. It reads behavioural, transactional, product and operational signal continuously, looks for where value is leaking or unclaimed, writes a hypothesis with an expected direction and a sized value, and puts it in a queue ordered by money rather than by opinion. ## The bottleneck nobody budgets for Every growth team has a backlog of ideas and a much shorter list of things it will actually test. The filter is not quality. It is who had time to size the idea, define the segment and write the brief. Hypotheses that would take a day of investigation to formulate never get formulated, so the business optimises the things that were easy to describe. - Ideas that require cross-domain evidence rarely survive the backlog. - Anything outside the campaign surface needs a different team, which means a different quarter. - Technical causes of revenue loss are usually found by accident, months late. ## Four domains, one queue The point of authoring hypotheses rather than ranking given ones is that the search space stops being the campaign tool. All four domains compete in the same queue on the same currency: expected incremental revenue. 1. **Detect.** Continuous scanning for deviations that matter commercially: a cohort behaving differently from its own history, a funnel step degrading, a segment whose margin profile has drifted, an anomaly nobody reported. 2. **Investigate.** Before a hypothesis is written, the candidate cause is checked against alternatives. A conversion drop that is really a traffic-mix change should not become a pricing experiment. 3. **Write the hypothesis.** Stated with a direction, a mechanism and an eligible population. 'Doing X for population Y will increase Z, because W.' A hypothesis without a mechanism cannot be learned from, only won or lost. 4. **Size it.** Expected value is estimated on the eligible population, net of margin and contact cost, so the queue is ordered by money. Sizing is a forecast and is never reported as a result. 5. **Kill it cheaply.** Most hypotheses are wrong. The design target is that a wrong hypothesis costs a small holdout and a short window, so that expensive-to-formulate, high-information hypotheses become affordable. _What Markin is allowed to hypothesise about_ | Domain | Typical hypothesis | How it is tested | | --- | --- | --- | | Marketing | This cohort is worth a win-back offer at this depth, and this other cohort is worth leaving alone. | Randomised holdout on the eligible population, read on incremental margin. | | Product | Customers who never reach this feature in week one churn at a materially higher rate; surfacing it earlier will move retention. | In-product treatment arm against a control, read across a full cycle. | | Commercial | Annual framing beats monthly for this cohort once discount depth is priced against margin. | Price and packaging variant with a margin floor as a guardrail. | | Technical health | Checkout error rate rose on one device and one region a fortnight ago and is suppressing conversion. | Anomaly confirmed against baseline, routed to the owning team, effect of the fix read against the pre-fix trend and a matched control where one exists. | ## Sizing is a forecast, not a claim - Expected-value estimates used to rank the queue are explicitly not published as results. BCG's finding that 20% to 40% of measured next-best-action uplift fails an incrementality test is the reason we treat the two as different classes of number. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) ## Score your own hypothesis pipeline Take last quarter's tested hypotheses and classify them. - What share were about a message, an offer or an audience? - How many originated outside the growth or CRM team? - How many were about pricing or packaging? - How many started from an anomaly nobody was looking for? - For each one, is the mechanism written down, or only the variant? - How many were killed within four weeks? If the answer is none, the pipeline is only testing safe bets. ## Where automated hypothesis generation adds little - Businesses whose revenue problem is already well understood and simply unbuilt. Execution capacity is the constraint, not hypotheses. - Environments where outcome data arrives too late to close the loop within a planning cycle. - Highly regulated decisions where every treatment needs individual legal review, which reintroduces the human bottleneck by design. - Very small bases, where nearly every hypothesis is underpowered and judgement beats testing. ## FAQ **How does Markin decide which hypothesis to test first?** By expected incremental revenue on the eligible population, net of margin and contact cost, with statistical power as a hard filter. A large opportunity that cannot be measured within a reasonable window ranks below a smaller one that can, because an unmeasurable result cannot be scaled responsibly. **Does Markin only test marketing hypotheses?** No. Marketing is one of four domains. Product, pricing and packaging, and technical health are in the same queue and compete on the same currency. In practice technical health is where the fastest, least contested wins usually sit, because nobody was looking for them. **What stops it from generating noise?** Two filters. A candidate must survive an investigation step that checks it against alternative explanations, and it must be sized above a threshold on an eligible population large enough to reach power. Anything that fails either filter never becomes a hypothesis. **Who approves a hypothesis before it runs?** Guardrails are set by humans in advance: margin floors, contact economics, brand and regulatory constraints, eligible populations. Within those, hypotheses run automatically. Anything that touches a guardrail is escalated rather than executed, which is the difference between autonomy and a system nobody can control. ## Related - [How Markin measures incrementality](https://markin.ai/methodology/incrementality-measurement) — What happens after the hypothesis is written. - [The ARPU operating model](https://markin.ai/guides/arpu-growth-operating-model) — Why throughput is the binding constraint. - [Markin and your data science team](https://markin.ai/compare/markin-and-your-data-science-team) — What the team does with the time back. - [Product and customer diagnosis](https://markin.ai/solutions/product-diagnosis) — The technical-health domain in practice. Source: https://markin.ai/methodology/hypothesis-generation --- --- title: Reference architecture for a decision layer url: https://markin.ai/architecture/decision-layer-reference-architecture author: Román Via-Dufresne, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: decision layer architecture, decisioning architecture, composable customer stack, cdp vs decisioning --- # 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. **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. 1. **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. 2. **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. 3. **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. 4. **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. 5. **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. ## FAQ **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. ## Related - [How decisions reach the customer](https://markin.ai/architecture/activation-and-integrations) — The four activation patterns and their trade-offs. - [Customer decisioning vs. CDP](https://markin.ai/compare/customer-decisioning-vs-cdp) — The boundary, argued in full. - [Markin + Segment / Tealium](https://markin.ai/compare/markin-and-segment-tealium) — A decision plane on top of a data plane. - [Customer decisioning: the guide](https://markin.ai/guides/customer-decisioning) — Start here if the category is new. Source: https://markin.ai/architecture/decision-layer-reference-architecture --- --- title: How decisions reach the customer url: https://markin.ai/architecture/activation-and-integrations author: Román Via-Dufresne, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: decisioning activation, reverse etl decisioning, real-time decision api, next best action integration --- # How decisions reach the customer > A decision reaches the customer in one of four ways: written back as a profile attribute, fired as a triggered event, served on request through a decision API, or rendered directly into a product surface. Each has a different latency, a different governance owner, and a different failure mode when the channel is busy. ## The decision is worthless until it is executed Most decisioning disappointments are activation disappointments. The ranking was fine. What failed is that the chosen action needed a new template, a release window and a compliance review, so by the time it shipped the reason for choosing it had passed. Activation design decides whether a decision layer produces revenue or a dashboard. - A recommendation that needs a human build step inherits the build queue's throughput. - Batch write-back that lands after the journey has already fired is a decision nobody used. - Every channel that receives decisions independently will eventually contradict the others. ## Four patterns Most deployments use two or three of these together. Choosing per surface rather than picking one for the whole estate is the correct default. 1. **Pick per surface, not per estate.** Lifecycle email over attribute write-back and a paywall over a decision API is a normal, healthy combination. Forcing one pattern everywhere either overpays for latency you do not need or starves the surfaces that do. 2. **Keep governance where it already is.** Frequency capping, quiet hours, consent and brand review should stay in the systems that already enforce them. The decision layer supplies intent; the channel keeps its veto. 3. **Make the write-back idempotent.** Decisions are recomputed. Activation must tolerate the same decision arriving twice without sending twice, and must handle a decision being superseded before it executes. 4. **Close the loop.** Delivery, engagement and outcome events flow back into the decision layer, keyed to the original decision. Without that key, the measurement plane can report what happened but not what it was a consequence of. 5. **Design the failure mode.** When the decision layer is unavailable, every surface should degrade to a defined default rather than to whatever the last cached value was. Write the default down for each surface before launch. _Activation patterns and their trade-offs_ | Pattern | How it works | Best for | Trade-off | | --- | --- | --- | --- | | Attribute write-back | The decision is written to the customer profile in the CDP or engagement platform; existing journeys read it as an entry condition. | Lifecycle programmes already built in the engagement platform. | Latency is the sync interval. A decision that changes hourly will be stale at the moment of send. | | Triggered event | The decision is emitted as an event that starts or advances a journey. | Time-sensitive lifecycle moments: dunning, churn risk, post-purchase. | Requires event contracts to be maintained. Journey logic can silently swallow events. | | Decision API | The surface asks for a decision at render time and receives one action plus its reason. | In-session surfaces: paywalls, checkout, home screens, care agent screens. | Needs a fallback path and a latency budget. The surface must be able to render without an answer. | | Direct surface rendering | The decision layer populates a slot in the product or a message body directly. | High-frequency in-product placements where round-tripping through a channel adds nothing. | Closest to owning the channel. Keep creative governance outside the decision layer. | ## Integration readiness, per surface Answer these once for each surface before you connect it. - What is the acceptable latency between decision and execution here? - Which pattern matches that latency at the lowest operational cost? - What renders if no decision is available? - Who owns the veto: consent, frequency, quiet hours, brand? - How does the outcome get back, and is it keyed to the decision ID? - If this surface is removed next quarter, does anything else break? ## When not to connect a surface - Surfaces with no outcome signal. If you cannot observe what happened, the decision cannot be learned from and the surface is just a broadcast. - Channels where every message needs individual legal sign-off. The approval step sets the throughput, so automation adds little. - Very low-volume surfaces, where no decision will ever reach statistical power. - Surfaces owned by a team that has not agreed to the guardrails. Activation without agreement is how a decision layer gets switched off. ## FAQ **Does Markin send messages itself?** Only where a surface has no other executor, such as a product slot that Markin renders directly. For channels you already run, Markin writes the decision into them: an attribute, an event or an API response. Content, channel governance and deliverability stay with the platform that already owns them, which is what makes the integration reversible. **How fast is activation?** It depends on the pattern rather than on the decision. A decision API answers in-session, a triggered event is near immediate, and attribute write-back inherits the sync interval of the platform receiving it, which is often hourly. Choose the pattern from the latency the surface actually needs. **What happens if two decisions target the same customer at once?** They should never leave the decision layer. Arbitration happens before activation and the output is one committed decision per customer per window. If two decisions reach the channel, the arbitration boundary has been drawn in the wrong place. **Do we have to replace our reverse ETL tooling?** No. Attribute write-back can run over the reverse ETL pipeline you already operate. The decision layer produces the rows; the existing pipeline moves them. Replacing a working pipeline adds risk without adding decision quality. ## Related - [Reference architecture for a decision layer](https://markin.ai/architecture/decision-layer-reference-architecture) — The planes and their boundaries. - [Markin + Hightouch](https://markin.ai/compare/markin-and-hightouch) — Activation pipeline and decision layer together. - [Markin + Braze](https://markin.ai/compare/markin-and-braze) — Write-back into journeys in practice. - [How Markin measures incrementality](https://markin.ai/methodology/incrementality-measurement) — Closing the loop after activation. Source: https://markin.ai/architecture/activation-and-integrations --- --- title: The evidence standard behind every number we publish url: https://markin.ai/trust/evidence-standards author: Romà Llambés, Co-founder, Markin published: 2026-08-04 updated: 2026-08-04 keywords: markin evidence, vendor claim verification, incrementality evidence, ai vendor claims --- # The evidence standard behind every number we publish > Markin publishes a number only when it came from a randomised holdout, is stated as a range rather than an average, and travels with the qualifier that explains what it is a range of. Claims we cannot evidence to that standard are not softened or hedged. They are not published. ## Why this page exists This category has a credibility problem, and vendors created it. Uplift figures are quoted without a control group, commissioned studies are cited as independent research, and a range across a handful of deployments becomes an industry benchmark by the time it reaches a slide. We publish our standard so that our numbers can be checked against it, including by people who do not trust us. - Every quantified claim on this site has an owner inside Markin and a review date. - Every claim that requires a qualifier renders with that qualifier, on every page. - Claims we have decided not to make are written down too, so nobody quietly reinstates them. ## The rules 1. **One wording, one place.** Approved claims live in a single register in the codebase and pages import the wording rather than retyping it. A claim that exists in three slightly different forms becomes a fourth form nobody approved once an answer engine paraphrases it. 2. **Ranges, never averages.** Performance is reported as a range across deployments. An average implies a typical customer, and with a small number of large, very different B2C bases there is no such thing. 3. **Qualifiers are mandatory, not decorative.** Where a claim carries a qualifier, the qualifier is rendered with it. It is not a footnote, it is part of the claim. 4. **Provenance is labelled.** Third-party statements carry a source label: vendor page, vendor documentation, vendor-commissioned research, analyst report, or independent research. A commissioned study is legitimate evidence and a different class from independent research, and readers are entitled to see which one they are reading. 5. **Review dates, not indefinite claims.** Every claim has a date by which it must be rechecked. A claim past its review date is removed rather than assumed to still hold. 6. **Refusal is a normal outcome.** Where we could not source something we would defend, we say so on the page instead of finding a weaker source that technically supports it. _What we claim, and what we refuse to claim_ | Statement | Status | Why | | --- | --- | --- | | +17% to +35% ARPU on treated cohorts against a randomised holdout | Published with a mandatory qualifier | Anonymised range across deployments in large B2C bases, read over a full measurement window. Not an industry benchmark and not a forecast for your base. | | Every decision carries a control group | Published | A property of how the product works, verifiable in a pilot. | | Programmes that fail to beat control are retired automatically | Published | A product behaviour, checkable in the decision log. | | An industry benchmark for decisioning uplift | Refused | We could not find one we would defend. We cite BCG's incrementality research instead. | | "Markin is GDPR compliant" | Refused | Compliance depends on the deployment, the lawful basis and your own processing. We describe controls and point to legal review. | | "A pilot takes N weeks" | Refused | Duration depends on data readiness and activation access. We publish stage gates instead of a promise. | ## The independent research we lean on Where third-party evidence is load-bearing, we prefer research nobody on the page paid for. - BCG finds that 20% to 40% of measured next-best-action uplift does not survive an incrementality test. We apply that haircut to projections before showing them, including in our own ROI calculator. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) ## How to audit any vendor claim, including ours Six questions. They work on our pages as well as on anyone else's. - Is the number measured against a randomised control group, or attributed? - Is it a range or a single figure? A single figure across different businesses is a rounding of something. - Who funded the study? Commissioned research should be labelled as such by whoever cites it. - Over what window was it read, and was the window chosen before or after the data arrived? - What population is the denominator: treated customers, eligible customers, or everyone? - Is there a date on it, and would the vendor still defend it today? ## The limits of this page - This is a statement of our own editorial standard, maintained by Markin. It is not an audit, a certification or third-party verification. - It covers public claims about performance and product behaviour. Security, privacy and contractual commitments are handled in contract and legal review, not here. - Customer-specific results are not published without that customer's written approval, which means our public evidence is deliberately thinner than our private evidence. ## FAQ **Where does the +17% to +35% ARPU range come from?** It is an anonymised range across Markin deployments in large B2C bases, measured on treated cohorts against a randomised holdout and read over a full measurement window. It is a range across deployments, not an average, not an industry benchmark, and not a forecast for any specific base. Your own number should come from your own holdout. **Why does Markin not publish an industry benchmark?** Because we could not source one we would defend. Published decisioning benchmarks are usually attributed rather than incrementality-tested, and the gap between those two is large enough that quoting one would mislead. We cite BCG's independent research on that gap instead. **Is this page verified by anyone outside Markin?** No. It is app-owner maintained content describing the standard we hold ourselves to, and it should be read as a statement of practice rather than as independent verification. The useful test is whether a pilot on your own base reproduces the behaviour described here. **What should I ask for to verify a claim in a pilot?** Access to the decision log and the holdout definition. For any customer, you should be able to see the action chosen, the alternatives considered, the expected value, the guardrails applied and whether that customer was in treatment or control. If any of those are missing, the resulting number is not verifiable. ## Related - [How Markin measures incrementality](https://markin.ai/methodology/incrementality-measurement) — The design behind every published number. - [How to evaluate a decisioning platform](https://markin.ai/guides/decisioning-platform-buyers-guide) — Apply the same audit to other vendors. - [ROI and incrementality calculator](https://markin.ai/roi-calculator) — Where the haircut is applied. - [About Markin](https://markin.ai/about) — Who is accountable for this. Source: https://markin.ai/trust/evidence-standards --- --- title: Customer action arbitration: choosing one action per customer url: https://markin.ai/guides/customer-action-arbitration author: Romà Llambés, Co-founder, Markin published: 2026-08-07 updated: 2026-08-07 keywords: customer action arbitration, next best action arbitration, contact policy, action prioritisation --- # Customer action arbitration: choosing one action per customer > Customer action arbitration is the step that decides which single action a customer receives when several are eligible at once. It compares candidate actions on expected value, applies eligibility and contact policy, resolves conflicts between teams and campaigns, and is allowed to choose no action at all when nothing clears the bar. **Customer action arbitration** — The process of selecting one action per customer from all eligible candidates, using expected value, eligibility rules, contact policy and conflict resolution, including the option of sending nothing. ## Every team is optimising the same inbox Retention has a win-back offer. Growth has an upsell. Product has an onboarding nudge. Finance has a dunning sequence. Each is defensible on its own, and each was prioritised inside its own tool. Without arbitration the customer gets whichever one happened to run first, and the business never learns which of the four was worth sending. - Contact frequency is capped per channel, not per customer, so pressure accumulates invisibly. - Conflicts are resolved by campaign start date rather than by value. - The cost of the action that was not sent is never measured. ## How an arbitration decision is made Arbitration is not a priority number in a spreadsheet. It is an ordered set of filters applied per customer, at decision time. 1. **Assemble candidates.** Every action the customer is technically eligible for, from every programme, is placed in one pool. An action that never enters the pool can never be compared. 2. **Apply eligibility.** Consent, channel availability, regulatory constraints, exclusion lists and product state remove candidates outright. These are hard filters, never trade-offs. 3. **Score expected value.** Each surviving candidate carries an expected incremental value on this customer, net of margin, discount depth and contact cost. 4. **Apply contact policy.** Per-customer frequency, channel fatigue and quiet periods are enforced across all programmes at once, rather than inside each tool separately. 5. **Resolve conflicts.** Two actions that cannot coexist, a retention discount and a price increase on the same week, are resolved by value and by the constraints the business set in advance. 6. **Choose, or choose nothing.** If no candidate clears the value threshold, the correct decision is no contact. Preserving attention is a real outcome and is measured as one. 7. **Hold out.** A share of eligible customers receives nothing by design, so the value of the arbitration itself can be read rather than assumed. _Prioritisation versus arbitration_ | | Campaign prioritisation | Customer action arbitration | | --- | --- | --- | | Unit of decision | The campaign. One audience, one treatment. | The customer. One decision per person, per moment. | | Conflict handling | Resolved by schedule and by whoever owns the calendar. | Resolved by expected value under stated constraints. | | Contact pressure | Capped per channel, per programme. | Capped per customer, across every programme at once. | | Doing nothing | Rarely modelled. Silence is a gap in the calendar. | A first-class option with a measurable value. | | Learning | Which campaign performed. | Which action was worth choosing for whom, against a holdout. | ## Test whether you have arbitration or just prioritisation Pick one customer who received a message last week and answer these. - Can you list every action that customer was eligible for that day? - Can you state why the one they received beat the others? - Is contact pressure capped per customer, or per channel? - Who resolves a conflict between two teams today, and how long does it take? - Is 'send nothing' a possible output of your current setup? - Is there a population that received nothing by design, so you can measure the arbitration itself? ## When arbitration is not the bottleneck - Businesses running a small number of programmes that rarely overlap. The conflicts are visible and a human resolves them well enough. - Bases too small for per-customer decisions to reach statistical power. - Environments where regulation fixes the sequence of communications, leaving nothing meaningful to arbitrate. - Organisations without shared eligibility data, where the candidate pool cannot be assembled in the first place. Fix the data layer first. ## FAQ **What is customer action arbitration?** It is the step that decides which single action a customer receives when several are eligible at once. Candidates from every programme are pooled, filtered by eligibility and consent, scored on expected incremental value, checked against per-customer contact policy, and resolved against each other. Sending nothing is a valid outcome. **How is arbitration different from campaign prioritisation?** Prioritisation ranks campaigns before they run and resolves clashes by schedule. Arbitration ranks candidate actions per customer at decision time and resolves clashes by expected value under stated constraints. One optimises the calendar; the other optimises the customer. **Why does 'no action' need to be an option?** Because contact has a cost that rarely appears in a campaign report: fatigue, unsubscribes and reduced response to the message that actually mattered. If a system cannot choose silence, it will always find a reason to send something, and that reason is never measured against the alternative. ## Related - [Customer decisioning, explained](https://markin.ai/guides/customer-decisioning) — The category this step sits inside. - [Controlled growth experiments](https://markin.ai/guides/controlled-growth-experiments) — How the arbitration itself is measured. - [Decision layer reference architecture](https://markin.ai/architecture/decision-layer-reference-architecture) — Where arbitration sits between context and activation. - [Activation and integrations](https://markin.ai/architecture/activation-and-integrations) — How the chosen action reaches your stack. Source: https://markin.ai/guides/customer-action-arbitration --- --- title: Controlled growth experiments: proving an action caused the result url: https://markin.ai/guides/controlled-growth-experiments author: Román Via-Dufresne, Co-founder, Markin published: 2026-08-07 updated: 2026-08-07 keywords: controlled experiments, incrementality testing, holdout group, growth experimentation --- # Controlled growth experiments: proving an action caused the result > A controlled growth experiment measures what an action caused rather than what followed it. An eligible population is split into treatment and a randomised control, a primary metric and observation window are fixed in advance, guardrail metrics protect against harm, and the readout resolves to one of three decisions: scale, refine or stop. ## Most growth reporting is not evidence A campaign report tells you what treated customers did. It cannot tell you what they would have done anyway, and in a large B2C base most of them would have done a great deal anyway. The gap between those two numbers is the entire question, and it is usually left unmeasured because measuring it means deliberately withholding the action from someone. - Attributed revenue counts customers who were going to convert regardless. - Pre and post comparisons absorb seasonality, price changes and traffic mix. - Uplift without a control is a description of the treated group, not an effect. ## The six things fixed before an experiment runs Every one of these is written down before the first customer is treated. Deciding any of them afterwards turns an experiment into a story. 1. **Eligible population.** Who could receive this action at all. Everything is measured inside this population, not across the whole base. 2. **Treatment and control.** Random assignment within the eligible population. The control receives no action, not a different action, unless the question is explicitly a comparison between two actions. 3. **Primary metric.** One metric, chosen in advance, at the level the business actually cares about: incremental margin or revenue per eligible customer, not open rate. 4. **Observation window.** Long enough to capture the behaviour and any pull-forward effect. A window that stops at the first good number measures timing, not value. 5. **Guardrails.** Metrics that can stop the experiment regardless of the primary result: margin floors, unsubscribe rates, complaint volume, support load. 6. **Decision rule.** What result leads to scale, to refine, or to stop, agreed before anyone sees the data. _The readout: scale, refine or stop_ | Result | What it means | Decision | | --- | --- | --- | | Clear positive effect on the primary metric, guardrails intact | The action is worth more than doing nothing for this population. | Scale, keeping a smaller permanent holdout to detect decay. | | Positive in a subgroup, flat overall | The eligible population was too broad, not the action wrong. | Refine the population and rerun rather than scaling as-is. | | Flat or inconclusive with adequate power | The action does not move the metric at this cost. | Stop. This is a cheap, normal outcome, not a failure. | | Underpowered, direction unclear | The base or the window could not support the question. | Stop or redesign. Do not scale on a directional read. | | Primary metric up, a guardrail breached | The gain is being paid for somewhere else. | Stop, then re-test with the constraint priced in. | ## Why the discipline is worth the cost of a holdout - BCG reports that between 20% and 40% of measured next-best-action uplift does not survive an incrementality test. That is the size of the error a control group is buying you protection against. [Independent research: BCG, incrementality in personalisation programmes (2026)](https://www.bcg.com/publications/2026/personalization-incrementality) ## Before you call a result a result - Was the control randomised inside the eligible population, or picked afterwards? - Was the primary metric chosen before the data arrived? - Was the observation window long enough to see pull-forward reverse? - Would the experiment have detected an effect worth acting on, given the base size? - Did any guardrail move while the primary metric improved? - Is the decision rule the one that was agreed at the start? ## When a controlled experiment is the wrong instrument - Populations too small to reach power in a reasonable window. Judgement and qualitative evidence beat an underpowered test. - Changes that cannot ethically or legally be withheld, such as a security fix or a regulatory notice. - One-off structural changes with no comparable control group, where a time-series or matched-market method is more honest. - Questions about why something happens. An experiment measures effect, not mechanism. ## FAQ **What makes a growth experiment controlled?** A randomised control group drawn from the same eligible population, a primary metric and observation window fixed before the test runs, and guardrail metrics that can stop it. Without random assignment inside the eligible population, differences between the groups explain the result as well as the action does. **How large should a holdout be?** Large enough to detect the smallest effect worth acting on, and no larger. Oversized holdouts cost real revenue; undersized ones produce a number nobody can act on, which costs more. The size follows from the base, the baseline conversion rate and the effect size you would scale on. **Is a flat result a wasted experiment?** No. A flat result with adequate power tells you not to spend on that action, which is a decision with real value. The expensive outcome is scaling something that never worked, which is exactly what happens when there is no control. ## Related - [How incrementality is measured](https://markin.ai/methodology/incrementality-measurement) — The full method, including window and guardrail choices. - [Customer action arbitration](https://markin.ai/guides/customer-action-arbitration) — What is being tested when several actions compete. - [Evidence standards](https://markin.ai/trust/evidence-standards) — What a result has to satisfy before we publish it. - [Experimentation versus continuous decisioning](https://markin.ai/compare/experimentation-vs-continuous-decisioning) — Where a test programme ends and a decision system begins. Source: https://markin.ai/guides/controlled-growth-experiments --- --- title: Predictive analytics versus growth decisioning url: https://markin.ai/guides/predictive-analytics-vs-growth-decisioning author: Román Via-Dufresne, Co-founder, Markin published: 2026-08-07 updated: 2026-08-07 keywords: predictive analytics, growth decisioning, churn score, propensity model --- # Predictive analytics versus growth decisioning > Predictive analytics estimates what is likely to happen. Growth decisioning chooses what to do about it, launches the action and measures whether it changed the outcome. A prediction is an input to a decision, not a substitute for one: a churn score tells you who is at risk, not who is worth saving, with what, at what cost. ## The model shipped, and nothing changed A churn model reaches good accuracy, goes into production, and twelve months later retention is where it was. This is the most common outcome of a predictive programme, and it is not usually a modelling failure. The score was never connected to a decision anyone was accountable for, an action anyone could launch, or a measurement anyone would accept. - A score without an action is a report. - An action without an eligibility and cost model treats every at-risk customer as equally worth saving. - An action without a control cannot be told apart from what would have happened anyway. ## What sits between a score and a result Prediction is one of six steps. The other five are where most programmes stall, and none of them is a modelling problem. 1. **Predict.** Estimate risk, propensity or value. Necessary, and the part most organisations have already built. 2. **Value the customer.** Convert risk into value at risk. A high-risk customer worth very little is not a priority. 3. **Choose the action.** Compare candidate treatments on expected incremental value, not on which team proposed them. 4. **Apply constraints.** Consent, contact policy, margin floors and regulatory limits are hard filters on what may be done. 5. **Execute.** Deliver through the existing engagement, product or service surface, or the decision stays theoretical. 6. **Measure incrementally.** Read against a randomised control. Model accuracy says nothing about whether the action helped. _Prediction versus decisioning_ | Question | Predictive analytics | Growth decisioning | | --- | --- | --- | | What does it produce | A probability, a score, a segment. | A chosen action for a specific customer, executed. | | Who is worth acting on | Not addressed. Risk is not the same as value at risk. | Expected value net of margin and contact cost decides. | | What action to take | Left to a human, usually in a separate tool. | Selected from competing candidates by arbitration. | | Execution | Hands the list to a marketer or a reverse-ETL job. | Launches inside the systems already in place. | | Measurement | Model accuracy: AUC, lift charts, calibration. | Incremental outcome against a randomised control. | | Failure mode | An accurate model nobody acts on. | A wrong hypothesis, retired cheaply and on purpose. | ## Diagnose your own predictive programme For each model currently in production: - What decision does this score change, and who owns it? - Is the action attached to the score, or is it chosen manually each time? - Does the action account for the customer's value, or only their risk? - Can the action be launched automatically, or does it wait for a build cycle? - Was the last readout about model accuracy or about incremental revenue? - If the model were switched off tomorrow, what would visibly change? ## When prediction alone is the right stopping point - Forecasting and planning use cases, where the output is a number a human uses to make a plan. - Risk, fraud and credit decisions, where the score feeds a governed rules process by design and autonomy is not wanted. - Early-stage analytics work where the goal is understanding a driver rather than acting on it. - Situations where no action is available or affordable. Adding a decision layer over an empty action space changes nothing. ## FAQ **What is the difference between predictive analytics and growth decisioning?** Predictive analytics estimates what is likely to happen. Growth decisioning chooses what to do about it for each customer, applies eligibility and cost constraints, executes through existing systems, and measures the incremental result against a control. Prediction is an input to decisioning, and on its own it changes no outcome. **Do I still need models if I have a decision layer?** Yes. Scores are one of the inputs the decision uses to estimate expected value. The change is what happens after the score exists: it is attached to an action, a constraint set and a measurement, instead of being delivered as a list. **Why does model accuracy not predict business impact?** Because accuracy measures how well you identify who will churn, and impact depends on whether the action you took changed their behaviour. A perfectly accurate model paired with an action that does not work produces zero incremental revenue, and only a control group reveals that. ## Related - [Churn prediction versus retention decisioning](https://markin.ai/compare/churn-prediction-vs-retention-decisioning) — The same distinction in the retention case specifically. - [Controlled growth experiments](https://markin.ai/guides/controlled-growth-experiments) — How the action is proven once it exists. - [How Markin generates hypotheses](https://markin.ai/methodology/hypothesis-generation) — Where the candidate actions come from. - [Decision layer reference architecture](https://markin.ai/architecture/decision-layer-reference-architecture) — Where models sit relative to decisions. Source: https://markin.ai/guides/predictive-analytics-vs-growth-decisioning --- --- title: Markin + Snowflake url: https://markin.ai/integrations/snowflake category: Warehouses and lakes description: Connect Markin to Snowflake: read customer, revenue and event history in place, and write decisions and holdout assignments back as tables. --- # Markin + Snowflake > Read customer history in place, on your compute. **Job:** Scores every customer against the ARPU model on your own warehouse compute, nightly. The warehouse is where ARPU is actually measurable, so it is where the loop closes. Markin queries it directly rather than syncing a copy, which keeps governance, row-level security and cost controls where your data team already set them. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Snowflake - Customer and account dimensions - Order, subscription and payment history - Event tables and derived behavioural features - Existing marketing exposure logs ## What Markin writes back - Decision and holdout assignment tables in a schema you own - Outcome reads per experiment, joinable to your own reporting ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) - [Comparison](https://markin.ai/compare/data-warehouse-vs-cdp-vs-decision-layer) ## FAQ **How does Markin connect to Snowflake?** Attribute write-back, Read only. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Snowflake?** Customer and account dimensions; Order, subscription and payment history; Event tables and derived behavioural features; Existing marketing exposure logs. **What does Markin write back into Snowflake?** Decision and holdout assignment tables in a schema you own Outcome reads per experiment, joinable to your own reporting **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/snowflake --- --- title: Markin + BigQuery url: https://markin.ai/integrations/bigquery category: Warehouses and lakes description: Connect Markin to BigQuery: read behavioural and revenue history in place and write decisions, holdouts and causal reads back into your own dataset. --- # Markin + BigQuery > Signal and outcome reads without moving a row. **Job:** Builds the opportunity feed from event and revenue tables without exporting a single row. Most large B2C estates already land every event in BigQuery. Markin treats it as the source of truth for both the hypothesis and its verdict, so nothing has to be reconciled between two systems later. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from BigQuery - GA4 and product event exports - Transaction and subscription tables - Customer attributes and consent state ## What Markin writes back - Decision tables partitioned by date - Holdout membership and experiment reads ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) - [Comparison](https://markin.ai/compare/data-warehouse-vs-cdp-vs-decision-layer) ## FAQ **How does Markin connect to BigQuery?** Attribute write-back, Read only. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from BigQuery?** GA4 and product event exports; Transaction and subscription tables; Customer attributes and consent state. **What does Markin write back into BigQuery?** Decision tables partitioned by date Holdout membership and experiment reads **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/bigquery --- --- title: Markin + Databricks url: https://markin.ai/integrations/databricks category: Warehouses and lakes description: Connect Markin to Databricks: read lakehouse tables and feature stores, and write decisions and experiment reads back as Delta tables. --- # Markin + Databricks > Lakehouse tables and feature stores as first-class signal. **Job:** Runs propensity and uplift models next to the feature tables your team already maintains. Where a data science team already exists, Markin should extend it rather than duplicate it. Existing features and models become inputs to the hypothesis space instead of being rebuilt. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Databricks - Delta tables and Unity Catalog assets - Existing feature store definitions - Model outputs your team already produces ## What Markin writes back - Decision and holdout Delta tables - Per-experiment causal reads ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) - [Comparison](https://markin.ai/compare/markin-and-your-data-science-team) ## FAQ **How does Markin connect to Databricks?** Attribute write-back, Read only. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Databricks?** Delta tables and Unity Catalog assets; Existing feature store definitions; Model outputs your team already produces. **What does Markin write back into Databricks?** Decision and holdout Delta tables Per-experiment causal reads **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/databricks --- --- title: Markin + Amazon Redshift url: https://markin.ai/integrations/redshift category: Warehouses and lakes description: Connect Markin to Amazon Redshift: read customer and revenue history in place, and write decisions and holdout assignments back. --- # Markin + Amazon Redshift > Direct reads against the warehouse you already operate. **Job:** Reads order and subscription history in place to size each hypothesis. No migration is required for Markin to start. The connection is a read role plus a schema it can write to, which is a change your data team can review in an afternoon. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Amazon Redshift - Customer and revenue tables - Event and exposure history ## What Markin writes back - Decision tables - Experiment and holdout reads ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Amazon Redshift?** Attribute write-back, Read only. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Amazon Redshift?** Customer and revenue tables; Event and exposure history. **What does Markin write back into Amazon Redshift?** Decision tables Experiment and holdout reads **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/redshift --- --- title: Markin + Segment url: https://markin.ai/integrations/segment category: CDPs and activation pipelines description: Connect Markin to Segment: consume unified profiles and events, and write next-best-action decisions back as traits for existing destinations. --- # Markin + Segment > Identity and consent stay yours; decisions flow through. **Job:** Turns a decision into a computed trait your existing destinations already read. Segment resolves who the customer is. Markin decides what should happen to them. Writing the decision back as a trait means every destination you already configured inherits it without new plumbing. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Segment - Unified profiles and identity graph - Track and identify events - Consent state ## What Markin writes back - Computed traits carrying the chosen action and its reason - Decision events for downstream destinations ## Related - [Solution: next-best-action](https://markin.ai/solutions/next-best-action) - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) - [Comparison](https://markin.ai/compare/markin-and-segment-tealium) ## FAQ **How does Markin connect to Segment?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Segment?** Unified profiles and identity graph; Track and identify events; Consent state. **What does Markin write back into Segment?** Computed traits carrying the chosen action and its reason Decision events for downstream destinations **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/segment --- --- title: Markin + Hightouch url: https://markin.ai/integrations/hightouch category: CDPs and activation pipelines description: Connect Markin to Hightouch: Markin writes decision tables in the warehouse and your existing syncs activate them to every downstream tool. --- # Markin + Hightouch > Your activation pipeline moves the rows Markin produces. **Job:** Ships the decision table to every downstream tool your syncs already cover. There is no reason to replace a working reverse ETL pipeline. Markin supplies the decision; Hightouch keeps doing the delivery, retries and observability it already does well. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. ## What Markin reads from Hightouch - Sync history and destination mappings - Audience definitions already in use ## What Markin writes back - Warehouse decision tables that existing syncs pick up unchanged ## Related - [Solution: next-best-action](https://markin.ai/solutions/next-best-action) - [Comparison](https://markin.ai/compare/markin-and-hightouch) ## FAQ **How does Markin connect to Hightouch?** Attribute write-back. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Hightouch?** Sync history and destination mappings; Audience definitions already in use. **What does Markin write back into Hightouch?** Warehouse decision tables that existing syncs pick up unchanged **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/hightouch --- --- title: Markin + Tealium url: https://markin.ai/integrations/tealium category: CDPs and activation pipelines description: Connect Markin to Tealium: read real-time visitor profiles and write one committed decision per customer back into your connectors. --- # Markin + Tealium > Real-time profiles in, committed decisions out. **Job:** Writes the next best action as an audience attribute inside your existing badge logic. Tealium is strong at collecting and routing in real time. What it does not do is decide which of forty possible actions is worth the contact. Markin arbitrates before anything reaches a connector. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Tealium - Visitor profiles and badges - Real-time event streams ## What Markin writes back - Decision attributes - Trigger events for existing connectors ## Related - [Solution: next-best-action](https://markin.ai/solutions/next-best-action) - [Comparison](https://markin.ai/compare/markin-and-segment-tealium) ## FAQ **How does Markin connect to Tealium?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Tealium?** Visitor profiles and badges; Real-time event streams. **What does Markin write back into Tealium?** Decision attributes Trigger events for existing connectors **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/tealium --- --- title: Markin + Census url: https://markin.ai/integrations/census category: CDPs and activation pipelines description: Connect Markin to Census: Markin writes decisions to the warehouse and your existing Census syncs activate them downstream. --- # Markin + Census > Decision tables synced by the pipeline you already trust. **Job:** Syncs Markin's decision table to the channels without new pipeline work. The integration surface is a table, not an API contract. That keeps the connection reversible: turn the sync off and the estate is exactly as it was. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. ## What Markin reads from Census - Sync definitions and field mappings ## What Markin writes back - Warehouse decision tables consumed by existing syncs ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) ## FAQ **How does Markin connect to Census?** Attribute write-back. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Census?** Sync definitions and field mappings. **What does Markin write back into Census?** Warehouse decision tables consumed by existing syncs **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/census --- --- title: Markin + RudderStack url: https://markin.ai/integrations/rudderstack category: CDPs and activation pipelines description: Connect Markin to RudderStack: consume warehouse-native event streams and write decisions back for downstream activation. --- # Markin + RudderStack > Warehouse-native events in, decisions back out. **Job:** Emits the decision as an event your existing routing already fans out. For teams that keep the warehouse as the system of record, Markin fits the same shape: it reads where the data already is and writes decisions to the same place. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from RudderStack - Event streams and warehouse-native profiles ## What Markin writes back - Decision traits and trigger events ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) ## FAQ **How does Markin connect to RudderStack?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from RudderStack?** Event streams and warehouse-native profiles. **What does Markin write back into RudderStack?** Decision traits and trigger events **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/rudderstack --- --- title: Markin + Braze url: https://markin.ai/integrations/braze category: Engagement and CRM description: Connect Markin to Braze: write next-best-action decisions as custom attributes or trigger events, with frequency, consent and quiet hours still enforced by Braze. --- # Markin + Braze > Braze keeps the channel. Markin decides what deserves to be sent. **Job:** Decides which of forty possible messages a customer deserves this week, then hands Braze the one that wins. Braze executes exceptionally well within the set of campaigns someone wrote. Markin widens that set: it proposes actions nobody has written yet, sizes them, and lets Braze do what it is best at once the decision exists. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Braze - Delivery, open, click and conversion events - Campaign and canvas exposure history - Subscription and channel eligibility state ## What Markin writes back - Custom attributes carrying the chosen action, reason and expiry - Trigger events that start or advance a Canvas ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) - [Comparison](https://markin.ai/compare/markin-and-braze) ## FAQ **How does Markin connect to Braze?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Braze?** Delivery, open, click and conversion events; Campaign and canvas exposure history; Subscription and channel eligibility state. **What does Markin write back into Braze?** Custom attributes carrying the chosen action, reason and expiry Trigger events that start or advance a Canvas **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/braze --- --- title: Markin + Salesforce Marketing Cloud url: https://markin.ai/integrations/salesforce-marketing-cloud category: Engagement and CRM description: Connect Markin to Salesforce Marketing Cloud: decisions land in data extensions and existing journeys read them as entry criteria. --- # Markin + Salesforce Marketing Cloud > Data extensions receive the decision; journeys stay untouched. **Job:** Fills the journey entry attribute so your existing programmes select the right customers. Rebuilding an SFMC estate is a multi-year project nobody wants. Writing into a data extension means the decision layer arrives without any journey being rewritten. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Salesforce Marketing Cloud - Journey exposure and send logs - Contact and subscriber attributes ## What Markin writes back - Rows in a dedicated data extension - API events that trigger journeys ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) - [Comparison](https://markin.ai/compare/markin-and-salesforce) ## FAQ **How does Markin connect to Salesforce Marketing Cloud?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Salesforce Marketing Cloud?** Journey exposure and send logs; Contact and subscriber attributes. **What does Markin write back into Salesforce Marketing Cloud?** Rows in a dedicated data extension API events that trigger journeys **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/salesforce-marketing-cloud --- --- title: Markin + Adobe Journey Optimizer url: https://markin.ai/integrations/adobe-journey-optimizer category: Engagement and CRM description: Connect Markin to Adobe Journey Optimizer: write decisions into Experience Platform profiles and trigger journeys with a reason attached. --- # Markin + Adobe Journey Optimizer > Profile attributes and events into the Adobe estate. **Job:** Supplies the offer and the reason; AJO keeps the orchestration and the consent veto. Adobe's own decisioning ranks offers you have configured. Markin decides whether an offer should exist at all, and proves the answer against a holdout before it scales. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Adobe Journey Optimizer - Experience Platform profile attributes - Journey step events ## What Markin writes back - Profile attributes with the committed action - Journey trigger events ## Related - [Solution: next-best-action](https://markin.ai/solutions/next-best-action) - [Comparison](https://markin.ai/compare/markin-and-adobe) ## FAQ **How does Markin connect to Adobe Journey Optimizer?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Adobe Journey Optimizer?** Experience Platform profile attributes; Journey step events. **What does Markin write back into Adobe Journey Optimizer?** Profile attributes with the committed action Journey trigger events **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/adobe-journey-optimizer --- --- title: Markin + HubSpot url: https://markin.ai/integrations/hubspot category: Engagement and CRM description: Connect Markin to HubSpot: write next-best-action decisions to contact properties and let existing workflows execute them. --- # Markin + HubSpot > Contact properties that drive existing workflows. **Job:** Puts the expansion play and its expected value on the record the rep is already looking at. Small integration surface, immediate effect: a property change is all an existing workflow needs to start doing something better than it did yesterday. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from HubSpot - Contact and deal properties - Email engagement history ## What Markin writes back - Contact properties with the action and its reason - Custom events for workflow enrolment ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) ## FAQ **How does Markin connect to HubSpot?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from HubSpot?** Contact and deal properties; Email engagement history. **What does Markin write back into HubSpot?** Contact properties with the action and its reason Custom events for workflow enrolment **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/hubspot --- --- title: Markin + Klaviyo url: https://markin.ai/integrations/klaviyo category: Engagement and CRM description: Connect Markin to Klaviyo: write decisions as profile properties or events so existing flows and segments execute them. --- # Markin + Klaviyo > Profile properties and events for commerce lifecycle. **Job:** Replaces send-to-everyone flows with a per-customer decision and a live holdout. Commerce lifecycle programmes usually run out of ideas before they run out of capacity. Markin supplies the next hypothesis and reads whether it was actually incremental. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Klaviyo - Profile properties and list membership - Flow and campaign engagement ## What Markin writes back - Profile properties carrying the chosen action - Events that trigger flows ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) ## FAQ **How does Markin connect to Klaviyo?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Klaviyo?** Profile properties and list membership; Flow and campaign engagement. **What does Markin write back into Klaviyo?** Profile properties carrying the chosen action Events that trigger flows **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/klaviyo --- --- title: Markin + Iterable url: https://markin.ai/integrations/iterable category: Engagement and CRM description: Connect Markin to Iterable: write decisions as user fields or custom events so existing journeys pick them up unchanged. --- # Markin + Iterable > Decisions as user fields and custom events. **Job:** Chooses the action per customer; Iterable keeps frequency caps and quiet hours. Frequency caps, quiet hours and consent stay enforced by Iterable. Markin only supplies intent, which is what makes the connection safe to switch on incrementally. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Iterable - User fields and channel preferences - Send and engagement events ## What Markin writes back - User fields with the committed action - Custom events for journey entry ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) ## FAQ **How does Markin connect to Iterable?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Iterable?** User fields and channel preferences; Send and engagement events. **What does Markin write back into Iterable?** User fields with the committed action Custom events for journey entry **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/iterable --- --- title: Markin + Customer.io url: https://markin.ai/integrations/customer-io category: Engagement and CRM description: Connect Markin to Customer.io: write decision attributes and trigger events into the campaigns you already run. --- # Markin + Customer.io > Attributes and events into existing campaigns. **Job:** Triggers the journey only for customers where the model says it pays. The fastest path from decision to revenue is usually a campaign that already exists and only needs a better audience and a better reason to fire. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Customer.io - Person attributes and segment membership - Delivery and conversion metrics ## What Markin writes back - Person attributes with the action and expiry - Trigger events ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) ## FAQ **How does Markin connect to Customer.io?** Attribute write-back, Triggered event. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Customer.io?** Person attributes and segment membership; Delivery and conversion metrics. **What does Markin write back into Customer.io?** Person attributes with the action and expiry Trigger events **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/customer-io --- --- title: Markin + Twilio url: https://markin.ai/integrations/twilio category: Engagement and CRM description: Connect Markin to Twilio: SMS and WhatsApp decisions arbitrated against every other channel before a single message is sent. --- # Markin + Twilio > SMS and WhatsApp as an arbitrated surface. **Job:** Reserves the expensive channel for the cases where the expected value covers the cost. Messaging is the channel where over-contact costs the most. Arbitration before send is worth more here than anywhere else, and holding is treated as a valid decision. ## Activation patterns - **Decision API.** The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Twilio - Delivery receipts and reply events - Opt-in and opt-out state ## What Markin writes back - Send instructions with the chosen action, or an explicit hold ## Related - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) ## FAQ **How does Markin connect to Twilio?** Decision API, Triggered event. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. **What does Markin read from Twilio?** Delivery receipts and reply events; Opt-in and opt-out state. **What does Markin write back into Twilio?** Send instructions with the chosen action, or an explicit hold **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/twilio --- --- title: Markin + Amplitude url: https://markin.ai/integrations/amplitude category: Product analytics and events description: Connect Markin to Amplitude: read behavioural cohorts and session events, and turn product friction into sized, testable hypotheses. --- # Markin + Amplitude > Behavioural signal in, hypotheses out. **Job:** Turns a behavioural anomaly into a sized, testable hypothesis within the day. Product analytics is very good at showing that something is wrong and silent about what to do next. Markin reads the same events and produces a ranked, sized queue of actions instead of a chart. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. ## What Markin reads from Amplitude - Event streams and cohort definitions - Funnel and retention curves ## What Markin writes back - Cohort membership reflecting Markin decisions, for your own analysis ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) - [Comparison](https://markin.ai/compare/markin-and-amplitude) ## FAQ **How does Markin connect to Amplitude?** Read only, Attribute write-back. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from Amplitude?** Event streams and cohort definitions; Funnel and retention curves. **What does Markin write back into Amplitude?** Cohort membership reflecting Markin decisions, for your own analysis **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/amplitude --- --- title: Markin + Mixpanel url: https://markin.ai/integrations/mixpanel category: Product analytics and events description: Connect Markin to Mixpanel: read session-level product events so friction and drop-off become sized revenue hypotheses. --- # Markin + Mixpanel > Session-level events as raw material for hypotheses. **Job:** Detects the funnel step where revenue is leaking and proposes what to change. Every unexplained drop in a funnel is a hypothesis waiting to be written. Markin writes it, sizes it, and puts it in the same queue as any marketing idea. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Mixpanel - Event and profile data - Funnel definitions already maintained ## What Markin writes back - Nothing. This system is a source of signal, not an executor. ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Mixpanel?** Read only. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from Mixpanel?** Event and profile data; Funnel definitions already maintained. **What does Markin write back into Mixpanel?** Nothing. This system is a source of signal, not an executor. **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/mixpanel --- --- title: Markin + Web and mobile SDK url: https://markin.ai/integrations/web-and-mobile-sdk category: Product analytics and events description: Use the Markin SDK to request an in-session decision for a paywall, home screen or offer slot, with a defined fallback and latency budget. --- # Markin + Web and mobile SDK > In-session decisions rendered into your own surfaces. **Job:** Answers the in-session decision call in milliseconds, with a defined fallback. Some surfaces cannot wait for a sync interval. A paywall or home screen slot asks at render time and gets one answer, and the surface always renders even when Markin does not answer. ## Activation patterns - **Decision API.** The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. - **Direct surface.** Markin populates a slot in the product or message body directly, for placements where round-tripping through a channel adds nothing. ## What Markin reads from Web and mobile SDK - Session context passed at request time ## What Markin writes back - One action plus its reason, per request, with a fallback default ## Related - [Solution: next-best-action](https://markin.ai/solutions/next-best-action) ## FAQ **How does Markin connect to Web and mobile SDK?** Decision API, Direct surface. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. **What does Markin read from Web and mobile SDK?** Session context passed at request time. **What does Markin write back into Web and mobile SDK?** One action plus its reason, per request, with a fallback default **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/web-and-mobile-sdk --- --- title: Markin + Stripe url: https://markin.ai/integrations/stripe category: Commerce, billing and subscriptions description: Connect Markin to Stripe: read subscriptions, invoices and dunning outcomes so every decision is measured in revenue, not clicks. --- # Markin + Stripe > Billing truth: the number every hypothesis is read against. **Job:** Reads payment and dunning ground truth so every read is against revenue, not clicks. Involuntary churn is often the largest recoverable ARPU line in a subscription business and the least optimised. Payment retry timing is a decision like any other, and it is unusually easy to prove. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Stripe - Subscriptions, plans and upgrades - Invoices, failed payments and dunning outcomes - Refunds and cancellations ## What Markin writes back - Optional dunning-timing decisions emitted as events ## Related - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Stripe?** Read only, Triggered event. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from Stripe?** Subscriptions, plans and upgrades; Invoices, failed payments and dunning outcomes; Refunds and cancellations. **What does Markin write back into Stripe?** Optional dunning-timing decisions emitted as events **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/stripe --- --- title: Markin + Shopify url: https://markin.ai/integrations/shopify category: Commerce, billing and subscriptions description: Connect Markin to Shopify: read orders, catalogue and margin so cross-sell decisions optimise contribution, not just conversion. --- # Markin + Shopify > Orders, catalogue and margin as decision inputs. **Job:** Decides the cross-sell that does not cannibalise the order the customer would have placed anyway. Optimising for conversion alone reliably grows unprofitable orders. With margin in the input, Markin can decline a discount that would have converted and still lost money. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Shopify - Order and refund history - Catalogue, price and margin - Cart and checkout events ## What Markin writes back - Decision events for downstream lifecycle tools ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Shopify?** Read only, Triggered event. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from Shopify?** Order and refund history; Catalogue, price and margin; Cart and checkout events. **What does Markin write back into Shopify?** Decision events for downstream lifecycle tools **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/shopify --- --- title: Markin + Recurly url: https://markin.ai/integrations/recurly category: Commerce, billing and subscriptions description: Connect Markin to Recurly: read subscription state and dunning outcomes to target voluntary and involuntary churn separately. --- # Markin + Recurly > Subscription lifecycle and involuntary churn signal. **Job:** Times the plan-change offer against real renewal and churn dates. Voluntary and involuntary churn need different interventions and are usually reported as one number. Separating them is often worth more than any new model. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Recurly - Subscription state changes - Dunning and payment recovery outcomes ## What Markin writes back - Retry and save-offer timing decisions ## Related - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) ## FAQ **How does Markin connect to Recurly?** Read only, Triggered event. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from Recurly?** Subscription state changes; Dunning and payment recovery outcomes. **What does Markin write back into Recurly?** Retry and save-offer timing decisions **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/recurly --- --- title: Markin + SAP and ERP systems url: https://markin.ai/integrations/sap-and-erp category: Commerce, billing and subscriptions description: Connect Markin to SAP or your ERP: bring cost, inventory and contract constraints into the decision so offers stay profitable and deliverable. --- # Markin + SAP and ERP systems > Cost, inventory and contract truth behind every offer. **Job:** Grounds every hypothesis in billed revenue rather than in tracked events. A decision layer without cost data optimises revenue and quietly destroys margin. The ERP is what stops that, and it is the input most decisioning tools never see. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from SAP and ERP systems - Cost and margin by product - Inventory and fulfilment constraints - Contract and entitlement data ## What Markin writes back - Nothing. This system is a source of signal, not an executor. ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to SAP and ERP systems?** Read only. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from SAP and ERP systems?** Cost and margin by product; Inventory and fulfilment constraints; Contract and entitlement data. **What does Markin write back into SAP and ERP systems?** Nothing. This system is a source of signal, not an executor. **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/sap-and-erp --- --- title: Markin + Zendesk url: https://markin.ai/integrations/zendesk category: Support and contact centre description: Connect Markin to Zendesk: surface the next best action inside the agent view and read ticket signal as an early churn indicator. --- # Markin + Zendesk > Next best action on the agent's screen, with its reason. **Job:** Puts the next best action, and its reason, on the agent's screen mid-ticket. A service contact is the highest-attention moment a customer gives you all year. Deciding what to do with it deserves the same rigour as a campaign, and it is measurable per agent. ## Activation patterns - **Decision API.** The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Zendesk - Ticket volume, reason codes and CSAT - Contact history per customer ## What Markin writes back - One suggested action per contact, shown in the agent view with its reason ## Related - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) ## FAQ **How does Markin connect to Zendesk?** Decision API, Read only. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. **What does Markin read from Zendesk?** Ticket volume, reason codes and CSAT; Contact history per customer. **What does Markin write back into Zendesk?** One suggested action per contact, shown in the agent view with its reason **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/zendesk --- --- title: Markin + Salesforce Service Cloud url: https://markin.ai/integrations/salesforce-service-cloud category: Support and contact centre description: Connect Markin to Salesforce Service Cloud: put retention and expansion decisions in the case view, with holdouts intact. --- # Markin + Salesforce Service Cloud > Retention and expansion decisions in the case view. **Job:** Turns a service contact into a sized retention or expansion moment. Agents are given scripts, not decisions. Giving them one ranked action with the reason attached is both easier to follow and, unlike a script, measurable against a control group. ## Activation patterns - **Decision API.** The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Salesforce Service Cloud - Case history and resolution outcomes - Account and entitlement data ## What Markin writes back - A single recommended action per case, with reason and expected value ## Related - [Solution: churn-prevention](https://markin.ai/solutions/churn-prevention) - [Comparison](https://markin.ai/compare/markin-and-salesforce) ## FAQ **How does Markin connect to Salesforce Service Cloud?** Decision API, Read only. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. **What does Markin read from Salesforce Service Cloud?** Case history and resolution outcomes; Account and entitlement data. **What does Markin write back into Salesforce Service Cloud?** A single recommended action per case, with reason and expected value **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/salesforce-service-cloud --- --- title: Markin + Intercom url: https://markin.ai/integrations/intercom category: Support and contact centre description: Connect Markin to Intercom: trigger in-app conversations only when the expected value clears the bar, and read the outcome back. --- # Markin + Intercom > In-app conversations as a decision surface. **Job:** Chooses whether a conversation deserves an offer, a fix or nothing at all. In-app messaging is cheap to send and expensive in attention. Arbitration keeps the surface useful instead of exhausting it. ## Activation patterns - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. ## What Markin reads from Intercom - Conversation history and resolution outcomes - User attributes ## What Markin writes back - Attributes and events that trigger targeted conversations ## Related - [Solution: lifecycle-automation](https://markin.ai/solutions/lifecycle-automation) ## FAQ **How does Markin connect to Intercom?** Triggered event, Attribute write-back. Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. **What does Markin read from Intercom?** Conversation history and resolution outcomes; User attributes. **What does Markin write back into Intercom?** Attributes and events that trigger targeted conversations **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/intercom --- --- title: Markin + Google Ads url: https://markin.ai/integrations/google-ads category: Paid media and audiences description: Connect Markin to Google Ads: push value-based audiences and suppression lists driven by incremental value, not list membership. --- # Markin + Google Ads > Suppress the spend that would have converted anyway. **Job:** Suppresses spend on customers who would have converted anyway. Paid retargeting of customers who would have returned anyway is one of the largest measurable wastes in B2C. Suppression driven by uplift, not propensity, is usually the fastest win in the whole estate. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. ## What Markin reads from Google Ads - Campaign spend and conversion exports ## What Markin writes back - Customer Match audiences for expansion - Suppression audiences for customers who need no paid contact ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Google Ads?** Attribute write-back. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Google Ads?** Campaign spend and conversion exports. **What does Markin write back into Google Ads?** Customer Match audiences for expansion Suppression audiences for customers who need no paid contact **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/google-ads --- --- title: Markin + Meta Ads url: https://markin.ai/integrations/meta-ads category: Paid media and audiences description: Connect Markin to Meta Ads: build custom audiences from expected incremental value and suppress spend that adds nothing. --- # Markin + Meta Ads > Audiences sized by expected incremental value. **Job:** Builds expansion audiences sized by expected value, not by list membership. An audience is a decision about who is worth reaching. Making it from uplift rather than from a lookalike changes the economics of the same budget. ## Activation patterns - **Attribute write-back.** Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. ## What Markin reads from Meta Ads - Ad exposure and conversion exports ## What Markin writes back - Custom audiences for expansion and suppression ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Meta Ads?** Attribute write-back. Markin writes the decision onto the customer profile; your existing journeys read it as an entry condition. Latency is the platform's sync interval. **What does Markin read from Meta Ads?** Ad exposure and conversion exports. **What does Markin write back into Meta Ads?** Custom audiences for expansion and suppression **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/meta-ads --- --- title: Markin + Optimizely url: https://markin.ai/integrations/optimizely category: Experimentation and feature flags description: Connect Markin to Optimizely: Markin proposes and sizes product hypotheses, Optimizely executes them, and impact is read in revenue. --- # Markin + Optimizely > Product-side hypotheses executed as flags, read as revenue. **Job:** Proposes product-side hypotheses and reads them on the same evidence bar as messaging. Experimentation platforms answer the question you brought them. Markin's job is to produce a continuous supply of questions worth asking, and to keep the ones that pay. ## Activation patterns - **Decision API.** The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. - **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance. ## What Markin reads from Optimizely - Experiment definitions and assignment logs - Feature flag exposure ## What Markin writes back - Proposed variants with expected value - Targeting decisions per user ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) - [Comparison](https://markin.ai/compare/markin-and-optimizely) ## FAQ **How does Markin connect to Optimizely?** Decision API, Triggered event. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. **What does Markin read from Optimizely?** Experiment definitions and assignment logs; Feature flag exposure. **What does Markin write back into Optimizely?** Proposed variants with expected value Targeting decisions per user **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/optimizely --- --- title: Markin + LaunchDarkly url: https://markin.ai/integrations/launchdarkly category: Experimentation and feature flags description: Connect Markin to LaunchDarkly: execute growth hypotheses through feature flags and read each one against a holdout. --- # Markin + LaunchDarkly > Feature flags as an execution channel for growth hypotheses. **Job:** Rolls a product change to the segment where the model says it pays, and reads it. Some of the largest ARPU changes are product changes, not messages. Treating a flag as a channel puts them in the same queue and under the same measurement discipline. ## Activation patterns - **Decision API.** The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. ## What Markin reads from LaunchDarkly - Flag definitions and exposure logs ## What Markin writes back - Per-user targeting decisions with holdouts preserved ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to LaunchDarkly?** Decision API. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. **What does Markin read from LaunchDarkly?** Flag definitions and exposure logs. **What does Markin write back into LaunchDarkly?** Per-user targeting decisions with holdouts preserved **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/launchdarkly --- --- title: Markin + Google Analytics 4 url: https://markin.ai/integrations/ga4 category: Product analytics and events description: Connect Markin to GA4: read web behaviour exports so drift in a segment is detected the week it starts, not the quarter it ends. --- # Markin + Google Analytics 4 > Web behaviour as an early signal of revenue drift. **Job:** Cross-checks the site-side read against the warehouse before a result is trusted. GA4 shows aggregate movement. Markin joins it to the revenue base and works out which segment moved, how much it is worth, and whether it is worth intervening. ## Activation patterns - **Read only.** Markin reads signal from this system. Nothing is written back and no schema is changed. ## What Markin reads from Google Analytics 4 - BigQuery event exports - Channel and campaign attribution ## What Markin writes back - Nothing. This system is a source of signal, not an executor. ## Related - [Solution: revenue-expansion](https://markin.ai/solutions/revenue-expansion) ## FAQ **How does Markin connect to Google Analytics 4?** Read only. Markin reads signal from this system. Nothing is written back and no schema is changed. **What does Markin read from Google Analytics 4?** BigQuery event exports; Channel and campaign attribution. **What does Markin write back into Google Analytics 4?** Nothing. This system is a source of signal, not an executor. **Do we have to move our data to Markin?** No. Markin reads from your warehouse, product events and operational systems in place, on your compute, under the access rules your data team already set. Nothing is copied into a separate customer base and there is no vendor-side profile store to migrate off later. **Does Markin replace our engagement platform or CDP?** No, and it should not. Your engagement platform keeps the channel, the templates, the deliverability and the governance. Your CDP keeps identity and consent. Markin adds the layer neither has: deciding which action deserves to exist for each customer, and proving it against a holdout. **What if the system we use is not listed?** The four activation patterns cover almost everything: attribute write-back, triggered event, decision API and direct surface rendering. Any system that exposes an API, accepts a table, or can read a warehouse column can receive decisions. New connectors are built during deployment, typically in days. Source: https://markin.ai/integrations/ga4 --- --- title: Customer decisioning vs. a CDP url: https://markin.ai/compare/customer-decisioning-vs-cdp kind: category description: A CDP unifies customer data. Customer decisioning chooses which revenue opportunity is worth acting on. What each layer owns, and where they meet. --- # Customer decisioning vs. a CDP > 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 each layer is **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. Answers: Who is this customer and what do we know about them? **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. Answers: Which opportunity is worth acting on, for whom, and how? ## Side by side | | 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. | ## 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. ## Where Markin fits 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. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - 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. ## FAQ **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. Source: https://markin.ai/compare/customer-decisioning-vs-cdp --- --- title: Customer decisioning vs. a customer engagement platform url: https://markin.ai/compare/customer-decisioning-vs-customer-engagement-platform kind: category description: Engagement platforms execute journeys. Customer decisioning chooses which opportunity deserves a message at all. How the two layers divide the work. --- # Customer decisioning vs. a customer engagement platform > A customer engagement platform builds and delivers journeys, campaigns and messages across channels. Customer decisioning decides which commercial opportunity justifies contact in the first place, ranks it against every other option for that customer, and holds when no treatment has positive expected value. One executes, the other prioritises. ## What each layer is **Customer engagement platform** — A system for designing, orchestrating and delivering messages and journeys across email, push, in-app, SMS and web, with templating, scheduling and delivery reporting. Answers: How do we deliver this message, to this audience, on these channels? **Customer decisioning** — A layer that ranks commercial opportunities per customer, selects the treatment with the highest expected incremental value, and decides when not to act. Answers: Is there an opportunity here worth acting on, and which treatment wins? ## Side by side | | Customer engagement platform | Customer decisioning | | --- | --- | --- | | Question it answers | How do we deliver this message, to this audience, on these channels? | Is there an opportunity here worth acting on, and which treatment wins? | | Primary input | Audiences, templates, journey logic, channel credentials. | Customer context, outcomes, contact history, costs and constraints. | | Primary output | Delivered messages, journey state, engagement reporting. | A ranked decision per customer, with expected value and a control group. | | Usual owner | CRM and lifecycle marketing. | Growth and data science. | | How it's measured | Deliverability, open and click rate, campaign conversion. | Incremental revenue, ARPU and margin against holdout. | ## What an engagement platform still leaves open Journey builders are extremely good at execution and have no view of opportunity cost. Every journey competes for the same inbox, and the platform cannot tell you which of them should have won. - Journeys are authored by hand, so the number of decisions you can run is capped by team capacity, not by opportunity. - Contact pressure is managed with frequency caps rather than by comparing the expected value of competing messages. - Engagement metrics reward sending. Nothing in the platform argues for silence, even when silence is worth more. - Personalisation chooses the content of a message; it does not choose whether the message should exist. ## Where Markin fits Markin sits upstream of the engagement platform. It decides what deserves contact and hands the chosen treatment to the channel your team already runs, so existing journeys become the execution surface for far better decisions. - **Fewer, better contacts.** Competing opportunities are ranked on expected value per customer, so contact pressure drops while revenue per contact rises. - **Hold is a first-class decision.** When no treatment beats doing nothing, Markin holds and records why. That decision is auditable, like every other one. - **Your journeys keep working.** No migration. The engagement platform stays the delivery layer; only the input to it changes. Next: [Next-Best Action](https://markin.ai/solutions/next-best-action) ## When Markin is not the right answer - You have very low contact volume and one obvious message per lifecycle stage: manual journeys are sufficient. - Your bottleneck is deliverability or channel coverage, not decision quality. - You have no way to hold out a control group, which makes incrementality impossible to prove. ## FAQ **Do we have to replace our engagement platform?** No. Markin does not send messages. It chooses which opportunity to act on and passes the decision to your existing platform, which keeps owning delivery, templating and channel logic. **Isn't this what journey orchestration already does?** Orchestration sequences steps someone designed. Decisioning generates and ranks the candidates in the first place, including the option of doing nothing, and validates each one against control. **How does this affect contact frequency?** It usually reduces it. When messages compete on expected incremental value rather than on campaign calendar slots, low-value contacts stop being sent. **How is Markin different from the decisioning or AI already inside customer engagement 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 engagement 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 engagement 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. Source: https://markin.ai/compare/customer-decisioning-vs-customer-engagement-platform --- --- title: Next-best action vs. next-best opportunity url: https://markin.ai/compare/next-best-action-vs-next-best-opportunity kind: category description: Next-best opportunity sizes what is at stake for a customer. Next-best action chooses the treatment. Why the order matters and how the two connect. --- # Next-best action vs. next-best opportunity > Next-best opportunity identifies and sizes what is commercially at stake for a customer: an upgrade, a retention risk, an attach, a reactivation. Next-best action selects the specific treatment for that opportunity: the message, offer, channel and timing. Opportunity comes first; without it, action selection optimises the wrong thing efficiently. ## What each layer is **Next-best opportunity** — The commercial situation worth addressing for a customer, expressed with an estimated revenue value and a confidence level. Answers: What is at stake for this customer right now, and how much is it worth? **Next-best action** — The treatment selected to address an opportunity: which message, offer, channel and moment maximise expected incremental value. Answers: Given the opportunity, which treatment moves it, for this person? ## Side by side | | Next-best opportunity | Next-best action | | --- | --- | --- | | Question it answers | What is at stake for this customer right now, and how much is it worth? | Given the opportunity, which treatment moves it, for this person? | | Primary input | Behaviour, holdings, lifecycle position, outcome history. | Candidate treatments, uplift models, costs, eligibility and contact constraints. | | Primary output | A ranked, sized set of opportunities per customer and per cohort. | One chosen action per customer, or a deliberate hold. | | Usual owner | Growth and data science. | Growth, lifecycle, data science. | | How it's measured | Realised revenue against the sized estimate. | Incremental conversion and revenue against control. | ## Why action-only programmes plateau Most next-best action deployments start from a fixed list of offers and rank them per customer. That is treatment selection on a menu someone wrote last quarter, and it caps upside at the quality of that menu. - A ranked offer list cannot surface an opportunity nobody thought to model. - Uplift is optimised within the candidate set, so a large unaddressed opportunity stays invisible. - Without a sized opportunity behind it, an action has no revenue estimate, only a propensity score. - Teams end up over-serving the easy opportunities and never discovering the expensive ones. ## Where Markin fits Markin runs both steps and keeps them separate. The intelligence layer discovers and sizes opportunities across the whole base, then treatment selection picks the action, and both are measured against control so the loop actually learns. - **Opportunity discovery is continuous.** New hypotheses are generated and sized as behaviour changes, instead of being fixed at programme design time. - **Treatment selection is per person.** Message, channel, timing and offer are chosen for the individual, with the option to hold when nothing has positive expected value. - **Both layers report in revenue.** Sizing predicts, execution proves, and the difference is fed back into the next round of hypotheses. Next: [Next-Best Action](https://markin.ai/solutions/next-best-action) ## When Markin is not the right answer - You have a single product and one possible treatment: there is no selection problem to solve. - Your data cannot connect a treatment to an outcome, so neither layer can be validated. - You need a rules engine to enforce a regulatory sequence, which is a compliance requirement, not an optimisation one. ## FAQ **Is next-best opportunity just a renamed propensity score?** No. A propensity score estimates the likelihood of an event. An opportunity attaches a revenue value, a population and a confidence level to a commercial situation, which is what makes it rankable against other uses of the same contact. **Which one should we build first?** Opportunity. Action selection on top of a poorly chosen opportunity set produces efficient waste. Once opportunities are sized, treatment selection has something worth optimising. **Can the two run in one system?** They should. When sizing and treatment selection share the same experiment record, the estimate improves every cycle instead of drifting from reality. **How is Markin different from the decisioning or AI already inside next-best opportunity?** 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 next-best opportunity 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 next-best opportunity?** 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. Source: https://markin.ai/compare/next-best-action-vs-next-best-opportunity --- --- title: Churn prediction vs. retention decisioning url: https://markin.ai/compare/churn-prediction-vs-retention-decisioning kind: category description: A churn model tells you who is at risk. Retention decisioning chooses who to save, with what, and at what cost. Why prediction alone rarely moves retention. --- # Churn prediction vs. retention decisioning > Churn prediction estimates the probability that a customer leaves. Retention decisioning uses that estimate plus expected uplift, margin and cost to decide who to intervene with, which treatment to use and who to leave alone. Risk is an input; the decision is what changes revenue, and only the decision can be measured against control. ## What each layer is **Churn prediction** — A model that scores each customer on the likelihood of cancelling, lapsing or not renewing within a horizon. Answers: Who is likely to leave? **Retention decisioning** — A layer that converts risk into an intervention decision by modelling incremental save probability, margin impact and cost per customer. Answers: Who is worth saving, with what, and who should we leave alone? ## Side by side | | Churn prediction | Retention decisioning | | --- | --- | --- | | Question it answers | Who is likely to leave? | Who is worth saving, with what, and who should we leave alone? | | Primary input | Usage, tenure, service events, payment and engagement history. | Risk, uplift models, offer costs, margin, contact history, constraints. | | Primary output | A risk score and a risk-ranked list. | An intervention decision per customer, including deliberate no-contact. | | Usual owner | Data science, analytics. | Growth, retention, finance. | | How it's measured | AUC, precision and recall of the model. | Incremental retained revenue and margin against control. | ## Why an accurate churn model can lose money A perfect risk score still says nothing about whether an intervention helps. Treat the highest-risk decile with a discount and a large share of the spend lands on customers who were leaving anyway, or on customers who would have stayed without the discount. - High risk is not the same as high savability: some at-risk customers are unreachable at any sensible cost. - Discounting customers who would have stayed converts margin into a giveaway and looks like a saved customer in the report. - Cost per save is rarely modelled, so retention programmes are judged on retention rate rather than retained margin. - Risk scoring can even raise churn when the intervention itself reminds a passive customer that cancelling is an option. ## Where Markin fits Markin models incremental save probability rather than risk alone, prices each treatment against the margin it protects, and holds where intervention has negative expected value. Retention becomes a budget allocation problem with an auditable answer. - **Uplift, not risk ranking.** Customers are selected on how much the intervention changes their outcome, which is a different population from the highest-risk decile. - **Cost-aware treatment choice.** The cheapest treatment that achieves the save is preferred, and discounts are reserved for the cases that need them. - **Deliberate non-contact.** Sleeping-dog segments are identified and excluded, which is often the single largest margin gain in a retention programme. Next: [Retention Decisioning](https://markin.ai/solutions/retention-decisioning) ## When Markin is not the right answer - You have no churn model and no outcome history yet: build prediction and measurement first. - Retention is contractually fixed for the period, so no intervention can change the outcome. - Your only available treatment is a single fixed discount with no room to vary cost or channel. ## FAQ **Do we still need a churn model?** Yes. Risk remains an input. Retention decisioning adds the layer above it: expected uplift, cost and margin, which is where the money is actually won or lost. **What is a sleeping-dog segment?** Customers whose probability of leaving increases when you contact them about staying. Uplift modelling identifies them so they can be excluded, which pure risk ranking cannot do. **How is retention impact measured properly?** Against a holdout of comparable at-risk customers who receive no intervention, reported as incremental retained margin rather than retention rate. **How is Markin different from the decisioning or AI already inside churn prediction?** 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 churn prediction 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 churn prediction?** On the assumptions preloaded above, 2.0M customers at 19 a month, 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. Source: https://markin.ai/compare/churn-prediction-vs-retention-decisioning --- --- title: Customer 360 vs. a decision system url: https://markin.ai/compare/customer-360-vs-decision-system kind: category description: A customer 360 shows everything you know about a customer. A decision system turns that into a ranked commercial action. Where visibility stops paying off. --- # Customer 360 vs. a decision system > A customer 360 assembles every known attribute, interaction and transaction into one view. A decision system consumes that view and produces a ranked, sized commercial decision per customer, with an expected value and a control group. Visibility is a prerequisite; on its own it does not change revenue, because nothing in it chooses. ## What each layer is **Customer 360** — A consolidated view of a customer across systems: profile, history, interactions, holdings, service events and consent. Answers: What do we know about this customer? **Decision system** — A layer that converts customer context into a ranked commercial decision, with an expected value, a treatment and an experiment attached. Answers: What should we do about this customer, and what is it worth? ## Side by side | | Customer 360 | Decision system | | --- | --- | --- | | Question it answers | What do we know about this customer? | What should we do about this customer, and what is it worth? | | Primary input | Source systems, integrations, identity resolution. | The 360 view, outcomes, costs, constraints and experiment history. | | Primary output | A single readable view, dashboards and traits. | A prioritised decision per customer, including hold. | | Usual owner | Data platform, CRM operations. | Growth, data science, revenue leadership. | | How it's measured | Coverage, freshness, adoption of the view. | Incremental revenue and ARPU against control. | ## Where a 360 programme stalls Most customer 360 initiatives succeed technically and disappoint commercially. The view is complete, adoption is reported, and the number of good decisions per week is unchanged, because deciding was never part of the scope. - A complete view still requires a human to notice a pattern, form a hypothesis and act on it. - Analyst capacity, not data availability, becomes the constraint on how many opportunities get worked. - Dashboards report what happened; they do not estimate what a different action would have produced. - Nothing in the view ranks two possible actions against each other for the same customer. ## Where Markin fits Markin turns the 360 into decisions at machine scale. It reads the view you already built, generates and sizes hypotheses across the full base, chooses treatments and validates them, so the investment in visibility starts producing revenue decisions instead of reports. - **Analysis without capacity limits.** Hypotheses are generated and tested continuously across the whole customer base, not on the subset an analyst has time for. - **Every decision is explainable.** Each recommendation carries the signal that produced it, its size, its expected value and its experiment record. - **No new source of truth.** The 360 stays the view. Markin reads it in place and writes decisions back to the systems that act. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - The 360 view is not yet trustworthy: fix data quality before layering decisions on top of it. - Your commercial teams have no way to execute differentiated actions, so better decisions cannot be delivered. - You need reporting and governance, not prioritisation. ## FAQ **Is a decision system the same as analytics?** No. Analytics explains what happened to a human who then decides. A decision system produces the decision itself, with an expected value and a control group, and learns from the outcome. **Do we need a complete 360 before starting?** No, but you need reliable context for the decisions you want to make. A decision layer can start on the subset of data that is trustworthy and expand as coverage improves. **Who owns the decision system?** Usually growth or revenue, with data science. It is a commercial system with analytical machinery, not a data platform project. **How is Markin different from the decisioning or AI already inside customer 360?** 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 360 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 360?** 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. Source: https://markin.ai/compare/customer-360-vs-decision-system --- --- title: Personalization vs. revenue decisioning url: https://markin.ai/compare/personalization-vs-revenue-decisioning kind: category description: Personalization tailors the experience. Revenue decisioning chooses which commercial outcome to pursue and proves it in euros. How the two differ in practice. --- # Personalization vs. revenue decisioning > Personalization adapts content, layout or recommendations to the individual, optimising relevance and engagement. Revenue decisioning chooses which commercial outcome to pursue for that customer, prices the alternatives and measures the result in incremental revenue and margin. Relevance is a means; the decision about what to pursue is where the money is decided. ## What each layer is **Personalization** — Adapting content, recommendations, layout or messaging to individual behaviour and preference, usually to improve relevance and engagement. Answers: What should this customer see? **Revenue decisioning** — Choosing which commercial outcome to pursue per customer, with a sized value and a treatment, and validating the choice against control. Answers: Which commercial outcome should we pursue, and what is it worth? ## Side by side | | Personalization | Revenue decisioning | | --- | --- | --- | | Question it answers | What should this customer see? | Which commercial outcome should we pursue, and what is it worth? | | Primary input | Behaviour, affinities, context, catalogue. | Customer context, margin, costs, constraints, experiment history. | | Primary output | A tailored experience or recommendation set. | A ranked decision with expected incremental value. | | Usual owner | Product, CRM, growth marketing. | Growth, data science, revenue leadership. | | How it's measured | Click-through, session conversion, engagement lift. | Incremental revenue, ARPU and margin against control. | ## Why relevance does not automatically mean revenue Personalization optimises the thing in front of the customer. It rarely questions whether that thing is the most valuable outcome available, and its metrics do not distinguish revenue you gained from revenue you would have had anyway. - Recommending what a customer was already going to buy raises click-through and adds nothing incremental. - Engagement metrics do not price margin, so a high-converting recommendation can be the least profitable option. - Cannibalisation is invisible when success is measured per surface rather than per customer. - Relevance models rarely consider the option of not intervening at all. ## Where Markin fits Markin decides the commercial objective before personalization executes it. Once the outcome worth pursuing is chosen and sized, personalization becomes far more valuable, because it is tailoring the right thing rather than the most clickable one. - **Margin-aware ranking.** Options are ranked on expected incremental margin, so cheap engagement wins stop outranking genuinely profitable ones. - **Cannibalisation measured explicitly.** Expansion tests separate net new revenue from revenue displaced from an existing product. - **Personalization keeps its job.** Your recommendation and content systems continue to run; they receive a better objective, not a replacement. Next: [ARPU Expansion](https://markin.ai/solutions/arpu-expansion) ## When Markin is not the right answer - Your catalogue is small and margin is uniform, so choosing between outcomes has little financial consequence. - You cannot attribute revenue to a customer, only to a session. - The immediate problem is a poor on-site experience, which is a product and personalization problem first. ## FAQ **Is revenue decisioning just personalization with revenue metrics?** No. Changing the metric does not change the candidate set. Revenue decisioning generates and sizes commercial opportunities across the base, then chooses among them; personalization tailors execution once that choice exists. **Can we keep our recommendation engine?** Yes. It stays in place as an execution component. The decision layer supplies the objective and the constraints it should optimise within. **How is cannibalisation handled?** By measuring net new revenue against a control group, so revenue moved from an existing product is separated from revenue genuinely added. **How is Markin different from the decisioning or AI already inside personalization?** 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 personalization 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 personalization?** On the assumptions preloaded above, 3.5M customers at 26 a month, 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. Source: https://markin.ai/compare/personalization-vs-revenue-decisioning --- --- title: Data warehouse vs. CDP vs. decision layer url: https://markin.ai/compare/data-warehouse-vs-cdp-vs-decision-layer kind: category description: Three layers, three jobs: storage and modelling, identity and activation, and commercial decisions. What each one owns and where the boundaries sit. --- # Data warehouse vs. CDP vs. decision layer > A data warehouse stores and models data. A CDP resolves identity and makes customer context activatable. A decision layer chooses which commercial opportunity to act on per customer and proves the choice against control. They stack: storage, then context, then decision. Each layer is a poor substitute for the one above it. ## What each layer is **Data warehouse** — The central store where raw and modelled data lives, queried by analysts and pipelines. Answers: What is the truth of what happened? **CDP** — The layer that resolves identity and exposes customer profiles, traits and audiences to activation tools. Answers: Who is this customer and how do we reach them? **Decision layer** — The layer that ranks commercial opportunities per customer, selects treatments and validates them experimentally. Answers: What should we do, for whom, and what is it worth? ## Side by side | | Data warehouse | CDP | Decision layer | | --- | --- | --- | --- | | Question it answers | What is the truth of what happened? | Who is this customer and how do we reach them? | What should we do, for whom, and what is it worth? | | Primary input | Source system extracts, event streams, transformations. | Warehouse tables, events, identity signals, consent. | Warehouse and CDP context, outcomes, costs, constraints. | | Primary output | Modelled tables and metrics. | Profiles, audiences, syncs to channels. | Ranked decisions with expected value and control groups. | | Usual owner | Data engineering, analytics engineering. | Martech operations, data engineering. | Growth, data science, revenue leadership. | | How it's measured | Freshness, cost, model coverage and test pass rate. | Match rate, sync reliability, audience latency. | Incremental revenue and ARPU against control. | ## The layer most stacks are missing Warehouse and CDP investments are usually well funded and well run. The decision layer is typically improvised: SQL segments, a quarterly campaign plan and a few propensity models feeding a journey builder. - Analyst-authored segments cannot cover the full opportunity space of a large base. - Propensity scores in a channel tool are ranking, not decisioning: no sizing, no cost, no counterfactual. - Without a decision record, the organisation cannot say why a customer received what they received. - Learning is trapped in individual campaign post-mortems instead of compounding. ## Where Markin fits Markin is the decision layer. It reads the warehouse and the CDP in place, generates and sizes hypotheses, chooses treatments per customer and hands them to activation, with every decision measured against control and logged for audit. - **Reads in place.** No data migration and no second source of truth. The layers below keep their responsibilities. - **Decisions are recorded.** Signal, hypothesis, size, treatment, experiment and outcome are all retained, which is what makes governance possible. - **Learning compounds.** Every experiment updates the priors used by the next round of hypotheses, so decision quality improves over time. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - Your warehouse is not yet reliable: the decision layer inherits every upstream data problem. - You have no activation path to customers, so decisions cannot be delivered. - The base is small enough that a single analyst can genuinely work every opportunity by hand. ## FAQ **Do we need a CDP if we have a warehouse and a decision layer?** Not necessarily. Many teams activate straight from the warehouse. A CDP earns its place when identity resolution, consent and multi-channel syncing are hard problems in your environment. **Can the warehouse be the decision layer?** It can host the models, but the decision layer is more than SQL: it needs hypothesis generation, sizing, treatment selection, experiment design and a decision record. Teams that try tend to rebuild exactly that, slowly. **Where do reverse-ETL tools sit?** In activation, between context and channel. They move a decision once it has been made; they do not make it. **How is Markin different from the decisioning or AI already inside data warehouse?** 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 data warehouse 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 data warehouse?** 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. Source: https://markin.ai/compare/data-warehouse-vs-cdp-vs-decision-layer --- --- title: Campaign calendar vs. continuous decisioning url: https://markin.ai/compare/campaign-calendar-vs-continuous-decisioning kind: category description: A calendar plans what everyone gets and when. Continuous decisioning evaluates every customer every day. What changes operationally, and what it is worth. --- # Campaign calendar vs. continuous decisioning > A campaign calendar schedules planned sends against a fixed timetable, with audiences defined per campaign. Continuous decisioning evaluates every customer on every cycle and acts only where expected incremental value is positive. The calendar allocates attention by date; continuous decisioning allocates it by opportunity, and can decide to do nothing. ## What each layer is **Campaign calendar** — A planned schedule of campaigns and sends, with audiences, creative and timing agreed in advance. Answers: What are we sending this month, and to whom? **Continuous decisioning** — An always-on loop that re-evaluates each customer's opportunities and treatments as context changes, and acts only when expected value is positive. Answers: For each customer today, is there something worth doing? ## Side by side | | Campaign calendar | Continuous decisioning | | --- | --- | --- | | Question it answers | What are we sending this month, and to whom? | For each customer today, is there something worth doing? | | Primary input | Commercial plan, seasonality, creative capacity. | Live context, opportunity sizing, uplift models, constraints. | | Primary output | Scheduled campaigns and audience briefs. | Per-customer decisions, continuously refreshed, including hold. | | Usual owner | CRM, lifecycle, brand marketing. | Growth and data science. | | How it's measured | Sends, engagement, campaign-attributed revenue. | Incremental revenue and ARPU against control. | ## What the calendar structurally cannot do A calendar is a capacity plan disguised as a strategy. The number of decisions per quarter equals the number of campaign slots the team can produce, and the timing is driven by the plan rather than by the customer. - Customers reach decisive moments continuously; a monthly plan only meets them by coincidence. - Every campaign must fill its slot, so low-value sends happen because the date arrived. - Learning is organised per campaign, so results rarely accumulate into a model of what works. - Adding decisions means adding headcount, because each one is authored by hand. ## Where Markin fits Markin runs the loop continuously. Opportunities are re-sized as behaviour changes, treatments are chosen per customer and per moment, and the calendar can keep its brand and seasonal moments while the always-on layer handles everything driven by customer state. - **Volume of decisions, not volume of campaigns.** Throughput stops being a function of how many briefs the team can write. - **Timing follows the customer.** Contract dates, usage shifts and lifecycle events trigger evaluation instead of waiting for the next slot. - **The calendar keeps what it is good at.** Seasonal and brand moments stay planned. Only the customer-state-driven work moves to the always-on loop. Next: [Growth Optimization](https://markin.ai/solutions/growth-optimization) ## When Markin is not the right answer - Your business is genuinely seasonal end to end, with almost no customer-state-driven revenue. - You cannot deliver messages outside a fixed weekly batch process. - Your team wants more control over creative sequencing than an always-on loop can accommodate today. ## FAQ **Does continuous decisioning mean sending more?** Usually the opposite. When every contact must beat the option of silence on expected value, low-value sends disappear and total contact volume falls while revenue per contact rises. **Do we abandon the campaign calendar?** No. Seasonal, brand and launch moments stay on the calendar. What moves is the always-on lifecycle work that should be triggered by customer state rather than by a date. **How quickly do results appear?** As fast as your outcome cycle allows. Short-cycle behaviours produce readable results in weeks; contract-driven ones take a full renewal window before incrementality is trustworthy. **How is Markin different from the decisioning or AI already inside campaign calendar?** 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 campaign calendar 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 campaign calendar?** On the assumptions preloaded above, 2.5M customers at 22 a month, 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. Source: https://markin.ai/compare/campaign-calendar-vs-continuous-decisioning --- --- title: Retention analytics vs. retention decisioning url: https://markin.ai/compare/retention-analytics-vs-retention-decisioning kind: category description: Retention analytics explains cohorts and churn drivers. Retention decisioning chooses interventions and proves retained margin. Where the handover sits. --- # Retention analytics vs. retention decisioning > Retention analytics describes what happened: cohort curves, churn drivers, survival by segment. Retention decisioning acts on it, choosing which customers to intervene with, which treatment to use and what it costs, then measuring incremental retained margin against control. Analytics informs a human decision; decisioning makes and validates the decision itself. ## What each layer is **Retention analytics** — Analysis of retention and churn: cohort curves, survival analysis, driver attribution and segment reporting. Answers: Why are we losing customers, and which segments are worst? **Retention decisioning** — The operational layer that selects who to intervene with, with which treatment, at which cost, and measures the incremental result. Answers: Who do we act on this week, how, and what does it return? ## Side by side | | Retention analytics | Retention decisioning | | --- | --- | --- | | Question it answers | Why are we losing customers, and which segments are worst? | Who do we act on this week, how, and what does it return? | | Primary input | Historical outcomes, tenure, usage, service events. | Risk, uplift, offer costs, margin, constraints. | | Primary output | Cohort reports, driver rankings, dashboards. | Intervention decisions per customer, with control groups. | | Usual owner | Analytics, data science. | Growth, retention, finance. | | How it's measured | Explanatory quality, adoption of insight. | Incremental retained margin against holdout. | ## The distance between insight and retained margin Most retention programmes have excellent analysis and a thin action layer. The drivers are known, the cohorts are charted, and the intervention is still one save offer applied to a risk decile. - Driver analysis explains a population; interventions have to be chosen per customer. - Insights arrive on a reporting cadence, while the decisive moments arrive continuously. - The cost of each save is rarely attached to the analysis, so margin impact is unknown. - Without a holdout, an improving retention rate cannot be separated from market conditions. ## Where Markin fits Markin takes retention from explanation to decision. It ranks customers by expected incremental save value rather than risk, chooses the least expensive effective treatment, and reports the programme in retained margin with control groups attached. - **From cohort to customer.** Insight about a segment becomes an intervention decision per individual, refreshed as their state changes. - **Margin as the unit of success.** Cost of treatment is modelled alongside save probability, so the programme is judged on what it protects net of what it spends. - **Analytics keeps its role.** Your analytics team keeps owning measurement and interpretation; Markin removes the manual step between insight and action, and launches the action itself. Next: [Retention Decisioning](https://markin.ai/solutions/retention-decisioning) ## When Markin is not the right answer - You have no intervention levers available, only reporting requirements. - Outcomes cannot be linked back to individual customers, which makes uplift unmeasurable. - Churn is dominated by a single fixable product or service defect: fix that first. ## FAQ **Does this replace our retention analytics?** No. Analysis remains essential for understanding drivers and validating measurement. Decisioning adds the layer that turns those findings into per-customer interventions with control groups. **What changes in reporting?** The headline metric moves from retention rate to incremental retained margin, which is comparable across treatments and honest about the cost of saves. **How does this relate to churn prediction?** Prediction supplies risk, analytics supplies understanding, and decisioning supplies the intervention choice and its proof. All three are needed. **How is Markin different from the decisioning or AI already inside retention analytics?** 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 retention analytics 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 retention analytics?** 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. Source: https://markin.ai/compare/retention-analytics-vs-retention-decisioning --- --- title: Markin + Braze: from customer data to prioritised retention actions url: https://markin.ai/compare/markin-and-braze kind: stack description: Braze orchestrates and delivers cross-channel journeys. Markin decides which revenue opportunity deserves one. How a decision layer works alongside Braze. --- # Markin + Braze: from customer data to prioritised retention actions > Braze is a customer engagement platform: Canvas journeys, cross-channel delivery and message personalisation. Markin sits before it and decides which commercial opportunity is worth acting on for each customer, and what it is worth. The decision is made in Markin; the message is still built, personalised and delivered by Braze. ## What each layer is **Braze** — A customer engagement platform for designing and delivering cross-channel journeys, email, push, in-app, SMS and web, with Canvas orchestration, Liquid personalisation and delivery analytics. Answers: How do we build, personalise and deliver this journey across channels? **Markin, the decision + execution layer** — A layer that ranks commercial opportunities per customer, sizes the revenue at stake, selects the treatment with the highest expected incremental value and decides when not to contact at all. Answers: Which opportunity justifies contact for this customer, and which treatment wins? ## Side by side | | Braze | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | How do we build, personalise and deliver this journey across channels? | Which opportunity justifies contact for this customer, and which treatment wins? | | Primary input | Audiences and user attributes, custom events, journey logic, content templates. | Customer context, outcomes, contact history, margins, constraints, past experiment results. | | Primary output | Delivered messages, journey state and engagement reporting. | A ranked, sized decision per customer, including hold, pushed into Braze as the entry signal. | | Usual owner | CRM and lifecycle marketing. | Growth, data science and revenue leadership. | | How it's measured | Deliverability, open and click rate, conversion attributed to the Canvas. | Incremental revenue and ARPU against a holdout. | ## What stays unsolved when Braze is running well A mature Braze setup usually has more Canvases than the customer base can absorb. The platform delivers whatever it is asked to deliver; deciding what deserves to be asked is a separate job, and it is normally done in planning meetings and spreadsheets. - A customer can qualify for several Canvases in the same week. Priority is resolved by frequency caps and eligibility rules, not by expected value. - Campaign reporting is per-Canvas. Nothing sums the effect of everything a customer received into one revenue number. - There is no explicit decision to leave a customer alone when no message has positive expected value. - New hypotheses arrive at the speed the lifecycle team can write briefs, not at the speed the data changes. ## How the two run together 1. **Context in.** Markin reads customer context where it already lives, warehouse, CDP, product and billing systems, plus outcome history. Braze exports of engagement and delivery events can be part of that context. 2. **Decision.** Markin generates and sizes revenue opportunities, ranks them per customer, chooses a treatment and assigns a control group. The output is one decision per customer, with an expected value attached. 3. **Activation back into Braze.** The chosen decision is written back as user attributes or a triggered event, so an existing Canvas picks it up and delivers it. Content, channel governance and send-time logic remain in Braze. ## Braze's own decisioning layer Products: BrazeAI™, Sage AI by Braze, BrazeAI Decisioning Studio™, Intelligence Suite Braze does have a decisioning layer, and it is a real one. It selects content, channel and timing per individual, inside Canvas, across the channels Braze itself sends. That is a different scope from deciding which commercial opportunity is worth pursuing in the first place. **What it optimises** - BrazeAI is presented as a suite of AI marketing and personalisation tools embedded across the Braze platform, with Sage AI as the collective name for capabilities integrated into Braze data flows and the execution stack. [Vendor page: Braze, BrazeAI product page](https://www.braze.com/product/brazeai) - BrazeAI Decisioning Studio™ is positioned to power autonomous, individualised decisioning for customer engagement strategies, and became available through the Google Cloud Marketplace in December 2025. [Vendor page: Braze, BrazeAI Decisioning Studio via Google Cloud Marketplace (Dec 2025)](https://www.businesswire.com/news/home/20251202496602/en/Braze-Delivers-BrazeAI-Decisioning-Studio-Through-Google-Cloud-Marketplace) - The Intelligence Suite is documented as a way to automate decision making from data-based insights within Braze. [Vendor docs: Braze Learning, Automate decisioning with the Intelligence Suite](https://learning.braze.com/automate-decisioning-with-the-intelligence-suite) **Documented constraints** - Decisioning operates through Canvas. It optimises the messages Braze itself sends; it is not an arbitration layer over channels and touchpoints outside the Braze estate. [Vendor page: Braze, BrazeAI product page](https://www.braze.com/product/brazeai) - The unit of optimisation is content, channel and send time within a journey, not the revenue at stake behind the journey, its margin, or whether the journey should run at all. [Vendor page: Braze, BrazeAI product page](https://www.braze.com/product/brazeai) **Evidence** - The only quantified performance research for Decisioning Studio is a Total Economic Impact™ study conducted by Forrester Consulting and commissioned by Braze (May 2026). The figures sit behind a registration form, and the study is vendor-funded rather than independent Forrester research. [Vendor-commissioned: Forrester TEI, commissioned by Braze (May 2026)](https://tei.forrester.com/go/braze/aidecisioningspotlight/) - Braze's April 2026 research announcement references the same TEI study and a further commissioned report; no independent benchmark of Decisioning Studio uplift is published. [Vendor page: Braze research announcement (April 2026)](https://www.businesswire.com/news/home/20260423105729/en/Braze-Unveils-New-Research-Showing-How-AI-Data-and-Decisioning-Are-Redefining-Customer-Engagement) **Where Markin differs** - **Decides across the estate, not one channel.** Markin arbitrates between everything a customer could receive this week, Braze journeys, service contact, in-product placements, field or care outreach, and picks one. Braze optimises what it sends; Markin decides whether Braze should be the one sending. - **Optimises revenue, not engagement.** Decisioning Studio ranks by likelihood of engagement. Markin ranks by expected incremental revenue net of margin and contact cost, which is why hold is a legitimate output. - **Measured against holdout, by default.** Every Markin decision carries a control group and reports incremental ARPU against it, rather than conversion attributed to a Canvas. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin does not send email, push, SMS or in-app messages. Delivery stays in Braze. - Markin does not manage templates, brand controls or channel credentials. - Markin is not a system of record for consent or communication preferences. - Markin does not replace Canvas orchestration; it supplies the signal that starts the right one. ## Where Markin fits Markin does not send messages. It decides which of the things you could send is the one that adds revenue, then hands that decision to Braze to execute. Lifecycle keeps its templates, its brand controls and its channel expertise; what changes is the input that triggers the journey. - **Canvas entry becomes a decision, not a rule.** Instead of an eligibility segment, the entry signal is a ranked opportunity with an expected value, so the highest-value action wins the customer's attention that week. - **Contact budget is allocated, not capped.** Frequency caps stop over-messaging. Decisioning goes further: it spends each contact on the opportunity with the best expected return, and holds when none clears the bar. - **Measured against control, not attributed.** Every decision carries a holdout, so the reported number is incremental revenue rather than conversions credited to a send. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - You run a handful of lifecycle journeys and the team can still reason about priority in a single meeting. - Your customer data is not yet reliable enough to size opportunities: fix ingestion and identity first. - You want a cheaper way to send messages. This layer does not replace an engagement platform and does not reduce its cost. ## FAQ **Does Braze already have AI decisioning?** Yes. BrazeAI Decisioning Studio™ selects content, channel and timing per individual inside Canvas, and Sage AI powers predictive and generative features across the platform. Its scope is the messages Braze sends. It does not size the revenue opportunity behind a journey, arbitrate against touchpoints outside Braze, or decide that no contact is the best option. The only published performance research is a Forrester Total Economic Impact study commissioned by Braze (May 2026). **Do we have to replace Braze?** No. Braze remains the execution layer. Markin decides which opportunity is worth a message and passes that decision into Braze, which builds and delivers it exactly as it does today. **How does the decision reach Braze?** As customer attributes or triggered events on the profile, so existing Canvases can key off them. The integration surface is the same one your team already uses for any other upstream signal. **Does this add another audience-building tool?** No. Markin produces ranked, sized opportunities per customer rather than segments. Audience building for broadcast and brand campaigns stays where it is. **Who owns the output, marketing or data?** Both, deliberately. Data science owns the models and the experiment design; lifecycle owns the treatments and the channel. The decision layer is the shared contract between them. **What does the first ninety days look like?** One revenue theme, one channel, a real holdout. The point of the first quarter is a defensible incremental number, not full coverage of the journey map. **How is Markin different from the decisioning or AI already inside Braze?** 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 Braze 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 Braze?** On the assumptions preloaded above, 4.0M customers at 18 a month, 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. Source: https://markin.ai/compare/markin-and-braze --- --- title: Markin + Salesforce: decisioning beyond journeys and campaigns url: https://markin.ai/compare/markin-and-salesforce kind: stack description: Salesforce unifies customer records and runs journeys. Markin decides which revenue opportunity is worth acting on, and proves it against a holdout. --- # Markin + Salesforce: decisioning beyond journeys and campaigns > Salesforce combines a system of record with unified profiles in Data Cloud and journey orchestration in Marketing Cloud. Markin adds the commercial decision on top: which opportunity exists per customer, what it is worth, and which treatment to run. Records, governance and execution stay in Salesforce. ## What each layer is **Salesforce** — A CRM and marketing estate: accounts, contacts and service history as the system of record, unified profiles and audiences in Data Cloud, and journey orchestration and personalisation in Marketing Cloud. Answers: What is the record of this customer, and which journey are they in? **Markin, the decision + execution layer** — A layer that turns that context into ranked commercial decisions: which opportunity is worth acting on for each customer, at what expected value, and proven against control. Answers: Which opportunity should this customer receive next, and is it worth the contact? ## Side by side | | Salesforce | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | What is the record of this customer, and which journey are they in? | Which opportunity should this customer receive next, and is it worth the contact? | | Primary input | CRM objects, service and sales activity, ingested events, unified profiles. | Customer context from Salesforce and the warehouse, outcomes, margin and constraints. | | Primary output | Segments, journey membership, delivered messages, pipeline and case records. | A ranked, sized decision per customer, written back to the record or the journey. | | Usual owner | Sales, service and marketing operations. | Growth, data science and revenue leadership. | | How it's measured | Journey completion, campaign conversion, pipeline and case metrics. | Incremental revenue and ARPU against a holdout. | ## What a complete Salesforce estate still leaves open Salesforce is excellent at knowing and recording. The commercial question, of everything we could offer this customer this month, which one adds the most revenue, is normally answered by segmentation rules and campaign calendars written by people. - Journey entry criteria encode decisions someone already made; they do not estimate the incremental effect of entering. - Priority between concurrent journeys is resolved by suppression rules rather than by expected value. - Uplift is rarely measured against a real holdout, so the reported number blends demand that would have happened anyway. - The number of hypotheses tested per quarter is bounded by the operations team's capacity, not by the data. ## How the two run together 1. **Context in.** Markin reads unified customer context, Salesforce records and Data Cloud profiles, plus warehouse, product and billing data, together with the outcome history needed to learn from. 2. **Decision.** Opportunities are generated, sized and ranked per customer. A treatment is selected, a control group is assigned, and the expected value is attached to the decision. 3. **Activation back into Salesforce.** The decision returns as a field on the record or an event that triggers the appropriate journey, task or next-best-action prompt for a service or sales agent. ## Salesforce's own decisioning layer Products: Einstein Next Best Action, Agentforce, Marketing Cloud Next, Data Cloud Salesforce has recommendation and agentic layers, but they are spread across products with different jobs: Einstein Next Best Action surfaces suggested actions, Agentforce executes autonomously, Marketing Cloud Next assembles campaigns, and Data Cloud has to be adopted for any of it to see the full customer. **What it optimises** - Einstein Next Best Action is described as the Salesforce recommendation engine that surfaces personalised action suggestions to users based on rules, data and AI-predicted scoring. [Vendor docs: Salesforce Trailhead, Get Started with Einstein Next Best Action](https://trailhead.salesforce.com/content/learn/modules/einstein-next-best-action/get-started-with-einstein-next-best-action) - Marketing Cloud Next, announced June 2025, is billed as a full-funnel agentic marketing solution using autonomous agents for campaign assembly, performance optimisation and 1:1 personalisation at scale. [Vendor page: Salesforce, Marketing Cloud Next announcement](https://www.salesforce.com/news/stories/marketing-cloud-next-announcement/) **Documented constraints** - Next Best Action is largely an internal-facing recommendation tool: suggestions are surfaced to sales and service users rather than arbitrated autonomously across outbound channels. [Vendor docs: Salesforce Trailhead, Einstein Next Best Action](https://trailhead.salesforce.com/content/learn/modules/einstein-next-best-action/get-started-with-einstein-next-best-action) - Data Cloud is presented as the foundational unification layer that fuels Agentforce, so decisioning quality is contingent on the customer estate being ingested into Salesforce's own data platform. [Vendor page: Salesforce, How Data Cloud powers Agentforce](https://www.salesforce.com/news/stories/how-data-cloud-powers-agentforce/) - Salesforce itself documents an Agentforce-versus-Einstein distinction for marketers, meaning teams have to reconcile two overlapping AI layers inside one platform. [Vendor docs: Salesforce Trailhead, Explore AI in Marketing Cloud Next](https://trailhead.salesforce.com/content/learn/modules/ai-in-marketing-cloud-next/explore-ai-in-marketing-cloud-next) **Evidence** - No public uplift percentage for Einstein Next Best Action, Agentforce or Marketing Cloud Next decisioning was found on Salesforce's own product pages; the material is positioning-led rather than benchmarked. [Vendor page: Salesforce, Marketing Cloud Next announcement](https://www.salesforce.com/news/stories/marketing-cloud-next-announcement/) - Salesforce was named a Leader in the 2026 Forrester Wave™ for Revenue Marketing Platforms for B2B, an independent report, but one covering B2B revenue marketing broadly rather than consumer decisioning. [Analyst report: Forrester Wave™, Revenue Marketing Platforms for B2B (Feb 2026)](https://www.salesforce.com/blog/salesforce-2026-forrester-wave-b2b/) **Where Markin differs** - **One decision layer, not three AI surfaces.** Markin produces a single ranked decision per customer that Salesforce clouds consume. There is no seam between a recommendation engine, an agent framework and a campaign assembler to reconcile. - **Works on the warehouse you already have.** Markin reads context where it lives, warehouse, CDP, billing, product, so decisioning does not wait on a full Data Cloud migration to see the customer. - **Sized in revenue, arbitrated across channels.** Every opportunity carries expected incremental value, so a service action, a sales task and an outbound message compete on the same scale instead of running in parallel. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin does not replace the CRM or become the system of record for customers, cases or pipeline. - Markin does not replace Journey Builder or campaign execution. - Markin does not manage consent, preferences or data governance. - Markin does not require a Salesforce migration; it reads context and writes decisions back. ## Where Markin fits Markin is not a CRM and has no ambition to be the system of record. It reads the context Salesforce maintains, decides what is commercially worth doing, and returns that decision so Salesforce can execute it through the journeys, tasks and agent surfaces you already run. - **The record stays the record.** Ownership of contacts, consent, cases and pipeline does not move. Markin reads context in place and never becomes a second source of truth. - **Decisions reach humans too.** The same ranked opportunity that triggers a journey can surface as a prioritised prompt for a retention agent or account manager, with the reason and the expected value attached. - **Proof that survives finance review.** Every decision runs against control, so the number presented is incremental revenue rather than conversions credited to a campaign. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - Your commercial motion is a single product with no repeat purchase or upgrade path, so there is nothing to prioritise between. - You need better reporting on existing journeys rather than a different way of choosing them. - Customer data is fragmented to the point that no reliable outcome history exists yet. ## FAQ **Doesn't Einstein Next Best Action already do decisioning?** Einstein Next Best Action is Salesforce's recommendation engine: it surfaces personalised action suggestions from rules and AI-predicted scoring, largely to sales and service users. Agentforce adds autonomous execution and Marketing Cloud Next adds agentic campaign assembly, but the full picture depends on adopting Data Cloud as the unification layer. Markin produces one ranked, revenue-sized decision per customer that those clouds consume, without a Data Cloud migration first. **Do we have to replace Marketing Cloud?** No. Orchestration and delivery stay in Salesforce. Markin decides which opportunity is worth acting on and passes it back as the trigger for the right journey or agent task. **We already have Data Cloud. Isn't the decision covered?** Data Cloud unifies profiles and builds audiences. That answers what we know about a customer. Choosing which of several possible commercial actions has the highest incremental value, and proving it against control, is a different job. **How does the decision get back into Salesforce?** As a field on the record or an event, so existing journeys, flows and agent consoles can consume it without new interfaces for the team. **Can service and sales teams use the same decisions?** Yes. A ranked opportunity is channel-agnostic. The same decision can be delivered as a message, an in-product offer or a prompt for a human, and each route is measured against the same holdout. **Is this a long integration project?** The first deployment targets one revenue theme and one activation route. The requirement is reliable customer context and outcome history, not a re-platforming. **How is Markin different from the decisioning or AI already inside Salesforce?** 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 Salesforce 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 Salesforce?** On the assumptions preloaded above, 5.0M customers at 30 a month, 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. Source: https://markin.ai/compare/markin-and-salesforce --- --- title: Markin + Hightouch: warehouse data, decisions and activation url: https://markin.ai/compare/markin-and-hightouch kind: stack description: Hightouch activates warehouse data into your tools. Markin decides which revenue opportunity is worth activating, on your composable stack. --- # Markin + Hightouch: warehouse data, decisions and activation > Hightouch is a composable CDP and activation layer: it models audiences on top of your warehouse and syncs them to downstream destinations without copying the data. Markin uses that same warehouse to decide which commercial opportunity is worth acting on per customer, and lets the activation route stay exactly where it is. ## What each layer is **Hightouch** — A composable CDP built on the warehouse: audience modelling, identity resolution and reverse-ETL syncs that push customer data from the warehouse into marketing, sales and support destinations. Answers: How do we get this warehouse data into the tools that need it? **Markin, the decision + execution layer** — A layer that reads the same warehouse and produces ranked, sized commercial decisions per customer, with a treatment choice, a control group and a measured incremental result. Answers: Which opportunity is worth acting on for this customer, and what is it worth? ## Side by side | | Hightouch | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | How do we get this warehouse data into the tools that need it? | Which opportunity is worth acting on for this customer, and what is it worth? | | Primary input | Warehouse tables and models, audience definitions, destination mappings. | Warehouse context, outcome history, margins, contact costs and constraints. | | Primary output | Synced audiences, profiles and traits in downstream destinations. | A decision per customer, materialised back into the warehouse for activation. | | Usual owner | Data engineering and marketing operations. | Growth and data science. | | How it's measured | Sync reliability and latency, audience coverage, destination match rates. | Incremental revenue and ARPU against a holdout. | ## What a composable stack still leaves open Once the warehouse is the source of truth and syncs are reliable, the bottleneck moves upstream of activation: someone still has to decide which of the many possible audiences deserves the customer's attention this week, and whether it moved anything. - An audience is a rule over the warehouse. It does not estimate the incremental effect of acting on it. - Multiple models can qualify the same customer at once, and priority is resolved by ordering rather than expected value. - Nothing enforces holdouts by default, so incremental effect has to be reconstructed after the fact. - Hypothesis generation stays manual: the number of ideas tested is bounded by analyst time. ## How the two run together 1. **Warehouse as the shared substrate.** Markin reads the same modelled tables Hightouch activates from. No data is copied into a separate profile store and no second identity graph is created. 2. **Decision written back to the warehouse.** Markin materialises ranked, sized decisions and control-group assignment as tables in the warehouse, so they are queryable, auditable and versioned alongside everything else. 3. **Activation stays in Hightouch.** Those decision tables become the source for syncs to email, SMS, ads, product surfaces or support tools. The activation architecture does not change. ## Hightouch's own decisioning layer Products: AI Decisioning (AID), Customer Data & AI Platform Hightouch AI Decisioning is the closest thing in this list to a true decision layer: reinforcement learning agents choose message, channel and timing per user. Its documented boundaries are what separate it from revenue decisioning, it selects between messages you pre-approve, and it needs someone else's platform to send them. **What it optimises** - AI Decisioning uses reinforcement learning and AI agents to automatically choose the best content, offer, channel and timing. [Vendor page: Hightouch, What is AI Decisioning (Feb 2026)](https://hightouch.com/blog/what-is-ai-decisioning-what-does-hightouch-do) - An agent combines an audience, goals and messages; AID then learns which message, channel and timing perform best for each person, balancing exploration and exploitation. [Vendor docs: Hightouch docs, AI Decisioning overview](https://hightouch.com/docs/ai-decisioning/overview) **Documented constraints** - Hightouch documents that agents operate entirely within the inputs and rules you define: they do not create new content or act outside your configuration. [Vendor docs: Hightouch docs, Agents](https://hightouch.com/docs/ai-decisioning/agents) - AID does not send. It requires at least one connected delivery destination, Salesforce Marketing Cloud, Braze or Iterable, so its reach is bounded by whichever channels that platform supports. [Vendor docs: Hightouch docs, AI Decisioning overview](https://hightouch.com/docs/ai-decisioning/overview) - AI Decisioning requires workspace configuration from data teams before marketers can create agents. [Vendor docs: Hightouch docs, AI Decisioning overview](https://hightouch.com/docs/ai-decisioning/overview) **Evidence** - Hightouch publishes lift metrics as a product capability inside its Insights dashboard, but no aggregate uplift percentage for AID appears on its public pages. [Vendor page: Hightouch, AI Decisioning platform page](https://hightouch.com/platform/ai-decisioning) **Where Markin differs** - **Opportunity first, message second.** AID optimises between messages that already exist. Markin starts a step earlier: it generates and sizes the revenue opportunity, then decides whether any treatment clears the bar. Message selection is the last step, not the whole job. - **Economics in the objective function.** Markin ranks on expected incremental revenue net of margin, discount cost and contact cost. Reward defined as engagement will happily optimise towards cheap conversions that would have happened anyway. - **No delivery-platform dependency.** Markin's decision is written wherever it is needed, an engagement platform, the warehouse, a service desk, a product surface, rather than requiring Braze, Iterable or SFMC to exist first. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin is not a reverse-ETL tool and does not sync data to destinations. - Markin does not replace warehouse modelling, identity resolution or audience management. - Markin does not require data to leave the warehouse architecture you chose. - Markin does not own channel delivery in any downstream tool. ## Where Markin fits A composable stack already made the right architectural choice: the warehouse is the source of truth. Markin adds the layer that turns that truth into ranked commercial decisions, and writes them back to the warehouse so activation continues through the syncs you already trust. - **No second source of truth.** Decisions are warehouse tables. Anyone can inspect why a customer received a treatment, and finance can reconcile the numbers against the same data. - **Experimentation is built in.** Control-group assignment is part of the decision, not an afterthought bolted on before a QBR. - **Hypotheses at data speed.** The layer generates and sizes candidate opportunities continuously, so the backlog is not limited to what an analyst had time to write this sprint. Next: [ARPU Expansion](https://markin.ai/solutions/arpu-expansion) ## When Markin is not the right answer - Your warehouse does not yet hold reliable outcome data, so no decision can be evaluated. - Activation is the bottleneck rather than prioritisation, solve the syncs first. - You are looking for reverse-ETL. Markin does not move data into destinations; that is what your activation layer is for. ## FAQ **How is Markin different from Hightouch AI Decisioning?** Hightouch AI Decisioning uses reinforcement learning to pick the best message, channel and timing per user. Its own documentation notes that agents operate entirely within the inputs and rules you define, that delivery requires a connected Braze, Iterable or Salesforce Marketing Cloud destination, and that data teams must configure the workspace first. Markin starts a step earlier: it generates and sizes the revenue opportunity, ranks options on expected incremental margin, and is not dependent on a third-party send platform. **Do we have to replace Hightouch?** No. Activation stays where it is. Markin writes its decisions back into the warehouse and those tables become the source for your existing syncs. **Hightouch also offers AI Decisioning. How is this different?** They overlap in ambition and are worth evaluating side by side. AI Decisioning optimises the content, offer, channel and timing of individual campaigns. Markin's emphasis is upstream of that: generating and sizing revenue opportunities across the customer base and ranking which ones deserve to be acted on at all. A direct comparison page is on the way; in the meantime the honest answer is that the right fit depends on whether your bottleneck is message optimisation or opportunity prioritisation. **Does Markin copy our data?** No. It reads the modelled tables in place and writes decisions back as tables. The warehouse stays the source of truth. **Who maintains the models?** Your data team keeps owning the warehouse models. Markin consumes them and adds the decision and experiment layer on top, with the logic visible rather than hidden in a black box. **How is Markin different from the decisioning or AI already inside Hightouch?** 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 Hightouch 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 Hightouch?** On the assumptions preloaded above, 1.5M customers at 28 a month, 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. Source: https://markin.ai/compare/markin-and-hightouch --- --- title: Markin + Segment or Tealium: turning customer context into revenue decisions url: https://markin.ai/compare/markin-and-segment-tealium kind: stack description: Segment and Tealium collect, resolve and govern customer data. Markin decides which revenue opportunity is worth acting on. How the layers divide the work. --- # Markin + Segment or Tealium: turning customer context into revenue decisions > Segment and Tealium collect events, resolve identity, govern consent and route customer data to downstream tools. Markin sits above that plumbing and decides which commercial opportunity is worth acting on for each customer. Collection, consent and routing stay exactly where they are. ## What each layer is **Segment or Tealium** — Customer data infrastructure: event collection across web, mobile and server, identity resolution into unified profiles, consent and tag governance, and routing of that data to downstream destinations. Answers: Is this data collected, resolved, compliant and delivered to the right tools? **Markin, the decision + execution layer** — A layer that consumes that governed context and produces ranked, sized commercial decisions per customer, each with a treatment, a control group and a measured incremental result. Answers: Given everything we now know, which opportunity is worth acting on and how much is it worth? ## Side by side | | Segment or Tealium | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | Is this data collected, resolved, compliant and delivered to the right tools? | Given everything we now know, which opportunity is worth acting on and how much is it worth? | | Primary input | Tracking calls, source system records, consent state, destination configuration. | Governed customer context, outcome history, margin, contact costs and constraints. | | Primary output | Unified profiles and traits, governed event streams, audiences in destinations. | A ranked decision per customer, including the decision not to act. | | Usual owner | Data engineering and martech operations. | Growth, data science and revenue leadership. | | How it's measured | Event delivery, identity match rate, consent compliance, destination uptime. | Incremental revenue and ARPU against a holdout. | ## What good data infrastructure still leaves open Segment and Tealium answer whether the data is trustworthy, compliant and where it needs to be. That is a hard problem and worth solving properly. It is a different problem from deciding what the data is worth acting on. - A trait is a fact about a customer. It carries no estimate of the revenue at stake or of what an intervention would change. - Audiences are rules; a customer can satisfy many at once and nothing arbitrates between them commercially. - Consent tells you what you may do, not what you should do. - Once the pipes are reliable, the constraint becomes how many well-designed interventions the team can conceive and test per quarter. ## How the layers run together 1. **Collection and governance.** Segment or Tealium keeps doing what it does: collecting events, resolving identity, enforcing consent and routing data, including into the warehouse Markin reads. 2. **Decision.** Markin generates and sizes revenue opportunities from that governed context, ranks them per customer, chooses a treatment and assigns a control group. Consent state is a hard constraint on what is eligible. 3. **Activation through existing destinations.** The decision is written back as a trait or event so your existing destinations, engagement platform, ads, product, support, activate it through the routes already configured. ## Segment and Tealium's own decisioning layer Products: Segment Predictions, Twilio CustomerAI, Twilio Engage; Tealium Predict ML™, AudienceStream Both platforms ship machine learning, and both apply it to the same job: scoring how likely a customer is to do something. That score then feeds a rule-based journey. A propensity score is an input to a decision; it is not a decision, and neither platform claims to arbitrate between competing opportunities. **What it optimises** - Segment Predictions lets you predict the likelihood that users will perform any event tracked in Segment, stored as computed traits on the user profile. [Vendor docs: Twilio Segment docs, Predictions](https://www.twilio.com/docs/segment/unify/traits/predictions) - Twilio positions Predictions as a way to uncover behavioural patterns and surface high-value audiences most likely to convert without calling in a data science team. [Vendor page: Twilio, Predictions product page](https://www.twilio.com/en-us/products/predictions) - Tealium Predict ML™ predicts the likelihood of customers achieving a defined goal and uses that prediction to define audience segments or engagement rules. [Vendor page: Tealium, Predict ML product page](https://tealium.com/products/tealium-predict-machine-learning/) **Documented constraints** - Segment Predictions is gated to the Business tier with the Unify Plus add-on, so propensity scoring is not available on lower plans. [Vendor docs: Twilio Segment docs, Using Predictions](https://www.twilio.com/docs/segment/unify/traits/predictions/using-predictions) - Scores are computed traits. Execution logic still lives in Engage's rule-based journey builder rather than in a learning arbitration engine. [Vendor docs: Twilio Segment docs, Predictions](https://www.twilio.com/docs/segment/unify/traits/predictions) - Tealium Predict ML is tied to AudienceStream and is described as business-friendly, per-goal modelling used for segmentation, not cross-channel offer arbitration. [Vendor page: Tealium, Predict ML product page](https://tealium.com/products/tealium-predict-machine-learning/) **Evidence** - Neither Twilio Segment nor Tealium publishes an uplift figure for its predictive layer on its public product pages. [Vendor page: Twilio, Predictions product page](https://www.twilio.com/en-us/products/predictions) - Twilio CustomerAI, launched August 2023, bundles Predictions with generative and voice capabilities across Engage, Flex and Segment as an AI-ready CDP, a data-and-scoring positioning rather than a decisioning one. [Vendor page: Twilio, CustomerAI launch release](https://www.twilio.com/en-us/press/releases/twilio-customerai-fuels-next-generation-customer-relationships-a) **Where Markin differs** - **A score ranks people, a decision ranks options.** Propensity tells you who is likely to churn. It does not tell you which of nine possible interventions is worth the margin, or whether the customer would have stayed anyway. Markin ranks options per customer, not customers per model. - **Consumes the scores you already have.** Predictions and Predict ML traits are valid inputs to Markin. Nothing gets rebuilt; the scores stop being the end of the pipeline and become one feature in the decision. - **Incrementality, not likelihood.** Acting on high propensity often means paying customers to do what they were going to do. Markin optimises the uplift a treatment causes, measured against control. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin does not collect events or instrument your web and mobile apps. - Markin does not perform identity resolution or maintain the profile store. - Markin is not a consent, preference or tag management system. - Markin does not route data to destinations; your CDP keeps that job. ## Where Markin fits Markin is not customer data infrastructure and will not ask you to re-instrument anything. It reads the context your CDP already produces, decides what is commercially worth doing with it, and returns that decision through the same routing layer. - **Consent is a constraint, not an afterthought.** Eligibility inherits the consent and preference state your platform governs. A decision that cannot be acted on compliantly is never made. - **No new identity graph.** Identity resolution stays where it is. Markin joins on the identifiers your platform already resolves. - **From traits to expected value.** The output is not another trait. It is a sized opportunity with a recommended treatment and a control group attached. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - Collection and identity are still unreliable: a decision layer cannot compensate for missing context. - You need consent management, tag governance or a data pipeline, that is what these platforms are for. - Your commercial model has no repeat purchase, upgrade or retention decision to prioritise. ## FAQ **Isn't a propensity score from Segment or Tealium the same as a decision?** No. Segment Predictions computes the likelihood that a user performs a tracked event, stored as a trait and gated to the Business tier with Unify Plus. Tealium Predict ML predicts goal likelihood to define audience segments or engagement rules. Both rank people; neither ranks the competing actions you could take, prices them against margin, or measures whether the treatment caused the outcome. Markin consumes those scores as inputs. **Do we have to replace Segment or Tealium?** No. They remain the collection, identity, consent and routing layer. Markin consumes that context and returns decisions through the destinations you already configured. **Is this a second CDP?** No. Markin has no profile store and no identity graph. It reads resolved context and produces ranked commercial decisions, which is a different artefact from a unified profile. **How is consent respected?** Consent and preference state are treated as hard eligibility constraints. If a customer cannot be contacted on a channel, no decision is produced for that channel. **What if our context lives in the warehouse rather than the CDP?** That works the same way. The requirement is reliable customer context and outcome history, not a particular product category. **How is Markin different from the decisioning or AI already inside Segment and Tealium?** 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 Segment and Tealium 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 Segment and Tealium?** On the assumptions preloaded above, 3.0M customers at 21 a month, 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. Source: https://markin.ai/compare/markin-and-segment-tealium --- --- title: Markin + Adobe: prioritising the opportunity before personalisation url: https://markin.ai/compare/markin-and-adobe kind: stack description: Adobe Real-Time CDP and Journey Optimizer unify profiles and personalise in the moment. Markin decides which opportunity deserves that moment. --- # Markin + Adobe: prioritising the opportunity before personalisation > Adobe Experience Platform unifies profiles in Real-Time CDP and orchestrates personalised experiences through Journey Optimizer. Markin sits before the moment of personalisation and decides which commercial opportunity deserves it for each customer, and what it is worth. Adobe still owns the profile, the journey and the experience. ## What each layer is **Adobe Experience Platform** — An enterprise experience stack: Real-Time CDP for unified profiles and audiences, and Journey Optimizer for orchestrating and personalising journeys and in-the-moment experiences across channels. Answers: How do we deliver a personalised experience to this profile, in this moment? **Markin, the decision + execution layer** — A layer that ranks commercial opportunities per customer, sizes the revenue at stake, chooses the treatment expected to move it, and holds when nothing has positive expected value. Answers: Which opportunity is worth this customer's attention, and what is it worth to the business? ## Side by side | | Adobe Experience Platform | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | How do we deliver a personalised experience to this profile, in this moment? | Which opportunity is worth this customer's attention, and what is it worth to the business? | | Primary input | Ingested events and records, unified profiles, audiences, journey and offer configuration. | Unified context, outcome history, margin, contact cost, constraints, experiment results. | | Primary output | Personalised experiences, journey state, audience activation and reporting. | A ranked, sized decision per customer, returned as the input to the experience. | | Usual owner | Marketing operations and experience teams. | Growth, data science and revenue leadership. | | How it's measured | Engagement, journey performance, personalisation lift within the experience. | Incremental revenue and ARPU against a holdout. | ## What a full Adobe estate still leaves open Personalisation answers how an experience should be tailored once you have decided to deliver it. The prior question, of everything we could put in front of this customer, which one is commercially worth the moment, is usually settled by audience rules and a campaign calendar. - A better-personalised version of the wrong offer is still the wrong offer. - Audience qualification is rule-based; concurrent qualification is resolved by suppression and priority ordering, not by expected value. - Experience-level lift is measured within the channel, rarely as incremental revenue across everything the customer received. - The rate of new commercial hypotheses is bounded by the operations backlog, not by the data. ## How the two run together 1. **Context in.** Markin reads unified customer context, Real-Time CDP profiles alongside warehouse, product and billing data, plus the outcome history required to learn from past treatments. 2. **Decision.** Opportunities are generated, sized and ranked per customer. A treatment is chosen, a control group assigned and an expected value attached before anything is delivered. 3. **Activation back into Adobe.** The decision returns as a profile attribute or event, so Journey Optimizer selects and personalises the experience. Content, channel and experience design stay with Adobe. ## Adobe's own decisioning layer Products: Journey Optimizer AI Decisioning, Offer Decisioning, Real-Time CDP, Adobe AI Assistant Adobe has the most complete decisioning product of the group: real-time ranking, journey arbitration, frequency capping, experimentation and global control groups. It is also the only vendor here that publishes the hard limits of that engine, and those limits describe an offer-catalogue architecture rather than an opportunity-generation one. **What it optimises** - AJO AI decisioning combines a real-time decision engine, AI ranking of options by likelihood of engagement, eligibility constraints, frequency capping and AI model insights reporting conversion or revenue lift. [Vendor page: Adobe, Journey Optimizer AI decisioning](https://business.adobe.com/products/journey-optimizer/ai-decisioning.html) - Adobe ships experimentation with global control groups, an automatically held-out subset used to measure true impact, plus send-time optimisation, with AI journey path, channel and arbitration optimisation flagged as coming soon. [Vendor page: Adobe, Journey Optimizer AI decisioning](https://business.adobe.com/products/journey-optimizer/ai-decisioning.html) **Documented constraints** - Adobe publishes decisioning guardrails: a maximum of 10,000 decision items, item size capped at 1KB with 30 attributes, 500 items per collection and 30 decision items returned per policy. [Vendor docs: Adobe Experience League, Decisioning guardrails](https://experienceleague.adobe.com/en/docs/journey-optimizer/using/decisioning/experience-decisioning/decisioning-guardrails) - Further documented ceilings: a maximum of 5 AI ranking models, 1,000 placements, 10 decision policies per email, and 1,500 to 5,000 decision requests per code-based experience API call depending on Edge segmentation. [Vendor docs: Adobe Experience League, Decisioning guardrails](https://experienceleague.adobe.com/en/docs/journey-optimizer/using/decisioning/experience-decisioning/decisioning-guardrails) - Full value depends on Adobe Experience Platform and Real-Time CDP being the customer data foundation underneath Journey Optimizer. [Vendor page: Adobe, Journey Optimizer AI decisioning](https://business.adobe.com/products/journey-optimizer/ai-decisioning.html) **Evidence** - Adobe was named a Leader in the 2026 Gartner® Magic Quadrant™ for Personalization Engines (published 3 February 2026), a genuine independent report, though the promotional framing is Adobe's selection from it. [Analyst report: Gartner® Magic Quadrant™ for Personalization Engines (2026)](https://business.adobe.com/resources/reports/gartner-mq-personalization-engines-2026.html) - Adobe's AI model insights surface conversion and revenue lift for your own programmes, but no aggregate customer uplift benchmark is published. [Vendor page: Adobe, Journey Optimizer AI decisioning](https://business.adobe.com/products/journey-optimizer/ai-decisioning.html) **Where Markin differs** - **Opportunities are generated, not catalogued.** Adobe ranks items from a decision catalogue someone has to author and maintain within published limits. Markin generates and sizes the opportunity from customer context, so the space of things worth doing is not capped by a catalogue. - **Above the platform, not inside it.** Markin runs on the warehouse alongside AEP rather than requiring the full Experience Platform footprint before decisions can be made, and writes decisions back into AJO for delivery. - **Ranked on money, not engagement likelihood.** AI ranking orders options by likelihood of engagement. Markin orders them by expected incremental revenue net of cost, which is why not contacting can win. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin does not deliver experiences, emails or on-site personalisation. - Markin does not replace Real-Time CDP profiles or the identity graph. - Markin does not manage consent, data governance or brand controls. - Markin does not replace Journey Optimizer; it supplies the decision that starts the right journey. ## Where Markin fits Markin does not build experiences. It decides which opportunity deserves one, then hands that decision to Adobe so the journey and personalisation machinery does what it is good at. The enterprise governance you have already implemented does not move. - **The decision precedes the experience.** Journey entry becomes a ranked opportunity with an expected value rather than an audience rule, so personalisation is applied to the offer worth making. - **Governance stays in place.** Profiles, consent, data governance and brand controls remain Adobe's. Markin reads context in place and writes decisions back. - **Revenue-level proof.** Each decision carries a holdout, so the number reported to the business is incremental revenue rather than in-channel lift. Next: [Next-Best Action](https://markin.ai/solutions/next-best-action) ## When Markin is not the right answer - Your priority is improving creative and experience quality rather than choosing between commercial opportunities. - You lack the outcome history required to size opportunities or evaluate treatments. - You want to consolidate vendors. This layer adds a decision capability; it does not remove an experience platform. ## FAQ **Adobe Journey Optimizer already has AI decisioning. Why add a layer?** Adobe's decisioning is the most complete in the category: real-time ranking, eligibility rules, frequency capping, experimentation with global control groups, and a 2026 Gartner Magic Quadrant Leader placement for Personalization Engines. It is also catalogue-based, and Adobe publishes the ceilings, 10,000 decision items, 30 items returned per policy, 5 AI ranking models, 1,000 placements. Markin generates and sizes opportunities from customer context instead of ranking a maintained catalogue, then writes the chosen decision into AJO. **Do we have to replace Adobe?** No. Adobe remains the profile and experience layer. Markin decides which opportunity deserves the moment and returns that decision so Journey Optimizer can execute and personalise it. **Real-Time CDP already has audiences and offers. Why add a decision layer?** Audiences describe who qualifies and offer management describes what can be shown. Neither estimates the incremental revenue of acting, ranks competing opportunities by expected value, or enforces a holdout by default. **How does the decision reach Journey Optimizer?** As a profile attribute or event that journeys can key off, so the experience team works with the interfaces they already use. **Does this create a governance problem?** It should not. Consent and eligibility rules are treated as hard constraints on what Markin may decide, and every decision is auditable with the reason and expected value attached. **How is Markin different from the decisioning or AI already inside Adobe?** 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 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?** On the assumptions preloaded above, 8.0M customers at 32 a month, 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. Source: https://markin.ai/compare/markin-and-adobe --- --- title: Markin + Optimizely: from winning experiments to deciding what is worth testing url: https://markin.ai/compare/markin-and-optimizely kind: stack description: Optimizely proves which variation wins. Markin decides which revenue opportunity is worth testing and acts on every customer continuously, against a holdout. --- # Markin + Optimizely: from winning experiments to deciding what is worth testing > Optimizely is an experimentation and feature-flagging platform: it runs A/B tests and bandits on variations you define and reports which wins on a metric you chose. Markin sits above it and decides which commercial opportunity deserves a test in the first place, sizes the revenue behind it, and acts continuously on customers who never enter an experiment. The learning happens in Optimizely; the decision of what to learn and who to act on happens in Markin. ## What each layer is **Optimizely** — An experimentation and feature-flagging platform that deploys code behind flags, runs A/B/n tests and multi-armed bandits, and reports which variation performs on a defined success metric with valid statistics. Answers: Which variation performs better on this metric, and how confidently? **Markin, the decision + execution layer** — A layer that discovers and sizes revenue opportunities per customer, selects the treatment with the highest expected incremental value, and assigns a control group, deciding what is worth testing and who to act on. Answers: Which opportunity deserves an experiment, and which action should this customer receive now? ## Side by side | | Optimizely | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | Which variation performs better on this metric, and how confidently? | Which opportunity deserves an experiment, and which action should this customer receive now? | | Primary input | Variations, a success metric, traffic allocation, audience targeting. | Customer context, outcomes, margins, costs, contact history, past experiment results. | | Primary output | A statistical read per variation: lift, confidence interval, significance. | A ranked, sized decision per customer, including hold, that can feed an Optimizely flag or act directly in other channels. | | Usual owner | Product, engineering and experimentation. | Growth, data science and revenue leadership. | | How it's measured | Lift on the chosen metric with significance and confidence interval. | Incremental revenue and ARPU against a holdout. | ## What stays unsolved when experimentation is running well A mature Optimizely setup tests whatever the team writes into it, at the cadence the team can ship. Experimentation throughput is bounded by the hypotheses a human decides to formalise, and the customers a flag is wired into, rather than by what the data is signalling across the base. - An experiment only covers customers who hit the flagged surface; the rest of the base receives no decision at all. - Stats Accelerator finds the best variation inside a test; it does not decide whether the test itself is the highest-value use of that contact. - Each experiment reports on one metric. Nothing sums the effect of every experiment a customer saw into one revenue number. - The backlog of hypotheses arrives at the speed the team can write specs, not at the speed the data changes. ## How the two run together 1. **Context in.** Markin reads customer context where it already lives, warehouse, CDP, product and billing systems, plus outcome history. Optimizely experiment results and flag exposure can be part of that context, so learning feeds the next decision. 2. **Decision.** Markin generates and sizes revenue opportunities, ranks them per customer, chooses a treatment and assigns a control group. Some decisions become Optimizely experiments; most become direct actions in other channels. 3. **Activation back into Optimizely.** Where a hypothesis needs a controlled test, the decision is written back as flag targeting or audience criteria so Optimizely runs it with its own stats engine. Flag logic, variation code and significance reporting remain in Optimizely. ## Optimizely's own decisioning layer Products: Optimizely Feature Experimentation, Optimizely Web Experimentation, Optimizely Personalization, Stats Engine, Stats Accelerator Optimizely is an experimentation and feature-flagging platform. It deploys code behind flags, runs A/B tests and bandits on variations you define, and proves which variation wins on a success metric you chose. It does not decide which commercial opportunity is worth testing, size the revenue behind it, or act on customers who never enter an experiment. **What it optimises** - Optimizely Feature Experimentation is documented as a feature-flagging and experimentation platform for deploying code behind flags, running A/B tests and targeted rollouts across web, mobile and connected devices. [Vendor docs: Optimizely docs, Introduction to Feature Experimentation](https://docs.developers.optimizely.com/feature-experimentation/docs/welcome) - Optimizely offers Frequentist (fixed-horizon), Bayesian and Sequential (Stats Engine) statistical methods, with sequential testing that keeps results valid whenever they are viewed and ends experiments early on average with fewer observations. [Vendor docs: Optimizely Support, Statistical analysis methods overview](https://support.optimizely.com/hc/en-us/articles/39714777161229-Statistical-analysis-methods-overview) - Stats Accelerator is documented as a multi-armed bandit algorithm that manipulates traffic allocation to shorten time to statistical significance and optimise rewards during a test. [Vendor docs: Optimizely Support, Stats accelerator overview](https://support.optimizely.com/hc/en-us/articles/4410283570701-Stats-accelerator-overview) **Documented constraints** - The documented unit of optimisation is the variation on a defined success metric, with traffic distributed across variations. Choosing what to test, and which metric defines success, remains a human decision outside the platform. [Vendor docs: Optimizely Support, Experimentation distribution methods](https://support.optimizely.com/hc/en-us/articles/4410289050893-Experimentation-distribution-methods) - Stats Accelerator and multi-armed bandits allocate traffic within a single experiment's variations; they do not arbitrate which of many possible commercial opportunities across the base deserves attention. [Vendor docs: Optimizely Support, Experimentation distribution methods](https://support.optimizely.com/hc/en-us/articles/4410289050893-Experimentation-distribution-methods) **Evidence** - Optimizely's documented performance claims concern statistical validity and speed-to-significance (Stats Engine, Stats Accelerator), not verified incremental revenue. No independent benchmark of Optimizely's impact on ARPU or revenue is published. [Vendor docs: Optimizely Support, Statistical analysis methods overview](https://support.optimizely.com/hc/en-us/articles/39714777161229-Statistical-analysis-methods-overview) **Where Markin differs** - **Decides what to test, not which variation wins.** Optimizely answers 'which variation performs better on this metric'. Markin answers 'which opportunity is worth running an experiment on at all', and surfaces the ones no one thought to test. - **Optimises revenue across the base, not a metric on one test.** Stats Accelerator reallocates traffic inside an experiment. Markin reallocates contact and treatment across the whole customer estate, on expected incremental revenue net of margin and cost. - **Holds across the estate, by default.** An Optimizely holdout is a traffic split within one experiment. Markin attaches a control group to every decision, so the reported number is incremental ARPU against holdout rather than a significance read on a flag. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin does not run A/B tests, feature flags or bandits. Experimentation stays in Optimizely. - Markin does not replace Stats Engine, Stats Accelerator or Optimizely's statistical reporting. - Markin is not an analytics or release-management tool; it decides what is worth testing and who to act on. - Markin does not manage variation code, rollouts or flag environments. ## Where Markin fits Markin does not run experiments or replace flags. It decides which revenue opportunity is worth a test, and acts on the customers a flag never reaches. Experimentation keeps its stats engine, its bandits and its release safety; what changes is the input that decides what gets tested and who gets acted on. - **The experiment queue becomes a decision, not a backlog.** Instead of a product roadmap of tests, the highest-value hypotheses are surfaced and sized from the data, so experimentation capacity is spent where the revenue is. - **Coverage extends beyond the flagged surface.** Customers who never enter an experiment still receive a decision, a save, an attach, a hold, measured against control in the channels they do use. - **Learning and acting share one record.** Optimizely results feed Markin, and Markin's holdout feeds back, so the next round of hypotheses improves on proven numbers rather than drifting. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - You run a handful of experiments a quarter and the team can still reason about which to prioritise in a meeting. - Every customer decision already flows through a flagged surface, so there is no unaddressed base to act on. - Your success metric cannot be tied to revenue, so neither experiments nor decisions can be valued. ## FAQ **Doesn't Optimizely already decide things with bandits?** Stats Accelerator and multi-armed bandits reallocate traffic between variations inside one experiment to reach significance faster or maximise reward during the test. They optimise the test you already wrote; they do not decide which opportunity is worth testing, size the revenue behind it, or act on customers who never enter the experiment. **Do we have to replace Optimizely?** No. Optimizely remains the experimentation and feature-flagging layer. Markin decides which hypothesis deserves a test and passes that decision into Optimizely as flag targeting, while acting on the rest of the base directly in other channels. **How does the decision reach Optimizely?** As flag targeting rules or audience criteria on a flag, so an existing experiment picks it up. The integration surface is the same one your team already uses for any other upstream signal. **Isn't running experiments all the time the same as decisioning?** No. Experimentation tests a few hypotheses at human cadence on the surfaces you flagged. Continuous decisioning acts on every customer, every cycle, with a control group by default, including customers no experiment reaches. Experiments prove what works; decisioning decides who gets it and who gets held. **Who owns the output, product or growth?** Both. Product and engineering own the experiments and the flags; growth and data science own the revenue decision. The decision layer is the shared contract between them. **What does the first ninety days look like?** One revenue theme, one channel, a real holdout. The point of the first quarter is a defensible incremental number, not full coverage of the experiment backlog. **How is Markin different from the decisioning or AI already inside Optimizely?** 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 Optimizely 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 Optimizely?** On the assumptions preloaded above, 3.0M customers at 22 a month, 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. Source: https://markin.ai/compare/markin-and-optimizely --- --- title: Markin + Amplitude: from behavioural insight to revenue decisions url: https://markin.ai/compare/markin-and-amplitude kind: stack description: Amplitude observes behaviour and tests features. Markin turns that into sized revenue decisions per customer, across channels, measured against a holdout. --- # Markin + Amplitude: from behavioural insight to revenue decisions > Amplitude is product analytics with experimentation and recommendations: it observes behaviour, builds cohorts, runs feature experiments and can recommend content toward a predictive goal. Markin sits above it and converts that observation into sized revenue decisions per customer, which action, in which channel, at what cost, with a holdout attached. Amplitude shows what is happening; Markin decides what to do about it, in revenue terms. ## What each layer is **Amplitude** — A product analytics platform with feature experimentation and content recommendations: behavioural insight, cohorts, A/B tests and AutoML item recommendations toward a predictive goal. Answers: What is happening in the product, and which feature variation or item performs? **Markin, the decision + execution layer** — A layer that turns behavioural signal into sized revenue decisions per customer, selecting the treatment with the highest expected incremental value and assigning a control group. Answers: Given what we see, which revenue action is worth taking for this customer, and what is it worth? ## Side by side | | Amplitude | Markin, the decision + execution layer | | --- | --- | --- | | Question it answers | What is happening in the product, and which feature variation or item performs? | Given what we see, which revenue action is worth taking for this customer, and what is it worth? | | Primary input | Instrumented events, user properties, experiment variants, predictive goals. | Behaviour and cohorts from analytics, outcomes, margins, costs, contact history, constraints. | | Primary output | Behavioural analysis, cohorts, experiment significance, ranked recommendations. | A ranked, sized decision per customer, including hold, pushed into the channels that can act on it. | | Usual owner | Product, analytics and experimentation. | Growth, data science and revenue leadership. | | How it's measured | Significance on the experiment metric; recommendation take rate and relevance. | Incremental revenue and ARPU against a holdout. | ## What stays unsolved when analytics is running well A mature Amplitude setup shows exactly what is happening and tests features well. Insight does not decide itself: turning 'users who do X churn more' into 'who to save, with what, at what cost, and who to leave alone' is a separate job, and it is normally done in a planning meeting and a spreadsheet. - A cohort describes a population; it does not attach a revenue value, a margin or a cost per intervention to each customer in it. - An experiment proves a feature works on a metric; it does not decide who should receive the rolled-out feature, or who should be held. - Recommendations maximise a predicted engagement goal, not incremental revenue net of contact cost, so the highest-relevance item is not always the highest-value action. - Holdout groups measure the program's combined lift, not the incremental revenue of each commercial decision as it is made. ## How the two run together 1. **Context in.** Markin reads behavioural context where it already lives, Amplitude events and cohorts, warehouse, CDP, billing, plus outcome history. Observation becomes one of the inputs to the decision, not the output. 2. **Decision.** Markin generates and sizes revenue opportunities, ranks them per customer, chooses a treatment and assigns a control group. The output is one decision per customer, with an expected value attached. 3. **Activation into channels.** The chosen decision is written back as user attributes or triggered events, so engagement and lifecycle channels act on it. Where a feature needs validation, the decision can feed an Amplitude Experiment as targeting. ## Amplitude's own decisioning layer Products: Amplitude Analytics, Amplitude Experiment, Recommendations (Activation), Personalization, Holdout groups Amplitude is product analytics with an experimentation and recommendations layer. It observes behaviour, builds cohorts, runs feature experiments and can recommend content toward a predictive goal. It does not size the revenue opportunity behind the behaviour or decide cross-channel actions in margin and cost terms. **What it optimises** - Amplitude is a product analytics platform that turns instrumented events into behavioural insight, funnels, retention, cohorts and user journeys. [Vendor docs: Amplitude docs, Recommendations (Activation)](https://amplitude.com/docs/data/audiences/recommendations) - Amplitude Experiment runs feature experiments using a sequential testing method that keeps results valid whenever they are viewed and ends experiments early, on average, with fewer observations. [Vendor docs: Amplitude docs, Sequential testing for statistical inference](https://amplitude.com/docs/feature-experiment/under-the-hood/experiment-sequential-testing) - Recommendations (Activation) use AutoML to determine which items are most likely to maximise each user's predicted goal, for use in personalisation campaigns. [Vendor docs: Amplitude docs, Recommendations: help users reach their goals](https://amplitude.com/docs/data/audiences/recommendations) **Documented constraints** - Amplitude's holdout groups measure the long-term, combined lift of an experimentation program as a whole, not the incremental revenue of a per-customer commercial decision across channels. [Vendor docs: Amplitude docs, Holdout groups](https://amplitude.com/docs/feature-experiment/advanced-techniques/holdout-groups-exclude-users) - The optimisation unit is an experiment metric or a content recommendation toward a predictive goal. Revenue at stake, margin and contact cost per customer are not part of the recommendation decision. [Vendor docs: Amplitude docs, Build a recommendation](https://amplitude.com/docs/data/audiences/recommendations-build) **Evidence** - Amplitude's documented performance material concerns experiment significance and recommendation relevance. No independent benchmark of Amplitude's impact on incremental revenue is published. [Vendor docs: Amplitude docs, Analyze your experiment data with the T-test](https://amplitude.com/docs/feature-experiment/experiment-theory/analyze-with-t-test) **Where Markin differs** - **Observes and tests; Markin decides the commercial action.** Amplitude answers 'what is happening, and which feature variation wins'. Markin answers 'which revenue action is worth taking for this customer, and what is it worth', turning observation into a decision. - **From a metric to a revenue decision.** A recommendation maximises a predicted goal; a Markin decision maximises expected incremental revenue net of margin and contact cost, which is why hold is a legitimate output. - **Per-customer decision across the estate.** Amplitude cohorts and experiments group users. Markin produces one sized decision per customer, across every channel, and reports it against a holdout, not an experiment metric. ## What Markin does not replace To be explicit about scope, because procurement will ask: - Markin does not replace Amplitude Analytics, dashboards, funnels or cohort building. - Markin does not run feature experiments or replace Amplitude Experiment's stats engine or holdout groups. - Markin is not a content recommendation engine; it decides commercial actions in revenue terms. - Markin does not manage event instrumentation or data governance. ## Where Markin fits Markin does not replace analytics or experiments. It turns what Amplitude observes into per-customer revenue decisions with a holdout attached, and acts in the channels that can move revenue, including customers a feature experiment never reaches. - **Insight becomes a decision, not a deck.** A behavioural finding is converted into a sized opportunity and a chosen treatment per customer, so the insight leaves the meeting and reaches the customer. - **Recommendations are ranked by revenue, not relevance.** Treatments are selected on expected incremental revenue net of margin and cost, so the highest-value action wins the contact even when it is not the most relevant item. - **Measured against holdout, by default.** Every decision carries a control group and reports incremental ARPU, rather than a significance read on a feature metric or a program-level lift. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - You cannot connect a behavioural signal to a revenue outcome, so neither analytics nor decisions can be valued. - Your only actions are in-product feature rollouts with no commercial treatment or channel to act in. - Your base is small enough that the team can reason about every cohort by hand. ## FAQ **Doesn't Amplitude already have recommendations and experiments?** Yes. Amplitude Experiment runs feature experiments with sequential testing, and Recommendations uses AutoML to suggest items that maximise a predicted goal. Both optimise a metric or an engagement goal inside Amplitude. They do not size the revenue at stake per customer, choose a cross-channel treatment in margin-and-cost terms, or decide who to hold. **Do we have to replace Amplitude?** No. Amplitude remains the analytics and experimentation layer. Markin reads the signals Amplitude produces, turns them into sized revenue decisions, and hands them to the channels that can act on them. **How does the decision leave Amplitude?** As user attributes or triggered events on the profile, so engagement and lifecycle channels can key off them. Where a feature needs validation, the decision can also feed an Amplitude Experiment as targeting. **What is the difference between an Amplitude holdout and a Markin holdout?** An Amplitude holdout group measures the long-term combined lift of your experimentation program as a whole. A Markin holdout is attached to each commercial decision, so the reported number is the incremental revenue of that specific action, not a program-level average. **Who owns the output, product or growth?** Both. Product and analytics own the insight and the experiments; growth and data science own the revenue decision. The decision layer is the shared contract between them. **What does the first ninety days look like?** One revenue theme, one channel, a real holdout. The point of the first quarter is a defensible incremental number, not full coverage of every cohort. **How is Markin different from the decisioning or AI already inside Amplitude?** 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 Amplitude 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 Amplitude?** On the assumptions preloaded above, 2.5M customers at 16 a month, 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. Source: https://markin.ai/compare/markin-and-amplitude --- --- title: Recommendation engine vs. next-best action url: https://markin.ai/compare/recommendation-engine-vs-next-best-action kind: category description: A recommendation engine surfaces the right content. Next-best action chooses the right commercial treatment. Why relevance is not revenue. --- # Recommendation engine vs. next-best action > A recommendation engine predicts which item or content a user will engage with and ranks by relevance. Next-best action selects the commercial treatment, an offer, a save, a channel, a hold, that maximises expected incremental revenue for a sized opportunity. A rec engine answers 'what should we show'; an NBA answers 'what is worth doing, and what is it worth'. The two are complementary, not substitutes. ## What each layer is **Recommendation engine** — A system that predicts and ranks the items, content or products a user is most likely to engage with, using collaborative filtering, content models or embeddings. Answers: What should we surface to this user next? **Next-best action** — A layer that sizes the commercial opportunity for a customer and selects the treatment, message, offer, channel, timing or hold, that maximises expected incremental revenue. Answers: Which action is worth taking for this customer, and what is it worth? ## Side by side | | Recommendation engine | Next-best action | | --- | --- | --- | | Question it answers | What should we surface to this user next? | Which action is worth taking for this customer, and what is it worth? | | Primary input | Item features, interaction history, user embeddings, catalogue metadata. | Opportunities, uplift models, margins, costs, contact history, constraints. | | Primary output | A ranked list of items by predicted engagement or relevance. | One chosen action per customer, including a deliberate hold. | | Usual owner | Product, data science. | Growth, data science, revenue leadership. | | How it's measured | Click-through rate, take rate, watch time, relevance. | Incremental revenue and ARPU against a holdout. | ## Why a great recommendation can leave revenue on the table Recommendation engines optimise engagement within a fixed catalogue. Relevance is not value: the most relevant next item is rarely the highest-value commercial action, and a rec engine has no concept of margin, cost or when not to act. - A rec engine ranks items by predicted engagement; it attaches no revenue value, margin or cost to the action behind the recommendation. - It cannot surface a commercial opportunity nobody modelled, an upgrade, a save, a reactivation, because its output space is the catalogue. - It cannot decide to hold: there is always a next-best item, even when no item has positive expected value. - Its impact is measured on take rate and engagement, not on incremental revenue against a control group. ## Where Markin fits Markin treats the recommendation as one candidate action among many. The intelligence layer sizes the revenue opportunity behind it, the action layer chooses whether to recommend, to offer, to save or to hold, and the whole loop is measured against control. - **Recommendations become a candidate, not the answer.** A rec engine's output is one input to the decision; the action layer compares it against a save, an upgrade or a hold and picks the highest expected incremental value. - **Ranked by revenue, not relevance.** Actions are selected on expected incremental revenue net of margin and cost, so the highest-value move wins the customer's attention even when it is not the most relevant item. - **Hold is a first-class output.** When no action has positive expected value, the decision is to do nothing, something a rec engine, which always returns a next item, cannot express. Next: [Next-Best Action](https://markin.ai/solutions/next-best-action) ## When Markin is not the right answer - Your only commercial lever is surfacing content, and engagement is the business model: there is no treatment selection problem to solve. - Your catalogue has no commercial action behind it, so there is nothing to size in revenue terms. - You cannot connect a recommendation to an outcome, so the loop cannot be validated against control. ## FAQ **Is a next-best action system just a recommendation engine?** No. A recommendation engine predicts the next item a user will engage with. A next-best action system sizes the commercial opportunity for a customer and chooses the treatment, offer, save, channel, hold, that maximises expected incremental revenue. The rec engine answers 'what to show'; the NBA answers 'what to do, and what is it worth'. **Can a recommendation engine do retention?** It can recommend content that keeps a user engaged, which indirectly helps retention. It cannot decide who is worth saving, with which treatment, at what cost, or who to leave alone, those are commercial decisions that need uplift, margin and cost, not relevance. **Do the two compete?** No. They are complementary. A recommendation engine is a strong candidate-action source; the next-best action layer decides whether to recommend, to offer something commercial, or to hold, and proves the choice against a holdout. **How is Markin different from the decisioning or AI already inside recommendation engine?** 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 recommendation engine 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 recommendation engine?** On the assumptions preloaded above, 5.0M customers at 14 a month, 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. Source: https://markin.ai/compare/recommendation-engine-vs-next-best-action --- --- title: Experimentation vs. continuous decisioning url: https://markin.ai/compare/experimentation-vs-continuous-decisioning kind: category description: A/B testing proves which variation wins on one metric. Continuous decisioning acts on every customer every cycle, with a holdout. Why testing is not deciding. --- # Experimentation vs. continuous decisioning > An experimentation platform runs controlled A/B/n tests on predefined variations and reports which wins on a chosen metric with valid statistics. Continuous decisioning decides the right action per customer, every cycle, with a holdout by default, across the whole base, including customers no experiment reaches. Experiments prove what works; decisioning decides who gets it, who is held, and what it is worth. ## What each layer is **Experimentation platform** — A platform that runs controlled A/B/n tests and bandits on predefined variations, on a defined success metric, and reports lift with significance and confidence intervals. Answers: Which variation performs better on this metric, and how confidently? **Continuous decisioning** — A layer that decides the right action per customer, every cycle, across the whole base, selecting treatments, sizing revenue and assigning a control group by default. Answers: Which action should this customer receive now, and is it worth it? ## Side by side | | Experimentation platform | Continuous decisioning | | --- | --- | --- | | Question it answers | Which variation performs better on this metric, and how confidently? | Which action should this customer receive now, and is it worth it? | | Primary input | Variations, a success metric, traffic allocation, audience targeting. | Opportunities, treatments, uplift models, margins, costs, past experiment results. | | Primary output | A statistical read per variation: lift, confidence interval, significance. | One action or hold per customer, ongoing, with expected value attached. | | Usual owner | Product, engineering, experimentation. | Growth, data science, revenue leadership. | | How it's measured | Lift on the chosen metric with significance and confidence interval. | Incremental ARPU and revenue against a holdout. | ## Why a strong experimentation program is not yet a decisioning system Experimentation tests a few hypotheses at the cadence a team can ship, on the surfaces that carry a flag. It proves what works; it does not decide who should receive it, act on customers a flag never reaches, or hold when nothing has positive value. - An experiment only covers customers who hit the flagged surface; the rest of the base receives no decision at all. - Each experiment reports on one metric; nothing sums the effect of everything a customer saw into one revenue number. - A holdout is a traffic split within one experiment, not a control group attached to every commercial decision across the estate. - The hypothesis backlog arrives at the speed the team can write specs, not at the speed the data changes. ## Where Markin fits Markin treats experiment results as one of the inputs to the decision. The intelligence layer sizes the revenue opportunity, the action layer chooses the treatment for every customer, and a control group is attached by default, so learning and acting share one record and the loop improves on proven numbers. - **Experiment results feed the decision, not a backlog.** What a test proved becomes an input to the next cycle of decisions, so the program compounds rather than producing isolated learnings. - **Every customer gets a decision, every cycle.** Customers a flag never reaches still receive an action, a save, an attach, a hold, measured against control in the channels they do use. - **A holdout on every decision, not every experiment.** The control group is attached to each commercial action, so the reported number is incremental revenue per decision, not a program-level lift. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - You run a few experiments a quarter and the team can still reason about who should receive the winner. - Every customer decision already flows through a flagged surface, so there is no unaddressed base to act on. - Your success metric cannot be tied to revenue, so neither experiments nor decisions can be valued. ## FAQ **Is continuous decisioning just running A/B tests all the time?** No. Running tests continuously still tests a few hypotheses at human cadence on flagged surfaces. Continuous decisioning acts on every customer, every cycle, with a control group by default, including customers no experiment reaches. Experiments prove what works; decisioning decides who gets it and who is held. **Do experimentation and decisioning conflict?** No. They are complementary. Experimentation proves which treatments work; decisioning uses those results as an input, chooses who receives the proven treatment, and holds the rest against a control group. Learning and acting share one record. **What about multi-armed bandits, don't they decide?** Bandits allocate traffic between variations inside one experiment to maximise reward during the test. They optimise the test you already wrote; they do not decide which opportunity is worth testing, act on customers outside the flagged surface, or hold when no action has positive value. **How is Markin different from the decisioning or AI already inside experimentation 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 experimentation 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 experimentation platform?** On the assumptions preloaded above, 3.0M customers at 20 a month, 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. Source: https://markin.ai/compare/experimentation-vs-continuous-decisioning --- --- title: Markin and your data science team url: https://markin.ai/compare/markin-and-your-data-science-team kind: stack description: Markin multiplies data science: your team owns models, economics and causal design, Markin runs millions of decisions against a holdout, continuously. --- # Markin and your data science team > Markin runs on top of your data science team, not instead of it. The team owns features, models, economics and causal design. Markin behaves like an extra bench of scientists that never sleeps: it writes its own hypotheses, marketing, product, pricing or a technical anomaly holding growth back, sizes them, launches them in the systems you already run, and reads every one against a randomised control group, at a volume no analyst team can sustain by hand. ## What each layer is **Your data science team** — The people who understand your customers quantitatively: features, propensity and uplift models, causal design, the economics behind every number. Answers: What is likely to happen, and what actually caused it? **Markin, decision + execution** — The system that consumes those models at machine cadence: generating and sizing opportunities, choosing one action per customer, and proving it against a holdout. Answers: For this customer, right now, what is the highest-value action? ## Side by side | | Your data science team | Markin, decision + execution | | --- | --- | --- | | Question it answers | What is likely to happen, and what actually caused it? | For this customer, right now, what is the highest-value action? | | Primary input | Warehouse data, event streams, domain knowledge | Your models, constraints, economics and outcome history | | Primary output | Models, scores, experiment designs, readouts | One sized, ranked decision per customer, with a control group | | Usual owner | Data science / analytics | Steered by data science, run continuously | | How it's measured | Model quality, validity of the causal read | Incremental ARPU against a randomised holdout | ## The bottleneck was never modelling. It is what happens to the score. A strong data science team can model anything you put in front of it. What it cannot do is spend a customer-level score at customer level across millions of people, every week, with a control group on each decision. So excellent models end their life in a monthly segment export, and the causal work is reserved for the flagship programmes. That is a throughput gap, not a competence gap. - Customer-level scores get collapsed into segments because that is the only unit downstream tooling can act on. - Sizing every candidate opportunity by hand costs more analyst time than most opportunities are worth, so prioritisation defaults to intuition. - Holdouts are wired manually, so most of what ships is never attributed to anything. - Senior analysts spend the week pulling data, building lists and reconciling reports instead of on causal judgement. - Model retraining is scheduled, not driven by what the last decisions actually proved. ## How data science and the decision layer run together 1. **The team sets the frame.** Features, models worth trusting, margin and contact economics, eligibility rules, and how a causal read must be designed to count. This stays with the people who know your business. 2. **Markin runs the volume.** Inside that frame, Markin generates candidate actions, sizes the revenue behind each, ranks them per customer, chooses one, and holds a randomised control group back, continuously, across the whole base, without a ticket. 3. **Evidence comes back to the team.** Every decision returns a measured result: what beat control, by how much, for whom. Data science reads the evidence, retrains on it, adjusts the frame and audits the system. The loop compounds instead of resetting each quarter. ## What Markin does not replace To be explicit, because this is the question every analytics leader asks first: - Markin does not replace data scientists. Feature engineering, domain models and causal judgement stay with the people who own them. - Markin does not hide its reasoning. Every decision is auditable back to the inputs and the model outputs that produced it. - Markin does not force you off your models. Bring your own propensity and uplift models, or override any model in the loop. - Markin does not own your warehouse. It reads from where your data already lives; no migration, no new source of truth. - Markin is not a reporting tool. It produces decisions and the evidence that they worked; your analytics stack stays where it is. ## Where Markin fits The split is simple: your team owns the science, Markin owns the arithmetic repeated millions of times. Modelling, economics and causal design stay human. Sizing, ranking, choosing, holding out and measuring stop being a roadmap item and become a system that runs while the team sleeps. - **Your models finally get used at customer level.** A propensity or uplift model built by your team feeds a per-customer decision that also knows margin, contact cost and eligibility. The score stops ending its life in a segment export. - **Causal design becomes the default, not the exception.** A randomised holdout on every decision means the model you shipped has a measured incremental effect, not a correlation you have to defend in a readout. - **Analysts become owners of a decision system.** Instead of servicing campaign requests, data science defines and audits the system that makes millions of decisions, a far larger surface of influence with the same headcount. - **Retraining driven by outcomes, not by calendar.** Each decision returns a labelled result under a known treatment assignment, which is the cleanest training data your models will ever get. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - You have no outcome history and no channel to act in, so there is nothing to learn from or decide about yet. - The organisation is not willing to hold out a control group, in which case nothing here can be verified. - Your base is small enough that a person can reasonably reason about every customer segment in a meeting. ## FAQ **Does Markin replace my data science team?** No, and a team that tried to run Markin without data scientists would get less out of it. Markin removes the manual decisioning work: sizing candidates by hand, exporting segments, wiring holdouts, reconciling readouts. The scarce skill, knowing what to optimise, what to constrain and what a causal read actually proves, becomes more valuable, not less. **Who owns the models?** You do. Markin uses the features, propensity and uplift models your team already maintains, alongside its own opportunity sizing, and every decision is auditable back to the inputs that produced it. Your team can inspect, override or replace any model in the loop. **Can we bring our own uplift models?** Yes. Bring scores from the warehouse or serve them live; Markin combines them with margin, contact cost and eligibility to choose one action per customer. Where you have no model, Markin's own sizing fills the gap until you do. **How is this different from deploying our models to a campaign tool?** A campaign tool consumes a score to build a list. A decision layer compares every candidate action for a customer on expected value, applies constraints, chooses one or holds, and attaches a control group. The output is a decision with evidence, not an audience. **How do we know the lift came from the decision layer and not the models?** You do not have to separate them, and the holdout does not care: treated and held-out cohorts differ only in whether a per-customer decision was made, in the same period, with the same models and the same seasonality. That is why the verified range we quote is post-holdout rather than pre/post. **How is Markin different from the decisioning or AI already inside your data science team?** 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 your data science team 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 your data science team?** On the assumptions preloaded above, 4.0M customers at 19 a month, 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. Source: https://markin.ai/compare/markin-and-your-data-science-team --- --- title: Markin and your growth team url: https://markin.ai/compare/markin-and-your-growth-team kind: stack description: Your team owns offers, brand and economics. Markin chooses who gets what, launches it in your tools, and reads every action against a holdout. --- # Markin and your growth team > Markin runs on top of your growth team, not instead of it. Growth owns the offer catalogue, the brand rules, the contact policy and the commercial targets. Markin is the execution capacity underneath: it finds the opportunity, decides which customer gets which treatment and when, launches it in your own channels and product surfaces, and holds a randomised control group, so the team stops building lists and starts steering a system. ## What each layer is **Your growth team** — The people who own the commercial outcome: which offers exist, which segments matter, what the brand will and will not say, and what ships this quarter. Answers: What should we launch next, and to whom? **Markin, decision + execution** — The system that runs the calendar out of the equation: sizing every opportunity, choosing one action per customer, and proving it against a holdout. Answers: For this customer, right now, what is the highest-value action? ## Side by side | | Your growth team | Markin, decision + execution | | --- | --- | --- | | Question it answers | What should we launch next, and to whom? | For this customer, right now, what is the highest-value action? | | Primary input | Scores, segments, commercial strategy, offer catalogue | Your offers, constraints, economics and outcome history | | Primary output | Campaigns, journeys, offers, a roadmap | One sized, ranked decision per customer, with a control group | | Usual owner | Growth / lifecycle / CRM | Steered by growth, run continuously | | How it's measured | Campaign performance, quarterly targets | Incremental ARPU against a randomised holdout | ## The bottleneck was never ideas. It is the calendar. A good growth team has more ideas than quarters. Each one costs a brief, a build, a list, an approval and a slot, so a base of millions gets served by a handful of campaigns a month, planned weeks ahead, aimed at segments. Everything that follows is a capacity gap, not a competence gap. - The backlog grows faster than the roadmap can clear it, so most ideas are never tested, not rejected, just never reached. - Prioritisation happens in a planning meeting, from intuition, because sizing every candidate offer by hand is not realistic. - Campaigns are aimed at segments, so the same offer lands on customers with very different expected value. - Contact pressure is managed by calendar and caps rather than by whether an action is worth sending at all. - Most of what ships is read pre/post, so nobody can say what the programme actually added. ## How growth and the decision layer run together 1. **Growth sets the frame.** Which offers exist, margin floors and contact economics, eligibility, brand and tone rules, frequency caps, and the commercial objective for the quarter. 2. **Markin runs the volume.** Inside that frame, Markin sizes the revenue behind each candidate action, ranks them per customer, chooses one or holds, and keeps a randomised control group back, continuously, across the whole base. 3. **Evidence comes back to the team.** Every decision returns a measured result: which offers beat control, by how much, for whom. Growth retires what does not work, invests in what does, and spends its time on the offers rather than the scheduling. ## What Markin does not replace To be explicit, because this is the question every growth leader asks first: - Markin does not replace growth marketers. Offers, positioning, creative and commercial judgement stay with your team. - Markin does not set strategy. Which markets, which products, which margin you are willing to give away are human decisions. - Markin does not invent guardrails. Eligibility, brand, compliance and contact policy are configured by your team and enforced, not inferred. - Markin does not replace your engagement platform. It decides; Braze, Salesforce or your CRM still deliver. - Markin does not write your creative. It chooses among the actions you allow it to choose from. ## Where Markin fits The split is simple: growth owns what may be said and what it is worth, Markin owns who gets it and when. Judgement stays human. The arithmetic of matching millions of customers to a catalogue of offers becomes a system that runs while the team sleeps. - **The calendar stops being the unit of work.** Instead of planning six campaigns a month, the team maintains a live catalogue of offers and constraints, and every customer is evaluated against all of them continuously. - **Every offer is sized before it ships.** Candidate actions carry an expected revenue figure, so prioritisation is an economic comparison rather than a debate about which idea sounds strongest. - **Contact pressure is spent where it pays.** When an action has no positive expected value, the system holds. Fewer, better-aimed messages usually beat more of them, and fatigue stops being a fixed cost of running growth. - **Every result is defensible.** A holdout by default means the number growth takes to the board survived a control group, rather than being a pre/post read with seasonality baked in. Next: [Next-Best Action](https://markin.ai/solutions/next-best-action) ## When Markin is not the right answer - Your base is small enough that a person can reasonably reason about every customer segment in a meeting. - You have no offer catalogue and no channel to act in, so there is nothing to decide between yet. - The organisation is not willing to hold out a control group, in which case nothing here can be verified. ## FAQ **Does Markin replace my growth team?** No. It removes the operational half of the job, briefs, list building, scheduling, manual prioritisation, and leaves the commercial half, which is where growth adds value. The team moves from running a calendar to owning a decision system: which offers exist, what they are worth, and what the brand will allow. **What does the growth team do differently on day one?** It stops writing a campaign calendar and starts defining the frame: which offers exist, what the margin floor is, what the brand will not say, how often a customer can be contacted. Markin decides who gets what inside that frame. **Do we still need our engagement platform?** Yes. Markin decides; your engagement platform delivers. It sends the chosen action into Braze, Salesforce, your CRM or whichever channel you already run, so nothing about execution changes. **Will this increase how much we message customers?** Usually the opposite. Because every action carries an expected value and the system holds when nothing clears the bar, volume tends to fall while incremental revenue rises. Frequency caps still apply as a hard constraint on top. **How do we know the lift came from Markin and not from the team?** Because it is measured against a randomised holdout inside the same period, with the same team, the same offers and the same seasonality. The treated and held-out cohorts differ only in whether a decision was made per customer. **How is Markin different from the decisioning or AI already inside your growth team?** 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 your growth team 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 your growth team?** On the assumptions preloaded above, 4.0M customers at 19 a month, 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. Source: https://markin.ai/compare/markin-and-your-growth-team --- --- title: vs BrazeAI Decisioning Studio: who writes the list url: https://markin.ai/compare/markin-vs-braze-ai-decisioning-studio kind: vs description: BrazeAI Decisioning Studio picks the best message inside Canvas. Markin decides which revenue opportunity deserves a message at all. updated: 2026-08-20 --- # vs BrazeAI Decisioning Studio: who writes the list > BrazeAI Decisioning Studio chooses content, channel and timing per individual, inside the messages Braze sends. Markin decides which commercial opportunity is worth pursuing for that customer at all, across marketing, product and pricing, and proves it against a holdout. One optimises the list; the other writes it. ## The short answer Both are called decisioning, and both are real. Decisioning Studio optimises what Braze sends, message, channel and time, inside Canvas. Markin sits earlier: it forms hypotheses about why ARPU is stuck, sizes them, picks one action per customer including hold, and measures it against a control group. ## The two options **BrazeAI Decisioning Studio** — The AI decisioning layer inside Braze. It selects content, channel and send time per individual across the channels Braze itself delivers, inside Canvas journeys. Choose it when the journeys are already written and the job is to send the best variant of them to each person. - Runs inside Canvas - Optimises message, channel, timing - Braze-delivered channels **Markin** — An autonomous growth-science team for large B2C bases. It investigates the base, forms and sizes its own hypotheses, chooses one action per customer, launches it through your stack and reads it against a holdout. Choose it when the bottleneck is how many good hypotheses get tested and proven, not how well the existing ones are delivered. - Decides before the journey - Holdout on every action - Executes in Braze ## Line by line | Dimension | Markin | BrazeAI Decisioning Studio | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | The AI decisioning layer of a customer engagement platform, embedded in Canvas. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | Which message, channel and send time each individual gets inside a journey a human designed. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Written by the lifecycle team as Canvases, campaigns and eligibility rules. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Messaging: email, push, in-app, SMS and web delivered by Braze. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | Braze delivers the message itself, which is what it is built to do well. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Conversion attributed to the Canvas, plus built-in variant testing. The published performance research is a Forrester TEI study commissioned by Braze. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Braze user profiles and custom events, fed from your warehouse or CDP. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Channel governance, frequency caps, brand controls and consent handling. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Fast for a new Canvas; the constraint is how quickly the team can write the next one. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Teams whose messaging programme is the growth programme. | ## What each layer is **BrazeAI Decisioning Studio** — The decisioning layer inside Braze. Selects content, channel and timing per individual across the channels Braze delivers. Answers: Which message, on which channel, at what time, for this person? **Markin** — A growth-science layer that generates and sizes hypotheses, picks one action per customer and proves it against a holdout. Answers: Which opportunity is worth acting on for this customer, and what is it worth? ## Side by side | | BrazeAI Decisioning Studio | Markin | | --- | --- | --- | | Question it answers | Which message, on which channel, at what time, for this person? | Which opportunity is worth acting on for this customer, and what is it worth? | | Primary input | Braze profiles, custom events, journey logic, content variants. | Warehouse and product context, margins, contact history, past experiment results. | | Primary output | A delivered, individually selected message inside a Canvas. | A ranked, sized decision per customer, including hold, executed through your stack. | | Usual owner | CRM and lifecycle marketing. | Growth, data science and revenue leadership. | | How it's measured | Engagement and conversion attributed to the Canvas. | Incremental revenue and ARPU against a randomised control group. | ## What BrazeAI Decisioning Studio does better - **Delivery is genuinely hard, and Braze is very good at it.** Deliverability, throughput, channel governance, consent, localisation and template management at hundreds of millions of sends a month. Markin does none of that and should not: it hands the decision to Braze and lets Braze do the part it is world-class at. - **Message-level optimisation is closer to the send.** Choosing the subject line, the channel and the hour for one individual, at send time, is best done where the send happens. Decisioning Studio has context Markin deliberately does not carry. - **One vendor is a real advantage.** If your programme is small enough that the same team writes and sends everything, adding a second system costs more than it returns. Braze alone is the right answer more often than we would like to admit. ## Which one to pick **Choose Markin if** - Your base is large enough that a customer qualifies for several journeys in the same week and priority is settled by caps, not by value. - You want the reported number to be incremental revenue against a control group, not conversions credited to a Canvas. - The hypotheses that would move ARPU are not all messaging hypotheses: pricing, product friction and technical anomalies matter too. - You need a decision that can legitimately be do not contact. - You want more tested hypotheses per quarter without hiring proportionally. **Choose Braze alone if** - Your growth programme is your messaging programme, end to end. - The lifecycle team can still reason about priority across journeys in one meeting. - Customer data is not yet reliable enough to size opportunities in money. - You want one vendor, one contract and one surface. - The current constraint is send quality and deliverability, not hypothesis supply. ## What Decisioning Studio does not answer Optimising the variant assumes the campaign deserved to exist. In a mature Braze estate there are usually more journeys than the base can absorb, and no system decides which of them earns the customer's attention this week. - Nothing sizes the revenue at stake behind a journey before it is built. - Nothing arbitrates a Braze message against an in-product placement, a service contact or a pricing change. - Reporting is per-Canvas, so no single number says what everything a customer received was worth. - Hypotheses arrive at the speed briefs are written, not at the speed the data changes. ## Where Markin fits Markin runs before Braze and executes through it. The Canvas entry stops being an eligibility segment and becomes a ranked, sized decision with a control group attached. - **Braze keeps the channel.** Templates, brand controls, consent and delivery stay exactly where they are. - **Markin supplies the reason to send.** The entry signal carries an expected value, so the highest-value action wins the week. - **Every action carries a holdout.** Incremental ARPU is measured, not attributed. Next: [Customer Decisioning](https://markin.ai/solutions/customer-decisioning) ## When Markin is not the right answer - You run a handful of journeys and priority is obvious. - You want a cheaper way to send messages: this does not replace or reduce Braze. - Your identity and event data are not yet trustworthy enough to size opportunities. ## FAQ **Is Markin an alternative to BrazeAI Decisioning Studio?** Not really, and pretending otherwise would be dishonest. Decisioning Studio optimises the messages Braze sends. Markin decides which commercial opportunity deserves a message at all, across channels and beyond messaging, then hands the chosen action to Braze to deliver. Most customers run both. **Do we have to replace Braze?** No. Braze stays the execution layer. Markin writes the decision into Braze as an attribute or event and an existing Canvas picks it up. **What does Braze do better?** Delivery at scale: deliverability, throughput, channel governance, consent, localisation and templates. Also send-time and channel selection for an individual message, which is best decided where the send happens. **How is the impact measured differently?** Braze reports conversions attributed to a Canvas. Markin assigns a randomised holdout to every decision and reports the difference in revenue per customer between treated and control. **Can Markin decide not to contact someone?** Yes, and it frequently does. Hold is a legitimate output when no available action has positive expected value net of margin and contact cost. **How is Markin different from the decisioning or AI already inside brazeai decisioning studio?** 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 brazeai decisioning studio 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 brazeai decisioning studio?** 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. Source: https://markin.ai/compare/markin-vs-braze-ai-decisioning-studio --- --- title: Markin vs Salesforce Einstein and Agentforce: decisions vs workflows url: https://markin.ai/compare/markin-vs-salesforce-einstein-agentforce kind: vs description: Einstein scores and Agentforce automates work inside Salesforce. Markin decides which revenue hypothesis is worth testing and proves it against a holdout. updated: 2026-08-20 --- # Markin vs Salesforce Einstein and Agentforce: decisions vs workflows > Einstein predicts and scores inside Salesforce objects; Agentforce runs agentic workflows over that estate. Markin is upstream of both: it investigates why ARPU is stuck across a consumer base, forms and sizes hypotheses, chooses one action per customer, and measures it against a randomised control group. ## The short answer Salesforce is strongest where the record is the unit of work: a case, a lead, an opportunity, a service conversation. Markin is strongest where the customer base is the unit of work and the question is which of ten thousand possible actions is worth taking this week, and what it returned. ## The two options **Salesforce Einstein and Agentforce** — Predictive scoring, generative assistance and agentic workflows across the Salesforce estate, grounded in Data Cloud and executed in Sales, Service and Marketing Cloud. Choose it when the work you want automated already happens inside Salesforce records and processes. - Record-centric - Runs on Data Cloud - Deep CRM automation **Markin** — An autonomous growth-science team that works the base rather than the record: hypothesis generation, sizing, arbitration, execution through your stack and holdout measurement. Choose it when growth depends on testing far more revenue hypotheses per quarter than a team can design by hand. - Base-centric - Holdout by default - Executes through existing systems ## Line by line | Dimension | Markin | Salesforce Einstein and Agentforce | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | An AI layer and agent platform embedded across the Salesforce clouds. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | The next step on a record or in a workflow: score, route, draft, escalate, recommend. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Configured by admins and architects as flows, models and agent instructions. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Sales, service and marketing processes inside the Salesforce estate. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | Native across Salesforce objects and channels, which is where its advantage is. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Pipeline, case and campaign reporting inside Salesforce; holdouts are possible but not the default. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Data Cloud plus the Salesforce object model. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Mature enterprise permissions, audit and admin controls. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Depends on the implementation programme; the estate is deep and configuration is real work. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Organisations whose commercial process lives inside Salesforce. | ## What each layer is **Salesforce Einstein / Agentforce** — Predictive scoring, generative assistance and agentic workflows across the Salesforce clouds, grounded in Data Cloud. Answers: What is the next step on this record or in this process? **Markin** — A growth-science layer over the whole consumer base that generates, sizes, launches and proves revenue hypotheses. Answers: Which opportunity in this base is worth acting on, for whom, and what is it worth? ## Side by side | | Salesforce Einstein / Agentforce | Markin | | --- | --- | --- | | Question it answers | What is the next step on this record or in this process? | Which opportunity in this base is worth acting on, for whom, and what is it worth? | | Primary input | Salesforce objects, Data Cloud profiles, flows and agent instructions. | Warehouse, product, billing and contact history; margins and constraints. | | Primary output | Scores, recommendations, drafted content and automated workflow steps. | A ranked, sized action per customer, executed through the systems you run. | | Usual owner | Salesforce architects, sales and service operations. | Growth, data science and revenue leadership. | | How it's measured | Pipeline, case and campaign metrics inside Salesforce. | Incremental revenue and ARPU against a randomised holdout. | ## What Salesforce Einstein and Agentforce does better - **Nothing beats it inside its own estate.** If the action is on a case, a lead or a service conversation, Agentforce acts natively where the record lives, with the permission model already in place. Markin would be routing an action back into Salesforce to do the same thing worse. - **Sales and service coverage is far broader.** Markin has no opinion on quoting, case deflection, field service or seller productivity. Those are large, valuable problems and Salesforce owns them. - **One vendor, one audit trail.** For regulated organisations already standardised on Salesforce, keeping governance in one place has real value that a second system has to earn. ## Which one to pick **Choose Markin if** - Your growth question is about millions of consumers, not thousands of records. - You need hypotheses the organisation has not thought of yet, sized before anyone builds them. - You want incremental ARPU against a control group as the standard reporting unit. - Pricing, product friction and technical anomalies are as likely to be the answer as a campaign. - You want the decision layer to be portable across the stack, not tied to one estate. **Choose Salesforce alone if** - The work happens on Salesforce records and should stay there. - Your priority is seller and agent productivity. - Consolidating on one vendor outweighs best-of-breed decisioning. - Your consumer base is small enough to plan manually. - You are mid-implementation and cannot absorb another system this year. ## What stays unanswered inside the estate Salesforce answers what to do with the record in front of you. It does not investigate the base to find the records that should be in front of you, nor size what acting on them is worth. - No mechanism generates new revenue hypotheses from the data; humans configure what the platform then executes. - Cross-estate arbitration is missing: a Marketing Cloud journey and an in-product placement never compete on expected value. - Reporting attributes outcomes to processes rather than isolating incrementality. - Non-marketing causes of flat ARPU, pricing, friction, technical faults, have no owner. ## Where Markin fits Markin decides; Salesforce executes wherever the record is the right surface. The decision arrives as an attribute or platform event and the existing flow takes it from there. - **No rip and replace.** The Salesforce estate keeps every process it owns today. - **Hypotheses at machine speed.** Markin proposes and sizes what nobody has time to analyse. - **Control groups as standard.** Every action reports incremental value, not activity. Next: [Revenue Discovery](https://markin.ai/solutions/revenue-discovery) ## When Markin is not the right answer - Your commercial model is B2B enterprise sales with a small account list. - You need CRM, case management or field service: Markin is not that. - There is no reliable consumer-level data outside the CRM to reason over. ## FAQ **Is Markin a Salesforce replacement?** No. Salesforce remains the system of record and, in many cases, the execution surface. Markin decides which opportunity is worth acting on across the base and hands the action back to Salesforce or to whichever system owns that touchpoint. **How is Markin different from Agentforce?** Agentforce automates work that a human defined, inside the Salesforce estate. Markin decides what work should exist at all, across marketing, product, pricing and technical health, and proves each decision against a holdout. **What does Salesforce do better?** Everything record-centric: sales process, case management, service automation, seller productivity, and native action inside its own objects with an enterprise permission model already in place. **Do we need Data Cloud for Markin to work?** No. Markin reads context where it already lives, typically the warehouse. If Data Cloud is where your unified profile sits, it can be that instead. **How is Markin different from the decisioning or AI already inside salesforce einstein / agentforce?** 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 salesforce einstein / agentforce 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 salesforce einstein / agentforce?** 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. Source: https://markin.ai/compare/markin-vs-salesforce-einstein-agentforce --- --- title: Markin vs Adobe Journey Optimizer: orchestration vs growth science url: https://markin.ai/compare/markin-vs-adobe-journey-optimizer kind: vs description: Journey Optimizer orchestrates journeys on Adobe Experience Platform. Markin decides which revenue hypothesis deserves a journey, and proves it. updated: 2026-08-20 --- # Markin vs Adobe Journey Optimizer: orchestration vs growth science > 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 answer 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. ## The two options **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 **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 | Dimension | Markin | Adobe Journey Optimizer | | --- | --- | --- | | What it is | An 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 decides | Which 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 from | Generated 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 action | Marketing, 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 customer | Written 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 proven | A 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 sits | Reads 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 control | Every 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 number | One 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 fit | Large 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 each layer is **Adobe Journey Optimizer** — Journey orchestration and offer decisioning on Adobe Experience Platform, delivering personalised experiences in real time. Answers: Which offer or journey step should this profile get right now? **Markin** — A growth-science layer that generates, sizes and proves revenue hypotheses over the whole base. Answers: Which opportunity is worth acting on for this customer, and what is it worth? ## Side by side | | Adobe Journey Optimizer | Markin | | --- | --- | --- | | Question it answers | Which offer or journey step should this profile get right now? | Which opportunity is worth acting on for this customer, and what is it worth? | | Primary input | AEP profiles, XDM events, offer catalogue, eligibility and ranking rules. | Warehouse, product, billing and experiment history; margins and constraints. | | Primary output | A delivered journey step or ranked offer across owned channels. | A ranked, sized action per customer, executed through the stack you run. | | Usual owner | Marketing technology and journey architects. | Growth, data science and revenue leadership. | | How it's measured | Journey and offer performance in Customer Journey Analytics. | Incremental revenue and ARPU against a randomised holdout. | ## What Adobe Journey Optimizer does better - **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. ## Which one to 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. ## 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. ## Where Markin fits 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. Next: [Growth Optimization](https://markin.ai/solutions/growth-optimization) ## When Markin is not the right answer - 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. ## FAQ **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. Source: https://markin.ai/compare/markin-vs-adobe-journey-optimizer --- --- title: Markin vs Amplitude: analytics that explain vs a team that acts url: https://markin.ai/compare/markin-vs-amplitude kind: vs description: Amplitude explains what happened in the product. Markin forms hypotheses on why revenue per customer is stuck, acts, and proves the result. updated: 2026-08-20 --- # Markin vs Amplitude: analytics that explain vs a team that acts > Amplitude is product analytics: cohorts, funnels, retention curves and experiment readouts that explain behaviour. Markin is the team that acts on that explanation. It generates and sizes revenue hypotheses, chooses an action per customer, launches it through your stack, and measures incremental ARPU against a control group. ## The short answer Amplitude answers questions an analyst asks. Markin asks the questions itself, thousands of them, keeps the ones worth money, acts, and reports what the action returned. They are complementary: analytics without action is a report, action without analytics is guesswork. ## The two options **Amplitude** — Product analytics with cohorting, funnels, retention analysis, session replay and experimentation, built to explain behaviour inside the product. Choose it when teams need to understand what users do and why a funnel behaves the way it does. - Explains behaviour - Self-serve analysis - Product and growth teams **Markin** — An autonomous growth-science team that turns findings into sized hypotheses, running actions and verified incremental revenue. Choose it when the analysis backlog is longer than the team, and insights are not converting into tested actions. - Generates hypotheses - Acts per customer - Reports incremental ARPU ## Line by line | Dimension | Markin | Amplitude | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | A product analytics platform with experimentation and audience features. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | Nothing on its own. It informs the humans who decide. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Formed by analysts and PMs from charts they choose to build. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Product behaviour, funnels, retention and in-product experiments. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | Audience syncs to downstream tools; the action itself belongs elsewhere. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Strong experiment analysis when a team designs and runs the experiment. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Event streams from product and web, plus warehouse sync. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Analysis governance, event taxonomy and access controls. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Fast to insight; time to verified revenue depends entirely on the team downstream. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Product and growth teams that need to understand behaviour. | ## What each layer is **Amplitude** — Product analytics: cohorts, funnels, retention, replay and experimentation over product event data. Answers: What are users doing, and where does the funnel break? **Markin** — A growth-science layer that generates, sizes, launches and proves revenue hypotheses per customer. Answers: Which opportunity is worth acting on, for whom, and what did it return? ## Side by side | | Amplitude | Markin | | --- | --- | --- | | Question it answers | What are users doing, and where does the funnel break? | Which opportunity is worth acting on, for whom, and what did it return? | | Primary input | Product and web event streams, user properties. | Warehouse, product, billing and contact history; margins and constraints. | | Primary output | Charts, cohorts, experiment readouts and audience syncs. | A ranked, sized action per customer, executed through your stack. | | Usual owner | Product, analytics and growth teams. | Growth, data science and revenue leadership. | | How it's measured | Engagement, conversion and retention metrics. | Incremental revenue and ARPU against a randomised holdout. | ## What Amplitude does better - **Exploratory analysis is a different craft.** When a human needs to interrogate a funnel, slice a cohort five ways and see the session replay, Amplitude is excellent and Markin is not a substitute. Markin proposes; people still need somewhere to look. - **Event taxonomy and instrumentation.** Amplitude has spent a decade on the boring, essential work of tracking, taxonomy and governance. That layer is a prerequisite for anything Markin does with product data. - **Product teams live there.** Adoption matters. If your PMs already reason in Amplitude, keeping them there and letting Markin work behind it is better than trying to move them. ## Which one to pick **Choose Markin if** - Insights pile up faster than they get tested. - You need money attached to a finding before anyone prioritises it. - Actions have to reach customers, not just dashboards. - Incremental ARPU against a holdout is the number the board wants. - Causes of flat revenue can be pricing or technical, not only product behaviour. **Choose Amplitude alone if** - The gap is understanding, not execution. - You need self-serve exploration for a wide internal audience. - Instrumentation and taxonomy are the current priority. - Your experiments are already designed and read by a strong team. - The product is early and the base is small. ## The distance between a chart and a euro Analytics ends where the decision starts. Someone still has to notice the chart, believe it, size it, design a treatment, get it built, run it against a control and decide whether to keep it. That chain is where most insight dies. - Findings are not sized in revenue, so prioritisation is argued rather than calculated. - Nothing arbitrates between a product fix, a price change and a campaign. - Experiments happen when someone has capacity to design them. - There is no per-customer decision, only cohorts. ## Where Markin fits Amplitude keeps explaining behaviour. Markin reads the same evidence, proposes what to do about it, sizes it, runs it against a holdout and retires what does not work. - **Insight becomes action.** Each hypothesis carries an owner, a treatment and a control group. - **Sized before built.** Expected value decides the queue, not conviction. - **Closed loop.** Results feed back into the next round of hypotheses. Next: [Product Diagnosis](https://markin.ai/solutions/product-diagnosis) ## When Markin is not the right answer - You need self-serve exploratory analytics: that is Amplitude's job, not Markin's. - Product instrumentation does not exist yet. - The base is too small for holdouts to reach significance. ## FAQ **Is Markin an Amplitude alternative?** No. Amplitude explains behaviour; Markin decides and acts. Most customers keep Amplitude for exploration and use Markin to convert findings into sized, tested, measured actions. **Amplitude has experiments. Why is that not enough?** Experimentation tools run the experiments a team designs. The constraint is usually how many good experiments get designed and sized, which is the part Markin automates. **What does Amplitude do better?** Exploratory analysis, event taxonomy and instrumentation governance, session replay, and giving a wide internal audience self-serve access to product data. **Does Markin need Amplitude data?** It helps but it is not required. Markin reads product and revenue context from the warehouse; Amplitude events are one useful source among several. **How is Markin different from the decisioning or AI already inside amplitude?** 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 amplitude 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 amplitude?** 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. Source: https://markin.ai/compare/markin-vs-amplitude --- --- title: Markin vs Optimizely: running tests vs deciding what to test url: https://markin.ai/compare/markin-vs-optimizely kind: vs description: Optimizely runs the experiments you design. Markin decides which experiments are worth running, sizes them in revenue, and reads every one against a holdout. updated: 2026-08-20 --- # Markin vs Optimizely: running tests vs deciding what to test > Optimizely is an experimentation and feature-management platform: it delivers variants, assigns traffic and reports statistical results. Markin decides what should be tested in the first place, sizes each hypothesis in revenue, arbitrates them against each other, and proves the winners against a randomised holdout. ## The short answer Experimentation platforms removed the technical cost of testing. The remaining constraint is human: someone has to invent the hypothesis, argue for it and design it. Markin removes that constraint, and Optimizely remains an excellent place to deliver the resulting test on web and product surfaces. ## The two options **Optimizely** — Experimentation and feature management across web, app and server, with traffic allocation, targeting, stats engine and rollout controls. Choose it when engineers and product teams need a reliable way to ship and measure variants safely. - Runs the test - Feature flags - Stats engine **Markin** — An autonomous growth-science team that decides which hypotheses deserve traffic, sizes them, launches across channels and reports incremental ARPU. Choose it when the test queue is short on ideas worth testing, not short on delivery capacity. - Writes the queue - Sizes in revenue - Per-customer decisions ## Line by line | Dimension | Markin | Optimizely | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | An experimentation and feature-management platform. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | Which variant a visitor sees, and when a feature rolls out. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Written by product managers, engineers and CRO specialists. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Web, app and server-side surfaces the team instruments. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | Delivers variants and gates features directly, which it does very well. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Rigorous statistics on the tests you choose to run. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Experiment exposure and outcome events, plus warehouse export. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Rollout safety, targeting rules and flag lifecycle management. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Fast per test; total throughput is bounded by hypothesis supply and design time. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Teams with the ideas and the engineering capacity to test them. | ## What each layer is **Optimizely** — An experimentation and feature-management platform that delivers variants, allocates traffic and reports results. Answers: Which variant performs better on this surface? **Markin** — A growth-science layer that decides which hypotheses deserve to be tested, sizes them and proves them across the base. Answers: Which hypothesis is worth traffic, for whom, and what is it worth? ## Side by side | | Optimizely | Markin | | --- | --- | --- | | Question it answers | Which variant performs better on this surface? | Which hypothesis is worth traffic, for whom, and what is it worth? | | Primary input | Instrumented surfaces, targeting rules, variant definitions. | Warehouse, product, pricing and contact history; margins and constraints. | | Primary output | Delivered variants, feature gates and statistical readouts. | A prioritised experiment queue and a decision per customer, executed through your stack. | | Usual owner | Product engineering and CRO. | Growth, data science and revenue leadership. | | How it's measured | Lift on the test metric for exposed traffic. | Incremental revenue and ARPU against a randomised holdout. | ## What Optimizely does better - **Delivery and safety are its own discipline.** Feature flags, progressive rollout, kill switches and SDK-level targeting are hard engineering problems. Markin does not do them and should not. - **Statistical rigour on-surface.** Sequential testing, sample ratio mismatch detection and variance reduction on web traffic are mature in Optimizely. It is a good place to read a test. - **Engineering trust.** If your teams already gate every release behind flags, that workflow is worth protecting. Markin should feed it, not fight it. ## Which one to pick **Choose Markin if** - Your test velocity is limited by ideas, not by infrastructure. - You want each hypothesis sized in revenue before it takes traffic. - Tests need to span channels, not just on-site surfaces. - You want a per-customer decision, not a variant per visitor. - Board reporting needs incremental ARPU, not lift on a page. **Choose Optimizely alone if** - You need feature flags and safe rollout above all. - Testing is confined to web and product surfaces. - Your team already produces more good hypotheses than it can run. - Engineering owns the experimentation workflow end to end. - Traffic volumes make on-site testing the fastest route to answers. ## The test queue is the bottleneck Most organisations can run far more experiments than they can design. The backlog is not full of sized, credible hypotheses; it is full of opinions ordered by who asked loudest. - Nothing sizes a test in revenue before it consumes traffic. - On-surface tests cannot arbitrate against a message, a price or a service action. - Wins are reported as lift on a metric, rarely as incremental revenue per customer. - Retiring a winner that stopped working is a manual, easily forgotten step. ## Where Markin fits Markin fills and orders the queue, then executes wherever the surface lives, including Optimizely, and reads every result against a control group. - **Hypotheses with a price tag.** Expected value decides what gets traffic. - **Cross-channel by default.** A web test competes with a message and a pricing change. - **Scale or retire.** Every winner is re-read, and decayed winners are retired. Next: [Growth Optimization](https://markin.ai/solutions/growth-optimization) ## When Markin is not the right answer - You need feature flags and rollout tooling: Markin does not provide them. - Testing is confined to a single page and a single metric. - Traffic is too low for controlled reads at any level. ## FAQ **Does Markin replace Optimizely?** No. Optimizely remains a good place to deliver and read on-surface tests. Markin decides which tests deserve to exist, sizes them, and extends the same discipline to channels Optimizely does not touch. **How is this different from an experimentation roadmap?** A roadmap is a human artefact refreshed quarterly. Markin regenerates and re-sizes the queue continuously from data, including hypotheses nobody proposed. **What does Optimizely do better?** Variant delivery, feature flags, safe rollout and on-surface statistical rigour. **Can both run together?** Yes. Markin can hand a chosen treatment to Optimizely for delivery, and read the outcome alongside every other action the customer received. **How is Markin different from the decisioning or AI already inside optimizely?** 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 optimizely 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 optimizely?** 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. Source: https://markin.ai/compare/markin-vs-optimizely --- --- title: Markin vs building it in-house: what a team can realistically ship url: https://markin.ai/compare/markin-vs-in-house-data-science kind: vs description: Building a decision layer in-house is possible and sometimes right. An honest comparison of throughput, cost, ownership and time to a verified number. updated: 2026-08-20 --- # Markin vs building it in-house: what a team can realistically ship > An in-house team can build a decision layer: models, feature store, orchestration, experiment framework and activation. The question is throughput. Markin generates, sizes, launches and reads hypotheses continuously, so the same team supervises hundreds of tested ideas per quarter instead of shipping a handful. ## The short answer This is the honest comparison, because the alternative to Markin is usually not another vendor, it is a roadmap. In-house wins on control and on domain judgement. Markin wins on throughput and on time to a verified number, and it makes your team the reviewers rather than the builders. ## The two options **In-house data science and growth** — Your own analysts, scientists and engineers building models, pipelines, experiment frameworks and activation on top of the warehouse. Choose it when the domain is unusual, the team is already staffed for it, and control matters more than speed. - Full control - Domain knowledge - Bounded by headcount **Markin** — The same operating loop, run continuously by an autonomous system your team supervises: hypothesis, sizing, design, execution, holdout read, scale or retire. Choose it when the backlog is measured in quarters and the base is large enough that untested ideas are expensive. - Hundreds of tested ideas - 90 days to a number - Your team reviews ## Line by line | Dimension | Markin | In-house data science and growth | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | A team, a warehouse and a roadmap. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | Whatever the team has had time to build a model and a pipeline for. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Proposed in planning, filtered by seniority and capacity. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | As broad as the team's remit, in practice narrowed to what is shippable this quarter. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | Custom integrations built and maintained per channel. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Good when the team insists on holdouts; often the first thing dropped under deadline. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Your warehouse, with a feature store to build and maintain. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Whatever the team documents. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Typically two to four quarters before the first defensible incremental number. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Unusual domains, strong existing platform teams, control-first organisations. | ## What each layer is **In-house data science and growth** — Your own team building models, pipelines, experiments and activation on the warehouse. Answers: What can we build and ship with the people we have? **Markin** — An autonomous growth-science team running the same loop continuously, under human review. Answers: Which opportunity is worth acting on, for whom, and what did it return? ## Side by side | | In-house data science and growth | Markin | | --- | --- | --- | | Question it answers | What can we build and ship with the people we have? | Which opportunity is worth acting on, for whom, and what did it return? | | Primary input | Warehouse data, roadmap priorities, stakeholder requests. | The same warehouse, plus margins, constraints and experiment history. | | Primary output | Models, scores, dashboards and a queue of shipped experiments. | A ranked, sized action per customer, executed through your stack. | | Usual owner | Data science, analytics engineering and growth. | Growth, data science and revenue leadership, as reviewers. | | How it's measured | Model quality and, where holdouts survive, incremental lift. | Incremental revenue and ARPU against a randomised holdout. | ## What In-house data science and growth does better - **Domain judgement is yours, not ours.** Your team knows which segments are politically untouchable, which margins are wrong in the warehouse and which promise the regulator will not accept. That knowledge is not replaceable, which is why Markin puts humans in the review loop rather than around it. - **Control and portability.** Building in-house means no vendor dependency, models you can inspect line by line, and a platform that can be repurposed. Those are real advantages and some organisations should pay for them. - **Sometimes the first version is enough.** If two propensity models and a weekly export move the number, build them. Markin earns its place when the constraint is the twentieth hypothesis, not the second. ## Which one to pick **Choose Markin if** - The analysis backlog is longer than the roadmap and growing. - You want hundreds of sized, tested hypotheses per quarter, not a handful. - You need a defensible incremental number this quarter. - Your scientists should be reviewing decisions, not maintaining pipelines. - Growth questions span marketing, pricing, product and technical health. **Choose building in-house if** - Your domain is unusual enough that generic hypothesis generation would miss. - You already have a staffed platform team and a working experiment framework. - Policy requires every model to be owned and inspectable internally. - The base is small enough that a few well-chosen models cover it. - There is no appetite for another vendor in the stack this year. ## The bottleneck is throughput, not talent Strong teams do not fail on model quality. They fail because each idea costs weeks of pipeline, integration and stakeholder work, so only the safest ideas get tested and the long tail of smaller, compounding wins is never examined. - The queue is ordered by who asked, because nothing sizes ideas in money. - Integration work dominates: the same activation is rebuilt per channel. - Holdouts are the first casualty of a deadline, so results become arguable. - Winners are rarely re-read, so decayed models keep running. ## Where Markin fits Markin does not replace the team. It multiplies what the team can supervise, and it takes over the parts nobody enjoys: pipelines, sizing, control-group hygiene and retirement. - **Your people review.** Every hypothesis carries its evidence, its expected value and its guardrails. - **Pipelines stop being the job.** Activation into existing systems is handled once, not per idea. - **Discipline by default.** Holdouts and re-reads are structural, not optional. Next: [Revenue Discovery](https://markin.ai/solutions/revenue-discovery) ## When Markin is not the right answer - You want a tool your team will operate as a library: Markin runs a loop, not a notebook. - The base is too small for controlled measurement. - Data foundations are not yet reliable enough to size opportunities in money. ## FAQ **Does Markin replace our data science team?** No, and the deployments that work best have strong teams. Markin changes what they spend time on: reviewing sized hypotheses and owning judgement calls instead of building pipelines and chasing integrations. **Could we build this ourselves?** Yes. Most of the components exist. The realistic cost is two to four quarters of platform work before the first defensible incremental number, plus ongoing maintenance of activation and experiment hygiene. **What does in-house do better?** Domain judgement, full control and inspectability of models, and no vendor dependency. **How is throughput actually different?** Markin generates and sizes hypotheses continuously and only escalates the ones that clear a value threshold, so review capacity, not build capacity, becomes the limit. **How is Markin different from the decisioning or AI already inside in-house data science and growth?** 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 in-house data science and growth 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 in-house data science and growth?** 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. Source: https://markin.ai/compare/markin-vs-in-house-data-science --- --- title: vs an LLM with MCP: asking questions is not running growth url: https://markin.ai/compare/markin-vs-llm-mcp kind: vs description: Connecting an LLM to your warehouse over MCP answers questions well. Compare cost, skills, hypothesis evaluation and model choice against Markin. updated: 2026-08-21 --- # vs an LLM with MCP: asking questions is not running growth > An LLM with MCP access reads your warehouse and answers questions about it, brilliantly and cheaply. Markin runs the loop that comes after the answer: it sizes each hypothesis in money, tests it against a randomised holdout, and routes the work across cheap models, frontier models and classical ML so that reasoning about millions of customers every week is economically possible. ## The short answer This is the real alternative most teams weigh, and for exploration the LLM usually wins. The difference is what happens next. A chat answer is plausible and unfalsifiable; Markin turns a candidate into a sized hypothesis, an experiment with a control group, and a number finance accepts. Cost is the reason the architecture underneath looks nothing like a prompt. ## The two options **An LLM with MCP access** — A frontier model, ChatGPT, Claude or Grok, given tools over your warehouse, BI and product systems through the Model Context Protocol. It reads, reasons and explains on demand. Choose it when the job is to understand what happened, draft an analysis or unblock an analyst in minutes. - Answers on demand - Priced per token - No control group **Markin** — An autonomous growth-science team. Versioned skills generate, size, design, launch and read hypotheses continuously, using the cheapest model class that can do each step correctly. Choose it when the job is to move ARPU across millions of customers and prove the movement was incremental. - Decisions, not answers - Holdout on everything - Routed model stack ## Line by line | Dimension | Markin | An LLM with MCP access | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | A general reasoning model with read access to your systems through MCP servers. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | Nothing on its own. It proposes; a human decides, briefs and builds. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Generated on request, in the direction the prompt points, with no memory of what has already been tried. | | How a hypothesis is evaluated | Sized in money on the eligible population, filtered by statistical power, then killed or kept by a randomised holdout. | Judged by how convincing the explanation reads. Nothing sizes the idea in money or checks whether it could ever reach significance. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | As wide as the tools it is given, but always ending at a recommendation in a chat window. | | Which models do the work | A routed mix: frontier language models to write and explain, small cheap models for volume classification, and classical ML and deep learning, uplift, survival, time series, embeddings, for the numbers. | One frontier model for every step, whether the step needs reasoning or not. | | What the cost scales with | Decisions taken and revenue proven, not tokens burned. Per-customer reasoning is handled by the cheap layers by design. | Tokens consumed. Reasoning over each customer weekly on a base of tens of millions is not a pricing problem, it is an impossibility. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | A human reads the answer and does the work in another system. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Whatever the analyst sets up afterwards, usually attribution rather than a holdout. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Your warehouse and tools, accessed live through MCP servers you host and secure. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Prompt and tool permissions. No record of why a given recommendation was made or what it was worth. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Minutes to an answer. The clock to a verified number has not started. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Analysts and operators who need to understand the business faster. | ## What each layer is **An LLM with MCP access** — A frontier model given read access to your data systems through the Model Context Protocol. Answers: What is happening in my data, and what might explain it? **Markin** — An autonomous growth-science team running a versioned loop over the same data, under human review. Answers: Which opportunity is worth acting on, for whom, and what did it actually return? ## Side by side | | An LLM with MCP access | Markin | | --- | --- | --- | | Question it answers | What is happening in my data, and what might explain it? | Which opportunity is worth acting on, for whom, and what did it actually return? | | Primary input | A prompt, plus whatever the MCP servers expose. | Warehouse, product, billing and experiment history, plus margins and guardrails. | | Primary output | An explanation and a list of plausible recommendations. | A sized, ranked action per customer, executed and measured. | | Usual owner | Analysts, data teams and curious operators. | Growth, data science and revenue leadership, as reviewers. | | How it's measured | Whether the answer was useful. | Incremental revenue and ARPU against a randomised holdout. | ## What An LLM with MCP access does better - **For exploration, the LLM is better and far cheaper.** If the question is what happened last week, why a cohort moved, or how to write a query, an LLM with MCP beats any platform on speed and cost. We use exactly this internally, and no one should buy software to replace it. - **The MCP ecosystem is moving fast.** Some of the plumbing we build today, tool access, schema awareness, safe read paths, will be commodity. The part that will not commoditise is the experimental discipline: sizing, power, holdouts and retirement. - **A small base does not need any of this.** Below a few hundred thousand customers, one good analyst with a frontier model and warehouse access will out-produce an autonomous system, because there is not enough population to power the experiments Markin depends on. - **General models reason better in the open.** Faced with a novel, unstructured question, a frontier model with tools is more flexible than any skill library. Markin is narrower on purpose: it trades breadth for reproducibility. ## Which one to pick **Choose Markin if** - You need a decision per customer per week, not an answer per question. - The number has to survive a randomised holdout and a finance review. - The base is large enough that untested ideas cost real money. - Per-customer reasoning has to be affordable at tens of millions of records. - You want the method to be versioned and repeatable, not re-prompted each time. **Choose an LLM with MCP if** - The job is exploration, diagnosis or drafting. - Your analysts are the bottleneck and want leverage, not autonomy. - You are not ready to run controlled experiments on the base. - The base is small enough that judgement beats testing. - You want to start this week with tools you already pay for. ## What is still missing when the model can read everything Access was never the hard part. The hard part is turning a plausible statement into a decision that is affordable to take a hundred million times, and into a number that survives being questioned. - Plausible is not falsifiable: nothing in a chat answer estimates the value at risk or the power needed to detect it. - No memory of method: the same question asked twice can produce two incompatible recommendations. - Cost scales with curiosity, not with revenue, so per-customer reasoning stays out of reach. - No control group, so every reported win inherits the attribution problem you already have. ## Where Markin fits Markin is what sits between the answer and the money: a skill library that sizes, designs, launches and reads, with the model class chosen per step so the economics work at population scale. - **Skills, not prompts.** Anomaly detection, sizing, experiment design, holdout reading and arbitration are versioned components with their own evaluations. - **Model routing is a cost decision.** Frontier models where language adds value; small models for volume; classical ML and deep learning where the number has to be defensible. - **Every claim carries a control group.** The output is incremental ARPU, not a convincing paragraph. Next: [Revenue Discovery](https://markin.ai/solutions/revenue-discovery) ## When Markin is not the right answer - You want a chat interface over your warehouse: use an LLM with MCP, it is the right tool. - The base is too small for controlled measurement. - There is no appetite to act automatically on anything, even under guardrails. ## FAQ **Why can't we just connect ChatGPT or Claude to our warehouse with MCP?** You can, and you should, for analysis. What it will not do is decide what each of ten million customers should get this week, size those decisions in money, and prove the result against a control group. Those steps need a method that is versioned and an execution cost that does not scale with tokens. **Isn't Markin just an LLM with better prompts?** No. Language models are one layer of several, used where language actually helps: writing hypotheses, explaining findings, drafting briefs. The scoring, uplift modelling, survival analysis and anomaly detection that produce the numbers are classical ML and deep learning, and most per-customer work never touches a frontier model at all. **How does the cost compare?** Different unit entirely. An LLM with MCP is priced per question asked. Markin's economics are built around decisions taken, which is why cheap models and trained models do the volume work and expensive reasoning is reserved for the few steps where it changes the outcome. **What stops an LLM from producing good hypotheses?** Nothing. It produces plenty, and some are good. The problem is that it cannot tell you which ones are worth the opportunity cost, whether the eligible population is large enough to detect the effect, or whether the same idea failed two quarters ago. **Do you use MCP internally?** Yes. Tool access to systems is useful plumbing and we treat it as such. It is a transport layer, not a growth programme. **How is Markin different from the decisioning or AI already inside An LLM with MCP access?** 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 An LLM with MCP access 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 An LLM with MCP access?** 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. Source: https://markin.ai/compare/markin-vs-llm-mcp --- --- title: vs ChatGPT with MCP: from a good answer to a proven number url: https://markin.ai/compare/markin-vs-chatgpt-mcp kind: vs description: ChatGPT with MCP connectors reads your data and answers well. Markin sizes, tests and proves growth hypotheses at population scale. An honest comparison. updated: 2026-08-21 --- # vs ChatGPT with MCP: from a good answer to a proven number > ChatGPT with MCP connectors gives your team a fast, cheap analyst over the warehouse. Markin is the system that runs after the analysis: versioned skills that size each hypothesis in money, test it against a randomised holdout, and use cheap models and classical ML so deciding for millions of customers weekly stays affordable. ## The short answer ChatGPT is the most widely adopted way to ask your data a question, and the connector ecosystem makes it easy to start. It is not built to decide, execute and measure per customer at scale, and the token economics of asking a frontier model about every customer every week make that structurally unattractive. ## The two options **ChatGPT with MCP** — OpenAI's assistant with connectors and MCP servers pointed at your warehouse, BI and SaaS tools. Broad adoption, large ecosystem, familiar to everyone in the business. Choose it when you want every team to be able to interrogate the data without waiting for an analyst. - Widest adoption - Rich connector ecosystem - Per-token pricing **Markin** — An autonomous growth-science team that turns findings into sized hypotheses, controlled experiments and executed actions in the systems you already run. Choose it when the goal is measurable ARPU movement, not faster answers. - One action per customer - Randomised holdouts - Cheap models do the volume ## Line by line | Dimension | Markin | ChatGPT with MCP | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | A general assistant with MCP connectors and file, search and code tools over your systems. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | What to show the person asking. Business decisions stay with the human reading the reply. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Produced on demand from whatever context the prompt and connectors provide. | | How a hypothesis is evaluated | Sized in money on the eligible population, filtered by statistical power, then killed or kept by a randomised holdout. | Assessed by plausibility in conversation. No sizing, no power calculation, no experiment history. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Analysis, drafting and light automation through tools a human has wired up. | | Which models do the work | A routed mix: frontier language models to write and explain, small cheap models for volume classification, and classical ML and deep learning, uplift, survival, time series, embeddings, for the numbers. | GPT-class reasoning for every step, including steps that a logistic regression would do better and for a fraction of the price. | | What the cost scales with | Decisions taken and revenue proven, not tokens burned. Per-customer reasoning is handled by the cheap layers by design. | Seats and tokens. Cost tracks how many questions get asked, not how much revenue moves. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | A person copies the recommendation into the campaign, product or pricing tool. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Whatever reporting already exists, typically attributed conversions. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Live reads through MCP servers your team hosts and secures. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Workspace controls, tool permissions and retention settings. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Immediate answers. Weeks or quarters before any of them turn into a proven result. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Organisations that want data literacy everywhere. | ## What each layer is **ChatGPT with MCP** — A general assistant with connectors into your data and tools. Answers: What does my data say, and what should I look at next? **Markin** — An autonomous growth-science team acting on the same data under human review. Answers: Which opportunity deserves to exist for this customer, and what did it return? ## Side by side | | ChatGPT with MCP | Markin | | --- | --- | --- | | Question it answers | What does my data say, and what should I look at next? | Which opportunity deserves to exist for this customer, and what did it return? | | Primary input | Prompts plus live reads from MCP servers. | Warehouse, product, billing, margins, guardrails and experiment history. | | Primary output | Explanations, queries, drafts and recommendations. | A sized action per customer, executed through your stack. | | Usual owner | Anyone in the business. | Growth and data science, as reviewers. | | How it's measured | Time saved and questions answered. | Incremental ARPU against a randomised holdout. | ## What ChatGPT with MCP does better - **Adoption is a real advantage, and we do not have it.** Everyone in the company already knows how to use ChatGPT. That removes the change-management problem that every analytics tool, including ours, has to solve. If usage is your bottleneck, start there. - **The connector ecosystem is broader than ours.** MCP servers exist for almost every tool your business runs. Markin integrates deliberately with a smaller set of warehouse, CDP, product and billing systems, because it writes decisions back rather than just reading. - **It is better at open-ended questions.** Faced with something novel and badly specified, a general assistant is more useful than a fixed skill library. Markin trades that flexibility for reproducibility. ## Which one to pick **Choose Markin if** - You need per-customer decisions at a scale no chat session can price. - Results have to be defended with a control group. - Hypotheses must be sized in euros before anyone builds them. - Marketing, product, pricing and technical-health ideas need to compete in one queue. - You want the method versioned, not re-prompted. **Choose ChatGPT with MCP if** - The goal is broad data literacy across teams. - You want value this week from a subscription you already have. - Nobody is ready to run automated actions on the base. - Your questions are exploratory rather than operational. ## What a great answer still leaves undone The assistant hands back a recommendation. Everything expensive comes after: deciding whether it is worth more than the other twelve recommendations, whether it can be measured at all, who is eligible, and what happens to the ones that lose. - No expected value, so priority defaults to whoever asked most recently. - No power check, so effects too small to detect still get built. - No holdout, so the win is attributed rather than proven. - No retirement, so decayed treatments keep running unnoticed. ## Where Markin fits Keep ChatGPT for exploration. Markin takes the same underlying data and runs the operating loop against it continuously, with a model stack chosen so per-customer work costs cents, not dollars. - **Skills with their own evaluations.** Sizing, design, reading and arbitration are components, not prompts. - **Right model, right task.** Frontier models write and explain; trained models score and predict. - **Proof by construction.** A control group is attached before an action ever launches. Next: [Revenue Discovery](https://markin.ai/solutions/revenue-discovery) ## When Markin is not the right answer - You mainly need an assistant over the warehouse. - The base is too small for controlled experiments. - There is no mandate to act on the customer base automatically. ## FAQ **Is Markin an alternative to ChatGPT?** No. They answer different questions. ChatGPT with MCP explains the business to whoever asks; Markin decides what to do about it for each customer and proves the effect. Most of our customers run both, and we would not recommend dropping either. **Why not just build agents on top of ChatGPT?** Teams do, and the first version usually works. It stops scaling when per-customer reasoning meets the token bill, and when the recommendations need to be ranked in money and validated against a holdout rather than accepted because they read well. **What does ChatGPT do better?** Adoption, breadth of connectors and open-ended reasoning. It is the better tool for any question that has not been asked before. **Does Markin use OpenAI models?** Where they are the right tool, yes: writing hypotheses, explaining findings, drafting briefs. Scoring, uplift, survival and anomaly detection run on trained models, which is what keeps per-decision cost viable at population scale. **How is Markin different from the decisioning or AI already inside chatgpt with mcp?** 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 chatgpt with mcp 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 chatgpt with mcp?** 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. Source: https://markin.ai/compare/markin-vs-chatgpt-mcp --- --- title: vs Claude with MCP: strong reasoning, no control group url: https://markin.ai/compare/markin-vs-claude-mcp kind: vs description: Claude with MCP is excellent at long-context analysis over your data. Markin sizes, tests and proves growth hypotheses per customer. An honest comparison. updated: 2026-08-21 --- # vs Claude with MCP: strong reasoning, no control group > Claude with MCP is the strongest general option for long-context analysis over your warehouse, and MCP is Anthropic's own protocol. Markin is a different layer: versioned growth skills that size hypotheses in money, run randomised holdouts, and route work across cheap models and classical ML so per-customer decisions stay affordable. ## The short answer If we had to pick one assistant for an analyst to reason over messy data with tools, it would be a close call and Claude would be in the final two. That is still analysis. Markin's job starts when someone has to decide what each customer gets this week and prove afterwards that it was worth doing. ## The two options **Claude with MCP** — Anthropic's assistant with MCP servers over your warehouse, code and documents. Long context, careful tool use, strong at multi-step reasoning on unfamiliar data. Choose it when the work is deep, exploratory analysis that a careful analyst would otherwise do by hand. - Long-context reasoning - MCP is Anthropic's protocol - Per-token pricing **Markin** — An autonomous growth-science team: hypotheses generated, sized, launched into your stack and read against a control group, continuously. Choose it when the constraint is how many hypotheses get proven, not how well one gets analysed. - Continuous loop - Holdout on every action - Routed model stack ## Line by line | Dimension | Markin | Claude with MCP | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | A frontier assistant with first-class MCP tool use over your systems. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | What to recommend to the person in the session. The human owns every downstream decision. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Reasoned out in the session, often very well, but without sizing or memory across sessions. | | How a hypothesis is evaluated | Sized in money on the eligible population, filtered by statistical power, then killed or kept by a randomised holdout. | Argued rather than tested. No eligible population, no expected value, no power threshold. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Analysis, code and document work across whatever tools are connected. | | Which models do the work | A routed mix: frontier language models to write and explain, small cheap models for volume classification, and classical ML and deep learning, uplift, survival, time series, embeddings, for the numbers. | One frontier model doing every step, including the ones a gradient-boosted tree does better. | | What the cost scales with | Decisions taken and revenue proven, not tokens burned. Per-customer reasoning is handled by the cheap layers by design. | Tokens, and long context is expensive context. Cost grows with depth of analysis, not with revenue. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | A human takes the conclusion into the execution system. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | None built in. Whatever the team sets up afterwards. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Live reads through MCP servers you host. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Tool scoping and workspace policy. No experiment record. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | An excellent analysis in an afternoon. A verified number, not yet. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Analysts doing deep, one-off investigations. | ## What each layer is **Claude with MCP** — A long-context assistant with tool access to your systems. Answers: What is really going on in this data, and what would a careful analyst conclude? **Markin** — An autonomous growth-science team running a versioned loop on the same data. Answers: Which action is worth taking for this customer, and what did it return? ## Side by side | | Claude with MCP | Markin | | --- | --- | --- | | Question it answers | What is really going on in this data, and what would a careful analyst conclude? | Which action is worth taking for this customer, and what did it return? | | Primary input | Prompts, documents and live tool reads. | Warehouse, product, billing, margins, guardrails, experiment history. | | Primary output | Analysis, code and reasoned recommendations. | A sized action per customer, executed and measured. | | Usual owner | Analysts and data scientists. | Growth and data science, as reviewers. | | How it's measured | Quality and speed of the analysis. | Incremental ARPU against a randomised holdout. | ## What Claude with MCP does better - **Claude reasons better over unfamiliar data than any skill library.** Give it a schema it has never seen and a vague question, and it will do genuinely good work. Markin is narrow by design and would simply not have a skill for that. - **MCP is Anthropic's protocol and their tool use shows it.** Multi-step tool orchestration is more reliable there than in most alternatives. We would rather say that plainly than pretend otherwise. - **For one hard question, it is cheaper than any platform.** A single deep investigation costs a few dollars in tokens. Nothing we sell competes with that, and nothing should. ## Which one to pick **Choose Markin if** - The output has to be a decision per customer, not a document. - Every claimed win needs a randomised control group. - Hypotheses must be ranked by expected value across marketing, product and pricing. - Per-customer reasoning has to run weekly on millions of records. - The method must be reproducible across quarters and teams. **Choose Claude with MCP if** - The work is deep, one-off analysis. - Your analysts want leverage, not autonomy. - The data model is unfamiliar and needs interpretation before anything else. - You are not running controlled experiments yet. ## Reasoning quality is not the binding constraint Most growth programmes do not fail because the analysis was shallow. They fail because good analysis arrives once a quarter, is never sized against alternatives, and is validated by the same attribution model that produced the problem. - One deep answer per investigation, versus hundreds of sized candidates per quarter. - Nothing carries forward: what was tried and failed is not in the context next time. - Depth costs context, and context costs money, so the analysis stays occasional. - No holdout, so a confident conclusion and a proven one look identical. ## Where Markin fits Use Claude for the hard questions. Markin industrialises the ordinary ones: it runs the loop continuously and reserves expensive reasoning for the steps where language genuinely changes the outcome. - **Versioned skills.** Detection, sizing, design, reading and arbitration, each with its own evaluations. - **Model routing by task.** Cheap models for volume, frontier models for language, trained models for prediction. - **Every action has a control.** Incremental ARPU, measured, not argued. Next: [Revenue Discovery](https://markin.ai/solutions/revenue-discovery) ## When Markin is not the right answer - You need an analyst's assistant, not an autonomous loop. - The base is too small for controlled measurement. - Every treatment requires individual legal review before launch. ## FAQ **Could we replicate Markin with Claude and a few MCP servers?** You can replicate the demo, not the economics or the discipline. The gaps show up as cost per customer, absence of sizing and power checks, and the missing control group that makes a result defensible. **What does Claude do better?** Open-ended reasoning over unfamiliar data, long-context work and reliable multi-step tool use. For a single hard investigation it is the better and cheaper choice. **Does Markin use Claude?** Where a frontier model is the right instrument, we route to whichever performs best on that step. Most of the per-customer work never reaches a frontier model, because propensity, uplift and anomaly detection are done by trained models. **How do you evaluate hypotheses differently?** Every candidate gets an eligible population, an expected value net of margin and contact cost, and a power check. What clears the threshold runs with a randomised holdout, and what loses is retired rather than quietly kept. **How is Markin different from the decisioning or AI already inside claude with mcp?** 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 claude with mcp 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 claude with mcp?** 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. Source: https://markin.ai/compare/markin-vs-claude-mcp --- --- title: vs Grok with MCP: cheap tokens, unproven decisions url: https://markin.ai/compare/markin-vs-grok-mcp kind: vs description: Grok with MCP is fast and cheap for real-time analysis. Markin sizes hypotheses in money and proves them with holdouts. An honest comparison. updated: 2026-08-21 --- # vs Grok with MCP: cheap tokens, unproven decisions > Grok with MCP is a fast, low-cost way to reason over live data, and cheap tokens make wider use realistic. Markin operates a layer above: versioned growth skills that size hypotheses in money, prove them against randomised holdouts, and use trained models rather than language models for the per-customer work. ## The short answer Grok's argument is price and immediacy, and it is a good one. But cheaper tokens do not turn a recommendation into a proven result. The gap is not how much reasoning costs; it is that nothing in a chat loop sizes the idea, checks it can reach significance, or holds out a control group. ## The two options **Grok with MCP** — xAI's assistant with MCP tool access, positioned on speed, cost and real-time signal from the open web and X. Choose it when you need fast, cheap reasoning and live external context alongside your own data. - Low cost per token - Real-time signal - Fast responses **Markin** — An autonomous growth-science team generating, sizing, launching and reading hypotheses against your customer base continuously. Choose it when the number has to hold up in a board pack, not just sound right in a thread. - Sized in euros - Holdout on every action - Executes in your stack ## Line by line | Dimension | Markin | Grok with MCP | | --- | --- | --- | | What it is | An autonomous growth-science team: it investigates why revenue per customer is stuck and acts on what it finds. | A general assistant with tool access, tuned for speed and price, with live external signal. | | What it decides | Which commercial opportunity deserves to exist for each customer this week, what it is worth, and when the right answer is to do nothing. | What to answer. Commercial decisions remain with the reader. | | Where hypotheses come from | Generated by Markin from customer, product, pricing and technical-health data, then sized before anyone builds anything. | Generated quickly and cheaply, which means more of them and no filter on which deserve attention. | | How a hypothesis is evaluated | Sized in money on the eligible population, filtered by statistical power, then killed or kept by a randomised holdout. | None. Volume of suggestions goes up; the share that is testable does not. | | Scope of action | Marketing, product, pricing and technical-health hypotheses, arbitrated against each other in one queue. | Analysis and commentary over connected tools and public signal. | | Which models do the work | A routed mix: frontier language models to write and explain, small cheap models for volume classification, and classical ML and deep learning, uplift, survival, time series, embeddings, for the numbers. | One model for everything, chosen for price rather than for the task. | | What the cost scales with | Decisions taken and revenue proven, not tokens burned. Per-customer reasoning is handled by the cheap layers by design. | Lower per token, which helps, but still priced by questions asked rather than by decisions taken. | | How the work reaches the customer | Written back into the systems you already run, as attributes, events or API calls. Markin does not add a new customer-facing surface. | Manual: a human moves the idea into the system that can act. | | How impact is proven | A randomised holdout on every decision. The reported number is incremental revenue and ARPU, not attributed conversions. | Not part of the product. | | Where the data sits | Reads context where it already lives, warehouse, CDP, product and billing systems. No new system of record. | Live tool reads plus public sources. | | Governance and control | Every action carries its hypothesis, its expected value, its guardrails and its control group, reviewable before launch. | Tool permissions and workspace policy. | | Time to a verified number | One revenue theme, one channel, one holdout: a defensible incremental number inside 90 days. | Seconds to an opinion, unchanged to a verified result. | | Best fit | Large B2C bases where the constraint is how many good hypotheses get tested, not how many messages get sent. | Teams that want cheap, fast reasoning and live external context. | ## What each layer is **Grok with MCP** — A fast, low-cost assistant with tool access and live external signal. Answers: What is happening, inside and outside the business, right now? **Markin** — An autonomous growth-science team running a versioned loop on your customer data. Answers: Which action deserves to exist for this customer, and what did it return? ## Side by side | | Grok with MCP | Markin | | --- | --- | --- | | Question it answers | What is happening, inside and outside the business, right now? | Which action deserves to exist for this customer, and what did it return? | | Primary input | Prompts, tool reads and public sources. | Warehouse, product, billing, margins, guardrails, experiment history. | | Primary output | Fast explanations and suggestions. | A sized action per customer, executed and measured. | | Usual owner | Anyone who wants a quick read. | Growth and data science, as reviewers. | | How it's measured | Speed and cost per answer. | Incremental ARPU against a randomised holdout. | ## What Grok with MCP does better - **Price genuinely matters, and Grok is aggressive on it.** Cost per token is one of the few things that decides whether an AI workflow can run at volume at all. That is the same reasoning that drives our own model routing, so it would be inconsistent to dismiss it. - **Real-time external signal is something we do not have.** Markin reads your systems. It does not watch the open web or social platforms for the story breaking around your brand right now, and for some teams that context is genuinely valuable. - **Fast and cheap changes who gets to ask.** When a question costs almost nothing, more people ask more questions, and that has real value independent of any platform. ## Which one to pick **Choose Markin if** - The output must be a decision per customer with a control group attached. - Ideas need to be ranked in money before they consume anyone's week. - Marketing, product, pricing and technical-health hypotheses compete in one queue. - Results are reported to finance and have to survive scrutiny. - The base is large enough that untested ideas are expensive. **Choose Grok with MCP if** - You want cheap, fast reasoning available to everyone. - Live external and social signal matters to your work. - The job is commentary and exploration, not execution. - You are not running controlled experiments on the base. ## Cheaper answers, same missing half Lowering the price of a suggestion increases how many suggestions you get. It does nothing about the part that costs real money: choosing between them, testing them properly and retiring the ones that stop working. - More candidates, no sizing, so the queue gets longer rather than better. - No power check, so undetectable effects still get built and argued about. - No holdout, so the reported win is attribution wearing a new interface. - No memory of what already failed, so the same idea returns next quarter. ## Where Markin fits Markin applies the same cost logic Grok is built on, but at the level of decisions: the cheapest model class that can do a step correctly does that step, and expensive reasoning is spent only where it changes the outcome. - **Cost per decision, not per question.** Volume work runs on small and trained models. - **Skills with evaluations.** Sizing, design, reading and arbitration are versioned components. - **Proof, not opinion.** Randomised holdouts on every action. Next: [Revenue Discovery](https://markin.ai/solutions/revenue-discovery) ## When Markin is not the right answer - You want the cheapest possible way to ask questions of your data. - The base is too small for controlled measurement. - Nothing may be actioned without individual human approval. ## FAQ **If tokens keep getting cheaper, does Markin still make sense?** More than before. Cheap reasoning makes candidate generation nearly free, which makes selection the bottleneck. Sizing in money, power checks and holdouts are what turn a large pile of suggestions into a small set of proven wins. **What does Grok do better?** Cost and speed per answer, and live external signal from the open web. Markin reads your systems and does not watch the outside world in real time. **Does Markin use cheap models too?** Constantly. Most per-customer work runs on small models and on trained ML, propensity, uplift, survival and time series. Frontier models are reserved for writing hypotheses, explaining findings and drafting briefs. **Can we use both?** Yes, and that is the common pattern: an assistant for questions, Markin for decisions and proof. **How is Markin different from the decisioning or AI already inside grok with mcp?** 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 grok with mcp 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 grok with mcp?** 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. Source: https://markin.ai/compare/markin-vs-grok-mcp --- --- title: ARPU benchmarks 2026: why B2C spreads keep widening url: https://markin.ai/blog/arpu-spreads-widening-b2c-2026 author: Team Markin published: 2026-07-18 keywords: ARPU benchmarks, ARPU 2026, B2C ARPU benchmarks, average revenue per user benchmarks, revenue per user, customer decisioning, growth data science --- # ARPU benchmarks 2026: why B2C spreads keep widening > ARPU benchmarks across eight B2C industries in 2026. The top quintile is pulling away at 2 to 4x the historical rate. What the leaders are doing differently. ## Key points - Across eight B2C categories, the top ARPU quintile is pulling away from the median at 2 to 4x the historical rate. - The leaders are not spending more on acquisition. They ship more per-user decisions per week against a preserved holdout. - The gap is compounding because decision volume, not creative volume, is now the binding constraint on ARPU growth. ## FAQ **What is ARPU and why are spreads widening in 2026?** ARPU (Average Revenue Per User) is the revenue a business earns per active customer over a period. Spreads are widening because a small group of operators has moved from campaign-based marketing to continuous per-user decisioning, which compounds ARPU faster than any traditional CRM or CDP program. **Which B2C industries show the largest ARPU gap between leaders and median?** Telecom, streaming, retail, travel, betting, food delivery, banking and insurance all show widening spreads. Streaming and telecom show the steepest curves because retention and upgrade decisions are near-daily and directly measurable. **How do ARPU leaders operate differently from the median?** They ship hundreds of small experiments in parallel against preserved holdouts, treat each customer state as a distinct decision, and measure incremental uplift rather than response rates. Creative and channel are downstream of that decisioning layer. **Can smaller B2C businesses close the ARPU gap without a large data team?** Yes. The binding constraint is decision volume, not headcount. An agentic decisioning platform can generate, stress-test and route candidate actions at a rate a small team cannot, provided every action is measured against a holdout. Full article: https://markin.ai/blog/arpu-spreads-widening-b2c-2026 --- --- title: Continuous decisioning: from campaign calendars to always-on 1:1 url: https://markin.ai/blog/campaign-calendars-to-continuous-decisioning author: Team Markin published: 2026-07-09 keywords: continuous decisioning, always-on experimentation, next best action operating model, campaign calendar alternative, revenue decisioning, growth operating model --- # Continuous decisioning: from campaign calendars to always-on 1:1 > Continuous decisioning replaces the weekly promo calendar with a loop that ships hundreds of small, causal experiments per week against a preserved holdout. A 90-day migration. ## Key points - The weekly promo calendar is a legacy constraint from an era of scarce creative and manual audience building. - Continuous decisioning replaces the calendar with a loop that ships small, per-user actions against a preserved holdout. - A 90-day migration path: instrument holdouts, move one lifecycle stage per sprint, retire the calendar last. ## Steps 1. **Instrument a preserved holdout at the base level.** Reserve 5 to 15 percent of the eligible customer base as a rolling holdout that never receives interventions from the new system. Every future decision reads incrementality against this control. 2. **Move one lifecycle stage to continuous decisioning.** Pick the stage with the clearest telemetry, usually onboarding or retention. Retire the calendar for that stage only and route decisions through the agentic loop. Keep the rest of the calendar untouched during weeks 3 to 8. 3. **Retire the calendar for the remaining stages.** Once the first stage shows a stable incremental read against the holdout, migrate acquisition, expansion and win-back in successive two-week sprints. Preserve calendar slots only for genuinely calendar-bound moments (launches, regulatory windows, seasonal peaks). ## FAQ **What is continuous decisioning?** Continuous decisioning is an operating model where per-user actions are proposed, stress-tested, shipped and measured against a preserved holdout on a rolling basis, instead of being scheduled into weekly or monthly campaigns. **How is it different from a marketing campaign calendar?** A campaign calendar batches audiences and creative into fixed slots. Continuous decisioning treats each customer state as a live decision, ships hundreds of small experiments per week, and reads incrementality per decision rather than per campaign. **How long does it take to migrate from a campaign calendar to continuous decisioning?** Typically 60 to 90 days. The critical prerequisites are a preserved holdout at the base level, a well-instrumented event stream, and one lifecycle stage to migrate first, usually onboarding or retention. **Do we still need a marketing calendar after moving to continuous decisioning?** Only for genuinely calendar-bound moments such as product launches, seasonal peaks and regulatory windows. Everything else is better handled as continuous decisions with holdouts. Full article: https://markin.ai/blog/campaign-calendars-to-continuous-decisioning --- --- title: Opportunity Feed, now with hypothesis provenance url: https://markin.ai/blog/opportunity-feed-hypothesis-provenance author: Team Markin published: 2026-06-27 keywords: hypothesis provenance, Markin Opportunity Feed, AI audit trail, candidate action, revenue decisioning, AI governance --- # Opportunity Feed, now with hypothesis provenance > Every candidate action in the Markin Opportunity Feed now carries the signal, segment and prior experiment it descends from. One click to audit or ship. ## Key points - The Opportunity Feed now attaches full provenance to every candidate action: source signal, segment, prior experiments and model version. - Reviewers can audit or ship an action in a single click without leaving the feed. - Provenance is a first-class object, not a log line, and is queryable in retrospectives. ## FAQ **What is hypothesis provenance in the Markin Opportunity Feed?** Hypothesis provenance is the structured trail attached to every candidate action, capturing the originating signal, the customer segment, the prior experiments it descends from and the model version that generated it. **Why does hypothesis provenance matter for revenue decisioning?** Provenance makes candidate actions auditable and reproducible. Reviewers can distinguish a novel hypothesis from a recycled one, retrospectives can query which signals produced winning actions, and governance can enforce policy at the source level. **Does provenance change how experiments are measured?** No. Measurement still runs against a preserved holdout on the operator's own base. Provenance changes how hypotheses are chosen, not how outcomes are read. Full article: https://markin.ai/blog/opportunity-feed-hypothesis-provenance --- --- title: Cross-sell without cannibalization: uplift, holdouts and guardrails url: https://markin.ai/blog/cross-sell-without-cannibalization author: Team Markin published: 2026-06-12 keywords: cross-sell cannibalization, cross-sell uplift modeling, incrementality measurement, uplift modeling, holdout design, revenue expansion --- # Cross-sell without cannibalization: uplift, holdouts and guardrails > How to measure incremental uplift, detect cannibalization and set profit-based guardrails for cross-sell programs that need to defend ARPU, not just campaign response rates. ## Key points - Response rate is the wrong metric for cross-sell. Incremental uplift against a preserved holdout is the only defensible read. - Cannibalization is measurable: it shows up as negative uplift on the substitute product inside the treated segment. - Guardrails should be set per product margin, not per campaign, so decisions are ranked by profit uplift, not revenue lift. ## FAQ **What is cannibalization in a cross-sell program?** Cannibalization occurs when a cross-sell offer moves revenue from an existing product to a new one without creating incremental spend. It shows up as positive response on the new product and negative uplift on the substitute product for the treated segment. **How do you measure incremental uplift in cross-sell?** By reserving a preserved holdout at the base level, ranking customers by predicted uplift from a two-model or meta-learner approach, and comparing treated versus holdout revenue on both the target product and any plausible substitutes. **Which model is best for uplift in a cross-sell program?** There is no single best model. Meta-learners such as T-learner, X-learner and R-learner all work with tabular customer data. What matters more than model choice is disciplined holdout design and evaluation on incremental profit rather than response rate. **How much holdout is needed to prove incrementality?** Enough to detect the smallest business-relevant lift with reasonable power. For most B2C cross-sell programs this is 5 to 15 percent of the eligible base, preserved for the full measurement window. Full article: https://markin.ai/blog/cross-sell-without-cannibalization --- --- title: What a top data science team looks like in an agentic era url: https://markin.ai/blog/top-data-science-team-agentic-era author: Team Markin published: 2026-05-30 keywords: data science team, agentic AI, growth analytics team, hypothesis authorship, analyst workflow 2026, data team operating model --- # What a top data science team looks like in an agentic era > Notes from conversations with heads of growth and analytics at eight enterprises rethinking how their data teams spend the week under agentic AI. ## Key points - Top data teams have shifted from report production to hypothesis authorship and adjudication. - The scarce skill is no longer building the model but deciding which of the agent's proposals deserves holdout. - Team structure follows: fewer dashboard shifts, more experiment reviewers embedded with revenue owners. ## FAQ **How is a data science team changing in the agentic era?** The share of time spent producing dashboards and one-off analyses is shrinking. The share spent authoring, stress-testing and adjudicating hypotheses generated by agents is growing. Team structures are shifting from centralized reporting pods to reviewer roles embedded with revenue owners. **Does agentic AI reduce data science headcount?** In the enterprises we spoke with, no. It reallocates it. The number of decisions the team can support goes up materially while the headcount stays flat or grows modestly. **What skills matter most for a data scientist in 2026?** Causal reasoning, experiment design, hypothesis adjudication, and the ability to critique an agent's proposal against domain context. Coding fluency remains table stakes but is no longer the differentiator. Full article: https://markin.ai/blog/top-data-science-team-agentic-era --- --- title: Churn prevention economics in streaming and telecom url: https://markin.ai/blog/churn-economics-streaming-telecom author: Team Markin published: 2026-05-14 keywords: churn prevention, incremental save rate, streaming churn, telecom churn, reduce customer churn, retention economics, subscription ARPU --- # Churn prevention economics in streaming and telecom > Where saves compound, where they don't, and why most retention programs in subscription businesses optimize the wrong margin. A CFO-grade view of incremental save rate. ## Key points - Most retention programs report save rate. The number that matters is incremental save rate against a preserved control. - In streaming, saves compound when they arrive before the first missed billing event; after that, most saves are non-incremental. - In telecom, the highest-margin save is a plan change, not a discount. Discount-first programs systematically erode ARPU. **Incremental save rate** — The share of treated at-risk customers who stay because of the retention intervention, above the rate that would have stayed anyway. Measured by comparing treated cohorts to a preserved holdout, not by observing save rate alone. ## FAQ **What is incremental save rate in churn prevention?** Incremental save rate is the share of treated customers who stay because of the intervention, above the rate that would have stayed anyway. It is measured by comparing treated cohorts to a preserved holdout, not by observing save rate alone. **Are discount-based retention offers profitable in telecom?** Rarely, once incrementality is measured. A large share of customers who accept a discount would have stayed without it. Plan-change offers and value-adds usually produce higher incremental margin than price cuts. **When is a retention intervention too late in streaming?** After the first missed billing event or the first disengagement window, incremental save rates fall sharply. The best-performing programs intervene during engagement decay, before the cancellation surface is reached. **How should retention success be reported to the CFO?** As incremental margin retained per treated customer, net of intervention cost. Save rate on its own overstates program value and hides cannibalization of natural retention. Full article: https://markin.ai/blog/churn-economics-streaming-telecom --- --- title: Agents on the open web: browsing inside a decisioning loop url: https://markin.ai/blog/agents-on-the-open-web author: Team Markin published: 2026-05-07 keywords: agentic browsing, AI agents open web, hypothesis generation, prompt injection defense, AI agent provenance, revenue decisioning --- # Agents on the open web: browsing inside a decisioning loop > A taxonomy of agentic browsing, the failure modes we spent the most time on, and empirical results from six enterprise workspaces measured against a preserved holdout. ## Key points - Agentic browsing changes which hypotheses are reachable, and therefore which experiments are ever run. - Five intent categories cover 94% of agent-initiated fetches: reference lookup, tonal widening, external signal discovery, competitor surveillance, hypothesis stress-testing. - In six enterprise pilots, novel hypothesis rate rose from 11% to 27% and experiment win rate from 22% to 29%. ## FAQ **What is agentic browsing?** Agentic browsing is a scoped, auditable capability that lets AI agents fetch, read and cite public web pages as part of a decisioning loop, with every fetch stored as a first-class object with URL, timestamp and content hash. **Why let agents browse the open web at all?** Because hypothesis authorship is the only station in a revenue decisioning loop that is not naturally bounded by first-party data. External context is what lifts hypotheses out of the operator's own data distribution and the model's pre-training. **How is prompt injection handled when agents browse public pages?** Fetched content is never composed directly into a system prompt. It is parsed to strip instructions, preserved as evidence in a separate context slot, and the agent is prompted to reason over it as data. A red team injection suite runs weekly against a rotating pool of real fetched pages. **Can Markin agents purchase, sign up or submit forms on third-party sites?** No. The browsing layer is read-only against any surface the operator does not own. Any write goes through the workspace action layer with human authorization. Full article: https://markin.ai/blog/agents-on-the-open-web --- --- title: CMOs on the shift from creative volume to decision volume url: https://markin.ai/blog/creative-volume-to-decision-volume author: Team Markin published: 2026-05-02 keywords: decision volume, creative volume, CMO priorities 2026, personalization at scale, revenue decisioning, 1:1 marketing --- # CMOs on the shift from creative volume to decision volume > Four CMO conversations on what changes when the constraint moves from producing creative assets to routing the right asset to the right customer. ## Key points - Creative production is no longer the bottleneck; deciding which asset goes to which customer is. - Budget is shifting from asset generation to decisioning infrastructure and holdout discipline. - The CMO org chart is following: fewer producers, more decision reviewers and experiment owners. ## FAQ **What is decision volume in marketing?** Decision volume is the number of distinct per-customer routing decisions a marketing system can make and measure in a given period. It is now the binding constraint on ARPU growth in most B2C categories, replacing creative volume. **Why is creative volume no longer the constraint for most CMOs?** Generative tools have collapsed the cost of producing high-quality creative variants. The scarce resource has shifted to deciding which variant is served to which customer under which conditions, and reading incrementality on that decision. **How are CMO teams reorganizing around decision volume?** Producer roles are shrinking or consolidating. Reviewer, experiment owner and lifecycle strategist roles are growing. Budget is moving from asset production tools to decisioning infrastructure and measurement discipline. Full article: https://markin.ai/blog/creative-volume-to-decision-volume --- --- title: How to increase ARPU: a framework for B2C enterprises url: https://markin.ai/blog/how-to-increase-arpu author: Team Markin published: 2026-07-29 keywords: how to increase ARPU, increase ARPU, grow ARPU, ARPU growth strategy, improve average revenue per user, ARPU optimization --- # How to increase ARPU: a framework for B2C enterprises > How to increase ARPU in a large B2C business: the five levers that actually move average revenue per user, and the operating model behind them. ## Key points - Five levers move ARPU: pricing, plan mix, cross-sell, retention and reactivation. Only two of them compound. - Discount-first tactics almost always lower incremental ARPU. Plan-change and value-add moves almost always raise it. - Sustainable ARPU growth is a rate, not a campaign. It comes from continuously scoring and ranking per-user decisions against a holdout. ## Steps 1. **Score every customer for the five ARPU levers.** For each active customer, compute per-lever propensities and expected uplift: price change acceptance, plan-tier upgrade, cross-sell attach, save-on-cancel, and reactivation from lapse. Store the scores as first-class objects. 2. **Rank actions by expected incremental margin, not response.** Convert per-lever uplift into expected profit using product margins and intervention cost. Do not rank by predicted response. Do not rank by revenue. Rank by expected incremental margin per action. 3. **Ship against a preserved holdout, read causally.** Route the ranked actions through your existing channels and preserve 5 to 15 percent of the eligible base as an untreated holdout. Report ARPU lift as the treated-versus-holdout difference, per lever, per cohort, per week. ## FAQ **How do you increase ARPU in a B2C business?** Move from campaign-based promotions to continuous per-user decisioning. Score every eligible customer for the five levers (pricing, plan mix, cross-sell, retention, reactivation), rank actions by expected incremental margin, and run each against a preserved holdout so you can prove ARPU lift causally. **What is the fastest way to grow ARPU?** Plan-change nudges to under-utilized customers on lower tiers. They typically move the highest incremental margin with the lowest CAC and no discount cost, and are measurable against a holdout inside a single billing cycle. **Which ARPU tactics erode value instead of building it?** Blanket discounts, always-on promotions and retention offers that don't distinguish natural stayers from at-risk customers. Each of these lowers incremental ARPU while raising apparent response rate, so they look successful on a dashboard. **How do you measure ARPU growth without confusing lift with seasonality?** Reserve a preserved holdout at the base level for the full measurement window, and report incremental ARPU per treated customer against that control. Never rely on year-over-year or period-over-period trends alone, they are dominated by seasonality and mix. Full article: https://markin.ai/blog/how-to-increase-arpu --- --- title: What is ARPU? Definition, formula and how to calculate it url: https://markin.ai/blog/what-is-arpu-definition-formula author: Team Markin published: 2026-07-28 keywords: what is ARPU, ARPU meaning, ARPU definition, average revenue per user, ARPU formula, how to calculate ARPU, ARPU SaaS --- # What is ARPU? Definition, formula and how to calculate it > ARPU (Average Revenue Per User) explained: definition, formula, worked example and the mistakes most operators make when reporting it. ## Key points - ARPU is total revenue in a period divided by the number of active users in that period. Nothing more, nothing less. - The two things operators get wrong most often: the denominator (active vs total users) and whether to net out refunds and taxes. - ARPU is a rate. Comparing it across periods without cohorting for tenure and mix is the most common way it gets misread. **ARPU (Average Revenue Per User)** — Total revenue generated in a period divided by the number of active users during the same period. Reported as a per-user monetary rate (typically monthly) and used as the primary unit economic in most B2C subscription and consumption businesses. ## FAQ **What does ARPU stand for?** ARPU stands for Average Revenue Per User. In some categories it is reported as ARPA (Average Revenue Per Account) or ARPPU (Average Revenue Per Paying User) to disambiguate the denominator. **What is the ARPU formula?** ARPU = Total revenue in the period / Number of active users in the period. Both terms must cover the same period and use the same definition of 'active'. **How do you calculate ARPU?** Pick a period (usually a month). Sum recognized revenue attributable to end users over that period, excluding refunds and taxes. Divide by the count of unique users who were active in the same period, using a consistent definition of active (paying, logged-in, or entitled). **What is a good ARPU?** There is no absolute benchmark. ARPU only carries information when compared inside a category, controlling for tenure, plan mix and geography. A subscription streaming service in the US and a prepaid mobile carrier in India can have identical growth stories with 30x different ARPU. **Is ARPU the same as LTV?** No. ARPU is a per-period rate. LTV (Lifetime Value) is the discounted sum of future ARPU over the expected customer lifetime, net of variable cost. LTV depends on both ARPU and retention; ARPU depends on neither. Full article: https://markin.ai/blog/what-is-arpu-definition-formula --- --- title: What is Next Best Action? A guide for revenue teams in 2026 url: https://markin.ai/blog/what-is-next-best-action author: Team Markin published: 2026-07-25 keywords: what is next best action, next best action, next best action marketing, next best action model, NBA marketing, next best action software, next best offer --- # What is Next Best Action? A guide for revenue teams in 2026 > Next Best Action explained: what it is, how it works, how it differs from segmentation, and what a modern NBA stack looks like in 2026. ## Key points - Next Best Action (NBA) is a decisioning approach that picks, per customer per moment, the single action with the highest expected incremental value. - It is not segmentation. Segmentation groups customers; NBA scores actions for individuals. - A modern NBA stack has three layers: signals, uplift models, and an execution layer that preserves a holdout on every decision. **Next Best Action (NBA)** — A decisioning approach where, for each customer at each moment, the system evaluates every eligible intervention and selects the one with the highest expected incremental value. NBA replaces segment-level campaign planning with per-customer, per-moment routing, measured causally against a preserved holdout. ## FAQ **What is Next Best Action?** Next Best Action (NBA) is a decisioning approach where a system evaluates, for each customer at each moment, every eligible intervention and selects the one with the highest expected incremental value. It replaces segment-and-blast campaigns with per-customer, per-moment routing. **How does Next Best Action work in marketing?** The system ingests behavioral, transactional and contextual signals; scores each customer for a set of eligible actions using propensity or uplift models; and picks the single action with the highest expected incremental margin, subject to channel, frequency and eligibility constraints. Each decision is measured against a preserved holdout. **What is the difference between Next Best Action and segmentation?** Segmentation groups customers into buckets and applies a shared treatment to the bucket. NBA scores every action for every individual customer and picks the winner per customer per moment. Segments can still exist as guardrails or eligibility filters, but they no longer decide what to send. **What technologies support Next Best Action?** A modern NBA stack combines: a real-time event stream, a feature store, propensity and uplift models (often meta-learners such as T-, X- and R-learner), a decisioning engine that ranks eligible actions, and an execution layer that preserves holdouts and reads incrementality per decision. **How does Next Best Action reduce churn?** By scoring retention interventions per-customer against a holdout, NBA distinguishes at-risk customers whose churn is actually preventable from natural stayers who don't need an offer. That lifts incremental save rate without eroding ARPU through unnecessary discounts. Full article: https://markin.ai/blog/what-is-next-best-action --- --- title: Customer churn prediction: models, features and incrementality url: https://markin.ai/blog/customer-churn-prediction-guide author: Team Markin published: 2026-07-22 keywords: customer churn prediction, churn prediction, churn prediction model, predict customer churn, reduce customer churn, churn management, churn risk --- # Customer churn prediction: models, features and incrementality > A practical guide to customer churn prediction: which models actually work, which features move the needle, and how to convert prediction into incremental save rate. ## Key points - A churn prediction score is not a retention program. Two customers with the same score can have very different treatment-effect economics. - The models that consistently win in production are gradient-boosted trees for propensity and meta-learners (T-, X-, R-learner) for uplift. - Feature engineering matters more than model choice: recency-weighted engagement, billing anomalies and support friction dominate every leaderboard we see. ## Steps 1. **Assemble the feature set.** Pull recency-weighted engagement, billing anomalies, support friction, plan changes and tenure interactions from your warehouse. Freeze features at prediction time to avoid leakage. 2. **Train propensity, then uplift.** Train a gradient-boosted propensity model on churn labels first. Then train a meta-learner (T-, X- or R-learner) on the same features using a preserved retention experiment as the treatment indicator. 3. **Route decisions through a holdout.** For each customer above the intervention threshold, rank the eligible retention actions by uplift-weighted margin. Preserve 5 to 15 percent as an untreated holdout and read incremental save rate weekly, per cohort. ## FAQ **What is customer churn prediction?** Customer churn prediction is the practice of estimating, for each customer, the probability of ending their relationship (canceling a subscription, closing an account, or lapsing) within a defined horizon, from historical behavioral, transactional and contextual features. **What is the best model for customer churn prediction?** For propensity (probability of churn), gradient-boosted trees (XGBoost, LightGBM, CatBoost) reliably win on tabular data. For uplift (probability of churn caused by treatment), meta-learners such as T-learner, X-learner and R-learner are the practical default. Deep learning helps only when sequence structure dominates the signal. **How can AI help predict and prevent customer churn?** AI does two distinct jobs. Prediction identifies who is likely to churn. Decisioning selects which intervention has the highest expected incremental save for each predicted churner. The second job is where most retention value actually lives, and it requires uplift models plus a preserved holdout. **Which features matter most for a churn prediction model?** Recency-weighted engagement (days since last active, session frequency decay), billing anomalies (failed payments, downgrades, plan changes), support friction (ticket volume, resolution time, escalation), and tenure interactions. Marketing exposure features usually add little unless the base rate of contact is low. **How do you measure the success of a churn prediction program?** Not by AUC or precision alone. Measure incremental save rate: the difference in retention between treated customers (those whose predicted risk triggered an intervention) and a preserved holdout of equally-scored customers who received no intervention. Report incremental margin retained, net of intervention cost. Full article: https://markin.ai/blog/customer-churn-prediction-guide