Insights / Paid media operations
Google Ads Change History: A Weekly Review Workflow
Use Google Ads Change history to investigate performance shifts, connect platform edits with team decisions, and document approvals and rollbacks.
Start with a change in behavior you can describe
Google Ads Change history helps marketing operators investigate what changed in an account and when. It becomes especially useful when delivery, spending, or reported outcomes move unexpectedly. Begin with a specific observation, such as a campaign receiving fewer impressions after a particular date, then review the account changes that could explain it.
This workflow combines the platform record with a team decision log. Change history is a diagnostic source with limits on coverage and available detail; timing alone does not establish cause, and the workflow promises no performance outcome. Use the records to build and check explanations against the affected settings and business context.
Use Change history to establish the account timeline
Change history records account, campaign, and ad group changes. It can help identify events such as a paused campaign, a keyword edit, or a budget adjustment. Review the relevant date range and narrow the scope by campaign, ad group, or change type to locate entries connected to the observed behavior.
Inspect the recorded actor or source along with the timestamp. Changes can come from people and from tools or automated systems. If the source represents a tool, use the team's automation records to identify the responsible process and its business owner.
Capture the affected entity identifier, available before and after details, and a reference to the entry. Pair that record with a fresh check of the current setting. A later edit may have changed the same field again, so the investigation needs both the sequence and the current state.
Define the performance question before searching for a cause
Write the observation in measurable terms: which campaign or offer changed, which metric moved, when it began, and what comparison period is being used. Check that the period is complete enough for the metric and that the reporting definition stayed consistent.
Then assemble plausible explanations. For a delivery shift, inspect relevant status, budget, targeting, keyword, and bidding changes. For a change in recorded outcomes, include measurement changes and conversion timing in the investigation. Ask the website and operations owners about events outside the advertising account, such as a destination release, stock problem, or service interruption.
Review an interval that starts before the observed shift. Keep time zones explicit when combining platform entries with website releases or team messages. The earliest visible symptom may occur after the setting change, particularly when business outcomes take time to arrive.
Work through a hypothetical budget investigation
In a hypothetical B2B software account, an operator notices spending rising in one inquiry campaign. Change history shows that the campaign budget changed from a hypothetical $30 to $50 per day during the review period. The team log explains that the increase was intended to support a product launch.
The reviewer checks the account's current budget, the exact campaign identifier, and whether any further budget or bidding changes followed. The product owner confirms the launch dates, while the analyst compares spending and qualified inquiries over a period appropriate for the sales process.
The record gives the team a concrete sequence to evaluate: an approved allocation change, its saved implementation, and the behavior observed afterward. The next action depends on that launch plan and the mature outcome data. The reviewer records the decision and the date for its next check.
Let the team log explain why the edit happened
The platform record helps establish the saved edit. The team log should explain the business reason, proposed scope, approval, expected behavior, and follow-up. Give each material change a stable reference that can appear in the task, approval record, and review notes.
Use identifiers as well as human-readable names. Names can change during maintenance, while an investigation may need to trace an earlier campaign or ad. Save the old and new values for the relevant fields and identify dependencies that affect recovery.
Keep the log concise enough that operators will maintain it. Routine work can use a consistent short entry; a material budget, targeting, measurement, or automation change needs enough detail for another person to evaluate the scope. Link internal evidence within the team's authorized working environment.
| Record | What to capture | Why it matters |
|---|---|---|
| Request | Business reason, affected IDs, and proposed scope | Explains the decision behind the edit |
| Approval | Approver, date, and any conditions | Shows the authorized action boundary |
| Implementation | Operator or process, time, and before and after values | Connects the plan to the saved setting |
| Verification | Readback result and relevant delivery checks | Records what was actually confirmed |
| Recovery | Previous values, dependencies, trigger, and recovery owner | Prepares a controlled correction |
| Follow-up | Business question, outcome evidence, and review date | Keeps evaluation connected to the original reason |
Review weekly changes in a consistent order
Use the weekly review to reconcile the team's intended work with the account record. Give unexplained entries an owner and a due date while continuing the rest of the review.
- Set the account scope, review interval, time zone, and relevant performance observations.
- Collect material Change history entries and match them to team requests or recurring operating tasks.
- Check affected IDs and available before and after details against the current account settings.
- Identify unexpected users, tool activity, missing approvals, or changes outside the intended scope.
- Compare observed behavior with the reason for each material change, accounting for concurrent business events.
- Assign corrective work or further investigation, preserving the relevant evidence and previous values.
- Update each change record with the decision, owner, verification status, and next review date.
Give recurring automated work a named owner and an expected scope. When its entries look unfamiliar, inspect the job's schedule and configuration before deciding what to change. Capture any approved adjustment in the same operating record.
Make approval and rollback records specific
Before a material edit, record the exact target, fields, intended values, and reason. Name the approver where the team's policy requires one, then have the operator verify the saved state. Track proposed, approved, applied, and verified as distinct stages so a completed request has a clear meaning.
Plan recovery around the current account state. Change history supports undo for eligible changes, and the availability depends on the change and related account state. A grouped entry may reverse several edits together. Inspect the full scope before using that option.
For a manual correction, read the current values and compare them with the preserved previous values. Check whether later approved work depends on the changed configuration. Record the correction as a new action with its own reason, operator, timestamp, and readback. Then schedule the delivery and outcome checks appropriate to the issue.
Work through a hypothetical targeting correction
In a hypothetical home services account, a weekly review finds that a campaign's service area expanded during a bulk edit. The team log authorized a wording update but contains no matching coverage change. The service manager confirms that the added area is outside the current operating plan.
The operator records the affected campaign and current locations, checks later changes, and prepares a correction to the approved service area. The appropriate owner approves the scope, and the operator applies it and reads back the saved settings. If the original entry grouped the targeting edit with other valid changes, the operator evaluates those dependencies before selecting a recovery method.
The follow-up log includes the configuration correction and a later review of delivery by the relevant geography. It also assigns a separate process improvement: add service-area readback to the checklist used for that kind of bulk edit.
Common mistakes that interrupt the investigation
Searching only for the most recent human edit can miss relevant automated activity or an earlier setting change. Another mistake is checking only campaign names and overlooking renamed entities. Use a timeline, identifiers, and current values together.
Reversing a broad group of changes before inspecting its contents can undo valid work. Reconstruct the dependency sequence and choose a recovery scope that matches the actual issue. Keep the recovery record connected to the original request.
Finally, filling the team log with copied platform entries leaves the commercial reasoning missing. Add the purpose, owner, approval, and follow-up that make the record useful to the next reviewer.
Leave a traceable decision for the next operator
Use Change history to reconstruct the account timeline, then connect each material edit with the team's intent and a current readback. Review unexplained changes, preserve recovery details, and close the loop on approved work. The resulting record should let another operator understand what changed, why it changed, and what needs attention next.