Landfall

An open standard for attributing web traffic and bookings to AI assistant channels.

Status of this document

This document is published for implementation. The specification text is licensed CC BY 4.0. Implementations MUST identify the version in any conformance claim (e.g., “Landfall v0.3”); pre-1.0 versions may still change in breaking ways between releases. The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, and MAY are to be interpreted as described in RFC 2119 as clarified by RFC 8174.

Abstract

AI assistants (ChatGPT, Claude, Perplexity, Gemini, and their successors) increasingly deliver human visitors to commercial websites through mechanisms that defeat conventional attribution: agent fetches precede human visits, in-app browsers strip referrers, and no click identifier survives the journey. Landfall defines a three-tier methodology for attributing visits and conversions to AI channels: (1) deterministic attribution where the implementer controls the served URL, (2) calibrated probabilistic attribution at the session level where it does not, and (3) aggregate incrementality measurement that bounds and audits the probabilistic tier. Landfall further defines mandatory reconciliation and calibration procedures that keep reported numbers honest as channel volume grows, and reporting requirements that distinguish observed, modeled, and illustrative claims.

1. Introduction

1.1 The measurement problem

When an AI assistant answers a user’s query about a product, place, or service, a characteristic event chain occurs: the assistant’s agent fetches one or more pages (directly, via a search index, or via a structured endpoint such as an MCP server); the assistant renders an answer; and some fraction of users subsequently land on the fetched page. The landing frequently arrives with no referrer, no click identifier, and no session continuity with the fetch — it is indistinguishable, at the individual level, from direct traffic.

The scale of the blindness is measurable: published analyses in 2026 find that between 35% and 70% of AI-assistant referrals arrive with the referrer stripped by HTTP-level mechanisms (referrer policies, noreferrer link attributes, in-app WebViews, and copy-paste navigation) and file in conventional analytics as Direct. Native analytics channels for AI assistants, where they exist, cover a subset of assistants and only the referrer-bearing minority of their traffic.

Early practitioners attribute referrer-less landings by temporal correlation: a landing on page P shortly after an agent fetch of P, on a page whose organic arrival rate is low, is probably assistant-delivered. This works — until it doesn’t.

1.2 The saturation problem

Temporal-correlation attribution degrades as the channel succeeds. When agent fetches of a page occur daily or hourly, every landing is temporally proximate to a fetch, and fetch recency carries no per-session information. The posterior probability of assistant delivery collapses toward the channel’s base rate, and per-session attribution becomes statistically uninformative precisely when the channel matters most. Landfall exists to provide a methodology that remains valid — and auditable — at any fetch volume.

1.3 Design principles

1. Deterministic where possible, modeled where necessary. Modeled attribution is a fallback, never a substitute, for observable event chains.
2. Modeled claims must be bounded by aggregate evidence. No sum of per-session attributions may exceed what an aggregate lift model supports.
3. Models must be calibrated against ground truth. An implementer with any deterministic surface MUST use it to validate its probabilistic tier.
4. Known causes outrank inferred causes. A deterministic non-AI explanation for a session defeats any probabilistic AI attribution of that session.
5. Reports must label epistemic status. Observed, modeled, and illustrative numbers are different kinds of claims and MUST be presented as such.

2. Terminology

Fetch Event. A retrieval of a resource by an AI assistant’s agent, identified by user-agent, published IP range, structured-endpoint access, or equivalent signal. Each Fetch Event MUST be logged with timestamp, URL, requesting agent identity, and (where applicable) the token minted for it. Implementers MUST distinguish answer-time agents (fetchers retrieving content while composing a live answer for a present user) from index/training crawlers; only answer-time Fetch Events anchor session-level attribution.

Composition Event. A cluster of Fetch Events from one agent within a short interval (RECOMMENDED: 15 minutes), typically produced by a single answer being composed. Implementations SHOULD collapse Fetch Events into Composition Events when constructing arrival-rate baselines and timing nulls, so that multi-fetch answers are not overcounted as independent exposure opportunities.

