Markin + LaunchDarkly integration
Feature flags as an execution channel for growth hypotheses.
What is a LaunchDarkly AI agent?
A Markin and LaunchDarkly setup uses flags as the execution surface for product-side decisions: Markin decides the treatment per customer, LaunchDarkly delivers it, and the outcome is read against a holdout.
Some of the largest ARPU changes are product changes, not messages. Treating a flag as a channel puts them in the same queue and under the same measurement discipline.
What Markin reads
- Flag definitions and exposure logs
What Markin writes back
- Per-user targeting decisions with holdouts preserved
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. |
What can you ask Markin to do in LaunchDarkly?
- How do I target feature flags by customer value?
- Can LaunchDarkly deliver a personalised experience per user?
- How do I measure the revenue impact of a feature rollout?
- How do I run a product experiment with a proper holdout?
What Markin does in LaunchDarkly
- 01Read flag definitions and current targeting rules.
- 02Decide the treatment per customer segment.
- 03Write targeting membership for the chosen treatment.
- 04Keep a randomised holdout excluded from the rollout.
- 05Track exposure events keyed to the decision ID.
- 06Read revenue and retention outcomes back per treatment.
- 07Recommend rollback when the read turns negative.
- 08Report incremental revenue per feature.
Scope of work
The growth work behind LaunchDarkly
The list above is what Markin touches in LaunchDarkly. 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.
Teams use LaunchDarkly together with
LaunchDarkly questions
- How does Markin connect to LaunchDarkly?
- Decision API. 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 LaunchDarkly?
- Flag definitions and exposure logs.
- What does Markin write back into LaunchDarkly?
- Per-user targeting decisions with holdouts preserved
- 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.