Google Analytics 4 Data as Evidence

What a GA4 export actually is

Google Analytics is Google's hosted web analytics platform (a system that records visits to a website and turns them into reports), and Google Analytics 4, or GA4, is the version that replaced Universal Analytics in 2023. Before anything else, you need to be clear about what a GA4 report is. It is not a record kept by the website owner's server. It is Google's processed account of hits sent to Google by a snippet of JavaScript, the measurement tag, that runs in the visitor's browser.

Google's own description is the best source. The measurement code “packages that information up and sends it to Google Analytics to be processed into reports,” and when Google processes the data it “aggregates and organizes the data based on particular criteria like whether a user's device is mobile or desktop.” Configuration settings “allow you to customize how that data is processed,” such as a filter that excludes internal company traffic. Only after that processing is the data “stored in a database where it can't be changed.”

Three consequences follow for an exhibit. Anything that never executed the tag (a visitor using an ad blocker, a bot that does not run JavaScript, a user who declined cookies under a basic consent setup) is absent by design. Anything the property's filters excluded is absent by configuration. And the numbers that remain are aggregated, sampled, thresholded, and in some properties partly modeled before anyone exports them. The request-by-request record of what the server received is the server log, a different exhibit with a different foundation.

Retention: what the setting deletes and what it leaves alone

