Ask Google Ads account questions in Slack with clear scope, metrics, and follow-up context

Start with the purpose behind the account question

An account question usually asks for one of several kinds of evidence. It may ask what happened during a period, how the account is configured now, which targets satisfy a condition, or how two entities are related. It can also ask for strategic or creative help that does not need a live read. Identifying that purpose is the first step toward a useful answer. Treating every sentence as the same kind of reporting request leads to unnecessary calls and results that miss the user's actual intention.

A question such as “What was our cost last week?” asks for measured activity with date bounds. “Which campaigns are enabled?” asks for current configuration and a count. “Where is this product excluded?” asks for relationship evidence. “Suggest a clearer headline for this offer” asks for creative help. These are all legitimate Slack conversations, but they need different work. The assistant should choose the evidence or conversational response that fits the question rather than forcing the user through one fixed command sequence.

State the business decision when it helps. “I want to understand which campaign deserves a budget review” gives useful context for a performance ranking. “We are relaunching this paused offer” explains why existing creative and destination checks matter. “I only need a quick count” helps the assistant avoid a long table. The user should not have to translate the request into API field names. A well-designed framework maps the ordinary question to compatible fields while preserving its purpose.

The answer should make the next step easier. A measured result can support a drill-down; a settings result can identify a current target; a relationship result can locate an occurrence; a creative draft can invite refinement. None of those automatically authorizes a live change. The assistant should let the conversation develop naturally while keeping the execution boundary clear. The useful outcome is an answer grounded in the requested evidence, followed by a reviewable action only when the user asks for one.

Resolve the account and preserve meaningful conversation context

A channel connected to a Google Ads account supplies the initial account context. The ownership paths resolve the actual workspace and channel rather than guessing from visible names. If the channel is not connected, account-dependent requests need that connection before the tool can read the intended account. A greeting, general advertising discussion, or creative request can still be conversational. The assistant should distinguish account access requirements from ordinary helpful discussion instead of demanding a connection for every sentence.

Within a thread, follow-ups often depend on the preceding answer. “Pause it” after a clear single-campaign result refers to that resolved campaign. “Show the same dates daily” refers to the established period. “Use the total for paid traffic” changes the requested population while retaining other relevant context. The current reporting instructions resolve follow-ups against the stored plan and preserve scope unless the user changes it. This prevents the assistant from treating every short follow-up as an unrelated new request.

Context still needs evidence. A conversation about one campaign does not establish that its present status remains unchanged forever. If a live action depends on current settings, the tool must check the relevant state before writing. If two possible targets fit the follow-up, ask a focused clarification. The goal is neither to forget the thread nor to assume unlimited certainty from it. Retain resolved identities and meanings, then refresh the particular facts needed for the next justified step.

Keep output context readable. A campaign can be shown by name; an ad group needs its campaign when ambiguity matters; a keyword or ad needs its actual group and campaign. Provider identifiers stay behind the scenes for the tools that require them. This makes the answer usable without sacrificing exact targeting. A parent relationship must come from the resolved account hierarchy, not from a guessed label. Clear names and correct context are especially important when the user later asks to edit the target just discussed.

Use a field and dataset library instead of a new tool for every sentence

The current reporting framework separates discovery, retrieval, and presentation. Field discovery helps identify supported metrics, settings, and registered datasets. Data retrieval selects compatible evidence and returns a data reference. Visual rendering uses that evidence when the user asks for a chart or table. This structure allows many ordinary-language questions to share the same underlying tools. It is more adaptable than adding a dedicated function for every combination of metric name, date phrase, and filter.

A field catalogue describes provider capability, not account data. The fact that the API exposes a measure does not prove the connected account has meaningful values for it. The assistant should discover the relevant field, then read the requested scope before stating a result. It should also respect resource compatibility: not every field can be selected with every dimension. A structured incompatibility error is a reason to adjust the plan, not a reason to announce that the entire business question is impossible.

