Keeping your own change log for ad accounts: the reason behind a change, which the platform history does not keep

Translated from the Japanese original on mureo.jp.

In the week results suddenly drop, you try to remember what you changed. Did you raise the budget, switch the bidding strategy, swap out an ad? Open the change history in the ad platform and the timestamps, the fields and the user who made each change are all there. What is not there anywhere is why you raised the budget on that day.

Every ad platform has a change history feature, but what it keeps goes as far as what was changed, when and by whom. The reason for a change, the set of things changed together, and a decision not to change anything are not kept. This article separates what the platform history covers from what only you can record, then covers how to build that record and how to reconcile it against the platform history. The second half goes as far as handing the collection work to an agent with read-only access.

The broader picture of handing ad ops to an agent is in Can you automate ad ops with Claude Code?

What the people opening the change history were actually looking for

Reading the public posts of people who run their own ads, “change history” shows up as the name of a step in a procedure. What shows up as the actual problem is handover, and why something was done.

A doctor who runs several clinics and manages their own search ads wrote that if you make a landing page change and a bid change on the same day, you can no longer tell which one caused a shift in enquiries. So before adding budget, they made it a rule to look back through the recent change history in the ad platform and check each thing they had moved, one at a time.

Someone who runs their own e-commerce business from product planning through to customer support wrote that all they inherited from their predecessor was a target CPA figure. Why that number, and which creatives had been working, was not recorded anywhere. The settings alone were not enough to reproduce the results, so they spent about two months re-testing. They named the fact that the numbers remain while the reasons do not as the biggest loss.

The third is a larger operation: a D2C operator running roughly ¥50 million a month in ad spend on their own. They collected the history of temporary budget changes from the platform’s history page every day and accumulated it in their own records. The sticking point they named was that the ad platform had no screen listing budget operations. In English, too, there was a post where a third party pointed out that what an AI agent setup touching an ad account was missing was approvals, caps and a change history.

What the three have in common is that none of them is struggling because the history does not exist. The history is there. What is missing is the material for isolating a cause, and the reasoning behind decisions.

These are public posts on X, and we have not verified the writers’ businesses or track records. We do not name anyone, and deal only with what they did and the mechanism it reveals.

The change history the platforms keep

First, what the platforms themselves keep. Putting the three main ones side by side, neither the retention period nor the way to get the data out is the same.

Platform	Name in the UI	How far back	What is kept
Google Ads	Change history	2 years in the UI; 30 days via the API	Time, type of change, target, before and after values, user, source of the change
Meta Ads	Activity history	Shown in Ads Manager for the selected object	Time, field changed, user
Yahoo! JAPAN Ads (search)	Operation history	365 days; exported as CSV, up to 1 million rows per file	Time, operation, user

The thing to watch with Google Ads is that the UI and the API reach back different distances. The change history screen shows the past two years, but the API’s change events only go back 30 days, and one query is capped at 10,000 rows. If you collect the history with a script or an agent, you need to fetch at intervals shorter than 30 days; any period you miss can then only be read from the UI.

On the other hand, the API’s change events carry the before and after values and a field showing the source of the change (the web UI, Editor, the API, automated rules, auto-applied recommendations and so on). When a change you did not make turns up, it helps you tell whether a person made it or it was auto-applied.

What the platform history does not keep

The platform history records the fact of an operation. To use it for decisions, at least four things are missing.

The reason for the change: Did you raise the budget because results were good, because spend was short at month-end, or because your manager told you to? The history only says “daily budget ¥3,000 → ¥5,000”. The case of inheriting only a target CPA is this gap turning directly into two months of re-testing.

The set of things changed together: The history lists one row at a time, so changing bids, the landing page and ad copy on the same day can be seen by reading down the rows, but they are not grouped as a single initiative. A landing page change happens outside the ad platform, so it never appears in the history at all. The doctor could not isolate the cause because this grouping sits outside the record.

A decision not to change anything: In a week results drop, you sometimes investigate and decide to change nothing. That is not an operation, so it appears in no platform’s history. Whoever looks at the same numbers the following week does the same investigation again.

A timeline across platforms: Lowering the Google Ads budget on the same day you raise the Meta Ads budget is a reallocation, but it is recorded separately in two ad platforms. The platforms offer no way to line them up.

What to record yourself

The record you keep yourself is not a copy of the platform history; it adds the columns the platform history does not have. Give each row the following:

Timestamp: to the minute, since you will reconcile it against the platform history.
Platform and account: the column that lets several platforms live in one record.
Target and change: what in which campaign, changed from what to what.
Who: a person’s name, an agent, or an automated rule.
Reason: what you looked at and what you expected. One sentence is enough.
Changed together: other changes that belong to the same initiative. Changes made outside the ad platform, such as landing page edits, go here too.
Review date and metric: when, and by which number, you will judge the effect.

Columns 5 and 7 are the ones the platform history lacks. Writing 7 in particular means the date for judging whether a change worked is set by the record. It also reduces premature calls made by reading results during a smart bidding learning phase.

A decision not to change anything also gets a row in the same form. Write “no change” in the change column and fill in the reason and review date, and next week’s you, or whoever takes over, will not repeat the same investigation.

