First-Touch vs Last-Touch Attribution for Product Analytics

Current as of August 21, 2026.This article reflects the public Poolstatis contracts available on its publication date.

First-touch attribution assigns an outcome to the earliest known acquisition source for a person. Last-touch attribution assigns it to the most recent eligible source before the outcome. Session landing attribution associates activity with the source recorded at the start of the current session.

These models answer different questions, and none proves that a campaign caused a conversion. Product teams should select the attribution scope before collecting data, preserve enough evidence to reproduce the association, and use a controlled experiment when the decision requires causal impact.

As of August 21, 2026, Poolstatis implements bounded session landing attribution. It does not implement persistent first-touch, last-touch, multi-touch weighting, ad spend reconciliation, or campaign incrementality.

Scope note, August 21, 2026: Google Analytics currently describes data-driven attribution and two last-click models in its Attribution reports. Its first-click, linear, time-decay, and position-based models were removed in November 2023. This article explains first-touch as a general measurement model, not as a currently available Google Analytics report option. Google Analytics attribution documentation

What is the difference between first-touch, last-touch, and session attribution?

First-touch, last-touch, and session attribution assign different scopes to the same acquisition evidence. The correct choice depends on whether the team wants to understand initial discovery, the interaction nearest an outcome, or the source associated with one visit.

Model	Attribution scope	Credit rule	Question it answers
First-touch	Person or account across sessions	Earliest eligible source receives credit	How did this person first discover the product?
Last-touch	Conversion path	Latest eligible source before the outcome receives credit	Which source immediately preceded the outcome?
Session landing	One browser or app session	Landing source is associated with events in that session	Which landing context brought this session?
Multi-touch	Ordered path of eligible interactions	Several touches receive rule-based or modeled weight	Which touches participated in the path?
Incrementality experiment	Treatment and control populations	Difference between experimental groups	How many outcomes occurred because of the campaign?

First-touch requires durable identity across the period being analyzed. If one person appears as three unrelated anonymous visitors, there is no defensible “first” touch for that person.

Last-touch requires an explicit eligibility rule. A product must decide how to handle direct visits, expired attribution windows, internal referrals, cross-domain checkout, and repeated campaign links.

Session landing attribution is narrower. It does not claim to reconstruct the person’s entire journey. It says that a particular session began with a recorded source, medium, campaign, landing route, or referrer origin.

Which attribution model should a product team use?

Use first-touch attribution when the decision concerns initial discovery. Use last-touch attribution when the decision concerns the interaction nearest conversion. Use session attribution when acquisition and the measured product behavior occur within a bounded visit.

A practical selection rule is:

Choose first-touch for questions such as “Which source introduces qualified users to the product?”
Choose last-touch for questions such as “Which eligible channel most often appears immediately before checkout?”
Choose session landing attribution for questions such as “Which landing campaigns produce sessions that reach setup?”
Preserve the ordered touchpoint history when the buying cycle spans many sessions and the organization genuinely needs multi-touch analysis.
Use an incrementality experiment when the question contains “caused,” “generated,” or “would not have happened otherwise.”

The model should match the identity available. A company cannot responsibly calculate person-level first-touch from a tab-scoped session identifier. A cross-device journey requires an audited identity link or an explicit statement that the report counts browser visitors rather than people.

The model should also match the outcome. A session landing source can be useful for same-session signup or activation. It becomes weaker for an enterprise purchase that occurs months later after sales calls, referrals, and several devices.

Does attribution prove that a campaign caused a conversion?

Attribution does not prove causation. Attribution applies a rule or algorithm that assigns credit among observed touchpoints. Causal measurement estimates what would have happened without the campaign.

Google Analytics defines attribution as assigning credit to ads, clicks, and other factors along a path. Its last-click model assigns 100% of an event’s value to the latest eligible channel under the model’s rules. Google Analytics attribution documentation

A high conversion rate for sessions tagged utm_source=partner can have several explanations:

The partner reached users with stronger existing intent.
The campaign targeted an audience already likely to convert.
The landing experience worked better.
Returning customers reused a tagged link.
Identity or campaign coverage differs between sources.
The campaign caused incremental conversions.

An attribution table cannot distinguish those explanations by itself.

