← Back to blog

Trust Markov Chain Attribution With 200 Conversions for Analysts

October 9, 2026
Trust Markov Chain Attribution With 200 Conversions for Analysts

Markov chain attribution scores each marketing channel by measuring how overall conversion probability changes when that channel is removed from the customer journey, a calculation known as the removal effect. It suits multi-touch journeys with enough volume for transitions to stabilize and where the order of interactions matters. It does not, on its own, prove that a channel causes conversions: that requires an experiment.


TL;DR:

  • Include nonconverting journeys; omitting them inflates removal effects and distorts channel rankings, so record ordered touchpoints, conversion status, and a stable user or device identifier.
  • Require at least 200 conversions before trusting probabilistic attribution, and treat low volume channel scores cautiously because a few additional paths can change their rankings.
  • Start with a first order model, then compare first and second order credit shares; use higher order only when validation performance clearly improves.
  • Unlogged offline interactions, call center conversations, and ad views remain invisible, so incomplete journey tracking can leave modeled channel rankings misleading.
  • Report removal effects as ranges when bootstrap intervals are wide or rankings shift across settings, and use incrementality tests before changing budgets.

Cassandra
cassandra.app
Put Attribution in Revenue Context
Cassandra combines attribution with MMM and incrementality testing to help B2C brands assess paid media’s revenue impact by channel.
Explore Cassandra’s measurement

Table of Contents

What Markov chain attribution models: states, transitions, and absorbing nodes

A Markov chain attribution model represents a customer journey as a graph of states. Every path begins at a Start node and moves through a sequence of channel states (paid search, social, email, display) before landing on one of two absorbing nodes: Conversion or Null. Once a path reaches an absorbing state, it stops. This structure differs from a simple funnel chart because it lets any channel appear at any position, multiple times, in any order.

Each observed journey contributes to a count of transitions between states: how often a visitor moved from paid search to email, from email to Conversion, or from social straight to Null. Those counts become the raw material for the transition matrix described in the next section.

  • Journeys are built from ordered, time-stamped touchpoints per user or session.
  • Start and the two absorbing states anchor every path, regardless of length.
  • Repeated visits to the same channel are preserved rather than collapsed.

Because order and repetition are captured, this approach can credit middle-funnel and repeat touchpoints that first-touch or last-touch heuristics tend to erase entirely.

How the math works: the transition matrix, simulation, and the removal effect formula

The transition matrix converts raw counts into probabilities. For each state, we divide the number of times a path moved to a given next state by the total number of transitions out of that state, producing a row of probabilities that sums to 1. This matrix fully describes the modeled behavior of the customer base.

From the matrix, we simulate random walks starting at the Start node and ending at Conversion or Null, repeated many times to estimate a baseline conversion probability, P(conversion). We then remove one channel at a time, forcing any path that would have passed through it to end at Null instead, and resimulate to get P(conversion | channel k removed).

  1. Build and normalize the transition matrix from observed journey counts.
  2. Simulate the baseline conversion probability using the full matrix.
  3. Remove each channel in turn and resimulate to get the restricted conversion probability.
  4. Compute the removal effect for each channel and normalize across all channels to produce credit shares.

The removal effect itself follows a simple ratio, as described by MetricGate's methodology: RE_k = 1 − P(conv | k removed) / P(conv). A channel whose removal cuts conversion probability sharply earns a high removal effect, and dividing each channel's RE by the sum of all REs turns the raw scores into percentage credit.

Removal effect in practice: a channel with RE_k = 0.30 means conversion probability drops 30% when that channel is excluded from the journey, a direct, interpretable signal of its structural importance in the model.

Journey simulation showing a channel removal effect

Implementing Markov attribution in practice: data, preprocessing, and software options

A usable dataset needs, at minimum, a path identifier, an ordered list of channel touchpoints, a conversion flag, and conversion value when available. Critically, it must also include paths that never converted. As ChannelAttribution's package documentation notes, non-converting paths are what let the model estimate a realistic baseline conversion probability; omitting them inflates removal effects and distorts channel rankings.

Before modeling, we settle a few preprocessing decisions:

  • Choose a consistent lookback window (commonly 30 to 90 days) and apply it uniformly across channels.
  • Pick a path separator and deduplicate consecutive repeats from the same channel if they represent a single session.
  • Link sessions to a stable user or device identifier so a journey is not artificially split.
  • Decide whether to group granular campaigns into channel-level buckets before modeling.

For implementation, the ChannelAttribution package in R exposes the core parameters: order for the Markov order, nsim for simulation count, seed for reproducibility, max_step to cap path length, and conv_par for the conversion value weighting. The ChannelAttribution function documentation details the markov_model and transition_matrix outputs for implementers working in production pipelines, and open proof-of-concept code is available in public GitHub repositories for teams building a first version from scratch.

Pro Tip: Run the model with both order 1 and order 2 before committing to a production pipeline, and compare the credit shares side by side to see how sensitive your channel rankings are to that choice.

Model choices and stability: order selection, sparsity, loops, and higher-order models

Choosing the Markov order is a bias-variance trade-off. A first-order model assumes the next step depends only on the current state, which is simple and data-efficient. Higher-order models capture more context but multiply the number of parameters, which demands far more data to estimate reliably. The ChannelAttribution package includes a choose_order utility that uses held-out predictive performance, often framed around penalized area-under-ROC criteria, to select an order empirically rather than by assumption.

