Google Ads reporting without GAQL: what to ask and what to check

Separate the business question from the query syntax

A marketing manager may know exactly which decision needs support without knowing how Google names the corresponding API fields. The question might be whether spend shifted toward one campaign, how purchase results changed over a period, or how many enabled groups contain a particular setting. Writing a query is an implementation step. Defining the question is the business work that comes first.

Reporting without GAQL means the user does not have to assemble provider clauses for ordinary supported questions. It does not mean the account can be interpreted without a report definition. A conversation still needs the source, relevant population, measure, period and requested detail. Those choices can be expressed in normal language and translated into a validated read behind the interface.

This division is useful for teams with different skills. An analyst may understand the business measurement deeply while rarely working with the API. A technical colleague may understand field compatibility but need help deciding which conversions count as a lead. The reporting workflow should preserve both kinds of knowledge. Removing syntax from the user experience should make the task accessible without hiding the definition.

ppctor uses a general reporting framework with discoverable fields, business measurements, validated plans and source adapters. Its role is to connect the requested definition to available account data and suitable presentation. This guide explains the decisions that remain important when the user no longer writes the query themselves, and the checks that make the returned answer useful to a colleague reviewing it later.

Understand what GAQL normally contributes

GAQL is Google's query language for Google Ads API reporting. A query specifies what information to select, the resource to report from, any conditions, ordering and other supported clauses. Google's query-structure documentation explains how those clauses form a provider request. A conversational interface can construct the appropriate read without asking the user to type those clauses.

Each part corresponds to an ordinary reporting choice. The selected fields describe what you want to see. The resource describes the reporting level. Conditions describe the population and period. Ordering describes a ranking. A row limit describes the requested presentation or query bound. Understanding those ideas is helpful even if the user never sees the technical syntax, because they explain why a vague question can have several possible answers.

The distinction also helps identify mistakes. A campaign total and a daily campaign report have different row structures. A filtered ranking and a full-account total have different populations. A list of enabled assets and a performance report over a historical window answer different questions. A model should not change one into another simply because the fields look related or because a compact reply is easier to produce.

There is no need to memorize query keywords to inspect the resulting definition. Read the reply's source, dates, population and labels. If any of those differ from the request, correct that specific choice. The technical implementation should follow the corrected definition. This creates a practical review process for non-technical users without asking them to validate provider syntax.

Write a report brief that carries the necessary choices

A useful brief can fit in one sentence: “Show daily spend for all campaigns over the last seven completed days.” It names the measure, population, period and detail. Another brief might be: “List enabled Search ad groups in the Spring Campaign and show their primary purchase conversions for the last month.” Both establish a report without a field name or query clause.

The most common omission is the business definition. “Conversions” may be enough when the team's default population is established, but a comparison involving purchases or lead events needs more care. “Revenue” can mean primary conversion value, purchase-only value or a GA4 measure. Specify the intended outcome in business language. The framework can then choose the relevant registered measurement rather than map an ambiguous label to a convenient raw column.

Do not add a visual requirement unless you need it. A single total is often best as a concise answer. A trend needs a time breakdown, and a category comparison needs meaningful labels. A table can support review of several exact values. Presentation follows the question; it should not cause a fresh interpretation of what the data means after the provider has returned it.

When the task has several stages, begin with the first report and use a follow-up for the next stage. Asking for spend, a comparison, a new creative concept and an account edit in one sentence can obscure which part needs evidence and which part needs approval. A short sequence makes the intended definition easier to preserve and allows the user to inspect the evidence before deciding what to do.

Follow a daily-spend question through its query and answer

A fictional business, Willow Desk, asks: “Show daily Google Ads spend for September 1 through September 7.” The question concerns the account total on each day. It does not request a campaign breakdown, an enabled-only population or a comparison with revenue. The dates are illustrative, and the figures below are invented to demonstrate how a defined answer works.

SELECT segments.date, metrics.cost_micros
FROM customer
WHERE segments.date BETWEEN '2026-09-01' AND '2026-09-07'
ORDER BY segments.date ASC