Keep the record append-only and do not rewrite past rows. If a decision turns out to be wrong, add a correction row instead of editing the original. That way a later reader can trace both the decision at the time and the later correction.

Reconciling against the platform history

Your own record alone will not show changes you forgot to log, or changes someone else made. Once a week, fetch the platform history and reconcile it against your record.

What you want to catch are rows that are in the platform history but not in your record. When you find one, it is one of these:

A change you forgot to record
A change by someone else who has access to the same account
A change from auto-applied recommendations or an automated rule

The third shows up as settings that changed even though you did nothing. Google Ads auto-applied recommendations, if left on and forgotten, can add or remove keywords or change the bidding strategy. The source field in the change events lets you tell these apart from a person’s operations.

The weekly interval is there to stay well inside the 30-day window of the Google Ads API mentioned above. Monthly, a single failed fetch is enough to leave a period outside the window.

Handing collection and reconciliation over with read-only access

This work involves almost no judgement, the procedure is the same each time, and people do not keep it up. It is the “change history collection” we listed in How much of ad ops to hand to Claude Code as one of the tasks people actually hand to agents.

Connect Claude Code to the ad platforms’ APIs and hand it these three:

Fetch each platform’s change history since the last fetch and lay it out in one table in a common format
Match it against your record by timestamp and target, and pull out the rows missing from your record
Report those rows grouped by source (a person, auto-apply, an automated rule)

None of the three needs write access. Reading the history, matching, reporting: all of it works with read-only access. Filling in the reason column is a person’s job, so what the agent produces stops at “a list of changes with no reason recorded”.

When you get to the stage of letting the agent itself make changes, reverse the order of recording. Rather than having it write the reason after executing a change, set things up so that a change does not execute unless a reason is written. In mureo, write operations require a reason field, and every call appends one row to the record with the timestamp, the kind of operation, the arguments, whether it writes, and the outcome. Each row holds the hash of the previous row, so rewriting a row in the middle later breaks the chain and becomes visible. Even with ops done by hand, deciding the record’s format first lets you run on the same idea.

How to narrow the scope of write access and combine approvals with caps is covered in Is it safe to hand ad ops to Claude Code? The steps for connecting to Google Ads are in Driving Google Ads from Claude Code.

Where people get stuck with change history

The API reaches back less far than the UI
For Google Ads it is two years in the UI and 30 days via the API. If you build a collection setup and then leave it stopped for more than 30 days, that period can only be filled in by hand from the UI.

Stacking several changes on the same day
Change bids and the landing page on the same day and you cannot later separate which one had the effect. A “changed together” column does not isolate the cause either, so spacing out the change dates comes first.

Leaving auto-apply on and forgetting it
Once auto-applied recommendations are enabled, changes keep coming in with no action from you. If reconciliation turns up rows missing from your record every week, check the auto-apply settings first.

Only the reasons disappear at handover
When the person in charge changes, account access and settings can be transferred, but the reasons exist only in that person’s head. Just asking them to fill in the reason column for the main changes of the past few months before handing over makes a large difference to the later re-testing. What to take over when moving to in-house management is covered in Bringing ad ops in-house.

FAQ

How far back does the Google Ads change history go?

The change history screen shows changes made to the account, campaigns and ad groups over the past two years. The API’s change events go back 30 days, and one query is capped at 10,000 rows. If you collect with a script or an agent, fetch at intervals shorter than 30 days.

The platforms have a change history. Do I still need my own record?

The platform history is enough for confirming what was changed, when and by whom. It does not keep why, what was changed together, or a decision not to change. When you need to explain afterwards why results moved, or when an account is handed over, not having those three means redoing the investigation.

Is a spreadsheet enough for the record?

Yes. What matters more than the tool is fixing the columns and not rewriting past rows. With seven columns (timestamp, platform and account, target and change, who, reason, changed together, review date and metric) you also have the keys you need when reconciling against the platform history.

Is there a way to combine the change history of several platforms?

The platforms do not provide one. You fetch each platform’s history via API or CSV, align the formats of timestamp, platform and target, and put them in one table. Fetching and formatting involve no judgement, so they can be handed to an agent given read-only access.

A change I did not make has appeared. How do I find the cause?

In Google Ads, the source field on the change event tells you whether it was a person, auto-applied recommendations, or an automated rule. Looking at the user field as well tells you whether it was someone else with access to the same account. If auto-apply is the cause, check the settings and separate the recommendation types you keep from the ones you turn off.

Summary

Ad platforms’ change histories keep what was changed, when and by whom. Google Ads offers two years in the UI and 30 days via the API, Yahoo! JAPAN search ads 365 days, and Meta Ads can be checked through the activity history in Ads Manager. What is not kept comes to four things: the reason for a change, the set of things changed together, a decision not to change, and a timeline across platforms. In the public posts, too, the real problem was not whether a history existed but reasons disappearing at handover and being unable to isolate a cause.

Build your own record by adding the columns the platform history lacks, and keep it append-only without rewriting past rows. Reconcile it against the platform history once a week and you will see changes you forgot to log and changes someone else made, such as auto-apply. Collection and reconciliation run on read-only access, so handing them to an agent opens no room for writes. Only filling in the reason column stays in human hands.