Multi-Touch Attribution Explained for Ecommerce

What multi-touch attribution actually is

Last-click attribution — the default in most native ad platform reporting, including Amazon's sponsored ads dashboards — gives 100% of the credit for a sale to whichever ad or channel the customer interacted with immediately before converting. Multi-touch attribution rejects that as too simple: it recognises that a customer might see a streaming video ad on day one, click a sponsored product ad on day four, then buy after a branded search on day seven, and it tries to divide credit for the sale across all three touches rather than handing everything to the search click.

The word "tries" matters. MTA isn't a single method — it's a family of credit-splitting rules, from simple (equal credit to every touch) to complex (a statistical model weighting each touch by its historical correlation with conversion). Which rule you pick changes the answer meaningfully, which is why the next several pages on this site cover the individual models on their own.

A worked example that shows why it matters

Take a $90 sale with three attributed touches: a DSP display impression, a sponsored brands click, and a branded search click, in that order. Under last-click attribution, the branded search click gets 100% of the $90 — meaning the branded search campaign looks like it's driving $90 of ROAS on a click that, arguably, only happened because the shopper already knew the brand from the first two touches. Under equal-weight multi-touch attribution, each touch gets $30. Under a first-touch model, the DSP impression gets full credit and the two clicks get none.

None of the three answers is "correct" in an absolute sense — they're three different questions. Last-click tells you what closed the sale. First-touch tells you what started the journey. Equal-weight multi-touch tells you a rough middle ground. The practical use of MTA isn't picking the one true number; it's using more than one lens on the same data so you don't make a budget decision based on a single, structurally biased view.

Why Amazon's native reporting doesn't do this for you

Sponsored Products, Sponsored Brands and Sponsored Display each report their own attributed sales independently, using their own click and view windows — Sponsored Products uses a 7-day click window for sellers (14 for vendors), Sponsored Brands and Sponsored Display use 14 days. None of these platforms natively stitches a shopper's exposure across the others into one multi-touch path; each one reports as if it were the only channel that mattered, and if the same shopper touched two of them before buying, both reports can independently claim partial credit for the same sale without either platform knowing about the other.

Amazon Marketing Cloud exists specifically to close that gap. Inside the clean room, you can query a shopper's pseudonymized exposure across DSP, sponsored ads and other Amazon Ads signals together and build a genuine cross-channel path, which is the only way to run a real multi-touch model on Amazon rather than stitching together three single-channel reports by hand.

The common mistake, including ours

The mistake is adding up the attributed ROAS from separate channel reports and treating the sum as the account's true performance. If DSP reports 6.04x and sponsored ads separately reports its own healthy ROAS on overlapping shoppers, the combined number the two dashboards imply is fiction — some of those sales are being counted by both platforms independently, each unaware of the other's claim. We've built a client summary this way before, under time pressure, by literally summing two channel totals — and had to correct it once an AMC reconciliation query showed real overlap between the two audiences. The fix wasn't a smarter spreadsheet; it was running the reconciliation before writing the summary, not after a client asked why the combined ROAS didn't tie out.

When multi-touch data gives you a confusing answer

Sometimes an MTA model returns something that looks wrong — a channel you'd normally call top-of-funnel getting credited with more weight than the channel that actually closed the sale, or two models disagreeing sharply on the same data. Before assuming the model is broken, check three things: whether the attribution windows across channels actually overlap (a 7-day and a 14-day window measuring the same path will produce different-looking paths depending on where you cut the data), whether the model you're using is even appropriate for your funnel length, and whether you're comparing attributed credit — which model choice changes — against something like ROAS, which model choice also changes, without realising both numbers moved for the same reason.

If two models genuinely disagree even after checking those three things, that disagreement is itself useful information: it tells you the channel mix is sensitive to methodology, which means neither number should be treated as gospel in a budget decision, and an incrementality test — a holdout or geo split — is a better next step than picking whichever model gives the answer you wanted.

What a multi-touch view changes about how you spend

The practical payoff of MTA isn't a prettier dashboard — it's catching budget decisions that last-click reporting would get backwards. A DSP display line that never shows a strong last-click ROAS can still be the touch that starts the majority of paths that eventually convert through search; cut it on last-click reporting alone and branded search volume — and its efficiency — often falls in the following weeks, for reasons the search report itself will never explain, because it only ever sees the final touch. A multi-touch view, even an approximate equal-weight one, is what surfaces that dependency before the budget gets cut rather than after conversion rates have already slipped.

Choosing a model for an Amazon-led business

Most ecommerce brands don't need a full statistical data-driven model to start. Equal-weight or position-based multi-touch, applied consistently inside an AMC query, is usually enough to correct the worst distortions of pure last-click reporting without building bespoke modelling infrastructure. The point isn't finding the perfect model — it's moving off a system that structurally credits only the last touch, toward one that at least acknowledges the touches that came before it, and combining that with periodic incrementality testing to check whether the attributed credit reflects real causation.