Ask Google Ads account questions for in-house teams: connect plain-language requests with clear evidence

Start with the team's actual question

A useful account question connects a business concern with evidence the tools can retrieve. Marketing may need to understand an expenditure change, analytics may need a selected outcome definition and a product owner may need to know which offer is represented in the account.

Begin with that concern rather than a technical field name. The AI can map supported plain-language requests to shared data capabilities, while the user reviews the resulting scope and meaning.

Keep the decision behind the question clear. A request to identify a low-performing campaign can support investigation. A request to pause it is a separate live action that needs the proper target and approval flow.

A question can also be explanatory or creative. The team might ask for a clearer handoff, a headline suggestion or a summary of supplied launch context. Those requests do not automatically require a provider call.

Use ppctor as a route to account evidence and structured follow-up. The bot should not invent business facts missing from the connected sources. The team still needs owners for offer availability, margin, implementation and commercial decisions that ordinary advertising data cannot establish.

Keep the connected account context

A Slack channel has a selected Google Ads account connection. A login may access several accounts, but a channel question should retain its connected account rather than silently combine every available account.

Confirm the connection before expecting current figures. A business or campaign name alone does not give an unconnected channel access to the account evidence.

Keep named targets inside that context. A campaign name can recur across accounts, and a group name can recur across campaigns. Parent relationships help resolve the intended target.

User-facing answers should use recognisable names and necessary parent context. Technical identifiers can be used by tools behind the scenes without becoming the explanation presented to the colleague.

If the connection changes, review the conversation's scope before continuing a dependent account action. A target discussed under one account should not be assumed valid in another. The team can still discuss supplied business context, but account facts and proposals need the actual selected connection and current authority.

Read the assumptions in an incomplete request

Users often leave out a target, period or metric. The current question policy supplies defaults so the bot can answer without asking an unnecessary preliminary question every time.

When no target is named, the account is the default population. The tool should not invent a campaign filter or ask which campaign merely because the user asked a broad performance question.

When no period is given, the default is the last thirty days. The answer should state the used time frame and allow the user to change it. A named month or weekday follows the policy's current-date interpretation rather than an arbitrary old period.

The wording guides the measure. Spend points to cost, traffic to traffic measures and return to an appropriate return measure. Broad performance questions can receive a concise overview. Ranking questions use the policy's available-value context when the user leaves the criterion unspecified.

Read the assumption statement as part of the answer. The user can correct the measure, population or period in a follow-up. Explicit defaults help the team move quickly while keeping the choice reviewable; they should not become silent permanent definitions for every later question.

Use actual periods and source time contexts

Actual date intervals make an account answer understandable. Last thirty days is a rolling interval, while last month is the preceding calendar month. The bot should not exchange one for the other because their labels sound similar.

Completed-period questions end at yesterday in the relevant source context. Today-so-far questions retain their partial-day coverage instead of presenting unfinished hours as a final day.

Advertising account and Analytics property time zones can differ. Keep the source and period with the answer so colleagues in another region do not infer dates from their own local clock.

Google's Analytics freshness guidance explains that recent data can change as processing completes. A later read can therefore differ from the first observation without establishing that the original question used the wrong period.

Preserve dates in follow-up comparisons. Asking for the same period by campaign should retain the interval. A request for a different month or comparison changes the evidence needed. State the change so a later colleague can reconcile the outputs rather than treat different populations as contradictory answers.

Define which outcomes the question means

The measurement framework distinguishes all primary conversions, purchases, leads, calls and named actions. A simple conversion label can conceal those different selections, so the answer should preserve its actual meaning.

Primary aggregates include the corresponding primary actions and exclude secondary actions unless the request deliberately includes them. The framework sums selected recorded actions without silently deduplicating or repairing their implementation.

A purchase count is narrower than all primary conversions. A call outcome can also have configured value, while a phone-link click in Analytics is not automatically a completed call.

