Analytics and Tracking

The first questions are about the configuration, not the numbers

Analytics evidence is party-held, which sounds like good news until you notice that almost everything about it is a setting somebody can change. Before a figure in an export means anything, four things have to be established: the retention period, the reporting identity in force, the consent configuration, and the date and time of the extract. Two honest exports of "the same" period will not reconcile without those.

So the configuration is evidence in its own right. The property's change history, the tag container's version history and the consent implementation are as discoverable as the reports, and often more probative, because they establish what the numbers could capture at all.

The second structural fact is that the platform deletes on a schedule nobody can pause. A litigation hold binds parties; it does not bind Google. The only step within a party's power is to copy the data out early, in native format, with the query and date range documented.

GA4 replaced a different data model, and the old model's data is gone

Google Analytics 4 is event-based: its documentation states that in GA4 "every 'hit' is an event; there is no distinction between hit types." Universal Analytics was hit- and session-based, and session counts differ between the two for the same site and period, partly because GA4 derives sessions from an automatically collected session_start event. Google's guidance to migrating properties was to rethink collection rather than port an event structure across, and there is no import mechanism for historical Universal Analytics data.

Then the old product was switched off on published dates. Standard Universal Analytics properties stopped processing hits on 1 July 2023, with 360 properties given a one-time extension to 1 July 2024. Google states that from the week of 1 July 2024 users "will not have access to any current or historical Universal Analytics data," losing both interface and API, and that once a property no longer appears, "you should consider your property shut down."

The consequence for any dispute reaching back before mid-2023 is direct. The contemporaneous analytics record now exists only in whatever the party exported before July 2024 — spreadsheets, PDFs, screenshots, a warehouse copy, an agency's reporting system. Those are secondary artifacts, they have to be authenticated as such, and their provenance is open to cross-examination in a way a platform export is not.

The retention setting, and the fact that nothing suspends it

Google's data retention documentation sets out the options plainly. User-level data can be retained for 2 or 14 months. Other event data can be set to 2 or 14 months on the free product, with 26, 38 and 50 months available only on Analytics 360. The maximum on the free product is 14 months; the maximum anywhere is 50 months with a paid license. The setting covers data associated with cookies, user identifiers and advertising identifiers.

Two operational details matter more than the numbers. First: "When data reaches the end of the retention period, it is deleted automatically on a monthly basis," whether or not a hold is in place. Second: the option to reset retention on new activity applies only to user-level data, so a returning user's record expires on a different schedule than a one-visit user's, and reasoning from "the data goes back N months" is unsafe. Google signals data is capped at 26 months regardless.

What the setting touches is the part that matters forensically. Google states that it "does not affect standard aggregated reports" and "only affects explorations and funnel reports." After the window passes you can still see that there were tens of thousands of paid-search sessions in a month; you can no longer build the exploration showing which users, in what sequence, on what path. The headline layer survives, the forensic layer expires.

Thresholding, cardinality and sampling: three reasons a report is incomplete

Thresholding. GA4 suppresses data to prevent viewers inferring the identity of individual users, in reports containing demographic data, audiences built on demographics, and search-query information where the number of users is insufficient. The interface says only that thresholding has been applied; the value is unpublished and fixed — "Data thresholds are system defined. You can't adjust them." The documented mitigations are a wider date range or the BigQuery export, which excludes Google signals data.

Cardinality. An "(other)" row appears when a table exceeds its row limit: Analytics surfaces the most common dimension values and condenses the rest into it, treating any dimension with more than 500 values as high-cardinality. The values most likely to be collapsed are exactly the ones a dispute is about — one landing page, one campaign name, one referrer. A party who says a traffic source "does not appear in the data" may be describing a row limit rather than an absence.

Sampling. The quota that triggers sampling is 10 million events for standard properties, with 360 properties supporting up to 1 billion per query. When results are sampled the data-quality icon shows the percentage of data used — and explorations, where litigation-grade questions get asked, are the place most likely to sample.

One further trap. GA4's reporting identity can be set to Blended, Observed or Device-based, a choice Google says "does not affect data collection or processing" and can be switched at any time. The same property therefore produces different user counts for the same dates, so a screenshot of a user count is not self-authenticating as to which identity space produced it.

Consent Mode v2 and behavioral modeling: the numbers that are estimates

Consent mode passes four signals: ad_storage and analytics_storage for advertising and analytics storage, and — the v2 additions — ad_user_data, required for measurement uses such as enhanced conversions, and ad_personalization for personalized advertising.