Landing. The first pageview of a human session on the measured property.

Session. A sequence of pageviews and events attributable to one visitor per the implementer’s sessionization rules, which MUST be documented. Sessionization MUST NOT mint a second identifier for a visitor that already carries one on the same surface (“adopt, never re-mint”): duplicate session identities corrupt the session-novelty and entry-depth features on which Tier 2 depends.

Attribution Token. A signed, high-entropy identifier minted by the implementer and embedded in a URL served to an agent, such that its presence on a subsequent Landing deterministically links the Landing to the Fetch Event (or fetch context) that carried it.

Baseline Arrival Rate (λ). The modeled rate of organic Landings on a page (or page cohort) absent AI-channel influence, expressed as a nonhomogeneous rate λ(t) capturing hour-of-day and day-of-week seasonality at minimum.

Scan Horizon. The maximum fetch-to-landing interval the implementation examines when searching for an anchoring Fetch Event. The Scan Horizon is an engineering bound, not an evidentiary threshold: evidence strength comes from the delivery-delay model and the baseline arrival model, never from falling inside the horizon. Implementers MUST publish their horizon and SHOULD set it wide enough that no landing capable of reaching their minimum evidence level is excluded by the horizon alone.

Capture Version. A published version identifier for the implementer’s data-collection layer (session minting, referrer capture, IP handling, bot gating). Feature availability in Tier 2 depends on capture correctness, so reports MUST state the Capture Version in force during the reporting period.

Conversion. A booking, purchase, or other terminal event the implementer measures. Conversion attribution inherits the tier of its session’s visit attribution, subject to the precedence rule of Section 6.5.

3. Architecture overview

Landfall attribution operates in three tiers. Every measured Landing is assigned to exactly one tier.

Tier 3 additionally serves as the audit bound on Tier 2 (Section 8), and Tier 1 serves as the calibration source for Tier 2 (Section 9).

4. Data collection requirements

• 4.1 Implementers MUST maintain a Fetch Event log and a Landing/session log with synchronized clocks (drift under 1 second).
• 4.2 Landing records MUST capture: timestamp, full URL including query parameters, referrer (or its absence), user-agent, coarse geolocation, session novelty, and entry depth.
• 4.3 Fetch Events MUST be distinguishable from human traffic and from non-assistant crawlers. Implementers SHOULD maintain an allowlist of assistant agent signatures and published IP ranges, reviewed at least monthly, and MUST separately tag answer-time agents per Section 2.
• 4.4 Bot and non-assistant crawler traffic MUST be excluded from both Landing counts and baseline estimation. Implementers SHOULD monitor for crawlers that execute client-side scripts while presenting browser user-agents, and MUST document their bot-exclusion method.
• 4.5 Reports MUST state the Capture Version in force, and material capture changes MUST increment it. Tier 2 features MUST NOT be used for periods in which their capture was known-defective.

5. Tier 1 — deterministic attribution

• 5.1 Where the implementer controls the URL served to an agent (structured endpoints, storefronts, feeds), it MUST mint Attribution Tokens. Tokens MUST be signed or otherwise unforgeable, SHOULD be unique per fetch or fetch-context, and MUST NOT encode personal data.
• 5.2 A Landing bearing a valid Attribution Token is deterministically attributed. No probabilistic treatment applies.
• 5.3 A Landing bearing a platform-supplied identifier (e.g., a utm_source parameter appended by the assistant, or an intact assistant-domain referrer) is deterministically attributed at the channel level. Implementers MUST document which platform signals they honor, since platforms change these without notice. Platform-supplied signals identify the channel, not the specific Fetch Event, and SHOULD be reported as such.
• 5.4 Tier 1 coverage — the fraction of AI-channel surface for which deterministic attribution is possible — MUST be reported alongside results, since it defines both the certainty floor and the calibration base.

6. Tier 2 — probabilistic session attribution

6.1 Model form

For each non-Tier-1 Landing within the Scan Horizon of at least one answer-time Fetch Event, the implementer computes a posterior probability of AI delivery.