Offline or imported actions can be visible as recorded account outcomes. They may overlap with another selected group, so they should not be added as an independent extra total without establishing the population.

Ask a named-action question when the aggregate does not match the business concern, subject to the supported output workflow. Resolve ambiguous names rather than select a similar-looking action. The team should know which actual outcome the answer describes before using it to rank or change an account target.

Keep purchase value and all-primary value distinct

All-primary conversion value can include value from non-purchase actions. Purchase-only value selects the purchase category. Both can be useful, but they answer different questions.

Keep that distinction when the user asks about revenue or return. The context may establish the intended measure; if it does not, the answer should make its selected definition reviewable rather than quietly label every value total sales.

Analytics purchase revenue has its own source and traffic population. It can be compared with related Ads value when the business meanings fit, but the two should not be added as independent revenue streams.

All-traffic purchase revenue divided by agreed advertising cost is described as blended ROAS or MER. It differs from a Google Ads-attributed return question. The spend source must be selected when the user has not established it.

A value figure also does not prove profit or cash settlement. Margin and billing context require separate evidence. The AI can explain those distinctions in conversation while the tools retrieve the selected account measure. This keeps a concise answer useful without pretending the advertising source knows the company's entire financial position.

Select the corresponding lead event

Sites can use different event names for their lead actions. A lead comparison against Analytics needs the corresponding selected event rather than an assumed universal name.

The framework treats the supported primary lead categories together as leads. It does not infer a business-quality hierarchy from category labels. Sales qualification needs supplied evidence or a suitable connected source.

The AI can inspect observed event names and suggest a plausible candidate. The user must confirm the corresponding event when its meaning is ambiguous. A suggested name is not confirmation.

The current named-comparison delivery gate remains a capability boundary. The presence of a measurement recipe does not prove every named Ads/Analytics output has been verified for delivery.

Ask a focused selection question when needed. The team can still receive established aggregate evidence while analytics confirms the event. This avoids producing a confident chart between unrelated actions merely because their names both contain form or contact. Keep the confirmed event meaning with later follow-ups so another colleague does not accidentally switch the comparison.

Give best and worst a defensible criterion

Best and worst need a measure. Lowest return, highest cost per outcome and largest cost without selected outcomes describe different rankings.

The current default policy uses account value context for unspecified ranking questions. The answer should state the criterion and period so the user can correct the assumption.

Use aggregate inputs for the selected population. Overall cost per outcome is total cost divided by selected outcomes, not an average of rounded daily ratios.

A ratio without its required denominator remains undefined. The tool should not treat an unavailable return or cost-per-outcome value as a favourable zero just to complete the ranking.

The ranking starts a decision rather than making every commercial judgment. A product owner may explain an intentional launch, while analytics may identify an unresolved definition. If the user asks to pause the ranked target, resolve the exact entity and prepare the supported proposal. The initial read does not itself authorise that live change.

Ask for the right counting population

A count must correspond to the entity the user asked about. Campaigns, groups, keywords, findings and unique products are different populations.

A compact preview is not a complete count. The tools need full requested coverage or an explicit bounded-result explanation before claiming how many matching targets exist.

Current status and historical data can also change the population. A paused campaign may have spent during the selected interval, while a current enabled-campaign count answers a different question.

Relationship counts need their hierarchy preserved. A product repeated across groups can have several excluded occurrences while representing fewer unique items. The answer should retain the requested occurrence or unique-item meaning.

Ask for clarification when the entity is genuinely ambiguous, not when a reasonable explicit default already exists. The team should receive a number that actually answers its question rather than whichever count is easiest for the tool to retrieve. Keep unavailable portions distinct from zero and retain the scope in the explanation.

Preserve conditions and combined logic

The shared condition framework supports numeric comparisons, membership, text conditions and logical groups. Provider-specific compilation determines which fields and combinations are valid for the requested source.

Strict and inclusive comparisons differ. Higher than is not the same as higher than or equal to. A request at a threshold needs its intended boundary preserved.

