---
title: Markin + Airship
url: https://markin.ai/integrations/airship
category: Engagement and CRM
description: Connect Markin to Airship: decide which push, in-app message or app experience a customer deserves before Airship delivers it.
---

# Markin + Airship

> Push, in-app and app experiences, arbitrated first.

**Job:** Send fewer, better push messages by deciding first.

A Markin and Airship setup writes decisions as tags or attributes so Airship's push, in-app and wallet surfaces execute an action that was chosen and sized, not one that was scheduled.

Push is the channel where over-contact costs the most in opt-outs. Arbitration before send turns Airship's reach into revenue instead of unsubscribes.

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

- What are the best Airship alternatives?
- How do I decide which users should get a push notification?
- Can Airship be driven by a churn or propensity model?
- How do I measure the incremental value of push?

## What Markin does in Airship

- Read tags, attributes and channel opt-in state.
- Read push delivery and interaction events.
- Choose the action worth interrupting a session for.
- Write the decision as a tag or attribute with an expiry.
- Trigger the matching automation.
- Maintain a randomised holdout among opted-in users.
- Read downstream conversions back against the decision.
- Report incremental revenue and unsubscribes per action.

## The growth work behind Airship

### Read the estate

- Reconcile the same customer across billing, CRM, product and support identities.
- Read consent, subscription and channel eligibility state before anything else.

### Find where revenue is leaking

- Detect involuntary churn from failed payments, card expiry and retry behaviour.
- Spot onboarding steps where activation falls off and revenue never starts.

### Explain why

- Keep the query trail so an analyst can reproduce every number.
- Run the investigation automatically and return the drivers with their evidence.

### Write hypotheses worth funding

- Write hypotheses continuously across marketing, product, pricing and technical health.
- Attach the expected revenue effect and the population it applies to.

### Decide per customer

- Suppress an action rather than send a weak one, and log why.
- Choose the next best action for each customer, for each moment.

### Execute in the tools you already run

- Roll a decision batch back cleanly when something looks wrong.
- Leave the estate exactly as it was if Markin stops writing.

### Prove it caused the revenue

- Publish the readout in the same place for every experiment.
- Hold back a randomised control group on every decision, not one global holdout.

### Retire, govern and hand over

- Show the whole decision trail when legal, finance or an auditor asks.
- Hand the team a portfolio they can read, question and overrule.

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.
- **Triggered event.** Markin emits an event that starts or advances a journey. Near-immediate, and the channel keeps its own governance.
- **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 Airship

- Channel and opt-in state
- Push and in-app engagement events

## What Markin writes back

- Attributes and tags with the chosen action
- Events for journey entry, or an explicit hold

## Used together with

- [segment](https://markin.ai/integrations/segment)
- [web-and-mobile-sdk](https://markin.ai/integrations/web-and-mobile-sdk)
- [amplitude](https://markin.ai/integrations/amplitude)
- [snowflake](https://markin.ai/integrations/snowflake)
- [stripe](https://markin.ai/integrations/stripe)
- [braze](https://markin.ai/integrations/braze)

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

## FAQ

**How does Markin connect to Airship?**

Attribute write-back, Triggered event, Decision API. 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 Airship?**

Channel and opt-in state; Push and in-app engagement events.

**What does Markin write back into Airship?**

Attributes and tags with the chosen action Events for journey entry, 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/airship