Multi-Touch Attribution — Foundations¶

What is Multi-Touch Attribution¶

Multi-Touch Attribution (MTA) is the user-journey, observational half of the Cerebro measurement stack. For each conversion (a topup, a swap, a GP payment), it builds the ordered list of prior touchpoints the same identified user produced, then divides fractional credit across those touchpoints by a chosen rule. The output looks like "out of 100 GA→GP topups in the last 180 days, chain.swap_filled events received 32 units of last-touch credit and 14 units of first-touch credit".

MTA is observational. It describes correlations along observed paths. It does not estimate causal lift. The single fact that a user signed a swap before topping up does not mean the swap caused the topup — both can be effects of an unobserved third cause (a marketing email, a Telegram post, a partner integration going live). For causal claims, MTA must be paired with MMM or a quasi-experimental design — see the Unified workflow.

When to use it¶

• "Which app actions tend to precede a Gnosis Pay topup?"
• "What's the typical path from chain.token_offer_claim to chain.swap_filled?"
• "How do first-touch and last-touch attribution compare for marketplace conversions?"
• "Where in the funnel are users dropping off?"

When NOT to use it¶

• "Did the LM rewards program cause TVL to grow?" — that's MMM.
• Conversion volume <30 in the window — descriptive funnel only, no attribution credit (see volume gates below).
• No usable user identifier on either side — downgrade to aggregate funnel diagnostics.
• A clean A/B holdout exists — use the experiment readout directly. Experiment evidence beats observational MTA.

How MTA differs from MMM¶

The two are complementary. MMM tells you the lift; MTA describes how that lift is distributed across observed user paths. The Unified workflow calibrates MTA shares against an MMM PASS so the per-touchpoint credits sum back to the MMM-estimated lift.

The touch / conversion / journey schema¶

The dbt pipeline materialises three layers per sector (gnosis_app and gpay):

The journey spine applies two leakage guards at materialisation time:

1. Temporal — event_ts < conversion_ts AND event_ts >= conversion_ts - 30 days. A touch that happens after its own conversion is excluded.
2. Self-exclusion — the conversion's own canonical event kind is filtered out via the conversion_kind_to_event_kind macro. A topup conversion can never be tracked by its own chain.topup event.

All identified users are referenced by user_pseudonym (a keyed sipHash64 of the lowercased address), never by raw address — see Privacy & Pseudonyms.

The four credit functions¶

For a conversion with n prior touchpoints \(t_1, t_2, \dots, t_n\) at lag-days \(d_1, d_2, \dots, d_n\):

By construction, each rule sums to 1.0 per conversion, so a row in fct_execution_<sector>_attribution_30d reading linear = 32.4 for event_kind = chain.swap_filled means "swap_filled events accumulated 32.4 conversions' worth of linear credit in the 180-day window".

Markov removal-effect and sampled Shapley-proxy methods are licensed at the ≥500-conversion volume tier and run in the persona, not the dbt mart.

Volume gates (hard)¶

Default lookback is 30 days. Sweep 7 / 14 / 30 / 60 when volume permits.

The GP role grain¶

Gnosis Pay introduces a wrinkle MTA on a pure-EOA flow doesn't have: the same human shows up under three different addresses depending on the GP frontend code path. The GP measurement stack fans out every conversion and every touchpoint by identity_role:

Picking the right role at query time is load-bearing — different roles answer different research questions and are not interchangeable. The GP attribution mart carries identity_role as a column so a single WHERE clause selects the grain:

-- Owner-grain attribution for GP payments
SELECT *
FROM api_execution_gpay_attribution_30d
WHERE conversion_kind = 'gpay_payment'
  AND identity_role   = 'initial_owner'
ORDER BY linear DESC;

A 2-owner Safe with one delegate produces 4 rows in the bridge (2 initial_owner + 1 delegate + 1 safe_self). A payment from that Safe yields 4 rows in int_execution_gpay_user_events_unified. This is intentional: the same payment is one event from the Safe's perspective, two events from the owners' perspectives, and one event from the delegate's perspective.

See Identity Grain in the MCP repo for the canonical framing of why the wrong grain is the most common silent failure in on-chain attribution.

Unified MMM + MTA¶

When an analytics request asks "attribute MMM-measured lift across observed user journeys" or "calibrate our MTA shares against the MMM lift estimate", the dispatcher routes through the Unified MMM + MTA workflow. The unified causal reviewer runs eight checks (MMM-gate, conversion consistency, incrementality bound, coverage, leakage, identity grain, selection bias, method stability) and applies the calibration:

The unified report must disclose the unexplained / untracked residual — the portion of MMM-estimated lift no observed touchpoint can claim. Omitting it overstates the explanatory power of the touchpoint set.

Common failure modes¶

• Hardcoded model names. The persona's "context examples" are illustrative; live runs must rediscover via search_models / discover_models and confirm columns with describe_table.
• Post-conversion leakage. Forgetting touch_ts < conversion_ts makes downstream events look causal. The dbt journey spine enforces this guard at materialisation time, so leakage in MTA reports comes from custom queries that skip the mart.
• Identity-grain mismatch. Wallet-grain attribution on a Safe-heavy flow over-credits the relayer EOA. Owner-grain on an EOA-only flow over-credits gas activity. State and justify the grain.
• Selection bias. A viewed-topup-screen touchpoint dominates any attribution model — anyone who eventually topped up almost certainly viewed the screen first. Report a counterfactual or caveat.
• Method instability. When first-touch and Markov disagree wildly, the result is directional at best. Downgrade confidence.

Cross-references¶

• Measurement Stack (MTA + MMM) — dbt-level implementation reference.
• Measurement Flow (MTA + MMM + Unified) — agent-facing dispatcher routing and persona reference.
• Privacy & Pseudonyms — why every MTA model keys on user_pseudonym.
• Marketing Mix Modeling — the aggregate / causal half of the stack.