Combined logic also matters. High cost and low return selects targets meeting both conditions. High cost or low return selects either. Negation changes the population again.

Missing-value conditions should remain separate from numeric values. A null ratio is not automatically below a positive threshold. The framework should not force unknown evidence into a zero merely to satisfy the filter.

A condition creates a review population, not automatic authorisation. The same generic syntax can support later account questions without a dedicated special-case tool for each phrase. The team still needs to establish the business reason and exact target before asking for a supported live edit.

Separate settings from performance evidence

A setting question asks what is configured. A performance question asks what was recorded over a period. Related settings and outcomes can be investigated together without treating one as proof of the other's cause.

The tools can use local capability discovery to identify supported settings and fields. They do not need a provider request merely to explain an available operation or data choice.

Current account values still need scoped evidence. A campaign's name does not establish its targeting, budget or status. Read the relevant target instead of inferring its settings from the team's description.

Keep the operation's valid target clear. An account-wide app-category exclusion does not need a campaign search. A keyword status question needs its group and campaign relationship.

Use the in-house audit guide when the question concerns a covered configuration finding. An audit can establish reported checks and limitations, while the conversation asks for the additional evidence needed by the team. A finding should not silently become a mutation.

Read search intent with its coverage limits

Search intent can help the team understand whether observed traffic fits the offer. A product or sales owner may need to confirm whether a phrase describes something the business actually provides.

Google's search-term guidance distinguishes actual queries from advertiser keywords and notes privacy-related omissions. A visible result is not a guaranteed list of every search.

Keep the matched keyword context where available. A search term's reported match relationship does not automatically establish the advertiser keyword's configured match type.

Separate an irrelevant intent from weak observed performance on a relevant phrase. The first can support a targeted negative decision when the offer is confirmed. The second may need measurement, destination or period investigation.

Do not claim that an empty filtered search-term result proves no unwanted query occurred. State the covered scope and period. The conversation can then ask a useful relevance question or prepare a supported exact-negative proposal without overstating what the provider exposed.

Retain product-targeting hierarchy

Product-targeting questions need campaign and group relationships. Performance Max uses asset groups; Standard Shopping uses ad groups. Each group can have its own listing segmentation.

The listing tree can move from all products through categories or brands to individual item criteria. A broad excluded node is not automatically a known count of individual items. Item resolution and hierarchy evidence matter.

The excluded-occurrence framework considers enabled groups within the requested scope. Repeated exclusions of the same product across different groups remain separate occurrences unless the user asks for unique items.

Performance conditions need a period and measure. An excluded product with unavailable return data is not a zero-return product. Keep unknown evidence distinct from values that meet or fail the requested threshold.

If the user asks to include or exclude selected products, preserve the exact occurrence targets. A selected-leaf action keeps unrelated partitions, while a complete retargeting action has a broader replacement scope. The proposal should make that difference readable before the authorised owner confirms.

Ask colleagues for missing business facts

Frame a question that one owner can complete

The account conversation can expose a question whose answer belongs elsewhere. If a campaign promotes an item with weak recorded outcomes, the product owner can establish whether the offer is current. Analytics can establish the outcome definition. Marketing can inspect the selected account population. These are separate tasks rather than one request for somebody to explain everything.

Give each owner the relevant context and acceptance question. The product colleague needs the named offer and the availability question. Analytics needs the selected action or event and the intended business meaning. Finance needs the amount, cycle and allowance decision. Passing the whole technical report to every owner can obscure the small fact each must supply.

Retain the answer's scope. A salesperson describing several recent enquiries has supplied those observations, not a measured quality score for every lead in the account. A product owner confirming one item's availability has not certified the whole inventory. The bot should use those facts at their actual breadth rather than expand them into unsupported account-wide claims.

Keep provisional answers recognisable. A colleague may recommend a temporary route before it is deployed, or propose a larger allowance before it is approved. The conversation should distinguish that recommendation from the established state. A dependent account proposal needs the selected intention and valid current evidence.