The framework chooses an appropriate reporting level when compatible fields support it. Account totals, campaign rows, group detail, and relationship datasets serve different purposes. The assistant should use the coarsest useful level for an aggregate and the necessary detailed level for an identification question. This reduces both unnecessary data and accidental double counting. A total should not be assembled by adding parent and child rows that represent the same underlying activity.

Google publishes its reporting concepts and field-selection rules in the Ads API documentation. Those rules constrain the compatible evidence a tool can request, while the app's library makes the selection accessible in ordinary conversation. See Google's reporting overview. The user-facing answer should focus on the resulting measure and scope rather than requiring the reader to understand the query language.

Ask performance questions with a metric, scope, and period

A performance question is strongest when it identifies what should be measured and over which interval. “Show campaign cost and primary conversions for the last thirty complete days” has a clear meaning. “What is doing worst?” needs an interpretation of worst: highest acquisition cost, lowest return, largest cost with no selected outcomes, or another agreed rule. The assistant can use account and business context where appropriate, but it should clarify a choice that materially changes the ranking.

Date phrases need actual bounds. Last month is a calendar interval; last thirty days is a rolling interval; current month through yesterday can have no completed days at the start of a month. A report should preserve the requested meaning instead of substituting whichever preset is easiest to query. The actual dates belong in the result. This lets the user recognize whether the report covers the launch, promotion, or recent change they intended to examine.

Ratios must use compatible aggregate inputs. Return on ad spend is the selected value divided by the selected cost, not the average of daily return ratios. Acquisition cost needs the selected outcome total. A daily chart and a period total can differ in presentation while sharing the same underlying scope. The assistant should reuse the returned totals rather than perform loosely related arithmetic from a capped preview. If the denominator is unavailable or zero, explain that state instead of fabricating a normal result.

Measured movement should not become a causal explanation automatically. A campaign's cost can rise while outcomes remain stable, but the report alone may not identify why. A focused drill-down can inspect distribution or current settings, and the owner can supply known business context. The assistant should state the observation and the next useful investigation. An evidence-backed answer can be direct without pretending that every change in a chart proves a particular auction, creative, or site cause.

Read present settings without treating them as historical facts

A settings question concerns the current account configuration returned by the applicable read. “Is auto-tagging enabled?” differs from “Was traffic attributed correctly last month?” “What is this campaign's budget setting?” differs from “How much did the campaign spend?” The assistant should select the settings path for the first kind of question and measured evidence for the second. A current setting can help investigate a performance issue, but it cannot independently reconstruct historical behavior.

Current status needs its subject. A campaign can be enabled while an ad group is paused. An ad can be configured as enabled while a policy state limits its use. A product occurrence can be excluded under one enabled group and included under another. The answer should identify the level rather than returning an isolated word such as “enabled.” That distinction prevents a follow-up from accidentally changing a parent when the user meant a child.

Setting relationships can affect an edit's prerequisites. A budget may be shared; a target may belong to a strategy; an asset may be reused through several attachments. Read enough context to establish the requested meaning before recommending a change. The ordinary dedicated campaign-budget action, for example, has narrower prerequisites than a general inventory question about all budgets. The existence of a readable setting does not establish that every possible edit to it is available through the same operation.

Present values in the user's terms. A currency amount should be readable rather than expressed in micros. A bidding target needs its familiar measure and units. A setting that cannot be established should remain unavailable, not default to a plausible value. The user is asking for evidence about their account, not an example configuration. This principle applies across settings, from tracking and status to targeting and asset relationships.

Define conversions and value before comparing results

Conversions is an aggregate that can include multiple primary actions. Purchases and leads are more specific business groupings. Calls can be primary conversion actions and can carry assigned value. A named conversion question selects the requested action rather than assuming the account's total is the same measure. The assistant should use the business-metric definitions returned by the catalogue and exclude secondary actions unless the user asks for them. This preserves the agreed meaning across the answer and its follow-ups.

