---
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.
updated: 2026-09-03
---

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

## In short

- Hightouch: How do we get this warehouse data into the tools that need it? Output: Synced audiences, profiles and traits in downstream destinations.
- Markin, the decision + execution layer: Which opportunity is worth acting on for this customer, and what is it worth? Output: A decision per customer, materialised back into the warehouse for activation.
- An audience is a rule over the warehouse. It does not estimate the incremental effect of acting on it.
- A composable stack already made the right architectural choice: the warehouse is the source of truth.

## 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