“Optimized your campaigns” is a status message, not an audit trail. When performance changes or a client asks what happened, the team needs to know which setting changed, who authorized it, and whether the advertising platform accepted the action.
A useful change log also avoids the opposite problem: dumping thousands of tool messages into a report and expecting a client to interpret them. Keep the operational record detailed, then summarize it in plain language for the people who need to make the next decision.
Keep five states separate
An advertising action moves through several states that should not collapse into a single green check mark.
- Proposed: an operator described a possible change.
- Authorized: the appropriate person or policy permitted that exact change.
- Attempted: the system sent a request to the advertising platform.
- Confirmed: a readback established the resulting platform state.
- Evaluated: enough time and evidence were available to assess the outcome.
A rejected proposal never becomes an attempted action. A timed-out request might still have changed the account. A confirmed budget update does not prove improved revenue. Keeping those distinctions visible makes both reporting and recovery more reliable.
The minimum record for one action
Use this worksheet as a starting point. Adjust the detail to the consequences of the change.
| Field | Purpose |
|---|---|
| Action identifier | Connect the proposal, approval, execution, and review |
| Platform and account ID | Establish where the action belongs |
| Campaign or asset IDs | Identify exactly what can change |
| Previous state | Capture the value against which approval was given |
| Proposed state | Make the requested change reviewable |
| Reason and evidence window | Explain the business hypothesis |
| Authorization | Identify the approver or active policy |
| Attempt time and response | Record the request and its known result |
| Verification time and state | Confirm what the platform now shows |
| Outcome review date | Prevent premature performance conclusions |
The identifier should remain stable as the action progresses. If the proposal changes materially, create a revised proposal with its own authorization rather than silently changing the approved record.
A worked budget-change example
Consider an illustrative campaign with an average daily budget of $80. The operator proposes $100 after reviewing a mature reporting window and the remaining monthly plan. The budget owner approves the $20 increase for that named campaign.
A useful human-readable entry might say:
Proposed a change from $80 to $100 for Campaign A. The budget owner approved it at 10:10. The platform accepted the request at 10:12, and a fresh read showed $100 at 10:13. Performance review is scheduled after the account's ordinary conversion delay. No performance conclusion has been recorded yet.
The underlying record retains the account and campaign IDs, the evidence snapshot, and the provider response. The summary preserves the decision without exposing credentials or unnecessary customer information.
If verification instead showed $90 because another buyer made a concurrent change, the entry should say that the expected state was not confirmed. Do not rewrite history to make the final number match the original proposal.
Use platform history as corroborating evidence
Your own log explains intent and approval. The advertising platform's history helps establish what actually happened. These records serve different purposes.
Google Ads change history can show account changes and their relationship to performance timelines. API-originated changes may appear under the API or a tool identity. A platform history entry still does not capture every internal business assumption behind a recommendation, which is why your own decision record remains useful.
During reconciliation, match the account, object, setting, value, and time. Treat a timestamp difference as something to explain through timezone and processing behavior rather than immediately declaring a missing action. If the records disagree, preserve both until the discrepancy is resolved.
Record partial success explicitly
Bulk changes need item-level results. “Twenty ads submitted” does not mean twenty ads were created, approved for delivery, or started spending.
The Google Ads API partial-failure documentation describes requests where successful operations can commit while failed operations return errors. Support varies by method. The operational lesson is to retain individual outcomes rather than assign one status to an entire batch.
For example, a batch could contain twelve confirmed updates, two rejected items, and one item whose final state remains unknown after a connection failure. The next step is to reconcile the unknown item and investigate the failures. Blindly replaying the whole batch can make the record harder to interpret and may repeat work that already succeeded.
Include decisions to wait and decisions to reject
A change log should also preserve important non-actions. A buyer who rejects a proposed creative because the product claim lacks support is making an operational decision. An agent that waits for delayed conversions is choosing not to optimize from incomplete evidence.
Record the reason and the condition that would reopen the decision. “Waiting for the nightly qualified-lead import” is actionable. “Insufficient data” without a date, source, or next check is not.
Do not log every trivial observation at the same level. Reserve the decision record for changes, proposed changes, meaningful holds, and exceptions. Raw system diagnostics can remain in technical logs with access appropriate to their contents.
Review outcomes without inventing causality
When the review date arrives, append the observed result and the context. If CPA improved after a budget change and a new promotion launched at the same time, say both. A favorable trend following a change does not isolate its effect.
An outcome entry can be “inconclusive.” It can also say the action achieved an operational objective, such as removing expired copy, even if no performance effect was measured. Operational correctness and revenue impact are different questions.
Use the log in a weekly review to identify repeated weak assumptions, unnecessary actions, and unresolved verifications. Connect it to the emergency stop runbook so an incident responder can see what changed most recently. The log earns its place when a teammate can reconstruct an action without guessing what “done” meant.