Value needs equally careful labeling. All primary conversion value can include values assigned to non-purchase actions. Purchase-only value narrows the selected action category. Neither automatically equals a reconciled business accounting total. If the user asks for revenue without specifying the scope, the assistant should apply the relevant established business definition or clarify when the difference matters. It should not silently change between total conversion value and purchase-only value to satisfy a visual compatibility shortcut.

A comparison with GA4 may need a user-selected event. Lead implementations differ across sites, so an event name that sounds likely is only a candidate. The assistant can list available names and suggest the most plausible one, then ask the user to select or confirm it. Only that selection establishes the correspondence used in the comparison. A named Ads conversion can similarly be compared with a named GA4 event once the requested pair and populations are clear.

Cross-source comparisons can be useful even when attribution differs. The series should retain source labels and requested scopes; they should not be added into a larger total. A GA4 all-traffic purchase view and an Ads conversion-value view answer related but distinct questions. The goal is to make those views available for investigation, not to hide every difference or promise identity. The user can then inspect the data while understanding which measure each line represents.

Combine filters with the correct logical meaning

The shared condition framework supports comparison boundaries and logical groups rather than a separate special-case tool for every filter wording. “Above” differs from “at or above.” “At least” includes the boundary; “less than” does not. A request for campaigns with cost greater than a threshold and no selected conversions should preserve both conditions. The answer should restate a complex rule clearly enough that the user can see whether the tool selected the intended population.

Grouping changes meaning. “Cost above 500 and either no purchases or return below 1” is not the same as “cost above 500 with no purchases, or any return below 1.” The first constrains both outcome alternatives by cost; the second can include low-cost targets through the return branch. The assistant should resolve this meaning before a selected set becomes an edit proposal. A readable restatement is especially useful when several criteria and exclusions appear in one sentence.

Use fields that are available at the requested resource level. A relationship condition may require a registered dataset rather than a campaign-performance row. A setting filter may need a settings read instead of a metric query. A post-aggregation condition can differ from a row-level provider condition. The tool's structured errors help identify these planning distinctions. They should guide a compatible request, not prompt unchanged retries or a generic claim that the provider does not support filters.

Do not confuse a filter with an action. “Show keywords with cost above 100 and no purchases” asks for evidence. “Pause those keywords” asks for an edit after the actual targets are resolved. A numerical candidate set does not prove business irrelevance, and the owner may supply context that changes the decision. Keep the selection rule visible and freeze the intended targets in the proposal. This lets the user review both the evidence and the exact requested consequence.

Count the requested population rather than visible examples

A count question requires a count operation over the actual requested scope. A response containing ten example rows does not establish that only ten targets exist. The current reporting instructions explicitly use counting for counts and prohibit counting capped examples. This matters for enabled campaigns, matching products, excluded occurrences, and any large filtered set. The user should receive the count definition and relevant scope, with examples supplied separately when they help identify the population.

Unique entities and occurrences are different counting questions. The same product can appear in more than one enabled group. If the question concerns excluded occurrences, each relevant group occurrence can count. If the question concerns unique product identifiers, deduplication has a different purpose. The assistant should preserve the requested unit rather than automatically collapse repeated identifiers. A clear answer can state the number of occurrences and the campaigns or groups through which they are distributed.

Hierarchy affects totals as well. Summing campaign rows and their ad-group rows counts the same activity twice. A count of groups containing disapproved ads differs from a count of individual disapproved ads. A destination-finding count differs from unique broken URLs. The tool should select the correct reporting grain and explain the result's unit. These distinctions are not technical trivia: they determine whether the answer matches what the owner is trying to inspect or change.

A bounded preview is still useful when labeled honestly. “Here are the five highest-cost examples among the matching set” gives the user a manageable list. “There are five matches” claims a total. The assistant should not blur those statements. If a requested edit selection is too large to review safely in the current reply, narrow the selection rather than apply only the visible preview without saying so. The displayed examples and the live execution targets must not diverge.

Inspect hierarchy and product relationships as their own evidence