Prior. The prior probability of AI delivery for a horizon-eligible Landing MUST be derived from measured aggregate evidence — the RECOMMENDED construction is the excess-share implied by the Tier 3 lift on the same page cohort (prior = 1 − 1/lift for exposure-window landings) — and MUST be estimated on a training period disjoint from the reporting period (see 6.6). Subjective or industry-benchmark priors MUST NOT be used.

Likelihood. The likelihood MUST incorporate, at minimum: (a) the fetch-to-landing interval against an empirically estimated delivery-delay distribution; (b) the page’s Baseline Arrival Rate λ(t) at the landing time; (c) exact-URL match granularity (page-level, not site-level). The likelihood SHOULD additionally incorporate: referrer absence, session novelty, entry depth, geo/device consistency, and Composition Event context. Implementers MUST publish their feature set and prior structure. Feature likelihood ratios SHOULD be estimated on the landing population, with hierarchical shrinkage where per-feature sample sizes are small.

6.2 Saturation handling

• 6.2.1 Posteriors MUST be computed per page (or per page cohort of similar λ), never pooled across pages of different traffic tiers. High-λ pages where fetch cadence saturates the timing signal MUST either fall back to Tier 3-only measurement or rely on non-temporal features; implementers MUST disclose which pages are in saturation fallback.
• 6.2.2 The dispersion of observed arrivals MUST be tested against the Poisson assumption. Where overdispersion is present, the implementer MUST use a negative binomial (or empirically estimated) noise model rather than raw Poisson.
• 6.2.3 For timing nulls and exposure accounting, Fetch Events SHOULD be collapsed to Composition Events so a single multi-fetch answer does not multiply apparent exposure.

6.3 Multiplicity control

Because implementations scan many pages and many windows, per-session “high-confidence” events MUST NOT be reported as counts based on raw significance thresholds. If threshold-exceeding events are surfaced at all (Section 10.3), the scan MUST apply false-discovery-rate control (e.g., Benjamini–Hochberg) and the FDR level MUST be disclosed.

6.4 Aggregation rule

The Tier 2 contribution for any period and scope is the sum of posterior probabilities across Landings (expected value), not a count of Landings above a threshold. Conversion contribution is likewise the posterior-weighted sum over converting sessions.

6.5 Precedence of known causes (normative)

A session carrying a deterministic indicator of a non-AI cause — including but not limited to email-campaign parameters or referrers, paid-click identifiers, verified referrers from non-AI channels, or URL structure characteristic of the property’s own internal navigation or search — MUST NOT receive probabilistic AI attribution, regardless of temporal proximity to Fetch Events. Known causes outrank inferred causes. Implementers MUST publish their known-cause signal list.

6.6 Prior/report separation (normative)

Because Tier 3 both supplies the RECOMMENDED prior (6.1) and audits the Tier 2 sum (Section 8), an implementation that estimates its prior on the same period it reports would render the Section 8 reconciliation circular. Priors and feature likelihoods MUST therefore be estimated on a training window disjoint from (RECOMMENDED: strictly preceding) the reporting period, and the training/reporting split MUST be disclosed.

7. Tier 3 — aggregate incrementality

7.1 For each page or page cohort, the implementer MUST estimate a baseline arrival model λ(t), capturing at minimum hour-of-day and day-of-week seasonality, re-fit on a documented cadence. Because periods and pages with no AI-channel exposure are increasingly unavailable, implementers MUST select and disclose one or more of:

• (a) Pre-exposure fit: λ(t) fitted on the property’s own history before AI-channel exposure began;
• (b) Out-of-window contrast: λ(t) fitted on the same pages’ arrivals outside exposure windows in the same period;
• (c) Matched control pages: λ(t) fitted on comparable pages with no or minimal Fetch Events;
• (d) Suppressed-exposure rotation: a randomized, rotating cohort of pages with agent access deliberately suppressed — the strongest design, which SHOULD be used where the business cost is acceptable.