This explanatory query selects account-level cost by date. Suppose the illustrative amounts are £100.00, £110.00, £90.00, £120.00, £130.00, £80.00 and £70.00. The corresponding answer is: “Spend totalled £700.00 from September 1 through September 7. September 5 had the highest daily spend at £130.00.” It should not infer a cause for that peak from the daily cost figures alone.

If the user asks for a line chart, the dates and amounts form one seven-point series. If the user asks which campaign produced the peak, the next read needs campaign detail for the relevant scope. The original account total cannot identify a campaign that was never selected. A conversational framework should recognize that additional evidence is necessary instead of making a plausible attribution.

The user never needs to type this query. It appears here to show that an ordinary sentence has a concrete reporting interpretation. Live replies need real account values, not the invented amounts used in the demonstration. When the source cannot be read, the workflow should explain that outcome rather than manufacture a completed report from the question's expected shape.

Use a catalogue of available fields instead of guessing names

A general reporting framework needs a way to discover what the source supports. The model should not invent a field because its name sounds plausible. It should consult available resource attributes, metrics, segments and reviewed business definitions, then build a plan using those entries. This is what makes the workflow extensible beyond a small collection of fixed questions.

In ppctor, field discovery can search provider metadata and registered datasets. Business measurements describe how conversions and cross-source comparisons should be selected. Settings discovery describes supported settings and relevant edit capabilities. These catalogues guide the tool selection, while the subsequent account read establishes whether the connected account actually has the requested information.

A catalogue is capability information, not a report result. A provider can support a metric even when the selected account has no matching activity. Likewise, an observed event list can help identify an appropriate GA4 event without proving what that event means on the website. Distinguish the available definition, the selected population and the returned values. Each answers a different question.

This separation reduces repeated special-case work. A user can ask for a different supported metric or breakdown without requiring a dedicated tool for that exact wording. The framework still validates the new combination. If a required field is not available on the chosen resource, the correct response is to choose a compatible level or explain the limitation, rather than bypass the catalogue with invented syntax.

Select the reporting level that matches the question

Reporting level determines what each row represents. An account total is different from one row per campaign. An ad group report is different from an individual keyword report. A query can also include attributes of related resources where the provider supports them. The choice should follow the requested question, not a habit of always downloading the smallest possible asset.

The Ads adapter seeks a resource that can select the required fields together. It prefers appropriate broad resources before moving to more specific ones, while checking compatibility. This matters for efficiency and meaning. If the question asks only for account cost, gathering every keyword and adding the rows locally creates unnecessary detail and can introduce overlap or aggregation problems.

A deeper report should carry enough parent context to identify its rows. An ad group name alone may be repeated. A keyword belongs to an ad group and campaign. Performance Max uses asset groups for its relevant structures. The normal output should show readable context without relying on raw resource names or numeric identifiers to make the row understandable.

When a field combination is incompatible, do not silently discard the inconvenient field. The user may need a different report level or two clearly separated results. A valid provider request that answers only half the question is still an incomplete answer. The conversation should explain the available choice and preserve the business intent, rather than claim that removing a field completed the original request.

Ask for the segmentation that makes the pattern visible

A segment divides the report into meaningful parts. Daily data shows movement over time. Device detail shows how the selected measure differs across devices. Campaign detail identifies contributions within the account. Google's segmentation guidance explains that selected segments change the reporting rows and that compatibility matters. A segment is therefore part of the report definition, not just a cosmetic chart option.

Start with the smallest breakdown that answers the question. If you want to understand a seven-day spend trend, daily account cost may be sufficient. If you want to locate the campaign driving a change, campaign totals across comparable periods may be more useful. Adding daily, device and campaign detail simultaneously can create a large report whose rows are harder to interpret than the original total.

A request for detail can require another read. A total does not contain the daily distribution hidden inside it. A campaign ranking does not contain device-level results unless that segment was selected. The workflow can reuse an existing dataset when it already has the necessary information, but it should obtain additional measured detail when the user asks a genuinely new question.

Check whether the chosen segment preserves the population and period. “Break that down by device” should not unexpectedly switch to a different month or include previously excluded campaigns. If a source does not support the requested combination, the answer should identify that combination specifically. A rejected plan should not become a general statement that segmentation is unavailable everywhere in the provider.

