Google Ads Account Forensics

The record is in the account, and the clock is already running

A Google Ads account is a system of record, and in a dispute it behaves like one. It logs who changed what and when. It reports impressions, clicks, cost and conversions down to the day. It holds the queries that triggered ads, the invoices, and enough settings history to show how campaigns were configured inside the retained period. Anyone with the right level of account access can pull all of it, which is why this page carries the verdict in the account.

The complication is not access. It is time. Each record expires on its own published schedule, the schedules are different lengths, and every one runs from the day the account is examined rather than from the day of the conduct in dispute. A change made forty months before anyone looks is not buried somewhere awkward; it is gone. That single fact reorders the sequence of a matter, because the cheapest step available early is also the only step that cannot be taken late.

Whether what the record shows is actionable is a question for counsel; I am not an attorney. What follows is what the account contains, what it does not, and where I most often see the record over-read.

Seven clocks, and the one that runs out first

The published windows, read August 14, 2026 in Google Ads Help and the Google Ads API documentation.

Two things matter more than the individual figures. The 37-month cap on granular reporting took effect June 1, 2026 — recent enough that anyone working from a retention figure learned two years ago has a number that has since changed. Trade coverage quotes a May 1, 2026 date; the Help page as I read it gives June 1, and June 1 is the date I use.

Google's wording is worth reading exactly, too: data outside the window is not accessible through the interface or the APIs. That is a statement about access, not destruction, and I do not assert the data was deleted, because Google has not said so. Nor have I located any published statement on whether a subpoena reaches data older than the window. Absent one, assume the schedule runs regardless of a hold.

What the change history actually logs

In the interface, each entry carries the user email attached to the change, the entity affected, the field, the old value, the new value and a timestamp. It covers changes made through the web interface, Google Ads Editor, automated rules and the API — not only manual edits, which is the assumption I most often have to correct. The history can be viewed by user, by campaign, and against a performance overlay mapping changes onto impressions, clicks, conversions, clickthrough rate and cost, so a bid or budget change can be read next to what happened to delivery afterward (Google Ads Help, Review your account history, read August 14, 2026).

Pulled through the API, the change_event resource is richer per row: old_resource and new_resource, changed_fields, user_email, client_type, change_date_time and resource_change_operation, across campaigns, ad groups, ads, criteria, budgets, assets, asset sets and feeds. That structure is what makes a clean, machine-readable, hashable export possible — and it is available for thirty days.

The coarser change_status resource covers ninety days but answers a smaller question: which resources changed, and whether each was added, changed or removed. It returns only the latest change per resource, does not show old against new values, and does not identify who made the change.

What the change history does not log

Google states plainly that for security reasons the change history does not track password changes. An account-takeover theory therefore cannot be carried by the change history alone; it needs login and session records that live somewhere else.

Google also concedes that sometimes not all account-level settings changes are listed, and that changes made by Google representatives during consultations may not appear. A setting altered during a call with the platform can leave no trace in the advertiser's own record — so the absence of an entry is weak evidence that nothing happened.

Large bulk edits are truncated. Google warns that the change history page limits the detail displayed for each entry and recommends keeping edits under 2,000 entities to preserve it.

Automated changes surface under generic identifiers rather than people — labels such as Google Ads system or an automated budget identifier. And the deeper limit sits under all of it: the log records the email attached to a change, not the human at the keyboard. A shared login, an agency service account and a set of API credentials each collapse many people into one identifier. That is a narrower finding than most parties expect.

Why an interface export and an API pull will not agree

This one surprises people, and it should be stated in a report before an opposing expert states it first. Google's own developer documentation warns that a change event may not include every row from the change history in the web client. The two surfaces are not equivalent, and the same account will yield two different record sets depending on which one is used (Google Ads API, Change Event, read August 14, 2026).

The API side carries its own mechanics. The queried date range must fall within the past thirty days. The query must include a limit clause capping results at ten thousand rows, so a busy account has to be pulled in slices. Changes take up to about three minutes to appear. And Google Ads Editor changes, though listed in the client-type enumeration, are documented as unsupported in the change event feed even though they do surface in the interface history.

