RESOURCES/Architecture
How decisions reach the customer
A decision reaches the customer in one of four ways: written back as a profile attribute, fired as a triggered event, served on request through a decision API, or rendered directly into a product surface. Each has a different latency, a different governance owner, and a different failure mode when the channel is busy.
The decision is worthless until it is executed
Most decisioning disappointments are activation disappointments. The ranking was fine. What failed is that the chosen action needed a new template, a release window and a compliance review, so by the time it shipped the reason for choosing it had passed. Activation design decides whether a decision layer produces revenue or a dashboard.
- A recommendation that needs a human build step inherits the build queue's throughput.
- Batch write-back that lands after the journey has already fired is a decision nobody used.
- Every channel that receives decisions independently will eventually contradict the others.
Four patterns
Most deployments use two or three of these together. Choosing per surface rather than picking one for the whole estate is the correct default.
01
Pick per surface, not per estate
Lifecycle email over attribute write-back and a paywall over a decision API is a normal, healthy combination. Forcing one pattern everywhere either overpays for latency you do not need or starves the surfaces that do.
02
Keep governance where it already is
Frequency capping, quiet hours, consent and brand review should stay in the systems that already enforce them. The decision layer supplies intent; the channel keeps its veto.
03
Make the write-back idempotent
Decisions are recomputed. Activation must tolerate the same decision arriving twice without sending twice, and must handle a decision being superseded before it executes.
04
Close the loop
Delivery, engagement and outcome events flow back into the decision layer, keyed to the original decision. Without that key, the measurement plane can report what happened but not what it was a consequence of.
05
Design the failure mode
When the decision layer is unavailable, every surface should degrade to a defined default rather than to whatever the last cached value was. Write the default down for each surface before launch.
Activation patterns and their trade-offs
| Pattern | How it works | Best for | Trade-off |
|---|---|---|---|
| Attribute write-back | The decision is written to the customer profile in the CDP or engagement platform; existing journeys read it as an entry condition. | Lifecycle programmes already built in the engagement platform. | Latency is the sync interval. A decision that changes hourly will be stale at the moment of send. |
| Triggered event | The decision is emitted as an event that starts or advances a journey. | Time-sensitive lifecycle moments: dunning, churn risk, post-purchase. | Requires event contracts to be maintained. Journey logic can silently swallow events. |
| Decision API | The surface asks for a decision at render time and receives one action plus its reason. | In-session surfaces: paywalls, checkout, home screens, care agent screens. | Needs a fallback path and a latency budget. The surface must be able to render without an answer. |
| Direct surface rendering | The decision layer populates a slot in the product or a message body directly. | High-frequency in-product placements where round-tripping through a channel adds nothing. | Closest to owning the channel. Keep creative governance outside the decision layer. |
Integration readiness, per surface
Answer these once for each surface before you connect it.
- What is the acceptable latency between decision and execution here?
- Which pattern matches that latency at the lowest operational cost?
- What renders if no decision is available?
- Who owns the veto: consent, frequency, quiet hours, brand?
- How does the outcome get back, and is it keyed to the decision ID?
- If this surface is removed next quarter, does anything else break?
When not to connect a surface
- Surfaces with no outcome signal. If you cannot observe what happened, the decision cannot be learned from and the surface is just a broadcast.
- Channels where every message needs individual legal sign-off. The approval step sets the throughput, so automation adds little.
- Very low-volume surfaces, where no decision will ever reach statistical power.
- Surfaces owned by a team that has not agreed to the guardrails. Activation without agreement is how a decision layer gets switched off.
Markin is an autonomous growth-science team for large B2C businesses. It investigates why revenue per customer is stuck, forms its own hypotheses across marketing, product, pricing and technical health, chooses the next best action for each customer, launches it through the systems the business already runs, and proves every one against a randomised holdout.
Decisioning tools choose between the actions your team already built. Markin decides what to build.
Questions people ask
- Does Markin send messages itself?
- Only where a surface has no other executor, such as a product slot that Markin renders directly. For channels you already run, Markin writes the decision into them: an attribute, an event or an API response. Content, channel governance and deliverability stay with the platform that already owns them, which is what makes the integration reversible.
- How fast is activation?
- It depends on the pattern rather than on the decision. A decision API answers in-session, a triggered event is near immediate, and attribute write-back inherits the sync interval of the platform receiving it, which is often hourly. Choose the pattern from the latency the surface actually needs.
- What happens if two decisions target the same customer at once?
- They should never leave the decision layer. Arbitration happens before activation and the output is one committed decision per customer per window. If two decisions reach the channel, the arbitration boundary has been drawn in the wrong place.
- Do we have to replace our reverse ETL tooling?
- No. Attribute write-back can run over the reverse ETL pipeline you already operate. The decision layer produces the rows; the existing pipeline moves them. Replacing a working pipeline adds risk without adding decision quality.