Markin + Web and mobile SDK integration
In-session decisions rendered into your own surfaces.
What is a Web and mobile SDK AI agent?
The Markin web and mobile SDK asks for a decision at render time and receives one action plus its reason, with a defined fallback and a latency budget. It is how in-session surfaces such as paywalls, home screens and checkout get a decision without a round trip through a channel.
Some surfaces cannot wait for a sync interval. A paywall or home screen slot asks at render time and gets one answer, and the surface always renders even when Markin does not answer.
What Markin reads
- Session context passed at request time
What Markin writes back
- One action plus its reason, per request, with a fallback default
How the connection works
| Pattern | What it means here |
|---|---|
| Decision API | The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback. |
| Direct surface | Markin populates a slot in the product or message body directly, for placements where round-tripping through a channel adds nothing. |
What can you ask Markin to do in Web and mobile SDK?
- How do I personalise a paywall in real time?
- How do I add a decision API to my app without slowing it down?
- What renders if the decision service is unavailable?
- How do I test in-product offers against a holdout?
What Markin does in Web and mobile SDK
- 01Serve one decision per surface request inside a latency budget.
- 02Return the reason alongside the action for logging and audit.
- 03Fall back to a defined default when no decision is available.
- 04Cache decisions per session to avoid repeated calls.
- 05Assign and honour holdout membership at the device level.
- 06Emit impression and interaction events back automatically.
- 07Respect consent state passed by the client.
- 08Report incremental revenue per surface and per slot.
Scope of work
The growth work behind Web and mobile SDK
The list above is what Markin touches in Web and mobile SDK. 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.
- Read contact history so past sends count as pressure on the customer.
- Track catalogue, pricing and plan changes as they happen.
Find where revenue is leaking
Normally a quarterly analyst deep dive.
- Spot pricing and packaging mismatch between what people buy and what they use.
- Spot product friction that correlates with downgrade and cancellation.
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.
- Arbitrate between every action competing for that same customer.
- Apply frequency caps, fatigue and quiet hours before anything is committed.
Execute in the tools you already run
Normally a ticket, then a slot in next month's calendar.
- Write decisions into the CRM, engagement and warehouse systems already in production.
- Trigger journeys and campaigns that your lifecycle team owns and can edit.
Prove it caused the revenue
Normally argued about, rarely measured.
- Read uplift in revenue per customer against that control.
- Report retention, ARPU, margin and contact pressure side by side.
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.
Teams use Web and mobile SDK together with
Where this shows up
Web and mobile SDK questions
- How does Markin connect to Web and mobile SDK?
- Decision API, Direct surface. The surface asks Markin for a decision at render time and receives one action plus its reason, with a defined fallback.
- What does Markin read from Web and mobile SDK?
- Session context passed at request time.
- What does Markin write back into Web and mobile SDK?
- One action plus its reason, per request, with a fallback default
- 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.