None of that makes either surface unreliable. It makes them different instruments, and an examiner comparing them has to explain the delta rather than present one as a complete mirror of the other. Where both can be pulled, I pull both and document the difference as a platform characteristic rather than a sign of removal.

The search terms report is not the list of queries that matched

The search terms report shows the actual queries that triggered ads — for those queries that clear Google's privacy volume threshold. Google's stated rationale is that the thresholds keep terms anonymous by reporting only on those that have seen sufficient search volume across all Google searches. Google has never published the numeric threshold, so any specific number attributed to it is unsourced.

The consequence is arithmetic and it matters in a report. Aggregate click and cost totals still include the withheld queries, so the rows in a search terms report will not sum to the campaign totals. That gap is expected behavior, not evidence that anyone edited or suppressed the data — and I have seen it argued as though it were.

The report's own history has edges too. From February 1, 2021 Google began surfacing more queries meeting the privacy standard for Search and Dynamic Search Ads campaigns, and historical search terms data collected before September 1, 2020 was phased out by February 1, 2022. No expert can reconstruct the full matched-query set from the platform record, and an opinion claiming to have done so is over-reading the report.

What Auction Insights can say about a competitor, and what it cannot

Auction Insights is the report attorneys reach for when a competitor is involved, and the one most often asked to carry more than it holds. Search campaigns get six metrics: impression share, overlap rate, position above rate, top of page rate, absolute top of page rate and outranking share. Shopping and Performance Max get three — impression share, overlap rate and outranking share.

It never shows a competitor's bid, budget, spend, keyword list or absolute impression volume. It cannot speak to auctions the advertiser never entered, so it is silent on exactly the conduct a competitor-bidding theory usually alleges. It does not display data at all where impression share is below ten percent, and it filters out auctions with very low impressions, which produces small discrepancies against campaign-level figures.

The most consequential limit is that impression share figures are not comparable between two advertisers' reports. Google's own example is that an advertiser showing one hundred percent impression share may be competing against an advertiser whose own report shows fifty percent. Two parties can therefore produce Auction Insights exports that appear to contradict each other while both are correct, and any comparison drawn across two accounts has to account for that before it is offered as a finding.

Ask about Search Ads 360 before concluding the record is gone

If the advertiser is an enterprise buyer, ask early whether campaigns were managed through Search Ads 360. Its change history goes back to May 21, 2016 or later — far longer than the two-year native window, and the best reason a record that looks aged out may not be. The SA360 log captures the email of the person who made the change, the method used, the timestamp, when the change reached the engine, the entity type and the alteration itself, and it filters by account, bid strategy, change type, item, tool and user.

It also downloads, in several formats, which produces a fixed exported record rather than a screen. Two traps come with that download and both belong in the workpapers. SA360 displays times in the browser's time zone but converts all timestamps to GMT in downloaded reports, so an export compared against a screenshot of the same screen shows two different times for one event. And a download captures only the columns currently visible in the table, which means a narrow column layout silently omits fields that existed in the record — that is how an incomplete production happens without anyone intending it.

SA360 has its own blind spots: it does not track ad copy test modifications or test membership changes, attribution model adjustments, or password changes.

Access, ownership, and the export I want first

Manager accounts are where paid-search matters stall. Google's documentation states that a client account still owns its data and can remove ownership access by unlinking, and that ownership is transitive — where a manager account owns a client account, every manager above it has ownership too. Exercising that depends on holding admin access, and an admin on an owning manager account can invite and remove users, grant access, accept link requests and change security settings. That is how an advertiser is locked out of an account they believe is theirs, and Google's documentation does not address how the dispute is resolved.

So the practical sequence, subject to what counsel decides about scope: the field-level API change record first, because it is thirty days wide and everything else can wait a week; the interface change history next; then billing records, governed by accounting retention rather than the reporting window; then daily reporting before it rolls up.

Two cautions on method. The Google help pages I have located do not document a download control for the native change history page, so I treat a clean CSV of it as untested rather than assumed. And Google publishes nothing either way on whether a user can delete or alter entries, so I say only that no user-facing deletion control is documented. I do not describe the log as tamper-proof, and would not sign a report that did.

Frequently Asked Questions

Published 2026-08-14 · Last reviewed 2026-08-15