Google Ads API Optimization: A Safe AI-Assisted Workflow

You have a Google Ads performance question, but answering it means choosing fields, writing GAQL, handling authentication, and turning the result into something the team can review. AI assistance can remove much of that technical friction. It cannot decide whether broader reach, a higher bid, or a new keyword strategy makes financial sense for your business.

The useful approach is to separate observation from action. Use the Google Ads API Developer Assistant to investigate performance through read-only queries, validate what it returns, and save repeatable analysis. Put any change to budgets, bids, targeting, or keywords through a deliberate human approval process.

Separate faster analysis from automated optimization

Google Ads API Developer Assistant v1.0 is a Gemini CLI extension that can translate natural-language requests into GAQL, answers, and Python code built around the google-ads-python client library. This makes it useful when you understand the business question but do not want to reconstruct every query from memory.

The assistant can also execute read-only API calls from the terminal, display results in formatted tables, export tabular data to CSV, and place generated code in a saved_code folder. Those capabilities shorten the path from a question to an inspectable result.

That is analysis assistance, not an optimization strategy. A table can show which campaign recorded the most conversions. It cannot determine whether those conversions were valuable, whether lead quality deteriorated, or whether the campaign consumed more budget than the outcome justified. Those judgments depend on business definitions and constraints that sit outside a generic performance query.

Keep the boundary explicit: the assistant retrieves and organizes evidence; an accountable person decides what the evidence means and whether the account should change.

Key takeaways

• Begin with reporting and diagnosis. Do not treat generated output as permission to change the account.
• Include the account scope, date range, dimensions, metrics, filters, sort order, and desired output in every request.
• Review generated GAQL and Python as untrusted code before running or reusing it.
• Treat Google Ads Recommendations as hypotheses to investigate, not instructions to accept.
• Keep changes to budgets, bids, targeting, and keywords behind human approval and a defined rollback path.

Ask questions that lead to decisions, not just reports

A vague request such as analyze my campaigns leaves too many choices to the assistant. It does not identify the problem, the period, the level of detail, or the decision you need to make. The result may be technically valid and still be operationally useless.

Start with the decision. If you are deciding where to investigate a conversion decline, ask for a result that isolates campaign performance over a named period and includes the metrics needed to distinguish lower volume from higher cost. If you are checking a Google recommendation, request the evidence that would support or contradict its underlying claim.

Use this prompt pattern: Within [account or campaign scope], for [date range], return [dimensions] and [metrics]. Apply [filters], sort by [metric], and provide [GAQL, Python, a terminal table, or CSV]. Explain the row grain, field choices, and assumptions before the result.

Each part prevents a common analytical mistake:

• Scope prevents a manager account, client account, campaign type, or status from being included unintentionally.
• Date range makes the comparison reproducible. Relative periods are convenient for exploration, while explicit periods are easier to audit later.
• Dimensions determine what one row represents. Adding a date, device, or other segment can change the grain and produce many rows for a campaign.
• Metrics determine whether you can connect activity to a business outcome. A ranking by conversions alone does not show the cost or value behind those conversions.
• Filters remove irrelevant entities, but an overly narrow filter can hide the reason performance changed.
• Output determines whether you get an explanation, a reusable query, executable code, or an artifact another person can inspect.

Prompts you can adapt

• For the previous 30 days, rank campaigns by conversions. Return the GAQL first, explain the selected fields, and then produce a read-only Python script using google-ads-python.
• Compare campaign cost and conversion performance across two explicitly named periods. Show the row grain and flag any filter that excludes paused or removed entities.
• Generate a read-only query that provides evidence for or against a recommendation to expand keyword matching. Separate the requested output by campaign so the account owner can review exposure and outcomes.
• Run this approved query, display a terminal table, and export the same rows to CSV. Include the account scope and date range in the output description.

The first example closely matches a documented use case: a request for campaigns with the most conversions in the last 30 days can produce both a GAQL query and an optimized Python script. The important addition is the review instruction. You want to see what the assistant plans to ask the API before you rely on the answer.

Inspect five things before execution: the customer being queried, the dates, the row grain, the filters, and the metric definitions. Then look for a sanity check. Compare a small part of the result with a familiar Google Ads view or an existing trusted report. A plausible table is not proof that the query answered the question you intended to ask.

Configure Developer Assistant v1.0 for repeatable work

The documented prerequisites for v1.0 include a Google Ads API developer token, a configured google-ads.yaml file, Python 3.10 or later, Gemini CLI, and a local clone of the google-ads-python library. A setup script handles the library cloning step.

Do not stop once the assistant returns its first successful table. A useful setup makes the same request behave consistently for different operators and on different days.