Google Ads documents this difference directly: standard attributed conversions follow configured tracking and attribution rules, while Conversion Lift compares a treatment group with a control group to estimate incremental conversions. Google Ads Conversion Lift

Product reports should therefore say “associated with,” “observed among,” or “recorded for.” Reserve “caused,” “drove,” and “generated” for evidence from an appropriate experiment or another identified causal design.

What acquisition data should be captured on the landing session?

A bounded acquisition snapshot should contain a stable session identifier, a safe landing-route key, a limited source vocabulary, and the timestamp of the landing event. It should not copy the complete browser URL into analytics.

A practical snapshot can contain:

Field	Example	Boundary
Session ID	`session:opaque-id`	Random identifier, not an email or account ID
Landing route	`docs_quickstart`	Finite product-owned key, not a raw pathname
Source	`partner_newsletter`	Bounded campaign label
Medium	`email`	Controlled channel label
Campaign	`sdk_launch`	Reviewed campaign identifier
Term	`agent_analytics`	Optional bounded value
Content	`footer_cta`	Optional creative or placement label
Referrer origin	`https://partner.example`	Origin only, without path or query
Event time	RFC 3339 timestamp	Explicit timezone or UTC offset

Google Analytics documents utm_source, utm_medium, utm_campaign, utm_term, and utm_content as manual traffic-source inputs. The same parameters may feed user-scoped and session-scoped dimensions, depending on the reporting contract. Google Analytics traffic-source dimensions

Campaign values should come from a naming convention. email, Email, newsletter, and e-mail will otherwise become separate values even when they represent the same channel.

Raw URLs are a poor analytics property. Paths and query strings can contain invite tokens, search text, email addresses, internal object IDs, or uncontrolled cardinality. Store a product-owned route key when the decision only needs the landing surface.

The W3C Referrer Policy specification distinguishes origin-only referrer information from full URLs and documents stricter policies that reduce cross-origin disclosure. That makes origin-only referrer capture a useful boundary when the full referring page is unnecessary. W3C Referrer Policy

Session attribution should preserve one immutable landing snapshot throughout the session. An internal route change should not replace the campaign that opened the session.

Suppose a user lands on pricing with utm_source=partner, moves to signup, and authenticates. The session landing snapshot remains partner. The page route changes, but the acquisition context does not.

Login creates a separate identity problem. The analytics system should retain the original anonymous event identity and create an audited link to the authenticated identity. Rewriting old events hides what the client originally sent and complicates debugging.

Person-level first-touch requires another layer. After identity resolution, the system needs a stated rule for selecting the earliest eligible touch across linked sessions. It also needs a policy for identity merges, deleted identities, late events, and imported historical activity.

Poolstatis currently keeps the acquisition snapshot at session scope. Poolstatis does not persist a first-touch acquisition record across sessions or compute a person-level first-touch model.

What should happen when a new session has no campaign tag?

An untagged session should remain explicitly unattributed unless the selected model defines another rule. It should not silently inherit campaign fields from an unrelated previous session.

This protects the meaning of session landing attribution. A user who arrives through a tagged email on Monday and opens the site directly on Friday has two different session facts:

Monday started from the email campaign.
Friday contained no tagged campaign landing.

A separate last-non-direct model may choose to assign Friday’s outcome to an earlier eligible channel. That is a model decision, not a property of Friday’s landing session.

Current Google Analytics last-click documentation, for example, ignores direct traffic when another eligible channel exists in the path and assigns direct credit when the path contains only direct traffic. Google Analytics attribution documentation

Reports should name this rule. “Session source” and “last non-direct source” are not interchangeable labels.

How should cross-domain journeys be handled?

Cross-domain attribution requires explicit identity continuity. Without it, a move from the product site to a separately hosted checkout can create a new user or session and replace the original acquisition context with an internal referral.

Google’s current cross-domain measurement guide describes passing first-party measurement identifiers between configured domains so activity can be treated as one journey. It also warns that without cross-domain measurement, an online store and a separate checkout can be counted as different users and sessions. Google cross-domain measurement

A product team should document:

Which domains belong to the same product journey.
Which identifiers can cross those domains.
How link decoration is protected from misuse.
Whether session boundaries survive the transition.
How consent and deletion apply across the domains.
Which internal referrers must be excluded.