When the fact is established, connect it to the next decision. Marketing can explain which supported action would address the confirmed scope, while the authorised owner reviews the exact proposal. This turns a missing business input into a useful handoff without treating the colleague's answer as automatic permission to mutate the account.

Advertising data can establish recorded cost and outcomes, but it cannot answer every business question. Product availability, margin, fulfilment capacity and sales follow-up need appropriate supplied evidence.

Assign a focused question to the colleague who can answer it. The product owner can confirm an offer, analytics can define an event and finance can clarify an allowance.

Keep the supplied fact separate from provider evidence. A statement that the team postponed a launch is business context. A later cost reduction is an account observation. Their sequence can be described without pretending the advertising tool independently inspected the launch process.

The bot should ask for unresolved context when it changes the decision. It should not invent stock restrictions or lead quality from a campaign name or low return ratio.

Give the question completion evidence. The receiving colleague should know what answer is needed before a dependent proposal is prepared. Independent account investigation can still proceed on established facts. This keeps the conversation useful while preventing a missing commercial decision from becoming an unsupported live edit.

Follow an invented team conversation

This example is invented. Meadow Supply's marketing colleague asks which enabled campaign has the lowest purchase return over the last thirty completed days. The tools retrieve the relevant population and identify a named campaign using the stated measure.

The product owner explains that the campaign supports a temporary offer and confirms its present availability. Analytics retains the purchase definition so the conversation does not switch unnoticed to all-primary value.

Marketing asks for the same period by group. That changes the breakdown while retaining the account, campaign, dates and measure. A daily chart request would require daily evidence rather than invented points from the original total.

The team then decides whether a change is appropriate. If it requests a group pause, the tool prepares a supported proposal with the named group and campaign context. The read and business discussion have not yet mutated the account.

The authorised owner confirms only after reviewing the exact step. The execution result and later performance observation remain separate. The example illustrates a contextual investigation, not a real client result or a universal instruction to pause whichever campaign ranks lowest.

Use a thread for a focused investigation

When a colleague joins midway, give them the current selected question rather than only the latest number. A short note with account, dates and outcome meaning prevents them from interpreting a purchase-specific answer as an all-conversion result. This explanation can use established evidence without another retrieval. If they request a genuinely different population, record that change and let the tools establish the new result instead of relabelling the earlier figures.

A thread keeps the question, evidence and decision together. It helps colleagues follow the target and scope without starting a new unrelated account conversation at every step.

Use follow-ups that identify what changes. “The same period by campaign” preserves the measure. “Now purchases only” changes the selected outcome. “The campaign just discussed” retains a target reference that the tools must resolve confidently.

Keep ambiguity explicit when names recur. Parent context can identify an ad group or keyword more reliably than its name alone. The bot should not choose the first similar target merely to avoid a clarification.

Ordinary account questions remain read work until an edit is requested and prepared. A colleague saying a value looks poor is not the same as authorising a pause or budget change.

The in-house reporting guide explains consistent measures and periods for shared updates. The thread can build on that agreement while asking new scoped questions, rather than silently abandoning the definitions as soon as another stakeholder joins.

Use AI conversation without unnecessary account calls

The AI can help with creative and explanatory work using supplied context. Headline suggestions, descriptions, keyword brainstorming and a clearer team handoff do not automatically require provider data.

Keep the output's status clear. A suggested keyword is an idea. Researched historical traffic is provider evidence. Observed account performance is another type of evidence. The request determines which kind is needed.

A creative request can mention a product discussed earlier without becoming a Keyword Planner call. The bot should use the supplied product context when the user asks for ideas rather than measured volume.

Current account facts still need tools. Claiming a headline performed best, a campaign is enabled or a keyword recorded a particular return requires evidence from the requested account population.

Creative suggestions also do not execute themselves. The user can refine copy in conversation, then request a supported proposal for the exact asset. This preserves useful language work while keeping factual retrieval and live mutations tied to their actual purpose.

