Markin + Snowflake integration
Read customer history in place, on your compute.
What is a Snowflake AI agent?
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 Markin reads
- 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
How the connection works
| Pattern | What it means here |
|---|---|
| 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 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
- 01Read customer, account and subscription dimensions on your compute.
- 02Read order, payment and refund history to build the revenue baseline.
- 03Derive behavioural features from event tables without a new pipeline.
- 04Detect ARPU drift by cohort, plan and market and raise it as an opportunity.
- 05Size the revenue at stake for each hypothesis before anything is launched.
- 06Write one committed decision per customer per window to a decision table.
- 07Write randomised holdout membership so every action has a control group.
- 08Write per-experiment causal reads your BI tool can join to its own models.
- 09Respect row-level security and masking policies your data team already set.
- 10Log every query and decision with its reason for audit.
Scope of work
The growth work behind Snowflake
The list above is what Markin touches in Snowflake. A connector is only the surface. Below is the work itself: what an analyst, a lifecycle manager, a data scientist and an experimentation lead would do between them, running continuously against your own data.
Read the estate
Normally a data engineer, once, then never refreshed.
- 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
Normally a quarterly analyst deep dive.
- 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
Normally a two-week investigation pulled off the roadmap.
- Separate mix effects from real behaviour change.
- Rank drivers by how much of the movement each one accounts for.
Write hypotheses worth funding
Normally a workshop, limited to the ideas in the room.
- Attach the evidence and the assumption each one depends on.
- Rank the portfolio by expected value, not by seniority.
Decide per customer
Normally segment rules refreshed when someone has time.
- 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
Normally a ticket, then a slot in next month's calendar.
- 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
Normally argued about, rarely measured.
- 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
Normally nobody's job, so nothing is ever switched off.
- Retire programmes automatically when they stop beating control.
- Re-test assumptions that decay, such as price sensitivity and seasonality.
Playbooks that run through Snowflake
- PlaybookAdd next best action to journeys you already run in BrazePer-customer arbitration written into the canvases your team already operates.
- PlaybookCross-sell a second product without cannibalising the plan the customer already pays forSecond-product offers valued on incremental margin, not on attach rate.
Snowflake questions
- 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.