Multi-Touch Attribution: Compare Models and Choose One

Choose a multi-touch attribution model only after defining the conversion and milestone you want to understand. A paid search click, article view, webinar registration, and sales meeting may all appear before a deal closes, but a report about new contacts answers a different question from one about created deals or won revenue.

Multi-touch attribution distributes reported credit across interactions in an observed conversion path. It can reveal assisted-touch patterns, but allocated credit is not proof that an interaction caused a conversion. The practical rule is simple: define the milestone, verify event coverage, then choose the simplest model that answers the business question.

This guide compares common models, separates funnel milestones, shows a documented HubSpot reporting workflow, and presents a hypothetical warehouse design. The HubSpot section describes documented product behavior. The warehouse section is an implementation pattern, not a ready-made vendor integration.

How to choose a multi-touch attribution model

Start by writing down the decision the report should support. “What introduced new contacts?” points to a different view than “What happened before a deal was created?” or “Which interactions receive credit for closed-won revenue?” Select a model whose weighting assumptions fit that question and whose required milestones your systems record.

What multi-touch attribution counts, and what it does not

A touchpoint is a tracked interaction included by a particular platform and report. Depending on configuration, examples may include an ad click, page view, form submission, email click, webinar registration, meeting, or other recorded activity. A touchpoint is not automatically a unique person, session, asset, or channel exposure.

Platforms may count repeated interactions separately. HubSpot documents that repeated email clicks can appear as separate interactions. Keep these measures distinct: event count is the number of recorded events; session count groups activity into visits; unique asset exposure counts distinct content or campaign items; and channel exposure groups events by channel.

Before comparing models, specify the conversion record and timestamp, included event types, identity key, lookback window, and deduplication rule. If any of these are undefined, pause model selection and resolve the data definition first.

Milestone	Question it answers	Reporting implication
First interaction	What introduced the contact?	Use a path definition that identifies the earliest included event.
Contact creation or lead conversion	What surrounded the transition to a known prospect?	Confirm the platform records the contact or lead milestone.
Deal creation	What preceded sales pipeline creation?	Use deal-based attribution and a deal timestamp.
Closed-won or revenue recognition	What is associated with realized revenue?	Define whether the report uses close date, recognition date, refunds, or another revenue rule.

“Last touch” means the final included interaction before the selected conversion milestone. It does not necessarily mean the final interaction before recognized revenue.

Consider a hypothetical path: a prospect clicks a paid search ad, reads an article, registers for a webinar, meets with sales, and then becomes part of a closed-won deal. A report can show which observed events received credit under its selected model. It cannot show what would have happened if one event had not occurred. When the decision depends on incremental impact, use a holdout, experiment, or other controlled comparison where feasible.

Compare attribution models by the question they answer

Each model applies a different credit rule. The recommendations below are decision heuristics, not claims that one model performs better for a particular business.

Model	Credit rule	Useful when
First Touch	All credit goes to the earliest included interaction.	You want to inspect what first introduced a contact, as defined by the report.
Last Touch	All credit goes to the final included interaction before the selected conversion.	You want to inspect what immediately preceded that milestone.
Linear	Credit is divided equally across included interactions.	You need a simple descriptive baseline across the observed path.
Time Decay	Interactions nearer the conversion generally receive more credit.	Recency is a deliberate assumption and the platform’s decay rule is understood.
U-shaped	Commonly emphasizes an early interaction and a lead-related milestone.	The platform’s anchor events match the funnel question.
W-shaped	Can emphasize first interaction, contact creation, and deal creation.	Those milestones are recorded and relevant to the analysis.
Empirical	Platform-specific weighting based on observed historical interaction data.	You can explain the method and have enough relevant history to interpret it.

Linear is a useful baseline when you want every included interaction represented equally. Equal allocation is a rule, not evidence that each interaction contributed equally. HubSpot documents a seven-day half-life for its current Time Decay implementation, but that value should not be generalized to other tools.

Model names are not universal specifications. HubSpot documents its current U-shaped model as assigning 40% to the first interaction, 40% to the lead-conversion interaction, and 20% across other interactions. Its documented W-shaped model assigns 30% each to first interaction, contact creation, and deal creation, with 10% across other interactions. The W model requires a deal-based interaction and is available in deal-creation and revenue attribution reports.

HubSpot’s current documentation also states that its Empirical model replaces U-shaped, W-shaped, J-shaped, and Inverse J-shaped models in the current interface. The Empirical model uses historical interaction data to weight interaction types, which is a HubSpot-specific definition rather than a universal meaning of empirical attribution.

For each candidate model, ask three questions: Does its weighting assumption fit the question? Are its anchor milestones captured? Can the report owner explain the rule to a budget owner? If not, use a simpler descriptive view or improve event coverage first.

Select the report around the conversion milestone

Contact creation, deal creation, and won revenue attribution answer different questions and can produce different channel rankings. In HubSpot, select the report type before choosing a model:

