Multi-touch attribution

Definition

Multi-touch attribution distributes the credit for a conversion across several of the marketing touchpoints that preceded it, rather than assigning all of it to a single first or last interaction.

Single-touch attribution is a rule that says one touchpoint caused everything and the rest caused nothing. Multi-touch replaces that with a different rule — a weighting — which is more honest about reality and no more provably correct. The value is not that MTA finds the truth; it is that it stops one channel from absorbing credit for work several channels did.

The five models, applied to the same journey

Suppose a user sees a display ad, clicks a search ad two days later, taps an influencer link on day five, and installs after an email on day six. Four touchpoints, one install, $1 of credit to distribute. Every model below is answering the same question with a different assumption baked in.

Notice that display goes from 0% to 100% of the credit without a single data point changing. That is the point to internalise before choosing a model: you are picking a story about how demand is created, and the numbers follow. Anyone comparing channel ROAS across two teams using different models is comparing nothing.

Why MTA is structurally harder on mobile than on web

MTA needs a stable identity across every touchpoint. On the web, a first-party cookie or a logged-in ID usually provides one. On mobile, the journey crosses a browser, an app store and an app binary, and no identifier survives all three by default.

The practical consequence is that mobile MTA is honest only for the touchpoints you tagged yourself. Everything a self-attributing network reports arrives already attributed, as a claim rather than a touch, and cannot be re-weighted by your model. That is not a bug in your pipeline — it is the deal those networks offer.

On iOS the gap is wider still. SKAdNetwork reports an aggregate winner per campaign, with no journey attached, so there is nothing to distribute. MTA and SKAN are not two views of one dataset; they cannot be combined into one number, and any tool claiming otherwise is modelling, not measuring.

Building it yourself

If every touch is logged to your own tables with a shared identity, the models above are one query each. The version below implements time decay, which is the model most teams settle on because it degrades gracefully when a journey has one touch or twenty.

-- Weight each touch by how recent it was, then normalise
-- so every conversion distributes exactly 1.0 of credit.
WITH touches_in_window AS (
  SELECT
    c.conversion_id,
    c.converted_at,
    t.channel,
    t.touched_at,
    POWER(
      0.5,
      DATE_DIFF(DATE(c.converted_at), DATE(t.touched_at), DAY) / 7.0
    ) AS raw_weight
  FROM conversions c
  JOIN touches t
    ON t.user_id = c.user_id
   AND t.touched_at <= c.converted_at
   AND t.touched_at > c.converted_at - INTERVAL 30 DAY
),
normalised AS (
  SELECT
    conversion_id,
    channel,
    raw_weight / SUM(raw_weight) OVER (PARTITION BY conversion_id) AS credit
  FROM touches_in_window
)
SELECT
  channel,
  ROUND(SUM(credit), 1)         AS attributed_conversions,
  COUNT(DISTINCT conversion_id) AS journeys_touched
FROM normalised
GROUP BY channel
ORDER BY attributed_conversions DESC;

The journeys_touched column matters as much as the credit column. A channel that appears in 40% of journeys but earns 8% of credit is doing real work that a last-touch report would show as zero — and a channel that earns credit only in journeys it also closed is a channel your model cannot yet distinguish from a coincidence.

When to use MTA and when not to

• Use it when you own most touchpoints, have a stable user ID, and want to stop last-touch starving upper-funnel channels.
• Use it for directional budget shifts between channels you tag yourself.
• Do not use it as the arbiter between two self-attributing networks; neither will accept your weighting.
• Do not use it on iOS install data, where SKAN gives you no journey to weight.
• Do not use it instead of incrementality testing. MTA distributes observed credit; only a holdout tells you what would have happened anyway.

The mature position is to run MTA and incrementality together and expect them to disagree. MTA tells you how credit should be shared among the touches that happened; a geo holdout tells you which touches needed to happen at all. When a channel scores well on the first and badly on the second, the second is the one to believe.