Attribution
What Amplitude actually knows about where your users came from
Half of 'Amplitude attribution' questions dissolve once you know what the SDK already captures by default - and the other half come from expecting an ads-attribution platform, which Amplitude is not pretending to be.
What does the Browser SDK capture automatically?
As of Browser SDK 2 v2.45.0, marketing attribution tracking is on by default in both persistence modes (user-property and event-property). Out of the box it captures:
- All six UTM parameters: utm_source, utm_medium, utm_campaign, utm_term, utm_content, utm_id.
- A long roster of ad click IDs - gclid, fbclid, dclid, gbraid, wbraid, msclkid, ttclid, twclid, rdt_cid, li_fat_id, ko_click_id.
- referrer and referring_domain.
Full list and defaults: Browser SDK 2 docs (Sources). If your acquisition reports look empty, the usual culprit is a proxy or consent layer stripping query params before the SDK sees them - an implementation issue, not a product gap (field observation).
How do first-touch and last-touch actually work here?
Two parallel sets of user properties, per the docs. The initial_-prefixed set (initial_utm_source, initial_referrer, ...) is written once via $setOnce - the attribution data at the start of the user's first session - and never overwritten. The non-prefixed set is captured at the start of each session, which the docs describe as usable for last-touch and multi-touch analysis.
One switch worth knowing: resetSessionOnNewCampaign (default false) starts a new session whenever any campaign parameter changes mid-visit - flip it if your definition of 'a visit from campaign X' must break on campaign change.
What about modeled multi-touch attribution?
Amplitude ships it - in Data Tables. Nine pre-built attribution models apply to a property's touch points within a configurable lookback window:
| Model | How credit is distributed (per Amplitude's docs) |
|---|---|
| First / Last / Last Non-Direct Touch | All credit to one touch point - and the only three models whose event totals sum to 100% of the overall count |
| Linear | Equal credit across every touch point in the window |
| Participation | Full 100% credit to every touch point - totals deliberately exceed the overall |
| U-Shaped / J-Shaped / Inverse J-Shaped | Credit biased to first+last, most recent, or earliest touch points respectively |
| Data Driven | A probabilistic model on first-order Markov chains - each channel's credit proportional to the effect of removing it; docs recommend properties with ≤50 unique values |
Doc-stated gotcha worth repeating: attribution applies to events, not unique users - one user can appear in multiple attribution groups, so summing user rows can double-count. Source in the list below.
Where does the Attribution API fit?
It's for mobile install attribution: the documented endpoint lets mobile measurement partners and ad platforms send attribution campaign events identified by idfa, idfv, or adid - with a hard operational rule that events unmatched to a user within 72 hours are dropped. If you run an MMP (AppsFlyer, Adjust, and peers), this is the pipe their data rides into Amplitude; it is not a general web-attribution service.
The honest scoping call
Amplitude's attribution answers 'which channels start users who then activate, retain, and pay' - acquisition quality read through behavior, which is a question ad platforms can't answer honestly about themselves. What it does not replace: an ads-side attribution/MMP stack for spend optimization, or GA4's ads-ecosystem integration. Scope it as the behavioral half of attribution and it over-delivers; scope it as your only attribution system and you'll blame the tool for a design decision. (Scoping judgment ours; capture mechanics documented above.)
Sources
- Amplitude docs: Browser SDK 2 (default attribution capture, initial_ properties, resetSessionOnNewCampaign)
- Amplitude docs: Attribute credit to multiple touch points (Data Tables attribution models)
- Amplitude docs: Attribution API (mobile, 72h matching window)
- Amplitude docs: Autocapture (UTM/referrer capture)
Product capabilities change - every claim above links to the primary source it came from. Judgment calls and field observations are ours and labeled in-line.
Frequently asked questions
Does Amplitude track UTM parameters automatically?+
Yes - Browser SDK 2 captures all six UTM parameters, a dozen ad click IDs, and referrer/referring domain by default (attribution tracking is on by default as of v2.45.0). If UTMs aren't arriving, the SDK usually never saw them: redirects, consent gates, or proxies stripping query strings are the standard culprits.
How do I get first-touch attribution in Amplitude?+
You already have it: the initial_-prefixed user properties (initial_utm_source, initial_referrer, and peers) are set once via $setOnce at the user's first session and never overwritten, while the non-prefixed versions update each session for last-touch views. Segment any chart by initial_utm_source and you're doing first-touch analysis.
Is Amplitude a multi-touch attribution tool?+
For the touch points it captures, yes: Data Tables include nine pre-built attribution models - first, last, and last non-direct touch, linear, participation, U-shaped, J-shaped, inverse J-shaped, and a Markov-chain data-driven model - each with a configurable lookback window. What it is not is an ads-side MMP: the models distribute credit over your captured properties and behavioral outcomes, not over ad-platform spend data.
Get a free, scored audit of your Amplitude instance
Send us read-only access and get a scored findings report within 48 hours: taxonomy health, duplicate events, governance gaps, and the three fixes with the highest data-trust payoff. No commitment.
Request the free audit