Two different claims, and they need different evidence
This distinction is the spine of the page, and reports collapse it constantly.
Lost traffic is a claim about sessions. It is proved, if at all, from server logs and analytics on both sides, plus the mechanism linking them — a redirect chain, a surviving referrer, shared infrastructure or shared account identifiers. Note what that requires: the disputed domain's own logs. Which usually means discovery against the other side, not analysis of the claimant's data.
Lost revenue is a claim about money. It requires everything above, plus a conversion rate applicable to that traffic type, an average order or lead value, evidence that a diverted visitor would have converted, and an accounting of variable cost. None of that is in a server log.
An expert can produce the traffic record and the revenue-mechanism record, and can quantify what the produced data shows. What a party is owed is not the expert's statement to make, and the causal step from "traffic arrived here" to "revenue was lost there" is a chain with named, disclosed assumptions at every link, or it is not evidence.
Classify the traffic before counting it
Three traffic types, three different proofs, three different relationships to a diversion theory.
Type-in traffic. Someone typed the name or followed a bookmark. This is exactly what a typo domain is built to capture, and it is the hardest to evidence, because by construction it arrives with no referrer. There is no field that records "this person typed it."
Search traffic. Someone searched and clicked. Evidenced by referrer strings, analytics channel classification, and search console impression and click data. The query itself is largely unavailable. Since 2011, organic search over encrypted connections passes the fact of the search engine but not the individual query, which is the origin of the "not provided" condition in keyword reports. The referrer confirms the engine, not the search.
Referral traffic. Someone followed a link, including from a redirecting typo domain. Evidenced by the referrer header where it survives. This is the only traffic type where the source is directly recorded — and it is precisely the record that browser policy has spent the last several years eroding.
"Direct" is a residual bucket, not a measurement
The most common analytical error in this area is short and easy to state: direct traffic is not type-in traffic.
Analytics platforms define their direct channel as sessions arriving with no identifiable source — the platform's own channel definition matches on source and medium fields being unset rather than on any positive evidence that a URL was typed. Everything without a usable source lands there: a bookmark, a typed address, an app link, a referrer stripped by policy, a referrer lost across a redirect, an untagged link in an email, a click from a document or a chat client.
So a rise in "direct" is consistent with type-in traffic and equally consistent with a referrer policy change, a tracking configuration change, or a migration. Treating the bucket as a measurement of typed URLs converts a residual into a finding, and it is a finding the other side can dismantle by quoting the platform's own documentation. Any report that touches this data reproduces that documentation and reasons from the definition rather than from the label.
What logs establish, and what they do not
From the receiving side's own records, a log can establish: that a request arrived, at what time, for what path, with what response code, from what address, with what user agent; that a redirect occurred and what its chain was, from the response codes and location headers; volume over time on the disputed name, if that name's logs are produced; and, where a referrer was sent, the origin that sent it.
It cannot establish:
- Intent. A log records a request, not why it was made.
- Where a visitor would otherwise have gone. No log on either side contains the counterfactual.
- That a visitor was human. Bot and crawler traffic has to be identified and excluded, by a method that is stated and reproducible.
- Identity. An address is not a person.
- Revenue. Traffic is not sales.
Two data sources will also disagree with each other. Client-side analytics undercounts, because blockers, consent refusal, script failure and privacy browsers remove sessions the server still sees. The report reconciles server-side and client-side counts and explains the delta rather than quietly picking the larger number.
The referrer problem, which is systematic rather than occasional
The referrer header is not guaranteed, and it has been deliberately reduced. The W3C Referrer Policy specification defines the policies that govern it: under a no-referrer policy the header is omitted entirely; under downgrade-sensitive policies it is omitted on a secure-to-insecure navigation; and under the strict-origin-when-cross-origin policy the full URL goes to same-origin destinations while only the origin — scheme, host and port, with path and query stripped — goes cross-origin.
That last policy became the default in Chrome 85 in 2020, so cross-origin requests from the most widely used browser carry origin only. The header's semantics are defined in RFC 9110.
The practical consequence for a diversion analysis is specific. A redirect from a typo domain may appear in the receiving site's logs as origin only — you know the typo domain sent the visitor, but not from which path — or as nothing at all, in which case it is indistinguishable from direct traffic. Referrer-derived counts are therefore floors, of unknown depth. And the absence of referrer evidence is not evidence that no diversion occurred.
Correlation between a typo domain and a traffic decline is not diversion
This sentence belongs on the page rather than in a footnote, and it belongs in the report too.
A decline in the claimant's traffic that begins when a typo domain goes live is a coincidence in time until something links them. Search algorithm updates, seasonality, a site migration, a tracking configuration change, a competitor's campaign and an advertising budget change all produce the same shape on the same chart. Charting a traffic decline against a registration date and calling it causation is the single most attackable move in this area, and it is attackable precisely because the alternative explanations are so many and so ordinary.
The linking evidence is a different artifact entirely: the captured redirect chain from the disputed name, server logs on the receiving side, shared advertising or affiliate account identifiers, analytics property identifiers, or surviving referrer strings. Where those exist, the report shows them. Where they do not, the report says the link is unproven — in those words — and describes what records would establish it and who holds them. That second output is often more useful to counsel than the chart, because it tells them what to ask for.
What traffic evidence cannot establish
No record contains the counterfactual. The number of users who would have reached the claimant absent the disputed domain is not in any log, on either side, and no amount of analysis produces it.
- Referrer stripping is systematic. Cross-origin referrers carry origin only under current browser defaults, and secure-to-insecure navigations carry nothing, so referrer-derived counts are floors of unknown depth rather than totals.
- "Direct" is a residual capturing everything without an identifiable source, and cannot be read as typed-URL traffic.
- Organic keyword data is largely unavailable, by design, since individual queries stopped being passed in the referrer for encrypted signed-in search.
- Analytics data expires on the platform's own schedule. Standard event-level retention options are short — a matter surfacing more than a year or so after the conduct may find the granular data already gone — and log rotation windows are provider-dependent and often far shorter.
- Thresholding and row caps suppress exactly the low-volume data a single typo domain produces, both in analytics reporting and in search console exports.
- Bots inflate server logs and must be excluded by a disclosed method.
- Cross-device and cross-session journeys break attribution, and third-party traffic estimators are modeled rather than measured.
What a retaining attorney should expect
First, preservation, and immediately. Log retention is the hard clock in this work: web server and content delivery logs rotate on short cycles, analytics platforms enforce their own retention windows, and neither pauses for a dispute. A preservation demand covering both sides, and every third party identified, is the step that determines whether there is anything to analyze later.
The deliverable is a traffic and mechanism exhibit: raw logs with the scripts that processed them, so the analysis is re-runnable; the redirect chain captured and re-captured over time and from multiple vantage points; analytics and search console exports with the platform's own limitation notices attached rather than stripped; archived captures of what the disputed name served, including the advertising and affiliate identifiers in its page source; and the DNS and hosting records tying the name to infrastructure.
US-specific: logs and analytics exports are business and machine-generated records, authenticated under FRE 901 with the 902(13) and 902(14) certification routes, presented in volume under FRE 1006; provider-held data is subject to the procedures of 18 U.S.C. 2703; and the remedies framework any quantification might feed is 15 U.S.C. 1117. The traffic opinion and any revenue opinion sit in separate sections with separately stated assumptions. Bill Hartzer has testified in domain-related legal cases and has provided expert witness reports in others, and has worked in this field since 1996; the current record is at hartzer.com.