Preserving Advertising and Analytics Evidence

The one structural fact that changes what a hold letter can do

A litigation hold works because a custodian can stop deleting. That assumption fails here. Nothing in Google Ads, Google Analytics 4, Search Console, Meta Ads Manager or Amazon Ads exposes a control that suspends retention. GA4's documentation states that when data reaches the end of the retention period "it is deleted automatically on a monthly basis." Meta's schedule is Meta's, and it was tightened twice across 2025 and 2026. A hold letter to your own client is necessary and it is not sufficient, because most of the record is not your client's to hold.

FRCP 37(e) asks whether a party failed to take "reasonable steps to preserve" electronically stored information that cannot be restored or replaced, and reserves the severe measures — an adverse-inference instruction, dismissal, default — for a finding that a party "acted with the intent to deprive another party of the information's use in the litigation." The rule was drafted against a background assumption that a custodian can in fact stop deletion. The text still governs; the mechanism does not exist.

So the reasonable step available is copying the data out, early, at the finest granularity the platform still offers, with the extraction documented. In this material the failure that gets sanctioned is a failure to copy out, not a failure to refrain from deleting.

Why the party's own export is the primary route

Counsel's instinct is often to subpoena the platform. That route is slow, contested, and of uncertain scope. The Stored Communications Act bars a provider of electronic communication service to the public from knowingly divulging the contents of a communication in electronic storage, and its exceptions do not include a civil subpoena; whether advertising performance data is content at all is not something courts have settled, and they have divided on the statute's reach over non-content business records. Plan around the party's own account export and treat platform process as a supplement.

That is also where the control argument lives. FRCP 34(a)(1) reaches ESI in a party's "possession, custody, or control." In Brown v. Tellermate Holdings (S.D. Ohio 2014) the defendant said it neither possessed nor controlled data in a vendor's hosted database; the court found employees with login credentials could retrieve it, that the company had taken no steps after a preservation letter to protect a constantly changing database, and that counsel had never asked the vendor about its backup retention — which foreclosed verifying the historical accuracy of what was eventually produced. Sanctions were preclusion, removal of confidentiality designations across roughly 50,000 pages, further production, and fees against the party and its counsel jointly. Not default, not dismissal, and no ruling on the underlying claims. It is one magistrate judge's decision, persuasive rather than binding, and the circuits differ on what control means.

The clocks, in the order they expire

Triage by expiry date rather than by importance. The most granular evidence is always the first to go.

1. Google Ads click-level data — about 90 days. The click_view resource is the only Google-side record of individual clicks keyed to the click identifier. Google's Ads API support channel states, in the documentation's own words, that queries including it "must have a filter limiting the results to one day and can be requested for dates back to 90 days before the time of the request," and that there is no workaround for older data. Note the shape: one day per query, so a 90-day capture is 90 requests.
2. Amazon Ads Reporting API — roughly 65 days. Amazon's own documentation repository describes a maximum of 31 days per report request, and that while a request can reach 95 days into the past, data is returned only for the last 65.
3. Google Ads invalid-clicks reporting — about 60 days in the campaigns table.
4. Google Ads change history through the API — 30 days.
5. GA4 — 2 or 14 months. User-level data may be set only to 2 or 14 months. Event-level data has the same two options on the free product, with 26, 38 and 50 months available only on Analytics 360. Deletion runs monthly.
6. Meta Ads Insights API — 37, 13 and 6 months. Effective 12 January 2026 Meta established three tiers: 37 months for total aggregate values, 13 months for unique-count and hourly breakdowns, and 6 months for frequency breakdowns.
7. Search Console — 16 months, rolling.
8. Google Ads change history in the interface — 2 years.

Universal Analytics is already past tense: standard properties stopped processing hits on 1 July 2023, 360 properties received a one-time extension to 1 July 2024, and access to current and historical UA data ended the week of 1 July 2024. For conduct measured in UA, whatever exists is what somebody exported before that date.

Day one and day two: what to pull before anything else

Click-level data first, always. It expires soonest, it is the only per-click platform record, and once it is gone the alternatives are the advertiser's own server logs, tag manager logs, or a third-party vendor's capture — all of which are party or vendor evidence rather than the platform's. If the matter touches click quality, competitor conduct, or any question that needs individual clicks rather than campaign totals, this pull cannot wait for a discovery plan.

Then the full account export at the finest granularity each platform still offers, dated and attributed, across every account in issue — including accounts held by an agency, which is where the control question usually bites and where an audit right in the services agreement may be faster than a Rule 34 request.

Then change history from the Google Ads interface rather than the API, because the interface reaches two years and the API reaches 30 days. In practice that means the interface's own download or a systematic screen capture. Anything older than two years is not available from Google at all and would have to come from a party's or agency's own records.

Analytics: raise the ceiling, then start the durable copy

Three GA4 actions, in this order. First, read the property's current retention setting and record what it says before touching it — the setting itself is evidence of what was available and when. Then raise it to the maximum the license allows: 14 months on the free product, up to 50 months on Analytics 360. Raising it does not resurrect what has already been deleted.