Keep date selection inside the report definition

Dates influence which events are included, how missing points are treated and how comparisons are aligned. A query that has no meaningful period can return a result that is technically valid but unsuitable for the requested decision. An ordinary user should be able to select exact dates or a clear relative period without knowing the provider's date syntax.

Rolling windows and calendar windows remain different. Last seven days, last month and current month are separate choices. Completed-day reporting also differs from including today's partial activity. The answer should reflect the actual selection, with readable dates. A graph label should not conceal a period mismatch behind a familiar month name or a raw provider date code.

The report plan includes grain and alignment as separate decisions. Daily, weekly and monthly detail can share the same underlying period while presenting it differently. Relative comparisons can align positions within periods, while calendar comparisons keep actual dates. The intended comparison should determine that choice. A tidy visual is not sufficient justification for changing the user's requested period.

Long windows need a deliberate presentation decision. If daily detail is not essential, coarser grain can keep one native chart readable. If every day is explicitly required, preserve the points within supported output limits or explain the necessary narrower request. Do not treat old data, missing recent days or an unexpectedly truncated graph as a normal consequence of asking in plain language.

Distinguish filtering the population from limiting the preview

A filter decides which rows belong to the result. A preview limit decides how many examples are shown. These choices are often confused in conversational output. “Campaigns with spend above £500” defines a population. “Show five examples” defines presentation. The second instruction should not make the first population contain only five campaigns when more matched.

Inclusive boundaries need their exact meaning. At least £500 includes £500; above £500 does not. The reporting framework supports structured comparisons and logical conditions, with source-specific validation. It can represent combined requirements rather than expecting the model to apply them informally to the text of a short reply. Unsupported conditions should be explained instead of silently dropped.

Some questions filter on relationships or derived measures rather than simple resource attributes. Registered datasets can provide the relevant grouping and filter stages, while ordinary provider reports use their supported scope and breakdown. The conversation need not expose that implementation distinction to a normal user. It does need to preserve whether the requested condition was actually evaluated at the intended level.

After a filtered answer, check the completeness statement and any unknown coverage. A preview of matching items is not an exhaustive edit selection. An unavailable metric is not a measured zero. If the user wants every matching asset changed, the proposal must resolve the actual complete targets through the supported flow. A limited report cannot safely serve as an unseen instruction to modify all assets.

Preserve the meaning of totals and ratios

Some values can be added across disjoint rows; others cannot. Account cost can be assembled from compatible campaign contributions. A ratio needs its underlying components. Impression shares and overlapping observations require care. A reporting framework should know these differences rather than apply the same arithmetic to every numeric column returned by the provider.

Consider two invented campaign rows. One spends £100.00 for 100 clicks, giving £1.00 CPC. Another spends £900.00 for 300 clicks, giving £3.00 CPC. Their combined CPC is £1,000.00 divided by 400 clicks, or £2.50. Averaging the displayed CPCs gives £2.00, which does not represent the combined click cost. The components preserve the correct weight.

ppctor's Ads reporting adapter uses defined ratio components and additive rules. It can reject unsafe overlapping combinations and leave a total unavailable when it cannot be combined reliably. That behaviour is preferable to a convincing but unsupported total. The output should explain what the displayed total covers, especially when a ranking or preview intentionally shows only selected rows.

Users can review this without inspecting the code. Ask whether a total covers the whole account or just the rows shown. Check the numerator and denominator of an efficiency metric. Keep unknown values distinct from zero. If a measure cannot be aggregated safely, choose an appropriate entity breakdown or separate presentation. Eliminating query syntax should not eliminate the arithmetic discipline that makes a report trustworthy.

Use business definitions instead of a convenient raw conversion field

A raw conversion column can be useful, but it is not a complete answer to every business question. The account may contain several actions with different categories, values and primary or secondary roles. A request about purchases should not become an unrestricted total merely because the provider exposes a field called conversions. The reporting definition needs to identify what the user intends to count.

