---
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:** Turn warehouse history into decisions without copying a single row out.

A Markin and Snowflake setup is a decision layer that runs on your warehouse. Markin reads customer, revenue and event history in place using a read role you grant, forms hypotheses about why revenue per customer is stuck, and writes decisions, holdout assignments and outcome reads back into a schema you own.

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.

## What can you ask Markin to do in Snowflake?

- How do I run next best action directly on Snowflake?
- Can I do customer decisioning without copying data out of my warehouse?
- How do I measure incrementality of lifecycle campaigns in Snowflake?
- How do I find which customer segments have the most ARPU upside?

## What Markin does in Snowflake

- Read customer, account and subscription dimensions on your compute.
- Read order, payment and refund history to build the revenue baseline.
- Derive behavioural features from event tables without a new pipeline.
- Detect ARPU drift by cohort, plan and market and raise it as an opportunity.
- Size the revenue at stake for each hypothesis before anything is launched.
- Write one committed decision per customer per window to a decision table.
- Write randomised holdout membership so every action has a control group.
- Write per-experiment causal reads your BI tool can join to its own models.
- Respect row-level security and masking policies your data team already set.
- Log every query and decision with its reason for audit.

## The growth work behind Snowflake

### Read the estate

- Rebuild the revenue baseline from orders, payments, refunds and credits.
- Derive behavioural features from event history without a new pipeline.

### Find where revenue is leaking

- Watch ARPU by cohort, plan, market, channel and tenure for drift that clears noise.
- Detect churn risk building in a segment before it shows in the monthly number.

### Explain why

- Separate mix effects from real behaviour change.
- Rank drivers by how much of the movement each one accounts for.

### Write hypotheses worth funding

- Attach the evidence and the assumption each one depends on.
- Rank the portfolio by expected value, not by seniority.

### Decide per customer

- Cap discount and margin exposure at the level finance agreed.
- Attach a plain-language reason and an expiry to every decision.

### Execute in the tools you already run

- Open the work as a draft for approval where a human should sign off.
- Recompute idempotently so a replay never double-sends.

### Prove it caused the revenue

- Refuse to call a result that has not cleared the evidence standard.
- Publish the readout in the same place for every experiment.

### Retire, govern and hand over

- Retire programmes automatically when they stop beating control.
- Re-test assumptions that decay, such as price sensitivity and seasonality.

Full catalogue: [Everything a growth team does, running every day.](https://markin.ai/growth-work)

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

## Used together with

- [hightouch](https://markin.ai/integrations/hightouch)
- [census](https://markin.ai/integrations/census)
- [braze](https://markin.ai/integrations/braze)
- [segment](https://markin.ai/integrations/segment)
- [amplitude](https://markin.ai/integrations/amplitude)
- [stripe](https://markin.ai/integrations/stripe)

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