The data retention control “give[s] you the ability to set the amount of time before user-level and event-level data stored by Google Analytics is automatically deleted from Analytics servers.” An event is a single recorded interaction, such as a page view or a click; user-level data is the record tied to a particular visitor identifier. For a standard property (a property is the container for one site or app's data), the choices are 2 months or 14 months. The 26-, 38-, and 50-month options exist only for paid Google Analytics 360 properties. Age, gender, and interest data are always held two months regardless of the setting, and Google Ads data in Analytics is limited to a rolling 36-month window.

The part litigators miss is the sentence that follows. Google states that the retention setting “does not affect standard aggregated reports (including primary and secondary dimensions)” and “only affects explorations and funnel reports.” Explorations are the custom, event-level analyses (a specific landing page, by traffic source, by day) that a damages opinion usually needs. So a party can truthfully say the standard Traffic acquisition report still shows 2022 while the event-level data behind any custom question about 2022 is gone. Google gives the example directly: with retention at 14 months and a date range of 14 months plus one day, “data for the additional 1 day is not available in your reports.”

Deletion runs “automatically on a monthly basis.” If someone reduces the period, “any affected data is deleted during the next monthly process.” Increasing it applies to data already collected and not yet deleted, so it cannot recover anything. Analytics waits 24 hours before implementing a change, and during that window the change can be reverted. Changing the setting requires the Editor role, which Google defines as “full control of settings at the property level.” Two other paths erase event-level data without anyone touching the setting: when a standard property grows into Google's “Large” tier, the event-level retention “is automatically reduced to 2 months and event-level data older than 2 months becomes inaccessible and is permanently deleted,” with warning emails to all property administrators before and after. The retention page is an undated living document; archive a dated capture before citing it.

Data-deletion requests: a logged, party-initiated mechanism

Separately from retention, GA4 has a deletion mechanism that a person invokes. A data-deletion request “is used to delete text collected by event parameters,” and the affected text “will be erased and replaced with ‘(data deleted)’, but the event will still be counted in the overall metrics in your reports.” Five request types exist, from all parameters on all events down to selected user properties. The request requires the Editor role, takes “between 7 and 63 days to be processed,” applies only to data more than 12 days old, and allows at most 12 active requests per property. The first seven days of the preview period are a grace period during which an Editor can cancel. After completion, “the deletion of the data is not reversible.”

What makes this mechanism matter in a dispute is that it leaves a trail. Editor users are notified by email when a request is made, when deletion begins, and when it finishes, and a list of the most recent requests is visible under Property column, Data Deletion Requests. Whether a request made after a preservation duty attached reflects intent to deprive under Rule 37(e)(2) is a fact question for the court. The request history, the email notices, and the access-role records showing who held Editor rights at the time are the discoverable artifacts that question turns on, and in my experience they are rarely requested until an expert points out that they exist.

Sampling, thresholds, and the “(not set)” row

Even where the data survives, the numbers in a report are estimates in ways Google documents plainly. Sampling (computing a result from a portion of the events and scaling up) “may occur when the number of events used to create a report, exploration, or request exceeds the quota limit for your property,” which is 10 million events for standard properties. Google calls sampled output “directionally accurate,” and the interface marks it with a data quality icon showing the percentage of data used. Filtering by country “may result in data sampling in standard Google Analytics reports.” And for unsampled reports, Google uses HyperLogLog++ to “estimate exact distinct counts” for users and sessions, with discrepancies that are “less than 1%” in most cases but “can be higher.” An unsampled GA4 user count is an estimate by Google's own account. That is a cross-examination point, not a disqualifier.

Thresholding is a second layer. Google withholds rows to “prevent anyone viewing a report or exploration from inferring the identity or sensitive information of individual users.” Thresholds are “system defined. You can't adjust them,” and a row containing search query information “may be withheld if there aren't enough total users.” A third is the placeholder (not set), which Google uses “when it hasn't received any information for a dimension.” A large (not set) share in the landing-page or source dimension usually traces to a tagging defect, such as a missing session_start event, and it limits what the surrounding rows can support.

Modeled versus observed data, and Rule 702(b)

Consent mode is Google's mechanism for honoring a visitor's cookie choice: “When visitors deny consent, instead of storing cookies, tags send pings to Google,” and Google then “fills the data collection gaps with conversion modeling and behavioral modeling.” Behavioral modeling “uses machine learning to model the behavior of users who decline analytics cookies based on the behavior of similar users who accept analytics cookies.” Google separates the two populations by name: observed data comes from users who granted permission, and modeled data is an estimate trained on the observed users of the same property and tuned by holdback validation.

The exhibit-level consequence is a setting called the reporting identity. Modeling “is automatically enabled when a given property becomes eligible,” and modeled data appears in reports only under the “Blended” reporting identity. An Editor can switch the identity at any time, and the switch “does not affect data collection or processing.” Google warns that reports including modeled data will “probably” differ from observed-only reports, “for example, higher user counts.” The same property, the same date range, two different user totals, depending on a toggle. Every GA4 exhibit should state which reporting identity was active when it was generated.

Rule 702(b) requires the proponent to show that “the testimony is based on sufficient facts or data,” and since December 1, 2023, that showing is made to the court by a preponderance. No located decision addresses whether modeled GA4 counts are sufficient facts or data, so what follows is analysis. An expert relying on a Blended report for a damages figure should be able to state the identity used, produce the observed-only figure, and explain the gap. Whether the gap goes to weight or to admissibility depends on its size relative to the claim. The rule text is at Cornell LII.

Universal Analytics and the baseline problem

Any traffic-loss claim whose baseline predates mid-2023 runs into the Universal Analytics shutdown. Google's timeline: “Starting July 1, 2023: Standard Universal Analytics properties stopped processing hits.” Previously processed data remained accessible “until July 1, 2024,” and starting that week “you will not have access to any current or historical Universal Analytics data.” Google told property owners to export, and warned that otherwise “your data will be permanently deleted by Google and won't be recoverable.” BigQuery backfill for Universal Analytics 360 could be requested only through June 30, 2024.

So for a pre-July 2023 baseline, either the party exported its Universal Analytics data before July 1, 2024, or that data no longer exists at Google. Ask for the export, its date, and the method. And because GA4 and Universal Analytics define sessions, users, and engagement differently, a baseline that crosses the two platforms is not a like-for-like comparison until an expert reconciles it; that is analysis, not a Google statement, and it is a step opposing counsel will look for in the report.

BigQuery: the only raw copy

BigQuery is Google's cloud data warehouse, and a GA4 property can be linked to export its events there. Google says BigQuery “contains only the raw event data that Google Analytics receives from the client,” that the daily export sends “all the raw, unsampled event data once per day from the previous day,” and that “you own that data.” Standard properties are capped at 1 million exported events per day. Once data is exported, “you cannot re-export it,” and if the export is interrupted by an invalid payment method, Google “[is] not able to re-export data for that time.” Linking requires an Editor on the Analytics side and OWNER access on the BigQuery project.

Read together with the retention page, this is why the BigQuery export is, in the site's analysis, the only way a party retains raw, event-level GA4 data past the retention window and outside the sampling and thresholding that apply in the interface. Google's pages do not say in terms whether the link exports events collected before it was created; the “data should start flowing … within 24 hours” and “previous day's data” language points toward a forward-only export, but treat that as inference. In a preservation letter, the practical demands are: do not reduce the retention setting, do not submit deletion requests, enable the BigQuery link now, and record the current reporting identity.

Hearsay, authentication, and the absence of an on-point decision

Searches run on November 4, 2026 located no reported decision ruling on the admissibility, authentication, or hearsay status of Google Analytics report data as such. The closest analogues are decisions on machine output generally. In United States v. Lizarraga-Tirado, No. 13-10530 (9th Cir. June 18, 2015), the Ninth Circuit held that a tack placed by the Google Earth program “isn't hearsay,” while noting that “a machine might malfunction, produce inconsistent results or have been tampered with” and that “such concerns are addressed by the rules of authentication, not hearsay,” pointing to Rule 901(b)(9). Lorraine v. Markel American Insurance Co., 241 F.R.D. 534 (D. Md. 2007), reasoned that when a record is “entirely the product of the functioning of a computerized system or process,” there is “no ‘person’ involved in the creation of the record, and no ‘assertion’ being made.” The Ninth Circuit opinion is on Justia.

A GA4 export does not fit that mold cleanly, and the better framing separates its layers. The underlying event counts are machine-generated and are not a person's statement under Rule 801. The filters, retention choices, and reporting-identity choices are the party's own conduct, discoverable and examinable. The modeled component is an estimate whose reliability is a Rule 702 and 901(b)(9) question rather than a hearsay question. A party offering the export under Rule 803(6) must still satisfy elements (A) through (E) through a custodian or a Rule 902(11) certification; a Rule 902(13) certification establishes authenticity only. Google's statement that processed data is stored “where it can't be changed” helps the process-or-system showing but says nothing about what was filtered, sampled, or modeled before storage, and that is where the examination belongs.

Frequently Asked Questions

Published 2026-11-04