The current measurement catalogue distinguishes all primary conversions, purchase conversions, leads, calls, offline actions and named individual actions. Secondary actions are excluded by default unless explicitly requested. All primary conversion value can include non-purchase actions with assigned values. A purchase-only value measure is narrower. Those distinctions belong in the business interpretation, even when no technical field names appear in the final answer.

Cross-source comparisons need corresponding definitions. A named Ads action can be compared with a selected GA4 event, while lead comparisons require the relevant event to be named or confirmed. The assistant can inspect observed event names and suggest a candidate. It should not treat the name alone as proof of the site's business implementation. Confirmation establishes the comparison choice for that conversation.

Use specific questions when the distinction matters. “Show all primary conversions” asks for a broad primary population. “Show primary purchase conversions” narrows it. “Compare Contact Form with form_submit_contact” identifies two individual measurements. None of these questions requires GAQL from the user. Each requires the framework to preserve a different definition and label the returned result accordingly.

Keep parent and child relationships intact

Some account questions concern structure rather than a flat performance table. A keyword belongs to an ad group and campaign. A product can be included or excluded through a listing-group tree. A product identity can appear in several enabled groups. The relevant report must preserve those relationships if it is going to answer where an item exists or how many exclusions occur.

A general framework can register relationship datasets alongside provider fields. Those datasets describe how the relevant parents, children, inclusion states and performance coverage fit together. This allows the conversation to ask structural questions without relying on a dedicated tool for every phrasing. It also gives later reporting and edit selection a shared model of the target, rather than unrelated lists that disagree about parentage.

The counting unit remains important. One product excluded in two enabled groups produces two group-level exclusion occurrences. If the question asks for distinct product identities, the result is one distinct item. A report should identify which population it counts and which enabled campaigns and groups contribute. A list of tree nodes is not automatically a count of excluded products represented by those nodes.

Performance conditions add another layer. A request for excluded products with ROAS above a threshold needs performance at the supported item and group relationship. Missing coverage should remain unknown instead of being treated as zero. The user does not need the implementation details in the reply, but they do need to know what the condition established and whether the count is complete.

Ask for complete counts deliberately

Counting entities and reporting their performance are different operations. A performance report can have a row for each combination of entity and segment. Counting those rows may count days or devices rather than assets. A question asking how many ad groups exist should select the intended entity population, not count the visible rows in a daily metric preview.

The reporting framework supports an explicit count path and instructs the answering workflow not to count capped examples. The Ads adapter separates entity counts from unnecessary performance selection. This matters for both correctness and efficiency: a count should not compute metrics for rows only to ignore those metrics afterwards. The returned completeness and population determine how confidently the answer can state a total.

A request can ask for the count and a few examples without contradiction. “How many enabled ad groups are in this campaign? Show five names” defines an exhaustive count and a limited preview. The reply should distinguish them. If only a limited dataset is available, it should not call the number of shown examples the total. A concise message can still preserve that distinction.

When the count will support a live action, resolve the complete target selection separately through the edit workflow. “Pause all matching groups” is not safely implemented by modifying whichever examples fit in the previous reply. The report can identify the business population, while the proposal identifies the exact targets and action for approval. This boundary keeps presentation limits from becoming invisible operational limits.

Respond to a rejected plan without inventing a provider limitation

A report can fail before any measured data is returned. The selected fields may be incompatible, the time breakdown may be unsupported at that resource, the source may not be connected or the period may be invalid. Each problem has a specific remedy. A general statement that Google cannot provide the information can be wrong when the actual issue is the plan chosen by the assistant.

ppctor's tools return structured errors for these cases. Field discovery can identify compatible resources. Plan parsing can reject unsupported formats or ambiguous selections. Provider failures remain distinguishable from those validation outcomes. The assistant should use the returned information to correct the plan or explain the needed selection. Repeating the same non-retryable request unchanged does not produce better evidence.

A useful error explanation names the affected part of the request. It can say that the chosen combination needs another reporting level, that a corresponding GA4 event must be selected, or that the required source needs a connection. It should not disguise an invalid field name as an empty account. It should not replace missing daily values with an overall total while claiming the original daily question was answered.