Second, enable the BigQuery export immediately, understanding exactly what it does and does not do. It is the raw event data Analytics receives from the client and the only durable copy in the stack — and it does not backfill. It begins when it is configured, has a daily limit of one million events on standard properties, and cannot be re-exported once exported. A litigant who configures it in the first week of a dispute preserves everything from that week forward and nothing before it. That asymmetry is worth explaining to the client in writing.

Third, export the explorations and funnel reports anyone intends to rely on. The retention setting affects explorations and funnel reports; it does not affect standard aggregated reports. So after the window rolls you can still see that there were 40,000 sessions from paid search in a given month, but you can no longer rebuild the exploration showing which users, in what sequence, on what path. The forensic layer expires and the headline layer does not.

Search Console, Meta and Amazon, each with a different failure mode

Search Console. Sixteen months, rolling, so a matter about conduct two years ago is already past the edge. Export the Performance report and the API pulls for the whole available window now, and separately enable the BigQuery bulk export, which contains all the performance data available to Search Console except anonymized queries and which accumulates indefinitely unless an expiration is set. Like the GA4 export, it is prospective only — Google's guidance for historical data is the API or the reports. Record the aggregation type on every pull, because aggregating by property and by page produce different totals for the same period.

Meta. Pull Ads Insights at every breakdown that will matter before the 13-month and 6-month tiers bite, and note that the same change removed the 7-day-view and 28-day-view attribution windows from the API entirely. Meta's own best-practices documentation states that insights "refresh every 15 minutes and do not change after 28 days of being reported," which means a pull taken inside 28 days may not match a later pull of the same period. Date every extract. Where political or issue advertising is in evidence, capture the Ad Library entries: the seven-year archive began pruning on 24 May 2025.

Amazon. The shortest window of the three. Pull the Reporting API continuously rather than once. Amazon Marketing Cloud's ad-traffic lookback expanded from 13 to 25 months in November 2025, and an expansion does not resurrect signals that had already aged out.

Suspend the destruction a party actually controls

Separate from the platform's schedule, there are destructive acts within a party's power, and unlike the platform's deletion these leave a trace. Instruct the client, in writing, to suspend all of them for the duration:

• GA4 data-deletion requests, which replace collected event-parameter text with "(data deleted)". These have a seven-day cancellable grace period, take 7 to 63 days to process, cannot touch data less than 12 days old, and are irreversible once complete.
• Property and account deletion, which runs through a 35-day trash window after which Analytics permanently deletes the entity and records the deletion in Change History, attributed to the Analytics System rather than to a person.
• Any change to the retention setting itself.
• Google Ads account cancellation. A canceled account remains signable-in and reactivatable, but its remarketing lists are set to closed and roughly a month later their membership duration is set to one day, removing all users from them.
• Tag manager republishing and theme or template edits on the site, where version history is the record of what was actually live.

This is one of the few places in the stack where intentional destruction is visible. That is worth saying out loud, because most of the rest of it destroys silently and leaves nothing to find.

Document the extraction, or spend the deposition on reconciliation

Two truthful pulls of "the same" data will not match unless the parameters match. For every extract, record the account identifier, the exact query or the interface path, the date range, the attribution setting, the reporting identity, the time zone, the currency, and the date and time of extraction. Preserve the native file rather than a reformatted copy, and keep hash values at collection.

That last step is what makes a certification available later. Federal Rule of Evidence 902(13) covers a record generated by an electronic process or system on a qualified person's certification, and 902(14) covers data copied from a device or file authenticated by a process of digital identification — in the ordinary case, hash verification. Both carry Rule 902(11)'s notice requirement, which is where proponents fail. And the Advisory Committee was explicit that such a certification "can establish only that the proffered item is authentic," leaving the opponent free to object on other grounds. Authenticity is not accuracy. An export produced under that certification can still be wrong, and admissibility itself is a separate subject covered elsewhere.

Ask third parties in writing what their retention periods are, in a form that can be put in evidence — affiliate network click logs in particular, where retention is unpublished and the click log rather than the commission summary is the evidence.

What preservation cannot fix, and what to write down instead

Some of this will already be gone when you are retained, and the honest move is to record what was missing rather than to work around it quietly. Make a contemporaneous note of what you asked for, on what date, and what the platform no longer held. That note does two things: it supports the argument that the loss was scheduled third-party deletion rather than party conduct, and it keeps the eventual report from sliding from "not found" to "did not happen."

Whether platform-side deletion on a published schedule can ever support a spoliation finding is unresolved. The intuitive answer is that it is the routine, good-faith operation of an electronic information system the Rule 37(e) framework contemplates. A party that knew about a 90-day click-data window, anticipated litigation inside it, and did nothing presents a harder question, and I have found no decision resolving it. Present it as an open question rather than as a proposition.

Finally, preservation does not cure the underlying limits. Preserving a modeled conversion preserves an estimate. Preserving a thresholded report preserves the suppression along with the data. Early export makes the analysis possible; it does not make the record say more than it says.

Frequently Asked Questions

Published 2026-08-12