Reuse evidence when the question only changes form

Recognise the difference between a new format and a new fact

A user may ask for a shorter explanation after receiving a table. That changes the wording, not the account evidence. The AI can summarise the established rows while retaining their measure, period and coverage. It should not manufacture another provider query just because the answer's format changed.

A request for a different breakdown can be a new fact question. An account total does not identify which group contributed to it. The tool needs the supported group population and appropriate scope. If those rows were already retrieved in the same investigation, they can be reused; otherwise the new question needs a focused read.

A request for the current state after execution is another distinct question. The earlier target read may have supported proposal preparation, but it cannot prove what the provider now stores. The next read should inspect the relevant target instead of rerunning every unrelated account query from the beginning.

Keep the data's uncertainty when reformatting it. A missing value remains missing in a chart, table or prose summary. A bounded population remains bounded. A visual should not erase the caveat merely because it has less space for explanation.

Reuse is useful when it preserves the user's question and evidence. It is not an excuse to answer a new period from old dates or invent a daily pattern from an aggregate. The conversation should state what changed in the request and retrieve only the additional evidence needed to answer that change.

The conversational reporting path can reuse suitable returned data when a later request only changes presentation. A table or clearer summary of the same established population should not require the same provider query again.

Local capability discovery can identify available fields, settings and registered datasets before retrieval. That information does not need an account call merely to explain what the tools can request.

New evidence is needed when the question changes its source, period, population, measure or time grain beyond what the returned data contains. A single total cannot supply a genuine daily series.

Keep the evidence's current-state limits. Reformatting an earlier snapshot is different from asking whether a target changed after execution. The latter needs an appropriate later read when the original evidence cannot answer it.

Do not retry the same unsupported or nonretryable request unchanged simply because the user asks for a different wording. The next useful step is a valid capability choice, narrower request or explicit missing selection. Reuse should improve the investigation without replacing new facts with stale assumptions.

Request a visual that fits the question

A chart or table is useful when it supports the requested decision. A time series can show a pattern, a target table can support review and a simple setting may be clearer in a sentence.

The native chart path supports a bounded number of series and points. It aims for one chart with coarser time grain on longer periods when daily detail was not explicitly requested. A forced daily split should be explained rather than presented as separate unrelated answers.

Keep aggregation valid. Additive inputs can be summed into a week, while ratios should be derived from those summed inputs. Averaging rounded daily return ratios can distort the overall value.

Cross-source comparisons need related business meanings and visible labels. Ads value and Analytics purchase revenue can be compared while retaining their distinct attribution and populations. They should not be added into a combined revenue total.

The current named-comparison and multi-table release gates remain limits on verified delivery. A field being present in a catalogue does not establish every output combination. The user should receive supported evidence and a clear boundary rather than an invented chart whose points were never returned.

Keep unavailable results and support boundaries clear

An unavailable read is not a zero. The answer should identify the missing source, field or selection instead of presenting an empty healthy result.

Partial results can still be useful. Retain established evidence and name the unavailable slice. Do not widen the conclusion to the entire account when the requested population was not fully retrieved.

Undefined ratios also need their own treatment. No usable denominator prevents the ratio; it does not make the target a low-cost success. Read the additive inputs separately.

Some requests need a valid capability choice or a manual provider workflow. The bot should state that boundary before promising an executable change or a detailed result outside current support.

Give a precise next step. The user may need to confirm an event, clarify a target or restore the connection. A focused question helps the team continue useful work, while a vague apology leaves it unsure what evidence is missing. The limitation should preserve the user's original question rather than substitute an easier unrelated answer.

Turn an established decision into a supported proposal

When the team requests a live edit, the tools prepare a proposal with the exact target and operation. The investigation itself has not yet made a change.

Read each logical step separately. A campaign budget change, group pause and keyword addition affect different targets. Clear steps and parent names make the proposal reviewable for a normal user.