The user can help by keeping the original question visible while clarifying the missing choice. If the period is invalid, choose the intended dates. If a named asset is ambiguous, supply its parent. If the measure needs an event, select it. This makes the next attempt a corrected report rather than a loosely related request that happens to succeed.

Reuse data without reusing assumptions that no longer apply

Reading the same source repeatedly for the same request wastes time and capacity. A report already containing daily spend can support both a total and a requested line chart. The current framework returns a data reference and can reuse matching report data within the request. The presentation step then renders measured values instead of asking the model to supply its own numbers.

Reuse has boundaries. A campaign total cannot reveal its daily distribution unless the original data included that detail. A new period, different population or new conversion definition may need another read. An expired request-level data reference should not be treated as a permanent account snapshot. The framework must distinguish presentation changes from changes that genuinely alter the required evidence.

Follow-up plans help preserve the established definition. “Show that as a bar chart” is primarily a presentation change when the dataset supports it. “Only enabled Search campaigns” changes the population. “Use last month” changes the period. The conversation should carry forward the unchanged choices and obtain the information needed for the changed ones, rather than rebuild the entire request from a vague memory.

Explain freshness when it matters to the decision. A saved result can be useful historical evidence, while a live edit needs the current target conditions checked again. Reusing an earlier report for explanation is different from assuming its settings remain current for execution. Efficient reporting and careful operation are compatible when the workflow knows which kind of evidence each step requires.

Choose a supported output without changing the question

Presentation should make the selected data easier to understand. A line chart is useful for a trend, a bar chart for category comparisons and a table for exact row review. The current native Slack renderer can present requested provider data through these supported forms. Ordinary totals do not need a chart, and a chart should not appear merely because the tool is available.

A native chart supports up to three series and twenty points per ordinary chart. A longer automatic trend can use coarser grain to keep a single readable chart when the user did not require daily detail. Explicit daily requests preserve that detail within supported output limits, with multiple charts and an explanation when appropriate. Larger requests may need a coarser breakdown, a table or a narrower period.

Series labels need their source and meaning. A comparison of Ads conversion value and GA4 purchase revenue should not use two indistinguishable “revenue” labels. A chart containing a cost measure and a rate should not hide their different units. Normal values are formatted for people rather than copied as raw provider numbers with excessive decimal places.

Keep the interpretation outside the visual when necessary. A table can show exact values while a short sentence explains whether totals cover all rows or only a ranking. A chart can show a pattern while a note identifies incomplete recent data. These explanations preserve the report's meaning without requiring the user to see a technical plan or query object.

Review an answer without inspecting the implementation

A non-technical reviewer can assess several important parts of a report. Check the account, source, period, population, metric definition and requested grain. Compare those choices with the original question. Look for a completeness statement when the answer lists examples or counts. Confirm that monetary values and ratios have clear units. These checks establish whether the output addresses the intended decision.

Then inspect the conclusion. A highest-spend campaign is not automatically the least efficient campaign. A conversion decline does not establish its cause. A difference between Ads and GA4 does not prove a tracking fault. An empty result does not establish zero activity unless that is what the measured selection shows. The language of the conclusion should match the strength of the evidence.

Ask a focused follow-up when something is missing. “Which dates were included?” resolves a period question. “Does that count include paused groups?” resolves a population question. “Is this purchase-only value?” resolves a measurement question. Those questions are more useful than asking the model to be more accurate in general, because they identify the specific definition that needs confirmation.

A report that passes these checks can still require business judgement. A campaign may have acceptable efficiency but an unsuitable strategic role. An account total may be correct but not answer a margin question. Conversational reporting provides evidence and explanations; it does not remove the need to decide which outcomes matter to the business and what action is justified.

Know when specialist inspection is still useful

Reporting without GAQL lowers the everyday interface burden. It does not make every possible provider field available in every combination. A specialist can help investigate unusual compatibility, attribution or aggregation questions, particularly when the requested report crosses several structures. The goal is to reserve that work for the cases that need it rather than require technical assistance for every ordinary account total.

A technical inspection should begin with the business question and the plan that attempted to answer it. Looking only at the provider error can lead to a fix that produces a valid query but changes the requested population. Looking only at the final sentence can hide an invalid aggregation. Review the definition, selected fields, source outcome and presentation together.