7.2 Incremental AI-channel visits for a period are estimated as observed arrivals minus expected baseline arrivals, with uncertainty intervals derived from the noise model of 6.2.2. Implementers MAY use a Bayesian structural time-series counterfactual (e.g., CausalImpact; Brodersen et al., 2015) in place of, or in addition to, the parametric baseline; the method used MUST be disclosed. 7.3 Tier 3 estimates MUST be reported as intervals internally and MUST be available in every report (Section 10.2). 7.4 Exposure windows used for Tier 3 are disclosed method parameters; sensitivity to the window length SHOULD be reported.

7.5 Revenue and conversion intervals. Where Tier 3 or Tier 2 results are expressed in revenue terms, uncertainty intervals MUST account for conversion-value concentration. Bootstrap resampling over conversions (or an equivalent heavy-tail-aware method) MUST be used for revenue intervals; Gaussian intervals derived from visit counts alone are not acceptable for revenue claims.

8. Reconciliation (normative)

8.1 For every reporting period and scope, the sum of Tier 2 posteriors MUST be compared to the Tier 3 incrementality interval for the same scope, with the prior/report separation of 6.6 in force. 8.2 If the Tier 2 sum exceeds the upper bound of the Tier 3 interval, the Tier 2 model is overclaiming: the implementer MUST NOT report the unreconciled figure, MUST either recalibrate priors or cap reported modeled contribution at the Tier 3 upper bound, and MUST disclose which was done. 8.3 A back-test of at least one full reporting period demonstrating reconciliation MUST be completed before an implementation first reports Landfall figures externally.

9. Calibration (normative)

9.1 Implementers with any Tier 1 surface MUST run a recurring calibration job (RECOMMENDED: monthly): score Tier-1-attributable Landings with the Tier 2 model as if tokens and platform signals were absent, then compare predicted probabilities to known outcomes. 9.2 Calibration MUST be assessed across probability bins (a reliability curve); Landings scored at p SHOULD verify as AI-delivered at a rate statistically consistent with p. 9.3 A calibration summary MUST include: bin edges, per-bin counts and observed rates, a scalar metric (RECOMMENDED: expected calibration error), the minimum per-bin sample size, and the date range scored; bins under 30 observations SHOULD be merged or flagged. 9.4 Systematic miscalibration MUST trigger prior or feature revision before the next external report. 9.5 Implementations claiming Landfall Calibrated conformance MUST make their most recent calibration summary available to report recipients on request.

10. Reporting requirements

10.1 Reports MUST present the three tiers distinctly and MUST NOT blend them into a single undifferentiated “AI visits” figure. The RECOMMENDED presentation: Delivered (Tier 1, observed), Estimated (Tier 2, bounded by Tier 3), and Lift (Tier 3).

10.2 The uncertainty of modeled figures MUST be available within the report — as fine print, a tooltip, or a methodology block. The display headline MAY be a point estimate provided it is labeled as including modeled data. Below-threshold modeled estimates MUST be suppressed rather than displayed with wide intervals. This matches platform practice for modeled conversions (single blended numbers, quality-gated, disclosed) while retaining the printed interval platforms omit.

10.3 Individual high-probability events MAY be presented as illustrative examples, clearly labeled as drawn from the modeled tier. They MUST NOT be summed into a separate headline count, and their inclusion MUST survive the multiplicity control of 6.3. Evidence-graded per-session classifications (e.g., significance-tiered badges) MAY be maintained internally and shown as exhibit labels, provided the report’s headline quantities follow 6.4 and 10.1.

10.4 Each report MUST reference: the methodology version (“Landfall v0.3”), the Scan Horizon, the Tier 3 exposure window, Tier 1 coverage, the Capture Version, the training/reporting split, and the dates of the most recent reconciliation and calibration runs. 10.5 Language MUST distinguish claim types: “delivered” (Tier 1), “estimated/modeled” (Tier 2), “incremental/lift” (Tier 3).

11. Conformance levels

