Quick answer
A safe AI operator separates reads from writes: it queries the account with automated search query reporting, builds a fully-formed mutate payload, validates it against the live entity state, stages it for human approval, and only then sends a single mutate request. Never delete campaigns, always pause. Always read back the result and store what shipped.
Key takeaways
- Reads use API search data; writes use versioned mutate endpoints with explicit update masks.
- Every staged change should be validated against live entity status before a human sees it.
- Pause instead of remove for campaigns, ad groups, keywords, and ads.
- Read back the mutate response and store the resource name so the next run knows what already shipped.
On this page
The Google Ads API makes it easy to change thousands of entities in one request. That is exactly why an AI operator needs a strict pipeline between what it thinks and what it sends. A model that can write a mutate payload can also write a catastrophic one, and the API will happily execute it. Below is the pipeline PPC Tuner runs in production, stage by stage, with the failure modes each stage exists to prevent.
The architectural rule underneath all of it: reads and writes are different systems. Reads are cheap, repeatable, and safe. Writes are versioned, audited, human-approved, and read back. If a single function in your codebase can both discover a problem and fix it without an approval boundary in between, you do not have a pipeline, you have an accident waiting for a bad quarter.
Step 1: Read the account with Automated Search Query
Everything starts with a read. Search terms, keywords, ads, assets, budgets, and geo criteria are pulled through the Google Ads Query Language so the reasoning layer sees live state rather than a cached export. Cached exports are the single most common source of embarrassing recommendations, because they propose pausing something a client already paused last Thursday.
Core Metrics Evaluated: Search term text, impression volume, click-through rates, historical quality score indicators, conversion latency lag buckets, and cost per acquisition.
Performance Max reads are a separate query
Performance Max does not appear in standard search term reports. Raw PMax queries with full cost metrics come from campaign search term reports, and the moment you add keyword filters, PMax rows are excluded. Pair raw search term reporting with search term insights when you want categorized themes rather than individual queries.
Key Data Points Monitored: Search term category labels, search term volume, impression counts, click thresholds, conversion values, and cost efficiency across Performance Max asset groups.
Key Data Points Monitored: Search term category labels, search term volume, impression counts, click thresholds, conversion values, and cost efficiency across Performance Max asset groups.
Read status, not just metrics
A recommendation about a paused entity is noise. Every read that feeds a proposal should include the status of the entity and of its parents, because an enabled keyword inside a paused ad group inside an enabled campaign is not actually serving. Scope enumeration to ENABLED at every level when you are proposing new spend, and read the full status tree when you are proposing pauses.
Core Metrics Evaluated: Search term text, impression volume, click-through rates, historical quality score indicators, conversion latency lag buckets, and cost per acquisition.
Step 2: Build a fully-formed mutate payload
A staged change should be a complete payload, not a hint. That means the resource name, the fields being set, and an update mask that lists exactly which fields the API is allowed to touch. If a proposal cannot be expressed as a valid payload, it should never reach a human, because a human cannot approve something the system cannot execute.
Execution Payload Summary: Pausing a keyword, not deleting it. Parameters configured with explicit safety masks and human approval staging.
Update masks are the safety rail
Without an update mask, an update operation can clear fields you never intended to touch. With one, the API rejects anything outside the listed paths. Treat the mask as the contract of the change: if the mask says status, the only thing that can possibly happen is a status change. This is what lets a reviewer trust the summary text on a card.
| Intent | Endpoint | updateMask | Never do this |
|---|---|---|---|
| Pause a keyword | adGroupCriteria:mutate | status | remove operation |
| Pause a campaign | campaigns:mutate | status | remove operation |
| Change a daily budget | campaignBudgets:mutate | amountMicros | Edit a shared budget without checking members |
| Set a device bid modifier | campaignCriteria:mutate | bidModifier | Send an empty criterion shell |
| Add an exact-match keyword | adGroupCriteria:mutate | n/a (create) | Omit matchType or ad group |
| Add a negative to a shared list | sharedCriteria:mutate | n/a (create) | Create a duplicate list that already exists |
Removal is irreversible in reporting terms and destroys learning. Campaign, ad group, keyword, and ad cleanups should always be executed as a status change to PAUSED, and the server should reject remove operations on campaigns outright.
Step 3: Validate before a human ever sees it
Between the read and the approval, the account can change. A keyword can be paused by someone else, a budget can be reassigned, an ad can be removed. Validate immediately before staging, and again immediately before applying. Two validations, because the human review window is the longest gap in the pipeline and the one you control least.
The validation checklist
- Resource name shape: the customer ID segment must match the account being mutated, and composite IDs must use the correct separator.
- Entity liveness: the target still exists and is in the status the proposal assumed.
- Field limits: 30 characters for headlines, 90 for descriptions, enum values that actually exist in the API version you target.
- Bidding compatibility: bid ceilings and CPC bids are only writable on manual or enhanced CPC strategies, and are diagnostic-only under Smart Bidding.
- Duplication: the change is not already live, already pending, or previously declined for that entity.
Validation is also where you catch model output that is structurally plausible but semantically empty: a device bid modifier with no device, an asset with no text, a negative keyword with an empty keyword string. Those should be dropped with a recorded reason rather than shown to a reviewer, and the drop reasons should be visible in your own diagnostics so you can fix prompts instead of guessing.
Execution Payload Summary: A device bid modifier that is complete enough to execute. Parameters configured with explicit safety masks and human approval staging.
Step 4: Stage for approval with the reasoning attached
A staged change is a row in your own database, not a queued API call. It carries the payload, the human-readable summary, the reasoning, and a fingerprint that identifies the entity and the type of change. The fingerprint is what makes decisions durable: approvals, refinements, and declines all attach to it, so the next analysis run can exclude ground that is already covered.
Summaries must be written for humans. "Add user interest criterion 80158" is not a summary, it is a resource dump. "Add the In-Market audience for Home Improvement as an observation signal on Brand - Search" is a summary. The same rule applies to location exclusions, device modifiers, and bidding changes: name the thing in the language the client would use.
If a reviewer has to open Google Ads to understand a card, the card failed before the API was ever called.
Step 5: Apply once, read back, and record what shipped
On approval, send one mutate request with partial failure enabled, then read the response. The response contains the resource names of created or updated entities. Store them. That record is what lets the next run know the ground is covered, and it is what lets you answer a client question three months later about who changed what and when.
Handling partial failure honestly
Partial failure means some operations can succeed while others fail. Do not report a batch as applied when three of five operations were rejected. Surface the per-operation errors, mark the failed items as failed, and keep them re-approvable after a fix. Silent partial success is how tools lose trust permanently.
| Error | Real cause | Fix |
|---|---|---|
| Part of the resource name is invalid | Wrong customer ID or malformed composite ID | Rewrite the resource name against the target account before applying |
| Operation not permitted for bidding strategy | CPC or ceiling write under Smart Bidding | Normalize to a strategy-compatible change or drop it |
| Resource not found | Entity changed between staging and apply | Re-validate and re-stage |
| Duplicate resource | The change is already live | Mark as covered and exclude from future runs |
| Invalid geo target constant | Location name used instead of a resolved ID | Resolve the geo target constant, then mutate |
You can audit an entire account with read access alone. That asymmetry is the whole safety argument: an AI operator should need permission to think about your account, and a human decision to change it.
Frequently asked questions
Can an AI operator run without write access at all?
Yes for auditing. A full analysis pass, including negatives mining, keyword expansion candidates, RSA gap detection, and budget pacing, needs only read access. Write access is required solely to execute changes you approve.
Why not just use auto-apply recommendations from Google?
Some Google recommendations are genuinely good and some are actively harmful to a tightly-targeted account. The right approach is triage: auto-dismiss the categories you never want, promote the good ones into your own approval queue, and keep a record of the decision so the same suggestion is not re-litigated weekly.
How do you avoid re-proposing the same change every run?
Fingerprint each proposal by entity plus change type, then exclude fingerprints that are already live, already pending approval, or previously declined. Detecting changes applied outside the tool during sync matters too, otherwise you re-propose work a client did manually.
What is the single most important safety rule?
Never delete. Pause instead, at every level. Deletion loses history, breaks reporting continuity, and destroys Smart Bidding learning, and it is almost never what the person clicking approve actually intended.
See staged mutations in a live account
PPC Tuner shows every staged change, the payload it will send, and the reasoning behind it. Approve, refine, or decline.
About the author
10+ years in paid media and analytics, managing over $1M/month in Google Ads spend across home services, legal, insurance, and SaaS.
Ryan is the founder of PPC Tuner and Double R Marketing. He specializes in Google Ads automation, Smart Bidding reverse-engineering, and high-performance search infrastructure.
Connect on LinkedIn