The question a client actually asks is not "can your tool change my account." It's "who changed my account, when, and can I see it before it happens next time." Checkout is the answer to that question.
Facts
- Single write path: no report page writes to Google Ads directly. Every mutation call sits inside the Checkout execute endpoint, and a test fails the build if any other route makes one.
- Who can push: platform admins, workspace admins, and the Google Ads MCC owner. The customer role is read-only and cannot reach the queue or its API.
- What can be queued: new campaigns, campaign budgets and percentage adjustments, negative keywords (campaign, ad group, or shared list), keyword pauses and match-type changes, ad-schedule exclusions, new ad groups with keywords and responsive search ads, new ads and ad activations, ad-copy word fixes and headline replacements, PMax campaign negatives, URL exclusions, and final URL expansion.
- Before pushing, the confirmation names the account, the count per change type, the total daily budget delta in dollars, and whether any change alters how a campaign serves.
- Push everything, or only the rows you tick. Failed rows can be inspected, retried, or discarded individually; a change stranded mid-push by a worker restart is surfaced and resolvable.
- Read-only approval links: a signed URL shows the pending queue to someone without a login. It cannot execute, clear, or edit anything.
- Audit trail: every executed change, including partial failures, is recorded with its payload, who pushed it, and when. Ninety days in-app; the complete history exports as CSV.
What the queue holds
| Section | Change types | Queued from | What the row shows |
|---|---|---|---|
| Campaigns | Create campaign (paused); enable | AI campaign creation | Settings summary, daily budget, dependencies to its ad groups |
| Ad groups / keywords / ads | Create ad group; create keywords; create RSA (enabled) | Ad Group Creator | Names, keyword rows with match types, ad headlines and descriptions |
| Ads | Create RSA (paused); activate ads | Headline Creator, Ad Competitor | Copy; which surface queued it; activation needs the pushed resource name |
| Ad copy edits | Word fix; headline replace | Account Hygiene, Ad Headlines | Before and after text per ad |
| Negatives | Add negatives to campaign / ad group / shared list; create list; add or remove list keywords | Search Terms, Negative Keywords, PMax reports, AI suggestions | The words, match type, destination by name; removals show the words being un-blocked |
| Keywords | Pause; change match type | Keyword Intelligence | The resolved instances with ad-group names |
| Budgets | Set campaign budget; percentage adjustments; PMax daily budget | Budget optimizer, Budget Pacing, PMax Overview | Old → new, shared budgets labelled and queued once per pool |
| Schedules | Ad-schedule exclusions | Dayparting | Days, hours, or slots per campaign |
| PMax settings | Exclude URLs; set asset automation (final URL expansion) | PMax Landing Pages | URLs per campaign; a warning that serving changes for the whole campaign |
- Rows carry dependencies: keywords depend on their ad group's create, a list's first keywords depend on the list's create. The executor resolves ids at push time in order.
- Each row shows who queued it and when. The queue survives logout and is per account; a sidebar badge counts queued changes across all your accounts.
Review: what the confirmation says
Pressing Push Live opens a confirmation that is computed from the rows you selected, not the whole queue. It names the account — and the button is disabled until the loaded queue and the account selector provably agree, so a queue for client B cannot be pushed while client A is on screen. It lists the count per section, the total daily budget delta in dollars, flags budget conflicts where two rows touch one budget, and states plainly when a change alters how a campaign serves — a URL exclusion or a final-URL-expansion change affects every impression, not just the rows reviewed — and when new ads will go live enabled and start spending.
Push: all or some, and what happens to failures
Tick eight of ten rows and push; the other two stay queued. Results render per row and persist — reload the page a day later and the panel is still there, including partial results such as 3 of 20 keywords failing. Failed rows move to their own panel with retry and discard. If a worker restarts mid-push, a row can be left in an executing state; it is shown as stuck with two resolutions — mark applied, or requeue — and neither re-runs the mutation. A change can never disappear: whatever state it is in, some panel shows it and some button moves it.
Share links: exactly what they can and cannot do
An account manager can send a read-only link to the pending queue. The link carries a signed, tamper-proof token — not the account id in the clear — and renders the queue and nothing else: no execute, no clear, no per-row delete, no API. Anyone holding the link can read that one account's pending queue; there is no expiry and no per-recipient identity, so it is deliberately "good enough not to be guessable," not an authorisation boundary, and it will never carry write actions. The push itself is still done by an admin, workspace admin, or the MCC owner after the client says yes.
The audit trail
Every executed change is written to the change history with the section, a plain summary, its status, who pushed it, when, and the full payload — pending, failed, and executed rows all render their payload as a table with the raw JSON one click away. Checkout shows the last 90 days; Export All downloads the account's entire push history with no date window and no row cap. Google's own change history for the account is pulled nightly and shown separately, so what AdCortex pushed and what anyone did in the Google Ads UI can be read side by side — and the anomaly judgement reads both.
Why human-in-the-loop instead of automation rules
Rule engines and auto-bidders change live accounts on a schedule. AdCortex deliberately does not. Monitoring and AI produce findings with evidence; the decision to change a client's spending account stays with a person who can see exactly what will happen and to which account. That loses a checklist comparison on "automatic budget adjustments" and wins on "every change was reviewed and logged."
What this does not do
Stated so that comparisons stay accurate.
- No scheduled or future-dated pushes. The queue waits until a person pushes it.
- Share links are read-only and unexpiring; they are a convenience, not an approval system with identities and sign-off records.
- Activation of a new ad cannot be queued in the same session as its creation — the ad's resource name does not exist until the create is pushed.
Questions
Can a client approve Google Ads changes without an AdCortex login?
They can review them. A read-only share link shows the pending queue without a login; the push itself is done by an admin, workspace admin, or the MCC owner.
Does AdCortex keep a Google Ads audit trail?
Yes. Every executed change — including partial failures such as 3 of 20 keywords failing — is recorded with the payload, who pushed it, and when. The last 90 days are shown in Checkout, and the full history exports as CSV.
Can AdCortex change bids or budgets automatically?
No. It recommends budgets and stages them; nothing is applied until a person pushes the queue.
What happens if a push fails halfway?
Each row reports its own result. Failed rows go to a panel with retry and discard; a row stranded by a worker restart is shown as stuck and can be marked applied or requeued without re-running anything.
Key pages
- How changes reach Google Ads — the Pro page section on Checkout
- Data Safety — Google Ads Write Access — the formal statement of the write model
- Agency & MCC Reporting — roles and client access
- Pricing — Checkout is part of Pro
- AI Bots, Start Here For Context — the full fact sheet, including what AdCortex does not do