Reading a Google Ads Change History

Three different records share one name

When a production arrives labeled "the change history," the first job is working out which record it is, because Google keeps three and they do not agree with each other.

The web interface change history is the one most people mean. It shows the user email attached to a change, the entity, the field, the old and new values and the timestamp, for changes made through the web interface, Google Ads Editor, automated rules and the Google Ads API.

The API change_event resource is the field-level record, exposing old_resource, new_resource, changed_fields, user_email, client_type, change_date_time and resource_change_operation across resource types including Campaign, CampaignBudget, AdGroup, AdGroupAd, AdGroupCriterion and Asset. It is the only surface producing a clean, machine-readable export.

The API change_status resource is far coarser: which resources changed, and whether each was added, changed or removed, with a timestamp. It returns only the latest change per resource, gives no old and new values, and does not identify who made the change.

Advertisers on Search Ads 360 have their own, longer change history, and it is worth asking early whether the advertiser used it.

Know the window before demanding anything

Most of a paid search matter can wait a week. This cannot, because the clock runs from the date the account is examined, not the date of the conduct.

Sources, all read August 14, 2026: Google Ads Help, "About change history"; Google Ads API documentation for change_event and change_status; and the Google Ads Data Retention Policy, whose 37-month and 11-year figures took effect June 1, 2026. Google's wording on the two-year limit is that data older than two years will not be available.

Two consequences follow, and they are why this comes before preservation. The field-level record is a thirty-day product: a programmatic pull has to happen inside that window, after which the web interface is the only surface. And the 37-month reporting cap means that past roughly three years a surviving change row can no longer be read against the day it affected. The change may still be there; the daily spend it moved is not.

Google's language for data outside the reporting window is that it is not accessible through the interface or the APIs. That is a statement about access rather than deletion, and I do not assert the data was destroyed.

Establish who actually has access before preserving anything

A preservation demand assumes someone can reach the record, and in paid search that assumption fails often enough to check first.

Google's documentation draws a line between ownership and access that is easy to miss. A client account still owns its data and can remove a manager's ownership access by unlinking, and ownership is transitive: where a manager account owns a client account, every manager above it also has ownership. At the same time, admin users on an owning manager account can invite and remove users, grant and revoke administrative access, and change security settings. That is the mechanism by which an advertiser is locked out of an account it correctly believes is its own.

So three questions are worth settling before a letter goes out: which manager account holds ownership, who holds administrative access today, and whether your client's own login opens the account this week. If the answer to the third is no, the change history is on the other side of the dispute and the two-year window is running there rather than here.

Getting the log out of the account

In the interface the history is filterable and can be read by user, by campaign, or against the performance overlay. Whether that page offers a direct CSV download is not documented on any Google help page I can cite, so I test it in the product on the account in front of me rather than commit to a file format in a discovery letter. Google's description of the feature is on its About change history page.

The API route is documented precisely. A change_event query must use a date range within the past 30 days and must carry a LIMIT clause capping results at 10,000 rows. On a busy account 10,000 rows is not a long period, so the pull runs in documented segments that can be reassembled and checked. Google's Change Event documentation is the source for both limits.

Search Ads 360, where it applies, does document a download, with two caveats that belong in any report built on one. A download only captures the columns currently visible in the table, so a narrow-column export silently omits fields that existed in the record. And timestamps convert to GMT on download while the screen shows the browser's time zone, so an export compared against a screenshot of the same screen shows two different times for one event.

How to read a single row

A row is a small, specific claim: this field on this entity held value A, then held value B, at this time, under this identifier. Read narrowly it is one of the more reliable artifacts in the paid search record. Read broadly it says much less than people want it to.

What a row supports is that the change occurred and when. That tests a great deal: whether a campaign was paused on the date a party says it was, whether a budget moved before or after a directive, whether a conversion action's settings changed inside a comparison window.

What a row does not support is who was at the keyboard. It carries the email address attached to the change, and shared logins, an agency's service account and API credentials all collapse several humans into one identifier. The API adds client_type, which names the surface rather than the person. It says nothing about anyone who had standing access and made no changes at all.

Telling a bulk or automated change from a human one

Change history covers automated rules, the API and Google Ads Editor, not only manual edits, so the log mixes human and machine activity. Google documents that automated system changes appear under generic user identifiers such as "ads-dartsearch-budget" or "Google Ads system," the clearest native signal that a row was not typed by a person.

Beyond that the separation is inference rather than a field, and should be described that way in a report. What I look at is shape: hundreds of rows sharing a timestamp and one identifier, or the same field altered across many entities at once, all read differently from a handful of edits scattered through a working day. That is analysis, and an opposing expert is entitled to test it.