Some questions cannot be answered by a flat performance table. Product listing structures, asset attachments, and parent-child relationships need their registered relationship datasets. A product can be included or excluded under different groups, and the structure can be segmented through brands, categories, and individual identifiers. The assistant should read the actual hierarchy and occurrence context instead of assuming a product has one universal account-wide status.

Performance Max and Standard Shopping use different group contexts. Performance Max uses asset groups, while Standard Shopping uses ad groups. An answer about exclusions should preserve that distinction and apply the requested enabled-group population. The same product excluded in two relevant groups can represent two exclusion occurrences. The report should identify where those occurrences sit when the user asks for a campaign-specific or group-specific drill-down.

Combining performance and relationship conditions requires compatible definitions. “How many excluded products have ROAS above 3?” needs an exclusion population and a dated performance measure. Current exclusion status and historical performance are not the same dataset. The framework must establish the applicable relationship and measure rather than guess from a product name. The answer should state the time scope and occurrence rule so the user can understand what was counted.

A relationship read can support an edit, but it is not an edit itself. Enabling or excluding a selected occurrence needs the correct current tree target and supported operation. Changing one occurrence should not silently change another group containing the same product. The proposal should show readable campaign and group context and the exact requested transition. A generic framework is valuable here because it keeps relationship selection and mutation prerequisites reusable across many question wordings.

Request the visual that helps explain the evidence

Charts and tables are presentation tools for returned evidence. The current instructions render a visual only when the user requests one and use the data reference from retrieval. The assistant must not invent numeric arrays to make a graph appear complete. “Show this daily as a line chart” should use the established scope and period with the requested time detail. If the existing data lacks daily rows, a justified new read supplies them before rendering.

Choose a format that fits the question, while respecting the user's explicit choice. Lines are useful for time movement, bars for category comparisons, and tables for named targets and precise values. Several compatible requested measures can share one chart with distinct labels. Different sources should remain distinguishable. A chart comparing Ads value and GA4 purchase revenue should not erase their definitions merely because both use a money unit.

Native Slack visuals have practical capacity limits. The current conversational layout keeps the series count small and uses readable time grain for ordinary longer periods. An explicit daily-detail request can require consecutive charts when the point limit would otherwise be exceeded. Explain the split rather than quietly returning two unrelated-looking graphs. A request for too many series should receive a polite request to narrow the selection, not an arbitrary subset presented as the complete requested result.

The visible dates and values should be readable. Current-year labels do not need a full raw date string in every point. Week labels should identify the meaningful date range rather than an opaque provider code. Metrics should not arrive with many decimal places. These formatting rules help the user understand the evidence quickly, but they do not change its scope or invent values for missing periods. A clear chart remains an account answer, not decorative output.

Keep creative discussion conversational when live evidence is unnecessary

The assistant can help brainstorm headlines, descriptions, keyword themes, campaign names, and explanations from context the user has supplied. A request for five sensible keyword suggestions is not automatically a request for Keyword Planner history. A request for a clearer product description is not automatically a Merchant report. The current creative instructions make that distinction explicit. The assistant should provide the requested ideas without adding unsolicited research or pretending its suggestions are provider results.

Use the product facts already established in the thread. If the offer lacks a necessary detail, ask for that detail or make the limits of the draft clear. Do not invent pricing, certifications, guarantees, or stock information to make the copy sound complete. Creative usefulness comes from interpreting the user's intention and producing relevant options, not from making every response longer or forcing a data call into a task that does not need one.

Measured research remains available when requested. “Give me keyword ideas around this phrase” can use the research tool when the user is asking for provider ideas; “show traffic history for related keywords” can need an ideas step followed by historical metrics. The initial source and requested measure determine the work. Ordinary creative brainstorming should not be mislabeled as that research. This separation saves time and makes the resulting evidence more trustworthy because the user knows what came from a provider.

A creative conversation can later become an edit request. Once the user selects wording and asks to create or replace an asset, the assistant resolves the applicable target and prerequisites. The proposal shows the actual content and intended state. The earlier brainstorm does not itself authorize publication. This gives the user a natural workflow: discuss an idea, refine it, inspect the concrete account proposal, and confirm the live change.