• Contact Create Attribution: examines interactions associated with creating contacts.
• Deal Create Attribution: examines interactions associated with creating deals.
• Deal Revenue Attribution: examines interactions associated with won revenue.

HubSpot documents that Deal Create Attribution and Deal Revenue Attribution require Marketing Hub Enterprise. Confirm current account access before planning the report. The report builder supports dimensions including assets, deals, interactions, UTM parameters, ad keywords, CTAs, and social posts. A report dimension is not a promise that the same data is available through every API or export.

Attribution reports may include up to 20 million interactions after sampling, and HubSpot separately documents limits on event input types and activities associated with a deal. These are reporting limits, not guarantees that every raw interaction is retained or available downstream. If the question is an exact activity count, use a report designed for activity counts rather than substituting attribution totals.

A practical workflow: define, inspect, compare, record

Use this sequence for a product report or a separate data pipeline. The report owner defines the question, marketing or data operations checks event and identity coverage, and the CRM owner approves changes to CRM fields.

For matching and eligibility, deterministic rules should lead. Use stable CRM or transaction IDs, timestamp rules, and versioned UTM mappings. If campaign text is ambiguous, AI may suggest a normalized channel, but it should return only an allowed value, confidence, and review status. A person approves changes to the mapping table, and AI should not determine whether a deal is valid or assign attribution credit.

Illustrative warehouse design

If a team builds its own pipeline, keep the grains separate:

• Raw event: one row per observed interaction.
• Conversion: one row per conversion or deal.
• Attribution allocation: one row per conversion, event, model, and model version.
• Aggregate summary: one row per declared period, channel, model, model version, and currency.

Do not store a period-wide channel share as though it were an individual touchpoint. Preserve source values alongside normalized values, plus source system, source record ID, ingestion batch or calculation run ID, model version, and calculation timestamp.

The following JSON is illustrative. It represents one event’s allocation for one conversion under one model version. A linear result of 0.5 would indicate that this row is one of two included events, not that the raw event itself has a 50% causal effect.

{
  "conversion_id": "deal_7842",
  "event_id": "evt_1001",
  "model_name": "linear",
  "model_version": "1",
  "credit": 0.5,
  "currency": "USD",
  "calculation_run_id": "run_2026_04_11_01"
}

Use a database-enforced unique key such as conversion_id + event_id + model_name + model_version. Include model_name because the same conversion and event may be allocated by multiple models. Use a transactional upsert or insert-on-conflict operation where supported. A lookup followed by create is not safe when concurrent workers process the same conversion.

Validate that credits sum to 1.0 within a declared rounding tolerance. Quarantine missing conversion IDs, invalid timestamps, duplicate event IDs, negative credits, unsupported currencies, and events outside the lookback window. Route unmatched identities, merged contacts, duplicate conversions, refunds, and conflicting revenue values to a named exception owner.

Documented example: build an attribution report in HubSpot

HubSpot documents a report-building sequence: choose a data source or report template, select an attribution model and dimensions, apply filters, then save or export the report. The public instructions describe the built-in reporting workflow, not a general-purpose raw-event export or a guarantee that every report dimension is exposed through an API.

1. Choose Contact Create, Deal Create, or Deal Revenue Attribution according to the conversion question.
2. Confirm account access, including the documented Marketing Hub Enterprise requirement for deal-creation and revenue reports.
3. Select the model, dimensions, filters, and reporting period. Confirm relevant tracking and connected ad accounts where applicable.
4. Inspect paths and unexpected results. If using W-shaped attribution, confirm a qualifying deal-based interaction exists and that deal and contact dates do not create an empty result.
5. Save or export the report with its type, model, dimensions, filters, period, sampling observation, and review date recorded.

Use HubSpot’s instructions for creating attribution reports alongside its reference for report types, interactions, models, and limitations. For account configuration and operational ownership, HubSpot systems support can help teams review their reporting setup.

Make model changes reviewable

Treat a change to a model, mapping, conversion definition, or lookback window as a new versioned calculation, not an edit to historical truth. Recalculate into a new version, compare results, and keep the previous output available for audit before replacing a decision-making report.

Keep raw events, allocations, and aggregates in separate tables or equivalent records. Preserve the previous and new values before any approved CRM write-back, and record the accountable CRM owner, calculation run, and write timestamp. A CRM field intended for one value should not receive a period-level channel share without an explicit aggregation rule.

These controls matter when CRM fields are shared by sales and marketing. Preserve source and normalized values, record the prior value before an approved write, and make field ownership explicit. See CRM systems support for help with field ownership and controlled CRM changes.

Use attribution for allocation questions, experiments for causal ones

Attribution describes how a selected model distributes credit across observed interactions. Incrementality testing asks whether an activity produced additional outcomes compared with a suitable alternative. If a budget decision depends on whether a channel caused more conversions, use journey reporting to identify patterns and hypotheses, then evaluate the causal claim with a holdout, experiment, or other controlled design where feasible.

The selection path is straightforward: define the milestone, verify the data, choose the simplest fitting model, document the report settings and version, and test causal claims separately.