Loops and self-transitions, such as a visitor returning to the same channel repeatedly, inflate transition counts for that state and can understate the apparent importance of neighboring channels if not handled deliberately.

  • Start with a first-order model as the baseline for any new dataset.
  • Move to a higher order only when held-out performance shows a clear improvement.
  • Watch for channels whose rank order shifts materially between orders, a sign of instability rather than insight.

Limitations and what Markov attribution does not prove (causality, offline touchpoints, sparse channels)

Markov chain attribution is observational. It describes patterns in the data we already collected, it does not establish what would have happened under a different budget allocation. Treating a high removal effect as proof of causal lift is a common and costly misreading, one better addressed by pairing attribution with a counterfactual design, as the CausalImpact literature on Bayesian structural time series frames it.

Two practical gaps compound this limitation:

  • Offline interactions, call center conversations, and ad view-throughs that are never logged in the journey data are invisible to the model, however influential they were.
  • Channels with thin volume produce unstable transition estimates, since a handful of extra paths can swing their removal effect considerably.

Reliability threshold: our analysis of probabilistic attribution reliability finds that analysts should require at least 200 conversions before trusting a probabilistic attribution output, a useful floor when deciding which channels to report with confidence.

Diagnostics, uncertainty, and validation: seeds, bootstrap, sensitivity, and convergence checks

Credible reporting means quantifying uncertainty rather than presenting a single point estimate as fact.

  1. Re-run the simulation with several random seeds and simulation counts, and report the spread in removal effects across runs.
  2. Apply bootstrap resampling of the underlying paths to build confidence intervals around each channel's removal effect.
  3. Test sensitivity to the lookback window, channel grouping scheme, and model order, and flag any channel whose rank changes across those variations.

Pro Tip: Present removal effects as a range, not a single number, whenever the bootstrap interval for a channel is wide enough to change its position in the ranking.

Concise worked example and implementation sketch (pseudo-code and expected outputs)

Say a dataset holds 10,000 journeys, of which 1,200 converted. The pipeline runs in a fixed sequence:

  • Ingest ordered paths and tag each with a conversion outcome and, optionally, order value.
  • Aggregate paths into transition counts between Start, each channel, Conversion, and Null.
  • Normalize counts into a transition matrix and simulate the baseline P(conversion).
  • Remove each channel in turn, resimulate, and compute RE_k for every channel.
  • Normalize the REs into percentage credit shares that sum to 100%.

Conversion value can be folded in by weighting each path's contribution to the simulation by its order value rather than counting every conversion equally, which shifts credit toward channels associated with higher-value transactions. For runnable code, the ChannelAttribution documentation and its accompanying GitHub proof-of-concept walk through the full calculation on sample data.

Cassandra perspective: operationalizing attribution with incrementality and production constraints

We built our measurement stack around a simple premise: attribution alone answers "what pattern did we see," not "what should we do next." Inside our platform, Markov-based attribution runs alongside marketing mix modeling and incrementality testing, combined into a single verdict per channel rather than three competing numbers. We apply the same 200-conversion reliability floor described in our probabilistic attribution analysis before surfacing a channel's attribution score with confidence, and we keep monitoring it continuously as new data arrives rather than recalculating once a quarter.

Cassandra perspective: operationalizing attribution with incrementality and production constraints — overview diagram

Author perspective: when I recommend Markov attribution and what to do next

I recommend Markov attribution as a first step when journeys are long, multi-channel, and reasonably well-tracked, never as a final budget decision on its own. A stakeholder-ready report states its uncertainty, its sensitivity to lookback and order, and a validation plan. When rankings look unstable, the next step is a focused incrementality test or marketing mix model, not a budget reshuffle.

— Gabriele Franco

How Cassandra helps: integrated measurement and production automation

Cassandra

Markov attribution tells you which channels the data associates with conversions. Proving that a channel actually drove them means pairing that model with experiments, which is why we combine attribution, always-on incrementality, and marketing mix modeling into one channel verdict instead of leaving you to reconcile three separate reports. That integration is what reduces the risk of cutting a channel that attribution undervalued but an experiment would have shown was genuinely driving volume. If your team is weighing a move from spreadsheet-based models to a managed system, our pricing page outlines the Essentials, Complete, and Scale plans alongside our Enterprise option.

FAQ

Is ChatGPT just a Markov chain?

No. ChatGPT is built on transformer neural networks that model long-range dependencies across an entire input sequence, while a classic Markov chain only looks at a fixed, short window of prior states. The two share the idea of predicting a next step from prior context, but the underlying mechanisms differ substantially.

What is 50/50 attribution?

Fifty-fifty attribution is a heuristic that splits conversion credit evenly between two touchpoints, typically the first and last interaction in a journey, rather than deriving credit from modeled transition probabilities. It is simpler to compute than Markov chain attribution but does not account for the full sequence of touchpoints in between.

Is AI built on Markov chains?

Some AI applications, like early text generators and certain recommendation systems, do rely on Markov chains, but most modern large language models use transformer architectures instead. Markov chains remain a practical tool for structured problems like attribution, where states and transitions map cleanly onto marketing channels.

Can you provide an example of an attribution model?

Markov chain attribution instead derives credit from the removal effect, measuring how much conversion probability drops when a given channel is taken out of the journey entirely.

Sources

Authoritative docs and tools to implement Markov attribution

For hands-on implementation, the ChannelAttribution package documentation covers inputs, parameters, and order-selection utilities. MetricGate's explainer walks through the removal-effect formula step by step, and the ChannelAttribution function reference alongside its GitHub proof-of-concept offers runnable code for validating your own results.