Interpret empty results, unavailable reads, and planning errors separately

An empty result can mean no rows matched the selected scope. It can also reveal that the chosen filters were narrower than the user intended. Inspect the query meaning before concluding that the account has no activity. A campaign-name ambiguity, wrong status population, or unavailable relationship can change the selection. The assistant should explain the result with its actual scope and use targeted clarification when needed rather than presenting every empty table as a business fact about the entire account.

An unavailable provider read is different from a zero result. It cannot establish no conversions, no cost, no excluded products, or a clean policy state. The answer should preserve the available evidence and identify the unresolved part. Partial data can still support a limited conclusion when its coverage is stated. It should not be promoted to a full account answer merely because the visible rows look tidy.

A planning error is also different from a provider capability limit. If a requested field is incompatible with a chosen resource, the framework can discover a suitable resource or explain the necessary selection. If a measure needs a user-selected GA4 event, ask for that event. Repeating the unchanged invalid plan wastes time without adding evidence. A useful assistant reads the structured error and makes the next compatible choice instead of apologizing repeatedly for a problem it could resolve.

The same discipline applies to external freshness and coverage limits. A recently completed reporting day may still change as provider processing continues. A query report may omit some detailed rows. A catalogue entry can exist without data in the account. These boundaries need concise explanation when they affect the user's conclusion. They should not become generic excuses for failing to retrieve evidence that the current tools can actually request.

Use short follow-ups without losing the established meaning

A follow-up such as “and by campaign?” usually asks for a new grouping of the established measure and period. “Only enabled ones” changes the population. “Now show it as a bar chart” changes the presentation. The assistant should preserve the other meaningful parts of the stored plan rather than start over. This makes the conversation efficient and keeps comparisons consistent. The user should not need to repeat the complete account question in every reply.

Recognize when the user deliberately changes the meaning. “Use all website revenue instead” changes a numerator scope. “Include secondary conversions this time” changes the action selection. “Use last month, not last thirty days” changes the date convention. The new answer should reflect that change explicitly where it affects interpretation. Preserving context does not mean preserving an earlier wrong assumption after the user corrected it.

Reuse evidence when possible and refresh what is needed. A requested display can use a returned data reference. A new metric or segmentation may justify another read. A live edit needs relevant current-state checks even when the performance data is already available. These are different reasons for tool use. The assistant should not perform a full account scan simply because the follow-up is short, nor avoid a necessary check merely to minimize calls.

Ask one focused question when a genuine ambiguity remains. If the preceding answer listed several campaigns, “pause it” needs a selected target. If the user asks for a lead comparison without naming the GA4 event, the correspondence needs selection. The clarification should offer the relevant names or choices already available. This preserves the conversation's progress instead of making the user re-explain the whole task.

Move from a read answer to a reviewed account action

The read stage establishes evidence and resolves candidates. The action stage selects the supported operation and its prerequisites. A request to pause the worst-performing campaign therefore needs a defined performance rule and period, a resolved current campaign, and a readable pause proposal. The execution tool should not rerun unrelated discovery when the candidate is already established, but it must check the relevant current state before writing. Evidence reuse and execution validation work together.

The confirmation message should name the target and correct parents and show the exact action in clear steps. A keyword addition needs its group and campaign; a creative replacement needs the full intended content; a status change needs the transition. The user should be approving a concrete result rather than a technical payload or a vague promise to optimize. The current proposal expires, and no live edit is applied before the connected owner confirms.

After confirmation, the visible change-in-progress state shows that execution has begun. The final receipt distinguishes executed and verified changes from a result that could not be fully established. A successful account write does not prove that performance will improve, and a creative write does not prove that provider review has finished. The later business or policy check remains its own question. See the execution workflow for those stages.

If the result is uncertain, inspect the account before requesting another mutation. An uncertain observation does not establish that the write failed. Repeating a creation can create another entity, and repeating an update can obscure what happened. The assistant should preserve the actual state of knowledge and guide the next evidence check. This is another reason to keep account questions and mutations in a reusable framework rather than a set of isolated scripts with inconsistent behavior.