The implementation choice changes the evidence. Google notes that blocking tags until a user consents forfeits the full benefit of consent mode. In the advanced implementation, when analytics_storage is denied, tags do not read or write first-party analytics cookies, but "cookieless pings will be sent to Google Analytics for future measurement" — used for modeling "to fill the gaps in your data."

Behavioral modeling, in Google's words, "uses machine learning to model the behavior of users who decline analytics cookies based on the behavior of similar users who accept analytics cookies." It has thresholds: at least 1,000 events per day with analytics_storage denied for at least 7 days, and at least 1,000 daily users sending events with it granted on 7 of the previous 28 days. A property below them gets no modeled data — its gap is simply missing.

Where modeled data lives is the most useful thing to carry into a deposition on this subject. Google's behavioral modeling documentation states that modeled data is included in standard reports, affecting users and sessions, but excluded from audiences, User explorer, cohorts, sequence segments, retention reports and the BigQuery export. That gives a clean test: if a figure appears in a standard report but cannot be reproduced from the BigQuery export, modeling is a candidate explanation. The labeling is a per-card data-quality indicator with an effective date, not a per-number breakout; Google publishes no modeled-versus-observed split for a metric.

BigQuery export, and the two ways a party can destroy analytics data on purpose

The BigQuery export is the only durable copy, and it does not look backwards. It begins when configured, exported data cannot be re-exported, and the daily export is capped at 1 million events on standard properties. It contains the raw event data Analytics receives from the client — its strength, being the closest thing to a primary record, and its limit, because it excludes post-processing, modeled data and Google signals data. Configure it the week a dispute starts and it preserves everything forward and nothing before.

Deliberate destruction is possible, and it leaves a trace. A data-deletion request erases text collected by event parameters, replacing it with "(data deleted)" while the events still count toward metrics; it requires an Editor role, carries a 7-day cancellable grace period, takes 7 to 63 days to process, applies only to data more than 12 days old, and is not reversible. Deleting a property puts it in a trash state for 35 days, after which Analytics permanently deletes it "and records the deletion in Change History, with the user identified as the Analytics System."

Server-side tagging moves the record onto the party's own infrastructure

Client-side tagging means the browser loads a vendor's tag and sends the hit straight to the vendor, so the evidence sits in that vendor's systems under its retention. Server-side tagging routes the same measurement through a container the advertiser provisions and serves from its own domain — Google's runs on infrastructure such as Cloud Run, and Meta's Conversions API connects an advertiser's server directly to Meta's endpoint.

Three consequences follow, and they cut in different directions. First, it creates a party-held record where there was none — every hit transits a server the party controls, and Google's own server-side tagging material notes that Cloud Run writes standard-output and request logs to Cloud Logging, with request logging enabled unless someone disabled it. An assertion that no server logs exist is therefore a discoverable claim rather than an architectural fact, though how long they survive depends on the party's own logging configuration.

Second, it moves the discovery target: the answer to "show that the conversion fired" stops being the platform's report and becomes the party's own server logs, converting a third-party retention problem into a preservation question.

Third, it inserts a party-controlled transformation step. Server-side containers can add, transform, hash, drop or synthesize parameters before forwarding, so a discrepancy between a party's data and a platform's can originate in that party's own configuration. Server-side data is better evidence without being automatically more trustworthy, and it deserves the same chain-of-custody discipline as any other party-held log. The container's version history shows who changed which tag and when.

What analytics data cannot establish

That the absence of data means the absence of the event. Every platform here deletes on a schedule. By the time a dispute is identified, counsel engaged and a preservation letter sent, the granular record has usually been deleted by the platform rather than by a party. Not found and did not happen are different statements, and a report that conflates them is impeachable on the platform's own documentation. The gap is symmetrical: it is equally unavailable to both sides.

That the figures reconcile, or that a failure to reconcile is misconduct. Thresholding suppresses at an undisclosed cutoff, high-cardinality values collapse into "(other)", explorations sample above a documented quota, and the reporting identity can be changed at any time. Discrepancies between two pulls are the expected condition.

That a user in these systems is a person. A "user" is a platform-defined construct. The same underlying activity yields materially different user counts under different settings, cross-device gaps are structural, and no analytics record identifies a natural person.

That a modeled figure was observed. Behavioral modeling estimates the conduct of users who declined consent from the conduct of those who accepted; it is not an observation of anyone doing anything. The most an expert can honestly do is identify where modeling is present and quantify the gap it fills.

Frequently Asked Questions

Published 2026-08-12