Landfall Core. Implements Sections 4–8 and 10. Available to implementers with no deterministic surface. Landfall Calibrated. Core plus Section 9 — requires a Tier 1 surface used as ground truth with recurring calibration. This is the level implementers SHOULD target and the level client-facing reports SHOULD claim where possible.

12. Privacy considerations

Landfall requires no cross-site tracking, no fingerprinting beyond standard first-party analytics, and no personal data in Attribution Tokens. Coarse geolocation and device class SHOULD be used at the granularity of standard web analytics only. Fetch Event logs describe agent behavior, not human behavior, and carry no personal data. Implementations MUST comply with applicable privacy law for their first-party session data as they would for any analytics deployment.

13. Relationship to existing practice

Landfall’s Tier 3 follows the established practice of baseline-and-lift measurement formalized in Bayesian structural time-series counterfactuals (Brodersen et al., Annals of Applied Statistics, 2015 — the CausalImpact framework). Its acceptance of modeled conversions where deterministic chains are broken follows the practice of major ad platforms, whose reported conversions include modeled components — introduced at scale precisely when privacy changes (Apple’s App Tracking Transparency, iOS referrer and cookie restrictions) broke deterministic chains — and whose published measurement frameworks (Google Meridian; Meta Robyn) rest on the same modeled-contribution logic. Landfall’s contribution is (a) the fetch-anchored event model specific to AI assistant channels, (b) the mandatory reconciliation bound between session-level and aggregate models, (c) the calibration requirement grounded in deterministic ground truth, and (d) the precedence rule that known causes always defeat inferred ones.

14. References

• Brodersen, K. H., Gallusser, F., Koehler, J., Remy, N., & Scott, S. L. (2015). Inferring causal impact using Bayesian structural time-series models. Annals of Applied Statistics, 9(1).
• Benjamini, Y., & Hochberg, Y. (1995). Controlling the false discovery rate. JRSS-B, 57(1).
• Google Meridian and Meta Robyn (open-source marketing mix models).
• RFC 2119 and RFC 8174.

Appendix A — worked reconciliation example

A page cohort shows 1,240 Landings in a month. The Tier 3 baseline model expects 1,050 ± 60 organic arrivals, yielding an incrementality interval of roughly 130–250 visits. The Tier 2 model’s posterior sum over the same cohort — with priors trained on the preceding period per 6.6 — is 205 visits: inside the interval; the implementation reconciles. Had the posterior sum been 420, Section 8.2 would prohibit reporting it: the implementer recalibrates or caps at 250 and discloses.

Appendix B — saturation across the density spectrum

A three-property field measurement (August 2026, 30-day windows, identical method) illustrates why the tiers must coexist. On a young property (141 fetched pages, 12% of page-hours inside 24h post-fetch exposure), arrival lift was 3.54× and per-session evidence was scarce but strong when present. On a mid-density property (140 pages, 7% exposure), lift was 1.79× and several sessions individually cleared a 2σ per-page timing bar. On a dense property (369 pages, 19% exposure), lift was 1.72× — roughly 285 ± 64 incremental visits — while no session cleared per-session significance: fetch cadence had saturated the timing signal exactly as Section 1.2 predicts. All three properties carry the same three-tier report: deterministic receipts, a bounded modeled estimate, and the lift interval. Only the mix shifts with density.

Appendix C — changelog

• v0.3 (Aug 2026): published (draft label removed); license set to CC BY 4.0; reporting language of 10.2 finalized (labeled point-estimate headlines with the interval available in the report; suppression below evidence thresholds).
• v0.2 (Aug 2026): known-cause precedence (6.5); prior definition + training/reporting separation (6.6); Scan Horizon replaces fixed attribution windows; Composition Events and answer-time vs index agent distinction; Tier 3 baseline strategies (7.1 a–d); bootstrap revenue intervals (7.5); Capture Version (4.5); headline presentation rules aligned with platform practice (10.2); calibration summary format (9.3); RFC 8174.
• v0.1 (Aug 2026): initial public working draft.