1. Validate the connection with a known read-only question. Choose a result you can verify in the Google Ads interface. This separates authentication or account-scope problems from query-design problems.
2. Define project conventions in GEMINI.md. The assistant uses GEMINI.md and configuration files as project context when tailoring code. State the expected client library, output conventions, code location, naming rules, and read-only default.
3. Require an explanation before execution. Ask for the GAQL, selected resources, filters, dates, and row grain in plain language. A reviewer should be able to understand the intended request without reverse-engineering the code.
4. Keep credentials out of prompts and generated files. Use the supported configuration mechanism. Review saved files before sharing them or adding them to version control.
5. Review generated Python before running it. Check imports, customer selection, request type, file paths, exception handling, and whether the code does anything beyond retrieval and export.
6. Preserve a verified query as a smoke test. Run it after configuration or dependency changes. If its known output or shape changes unexpectedly, investigate the environment before trusting new analyses.

Project context is leverage. Good instructions make repeated analysis more consistent; incorrect instructions make the same mistake repeatable. Keep GEMINI.md short enough to review, specific enough to guide the assistant, and under the same change-control discipline as other project configuration.

The saved_code folder is most valuable when it becomes a reviewed library rather than a dumping ground. Give each retained script a clear purpose, record its account scope and required inputs, and distinguish experimental output from approved reporting code. Remove ambiguity before another person schedules or modifies it.

Turn Recommendations into an evidence-backed test queue

Google Ads Recommendations are prompts to evaluate. They are not proof that the proposed change fits your economics. A suggestion may be informed by patterns across accounts while missing a constraint that matters in yours. For example, an account using Exact and Phrase match keywords may receive a Broad Match suggestion even when its budget or niche requires tighter control.

The Optimization Score is easy to misread as a performance grade. It reflects how recommendations are being handled, and dismissing a recommendation can affect the score in the same way as applying it. You do not need to accept an unsuitable change merely to clear the prompt or improve the displayed score.

Use the API assistant to build an evidence packet for each recommendation:

1. Restate the claimed problem. Is the recommendation trying to expand reach, improve efficiency, repair setup, or remove a limitation?
2. Request the relevant account evidence. Define the entities, period, metrics, and filters that would show whether that problem exists.
3. Write down the business constraint. Include budget limits, acceptable lead quality, geographic restrictions, inventory realities, or other rules that the platform cannot infer reliably.
4. Set success and failure criteria before making a change. Decide what result would justify keeping the change and what result would trigger reversal.
5. Choose a reversible test. Limit the blast radius and preserve the prior state so the account can be restored if performance or traffic quality deteriorates.
6. Assign an owner. One person should approve the change, monitor the agreed evidence, and decide whether to keep or roll it back.

Auto-apply deserves stricter treatment because it can remove that review gate. The documented control path is Recommendations, All Campaigns, and Auto-Apply Settings, where you can confirm that unwanted selections are unchecked. Check the setting at the account level instead of assuming that an earlier choice still reflects current policy.

This is a financial control, not interface housekeeping. Automatically applied suggestions can affect reach, spending, bids, or keyword behavior. Enable a category only when you have defined who owns it, what changes it permits, how the effect will be monitored, and how the prior state can be recovered.

Do not give every interface notice the same urgency. Blue or yellow notices can represent suggestions, while red or purple notices can indicate issues such as billing errors or disapproved ads. Investigate actual delivery or account-access problems before spending time on an optional optimization prompt.

Run one controlled loop from question to verified change

A reliable optimization process leaves a trail from the original question to the final decision. It should be possible for another person to see what was queried, what came back, why a change was approved, and whether the expected result appeared.

1. Name the decision. Write the question in a form that could change an action: which campaigns need investigation, whether a recommendation deserves a test, or where a recurring report shows an exception.
2. Specify the evidence. Add account scope, dates, dimensions, metrics, filters, and output format to the prompt.
3. Generate before executing. Read the proposed GAQL and code. Correct ambiguous fields, unintended segments, and overly broad scope.
4. Run read-only. Display the result in the terminal and export CSV when another reviewer or a longer audit trail is needed.
5. Validate the result. Compare a small slice with a trusted interface view or established report. Confirm that each row represents what you think it represents.
6. Form a testable explanation. State what appears to be happening, what evidence is still missing, and which reversible change could test the explanation.
7. Approve and implement separately. Use your normal controlled account-management process for changes. Do not turn generated analysis code into mutation code simply because the first output looked correct.
8. Run the same query again. Reuse the reviewed query so the before-and-after comparison is based on the same scope, fields, filters, and row grain.

Label saved queries and exports with enough context to make them interpretable later. At minimum, preserve the account scope, analysis period, purpose, and important filters alongside the artifact. A file called campaign_report.csv creates less accountability than an export tied to a specific question and approved query.

Automate stable retrieval only after the query has survived review and repeated validation. Keep recommendations and account mutations gated. The cost of manually approving a consequential change is small compared with the cost of allowing a misunderstood prompt, broad filter, or unsuitable recommendation to alter spend without supervision.

Start with one recurring question your team currently answers by hand. Define it precisely, run it read-only, verify the output, and retain the approved query. Once that loop is dependable, add the next question. The real efficiency gain comes from reusing trusted analysis while keeping financial decisions under human control.

References

• Search Engine Land – Google launches natural language developer assistant for Google Ads API
• Search Engine Land – Google Ads Recommendations and auto-apply