Three illustrative account conversations

A campaign count leads to a named status proposal

Imagine an owner asking how many campaigns are enabled. The assistant performs the appropriate count and returns a single enabled campaign with its readable name. The owner then asks to pause it. The assistant retains the resolved campaign context, prepares the status transition, and displays the confirmation. It does not ask the owner to type the campaign name again when the preceding result was unambiguous. It also does not execute merely because the owner expressed the request in the thread.

After confirmation, the result reports the actual verified transition. A later request to enable the same campaign uses that established context while checking current prerequisites. The interaction is natural because the assistant preserves identity and meaning. It remains controlled because every live change has its own reviewed proposal. A correct framework does not have to choose between fluent conversation and exact account targeting.

A performance answer becomes a requested two-source chart

Imagine a retailer asking for purchase value over a recent interval, then asking for a daily comparison with GA4 purchase revenue. The assistant selects the explicit measures and scopes, retrieves compatible daily evidence, and renders one requested chart with distinct labels where the supported layout permits it. It does not add the two sources or block the comparison merely because attribution differs. If the user changes the GA4 scope to all traffic, that correction is preserved in the next result.

The owner then asks for possible explanations of the difference. The assistant identifies what the returned data establishes and which further evidence would help, such as selected action definitions or business context. It does not invent a tracking fault from the difference alone. A focused setting or conversion-catalogue read can support the investigation when requested. The chart, explanation, and later read all remain tied to the original question's actual scope.

A product relationship question leads to a scoped occurrence review

Imagine an owner asking how many excluded product occurrences exist in enabled groups, then narrowing the question to one Performance Max campaign. The assistant uses the registered relationship evidence and preserves the occurrence count rather than deduplicating every repeated product identifier. A follow-up for one asset group narrows the hierarchy further. The answer identifies the relevant campaign and group context, not a flat product count detached from where the exclusion exists.

The owner asks whether the selected occurrence can be enabled. The assistant resolves the actual tree target and prepares the applicable supported action. It does not change every occurrence of that product across unrelated groups. The proposal shows the selected context and requested transition. This interaction illustrates the value of generic datasets, conditions, and mutation prerequisites: the tools can adapt to the question while preserving the exact relationship the user intended.

Common questions about account conversations in Slack

How should I check that the answer matches my intention?

Read the target, dates, metric labels, and population statement before drawing a conclusion. If you asked for purchases but the answer describes total conversions, correct the measure. If you asked for a current setting but the answer describes last month's performance, correct the evidence type. If you asked for exclusion occurrences but the answer counts unique products, correct the counting unit. These checks are quick because a readable result exposes the meaning rather than hiding it behind a technically valid query.

A correction should become part of the next answer's established context. The assistant should preserve the parts you did not change and retrieve only the evidence needed for the revised meaning. That makes a conversation progressively more precise instead of forcing you to restart each time. It also gives a later action proposal a better foundation: the selected target and condition reflect your clarified request, not an assumption that was already rejected earlier in the thread.

Do I need to know API field names?

No. Ask in ordinary language. The framework discovers compatible fields and datasets, then uses the requested meaning to select evidence.

Does every reply need a Google Ads call?

No. Creative suggestions and discussion can use established context. Measured account claims need applicable evidence, and a new requested scope may require a read.

Can I combine several filters?

Yes, within the supported field and condition framework. Keep comparison boundaries and logical grouping clear so the selected population matches your intention.

Can the assistant count more targets than it lists?

Yes. Counts use the requested population; visible examples are a separate bounded presentation and should not determine the total.

Does a short follow-up keep the prior dates and scope?

The reporting instructions preserve the stored plan unless you change it. Clarification is needed when the target or requested meaning is genuinely ambiguous.

Does an answer authorize a live edit?

No. A requested edit needs a supported target, a readable proposal, and owner confirmation before execution.