Provider field catalogues and the application catalogue also have different roles. Google's capabilities evolve, while the application supports a validated subset and registered relationships. A field being documented by Google does not establish that a particular application workflow implements it. Conversely, an application validation failure does not establish that the provider lacks the underlying capability. Keep those conclusions separate during investigation.

For the ordinary user, the practical benefit remains substantial. Familiar questions can be expressed in business terms and answered through the general framework. Specialist work can improve that framework when a real gap is identified. It should avoid creating a dedicated patch for one phrasing when the underlying issue belongs to field discovery, scope preservation, measurement definition or data composition.

Run the reporting conversation in the connected Slack destination

Use the Slack channel connected to the intended advertising account. Mention the app and state the report brief. A question such as “Show daily account spend for the last seven completed days” establishes a useful first read. Continue in the thread for related follow-ups so that the established scope and period remain available to the workflow.

If you need a visual, request it explicitly: “Draw that as a line chart.” If the first read lacked daily detail, the workflow needs the appropriate time series before rendering. If you change the selection, say what changes: “Now only Search campaigns” or “Use the previous calendar month.” A good follow-up modifies that choice while preserving the rest.

Normal replies should remain readable. Campaign and ad group names belong in the output; raw identifiers and technical object formatting are usually unnecessary. Deeper targets need their actual parents, not invented parent relationships. A concise answer can show the key result and a few examples while retaining a complete count and the correct scope.

Choose the audience deliberately. Channel members can see messages and files posted there. A larger export may be useful for detailed review, but it introduces more information than a short answer. Keep the destination appropriate to that content. The plain-English questions guide explains how precise wording and follow-ups make this conversational surface useful without requiring query syntax.

Keep report reads separate from live account operations

A reporting query reads information. A live edit changes an account. The conversation can move from one to the other, but the transition should be explicit. A request to identify low-efficiency campaigns does not authorize pausing them. A request to draft keywords does not add them to an ad group. The desired operation needs its own supported proposal.

ppctor's edit workflow prepares the action and exact target for review. Confirmation is required before the live call, and relevant settings and authorization are checked again. The proposal shows clear steps for supported multi-part work, while dependency logic sequences related operations. Reporting data can support target selection, but a preview or stale setting should not substitute for a complete, current execution target.

Scheduled reporting and scheduled Rules are also different. A saved report describes recurring output. A configured Rule can describe a supported action under its allowed conditions. Asking for a one-time chart does not create either automatically. Choose the relevant workflow deliberately and review its destination, schedule and authority instead of assuming that conversation history becomes ongoing configuration.

This separation is part of making reporting accessible. A user can ask questions freely without every recommendation becoming an immediate account change. When the user does want an action, the resulting proposal is concrete enough to review. The confirmation guide describes that boundary and the meaning of the progress and execution messages that follow.

Frequently asked questions about reporting without GAQL

Does the app stop using queries behind the conversation?

No. The interface removes the need for the ordinary user to write provider syntax. The framework still builds validated reads using available fields, source capabilities and the report definition. The business choices remain important even when the technical request is handled behind the scenes.

Can I ask for any combination of fields?

No. Resources, metrics and segments have compatibility rules, and the application must support the requested combination. Field discovery helps choose an appropriate report. A rejected combination should receive a specific explanation or corrected plan, rather than silently losing part of the question.

Can a total become a daily chart without more data?

Only if the existing dataset contains the required daily detail. An overall total alone does not reveal its daily distribution. The framework can reuse suitable returned data within the request, but a genuinely new breakdown needs the appropriate measured read before presentation.

Will a list of examples tell me the complete count?

No. Ask for the count explicitly. A preview can show representative rows while a complete count uses the defined population. The answer should identify completeness and coverage. Never assume the visible number of names is the total number of matching assets.

Do I need a separate tool for every wording?

No. The reporting framework uses discoverable fields, reviewed measurements, structured conditions and registered datasets. Supported variations can share that framework. The user supplies the business question, while the validated plan preserves its meaning and the provider read supplies the actual values.