Markin + Airship integration
Push, in-app and app experiences, arbitrated first.
What is a Airship AI agent?
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.
Attribute write-backTriggered eventDecision API
What Markin reads
- 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
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. |
| 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 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
- 01Read tags, attributes and channel opt-in state.
- 02Read push delivery and interaction events.
- 03Choose the action worth interrupting a session for.
- 04Write the decision as a tag or attribute with an expiry.
- 05Trigger the matching automation.
- 06Maintain a randomised holdout among opted-in users.
- 07Read downstream conversions back against the decision.
- 08Report incremental revenue and unsubscribes per action.
Scope of work
The growth work behind Airship
The list above is what Markin touches in Airship. 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.
- 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
Normally a quarterly analyst deep dive.
- Detect involuntary churn from failed payments, card expiry and retry behaviour.
- Spot onboarding steps where activation falls off and revenue never starts.
Explain why
Normally a two-week investigation pulled off the roadmap.
- 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
Normally a workshop, limited to the ideas in the room.
- Write hypotheses continuously across marketing, product, pricing and technical health.
- Attach the expected revenue effect and the population it applies to.
Decide per customer
Normally segment rules refreshed when someone has time.
- 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
Normally a ticket, then a slot in next month's calendar.
- 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
Normally argued about, rarely measured.
- 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
Normally nobody's job, so nothing is ever switched off.
- Show the whole decision trail when legal, finance or an auditor asks.
- Hand the team a portfolio they can read, question and overrule.
Airship questions
- 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.