Poolstatis source reviewed for this article does not establish a general cross-domain linker contract. Do not infer cross-domain identity continuity from the presence of UTM fields or a session identifier.

How should acquisition connect to activation or revenue?

Acquisition evidence becomes useful when it is connected to a registered outcome with compatible identity and time scope. Counting campaign-tagged page views alone does not measure activation or revenue.

A decision-ready acquisition analysis should define:

The attribution model and scope.
The eligible acquisition population.
The trusted campaign properties.
The outcome metric and its purpose.
The identity grain.
The conversion window.
Exclusions such as internal traffic or test accounts.
Coverage and unavailable dimensions.

For example, “partner campaign activation” is incomplete. A defensible contract might ask:

Among browser sessions with a trusted session landing source, what share of resolved actors completed the registered setup outcome within seven days?

That question still describes association. It specifies a source scope, outcome, actor resolution, and time window without claiming the campaign caused the result.

A funnel should use the same identity grain from entry to outcome. Combining session entries with account-level conversions without a documented link can inflate or suppress conversion.

See the Poolstatis measurement model, identity model, and goal-driven funnel contract for the related semantic boundaries.

What does Poolstatis implement today?

Poolstatis Core currently implements a bounded, immutable session landing snapshot for browser acquisition. The reviewed source is Core commit c223efc0677995db278f233d6b69c9d43c708470.

The current source contract includes:

@poolstatis/sdk/attribution as a separate browser entrypoint.
One session.started and one initial page.viewed when the attribution client starts.
One immutable snapshot reused for later events sent through that client.
Five allowlisted UTM properties: source, medium, campaign, term, and content.
The first valid occurrence of each allowed UTM parameter.
Unicode NFC normalization, trimming, and a maximum value length of 256 characters.
A finite landing_route key rather than a raw path.
Referrer origin rather than the complete referrer URL.
A required session_id whenever acquisition properties are submitted.
Rejection of the removed landing_path field.
Fresh unattributed state for a new untagged session.
Canonical acquisition property definitions that begin as proposed.
A stricter trusted-property requirement for customer-facing web-analytics breakdowns.
Explicit semantic copy stating that the fields support bounded acquisition analysis, never causal campaign credit.

The implementation is visible in the SDK attribution source, Core acquisition validation, and Browser Analytics documentation.

When Browser Analytics uses captureAcquisition: true, acquisition shares its session and page.viewed event. The documentation warns against starting the separate attribution client alongside that composed mode because both would create their own page-view evidence.

These are source-available implementation facts. This review did not verify a live Poolstatis Cloud attribution flow at that commit.

What attribution features does Poolstatis not claim?

Poolstatis does not currently claim:

Persistent first-touch attribution across sessions.
Last-touch or last-non-direct calculation.
Multi-touch paths or weighted credit.
Data-driven attribution.
Ad-platform click-ID ingestion.
Advertising cost or return-on-ad-spend reconciliation.
View-through attribution.
Cross-domain linker behavior.
Campaign incrementality.
A causal claim based on UTM association.

These limits matter because the word “attribution” often implies more than a session snapshot. Poolstatis should describe its current result as session landing attribution or a source breakdown, not as a complete marketing-attribution platform.

What should an acquisition report contain?

A useful acquisition report should make its model, population, coverage, and limitation visible next to the result.

Question: Which session landing sources are associated with verified setup?
Attribution model: Session landing attribution
Acquisition dimensions: $utm_source and $utm_campaign
Outcome: [registered metric key and purpose]
Identity grain: [browser visitor, user, or account]
Window: [explicit event-time range]
Conversion window: [explicit duration]
Coverage: [tagged, untagged, unavailable, and unresolved populations]
Result: [counts and rates by source]
Limit: Observational association, not campaign incrementality
Next action: [instrumentation fix, segment review, or experiment]

Do not replace missing acquisition data with zero. If the canonical properties are untrusted or unavailable, the report should return an unavailable state and explain the setup step required. A false zero makes missing evidence look like measured absence.

What should teams check before trusting acquisition attribution?

Attribution is a credit rule. Session landing attribution is a bounded association. Incrementality is a causal question. Keeping those statements separate makes acquisition data useful without asking it to prove more than it observed.

Continue reading