The dependency framework should preserve prerequisite order for supported creation chains. It also should avoid unnecessary target searches for operations that have an account-level target or no unrelated dependency.

The proposal has a limited validity period and relevant settings are checked again before execution. Confirmation is bound to the authorised connected owner and proposal actor under the current Slack controls.

Commercial decisions and execution access remain distinct. A product or budget owner can supply the reason while the authorised actor confirms the supported account request. The approval workflow explains this handoff. A discussion of possible changes is not a collection of silently authorised mutations.

Read the account outcome before another edit

After authorised confirmation, the interface indicates that the change is in progress. Execution checks authority and relevant current settings before sending the prepared request.

A verified result establishes the expected account outcome within the tool's scope. An accepted result can mean the provider acknowledged the request without independent final-state confirmation. An uncertain outcome means the target may already have changed.

Do not blindly repeat an uncertain edit. Inspect the current target before requesting another mutation. A delayed completion message does not prove that the original provider request never happened.

Verification is also separate from later policy, delivery and business results. A creative setting can be verified while provider review is pending. A budget setting can be verified without guaranteeing future expenditure.

Record the exact account result and next observation. Cancelling a pending proposal does not reverse an earlier execution; a reversal requires a new supported proposal from current evidence. The conversation should show those stages clearly so another colleague does not repeat a completed action under the impression that it remained pending.

Leave the next colleague a clear question

Preserve the selected version of the investigation

A thread can begin with a broad performance overview and evolve into a purchase-only campaign question. The handover should identify the latest selected definition while retaining earlier outputs as answers to their own questions. Do not merge their figures into one supposed population if the measure changed.

Keep explicit user corrections. If the user asks to use total paid traffic rather than a narrower source selection, that correction belongs in the subsequent plan. Another colleague should be able to see which population was selected without relying on the first message alone.

Event confirmation needs the same care. An AI suggestion is not the selected event until the user named or confirmed it. Retain the confirmed meaning and any remaining capability boundary so the substitute does not silently choose another similar name.

Also preserve action status. A target can be identified, discussed and included in a pending proposal without being changed. A later execution can be verified, accepted or uncertain. The handover should not collapse those stages into the vague statement that the team dealt with it.

End the note with one concrete next question and its owner. That may be a commercial confirmation, current-state inspection or supported new breakdown. A clear continuation point helps the substitute make progress on the same account investigation instead of repeating completed work or executing a discarded alternative.

A useful handover states the account, named target, period, measure and unresolved decision. The next colleague should not need to infer the scope from a long thread of changing requests.

Keep confirmed business facts with their owners. A product-range answer, event definition and budget allowance are separate inputs. Retain what each person established and which dependent action remains pending.

Preserve the distinction between earlier suggestions and the selected proposal. A thread can contain several alternative headlines or targeting ideas. They are not all instructions waiting to be executed.

Retain unavailable slices and bounded counts. A completed action on one target does not make the earlier partial investigation complete. The substitute needs to know which evidence still limits the conclusion.

State the next useful request. It may be a current target read, a broader population or a supplied commercial fact. This gives the colleague a concrete route to continue the same investigation without unnecessary repeated calls or a new question that abandons the team's established definitions.

In-house account-question answers

Does every message require a provider call?

No. Creative and explanatory work can use supplied context. Current account facts need appropriate evidence, while local capability discovery does not need provider retrieval.

Does an unspecified target mean one campaign?

The current policy defaults to the whole account when no target is named. The answer should state the used scope and period.

Can the team use inclusive conditions?

Yes. The shared framework distinguishes strict and inclusive numeric comparisons and supports combined logic within valid source capabilities.

Does a visible preview establish the full count?

No. Complete counts need the requested population's coverage. A bounded or partial result should retain that limitation.

Does identifying a target authorise its pause?

No. The supported edit flow prepares an exact proposal and requires authorised confirmation. The read and the live action are separate stages.