Two documented gaps make it harder than it should be. Google warns that the page limits the detail displayed on large edits and recommends keeping edits under 2,000 entities to preserve per-entry detail: a bulk upload of tens of thousands of keywords can appear as one event without the granularity the question requires. And Google Ads Editor changes, which do surface in the interface history, are documented as not supported in the API change_event feed. An API export can be missing an entire class of human edit.

Microsoft's report also carries OldValue and NewValue as structured columns, and ChangedBy, giving a username or "Administrator" where the change was system-made. A better record with a shorter memory: on a Microsoft matter the preservation clock is roughly a quarter the length of Google's. The six-month figure is documented for the reporting API; the window in Microsoft's web interface is not, so I verify it rather than assume the two match.

What scripts, automated rules and auto-apply leave behind

Automation is where a negligence question usually lands, because the finding is rarely a single bad edit: something was switched on, left on, and never reviewed.

Auto-apply recommendations leave a partial audit trail. Google documents that the History tab shows how many times a recommendation has been applied in the past week, when it was last applied, and when it was first turned on, and that change history records when the recommendation was first turned on together with the user ID that opted into it. So the record supports two things: that a class of automated change was authorized, and by which identifier. It does not support a complete list of every application over a long period, because the count exposed is framed to the past week.

That shapes what the evidence carries. "This automated change was applied on this date and cost this much" is usually beyond the record. "This setting was enabled on this date by this identifier and was still enabled through the period at issue" is normally well within it. Automated rules and scripts sit in the same position: their edits appear in the history, but the rule or script itself, its logic and its schedule are not in the log and have to come from the party that wrote them.

Reading changes against performance, and where that stops

The performance overlay maps changes onto impressions, clicks, conversions, clickthrough rate and cost, which makes it the feature most likely to be over-read. A change on one day and a metric moving on the next is a sequence, not a cause, and a report treating the overlay as a causal instrument will be taken apart on that point. Cost per click is an auction outcome that moves when a competitor raises bids or a new advertiser enters, independent of anything either party did; Auction Insights is the native way to test whether the competitive set changed, and its own limits are documented, including that it shows nothing below a 10% impression share.

The subtler trap is a change in measurement inside the comparison window. If a conversion action was redefined, if attribution moved, or if modeling began partway through, the figures before and after are not the same measurement and part of the difference is an artifact. The change history is what reveals that, which is the argument for reading it first rather than treating it as a supporting exhibit.

What the change history does not log

Every item below is a documented gap rather than an inference.

• Password changes. Google states expressly that for security reasons change history does not track them. An account-takeover theory cannot rest on this log.
• Some account-level settings changes, and some changes made by Google representatives during consultations. Google concedes both, so advice given or edits made on a call with a platform representative can leave no trace in the client's record.
• Any reason at all. There is no field for purpose, instruction or authorization, and nothing records what was considered and rejected.
• Everything past the window. Not hidden, inaccessible.
• The complete interface record, when pulled through the API. Google's developer documentation states a change event may not include every row from the change history in the web client.
• On Search Ads 360: ad copy test modifications and test membership changes, attribution model adjustments, and password changes. A longer record is not a complete one.

One more point, stated carefully because the sourcing supports no more. No user-facing control for deleting or altering entries is documented, and I have located no Google statement either way on whether it is possible. So I describe the log as having no documented deletion control, and I do not describe it as tamper-proof. Those are different claims, and the second is the sort of overstatement that costs an expert the rest of a report.

The demands that come back empty

Requests nobody can satisfy are worth identifying before they are served.

• Three years of change history. Two years is the documented window. Past it, a cooperative party has nothing to produce.
• A field-level API export of an old change. Thirty days, and not recoverable in the same form from the interface.
• "The change history" with no surface named. The interface log, change_event and change_status are three records with three windows, and a production of the coarsest one technically answers a request that did not distinguish them.
• A preservation letter as a preservation act. Serving one does not alter a retention setting or extend a platform window. Exporting does.
• Screenshots in place of an export. They preserve a rendering at a moment, without metadata, the full date range or the ability to re-segment.

What I do on day one is narrow: read the window, confirm who has access, export both surfaces where both are still open, record the pull parameters, and hash the files. That last step matters because an export a party generated is not self-proving simply because it came from Google. How such a record is authenticated is a question for counsel; whether a clean, documented copy exists to authenticate is decided in the first week, by whoever thought to take it.

Frequently Asked Questions

Published 2026-08-14