Performance questions and recurring delivery

Google Ads reporting in Slack with clear metrics, periods, and useful follow-up questions

Ask for the account evidence you need, request a readable chart or table, and configure recurring Reporting when the same review belongs in the channel regularly. Keep scope, conversion definitions, comparison periods, and decisions explicit.

A good performance report makes a decision easier. It identifies the account activity being discussed, uses metrics that fit the business, and presents enough evidence to support the next question. A long collection of numbers can look thorough while still leaving the reader uncertain about what changed or what to investigate.

Slack reporting brings that evidence into the place where the team can discuss it. The owner can ask for a period, the operator can inspect a campaign breakdown, and the assistant can generate a requested native visual from provider data. A recurring configuration can deliver a stable review without requiring the same manual request every week.

ppctor has both conversational reporting tools and a current recurring Reporting feature. These are related workflows, with different entry points and review needs. This guide explains how to use them deliberately. Its scenarios are invented examples, not customer accounts or claimed results.

Start with the business question

Begin with what the reader needs to decide. “How did the account perform?” can be a useful opening, but a more specific question produces more useful evidence. The owner may want to know whether spend is rising faster than outcomes, which campaign contributes the most value, or whether a named conversion changed after a website release.

Identify the business model. A retailer often needs purchase and value measures. A service business may need primary leads, calls, or a named conversion. A campaign with a different objective may need another selected outcome. The assistant should use the intended measure rather than force every account into a purchase-only template.

Specify the account or campaign when the context requires it. A connected Slack channel provides account context, but a discussion can still mention several campaigns. The assistant should preserve the current target and clarify ambiguity before retrieving or ranking the wrong population.

Decide whether the question concerns a total, a trend, a breakdown, or a relationship. A total answers how much occurred. A time series shows when it occurred. A campaign breakdown shows where it occurred. A comparison across sources examines related measurements with different definitions.

Do not request every available dimension by default. Adding device, geography, audience, and campaign detail at once can obscure the question and increase retrieval work. Start with the evidence that addresses the actual decision, then add a justified breakdown when the result raises a specific uncertainty.

Keep the known business context in the conversation. A promotion, stock change, launch, or planned pause can matter to interpretation. The assistant should distinguish those user-supplied facts from provider observations rather than pretend it independently retrieved every commercial detail.

The report should leave the reader with a concrete next question or decision. That can be further investigation, acceptance of expected performance, or a request to prepare a supported edit. A report is still useful when the correct conclusion is to leave the account unchanged.

Choose conversational or recurring reporting

Conversational reporting suits a question that arises now. The user can ask for the last thirty days, narrow the answer to one campaign, add a condition, or request a chart. The assistant uses available data tools to answer the current request and can carry the established plan into a follow-up.

Recurring Reporting suits a stable review that the team wants delivered on a schedule. The user chooses the source, target, metrics, period, comparison, and delivery settings. The saved configuration then supports future runs rather than relying on the model to reconstruct the same instruction from memory.

The current feature is called Reporting. It should not be confused with an older standalone Report workflow that has been removed. Use the current management controls and commands rather than assume an old article or remembered command still describes the product.

A one-time chart request does not need a new recurring configuration. The assistant can read the requested data and render the requested visual. Conversely, a request for a regular delivery should use the explicit Reporting setup rather than promise that an ordinary chat response will remember to post later.

Choose the path according to the user's intent. “Show yesterday's campaign results” is an immediate read. “Send this account review every Monday” is a schedule request. A useful assistant recognizes the difference and does not make the user navigate a recurring form to answer a simple factual question.

Keep configuration and execution distinct. Saving a recurring report sets its future behavior. Running it now requests a current delivery through the supported action. Neither is a Google Ads mutation. The account's budget, campaign states, and creative remain unchanged by a report read.

The workflows can support each other. A recurring report can prompt a conversational investigation, and a useful conversational analysis can inform the next saved configuration. The team should still review the stable fields instead of assuming every temporary follow-up automatically changes the schedule.

Keep metric definitions visible

Metric labels must describe the selected measurement. Spend is advertising cost. A conversion count depends on which actions are included. Conversion value can include value from several primary actions. Purchase-specific revenue is narrower. The assistant should preserve these distinctions in both the data request and the output.

For the general Ads conversion measure, the intended business framework includes primary actions by default and excludes secondary actions unless the user requests them. A named conversion can be selected explicitly. Do not silently replace that selection with a broader raw column that has a different inclusion rule.

Several primary actions can contribute to the aggregate. The report should reflect the configured primary measurement the user requested, not rewrite it to fix a suspected duplicate implementation. Deduplication investigation is a separate task. The reporting tool should not remove an action merely because two labels appear related.

Purchase and lead categories can support aggregate business measures, while a named action supports a specific outcome. Lead subcategories need not become separate business concepts in every answer. If the user wants all primary leads, preserve that aggregate rather than make an unrequested distinction between lead labels.

Calls and imported offline outcomes can also be part of the account's measurement. Their visibility does not create an automatic Analytics equivalent. A request to list or report them should use their available action metadata and relevant results, not invent a cross-source event counterpart.

A ratio needs an explicit numerator and denominator. Ads return on spend, purchase-only return, and a website-wide blended return can answer different questions. Total website revenue divided by the selected advertising cost should be described as blended ROAS or MER, with the spend scope stated.

Average purchase value is another distinct ratio. The output should use compatible purchase value and purchase quantity rather than divide a broad all-action value by an unrelated order count. Clear inputs are more useful than a familiar label attached to the wrong calculation.

Google's Analytics Data API schema documents separate metrics for sessions, events, key events, and purchase-related revenue. These are different quantities. Use the relevant documented measure rather than assume every outcome or revenue field can replace another.

Use the intended dates and comparison

A rolling period and a calendar period are different requests. Last thirty days means a defined recent window. Last month means the previous calendar month. This month through yesterday means the completed portion of the current month. The report should show the actual boundaries so the reader can verify the interpretation.

Completed-day reporting avoids presenting the current partial day as if it were complete. The recurring range options resolve in the configured reporting time zone. A reader in another country may have a different local date, so the report's period needs to remain tied to its selected context.

Do not omit the most recent completed day merely because the provider updates asynchronously. The period request and data freshness are separate concerns. Retrieve the requested dates, then identify any material availability issue rather than silently substituting an older end date.

A previous-period comparison generally uses the corresponding preceding window. A year-over-year comparison uses the relevant prior-year period. Month-to-date comparisons need attention when the previous month has fewer days. The report should not hide a clamped comparison as though both date spans were identical.

Ask what the comparison is meant to control for. A previous period can show recent movement. A prior-year period can provide seasonal context. Neither automatically accounts for changed promotions, inventory, conversion configuration, or budget. Interpretation still needs business context.

Use readable date labels in charts. Current-year labels need not display a long numeric year on every point. Older periods need enough context to distinguish the year. Weekly output should identify meaningful date ranges rather than expose a provider code that the client must decode.

Preserve an explicitly requested daily grain. If the period needs more native chart space, explain the resulting presentation boundary rather than silently aggregate away the requested detail. When no daily detail is required, a coarser readable grain can keep the trend in one chart.

Retain the date basis for conversion comparisons. A conversion-date view and an interaction-date view answer different questions. The business reporting framework can select the appropriate basis, and a user-requested override should be explicit. Do not change the basis halfway through a thread without explaining the new measurement.

Preserve shared scope and series populations

A report can have one shared restriction and several different series populations. For example, the country can remain fixed while one series covers all traffic and another covers a selected paid segment. The assistant should apply the shared restriction to both and keep each population explicit.

“Total” needs a defined boundary. Total paid activity is not total website activity. Total within the selected country is not worldwide activity. A follow-up asking for the total should resolve against the established plan and the user's correction, not infer which filter is easiest to remove.

Keep selected channel membership deliberate. A paid grouping can include several channels chosen for the request. The total should use that grouping consistently. Do not substitute a different built-in channel label merely because it sounds similar to the user's wording.

Preserve scope when changing the visual. A table of paid activity in one country should not become an all-traffic chart when the user asks for a line instead. The rendering request changes presentation; it does not authorize a new population unless the user asks for one.

Preserve scope when adding another metric too. Spend and revenue in the same report need compatible target and period context. A campaign-specific spend series and an account-wide revenue series can be misleading if the output implies they cover the same population.

Use separate readable labels when populations intentionally differ. The user may want total website purchase revenue alongside Ads attributed conversion value. The graph can compare them with distinct definitions, but the assistant should not add them together as one revenue total.

If the user corrects a population in a follow-up, use that correction in the actual plan. Repeating an explanation while rerunning the unchanged wrong scope does not answer the request. The report state and provider selection need to reflect the latest explicit instruction.

Clarify genuine ambiguity with a focused question. “Do you mean all paid channels within Canada or all website traffic within Canada?” identifies a meaningful choice. Avoid making the user repeat the entire request when only one population boundary is unresolved.

Apply filters and rankings faithfully

A condition defines the population, and a ranking orders it. The assistant should keep those operations distinct. “Campaigns with spend at or above the threshold, ranked by return” first filters eligible campaigns and then ranks the valid results using the chosen measure.

Preserve inclusive and exclusive comparisons. Higher than differs from higher than or equal to. Lower than differs from lower than or equal to. The selected condition should match the user's meaning, especially when the threshold determines which targets might later be proposed for editing.

Preserve logical combinations. “Spend above the boundary and no primary conversions” is not the same as either condition alone. An OR request selects a different population. The assistant should use the supported condition framework rather than approximate the request with a loose sentence.

Do not rank undefined ratios as zero. A campaign without the denominator needed for return or cost per result needs the appropriate unavailable state. Treating it as an ordinary zero can distort a worst-performing list and lead to an unsupported action recommendation.

Ask whether minimum evidence is needed for the decision. A user can set a spend or activity condition to avoid a ranking dominated by tiny samples. Apply the chosen condition explicitly rather than invent an undisclosed policy that changes which campaigns qualify.

Counts need complete population evidence. A list showing a small number of examples should not be counted as an account total. The reporting framework distinguishes count requests from capped presentation. If complete coverage cannot be established, the answer should say what selection needs narrowing.

For a deeper asset, include parent context in the output. A keyword belongs to a group and campaign. An excluded product listing can have a campaign and relevant group structure. The reader needs enough hierarchy to understand the row without seeing internal identifiers.

A ranking is evidence, not an automatic edit instruction. The user may ask which campaign has the lowest selected return simply to understand the account. If they later request a pause, the exact target and action should be prepared for approval under the live-edit workflow.

Request a readable native chart

Ask for a visual when it helps the question. A line chart suits change over time. A bar chart can compare categories or daily values when requested. A table suits precise reading. The assistant should follow the requested format rather than always append a chart to every factual answer.

The conversational framework renders requested provider data. It does not accept invented numerical arrays from the model as a substitute for a report. This keeps the visual tied to the retrieved evidence and prevents a plausible-looking graph from being mistaken for measured account activity.

Related metrics can share a native chart when the selected plan is valid. Spend and value can appear as separate bar or line series with clear labels. The system should not create two unrelated graphs merely because the user asked for two metrics in one comparison.

The application limits one graph to three metrics or segments to keep it readable. If the user requests more, ask them to choose the most useful series or split the question deliberately. A limit explanation should identify the presentation choice rather than claim the provider has no data for the additional measures.

Native presentation also has a point boundary. The current framework works with twenty points per chart and a bounded multi-chart message. For an automatically chosen time grain, a coarser weekly or monthly view can preserve a single readable chart. An explicit daily request needs its detail retained or an explained alternative.

Choose labels that make the series understandable. A graph of Ads primary conversion value and GA4 purchase revenue should name both. Calling them “Revenue 1” and “Revenue 2” hides the source distinction that matters to interpretation.

Use appropriate units and readable precision. Money, percentages, and ratios should not display long decimal tails. The axis and series labels should make the scale clear. A technically correct value can still be difficult to use when the presentation overwhelms the reader.

Do not force missing measurements into zeros to connect a line. A gap can represent unavailable evidence rather than no activity. If native multi-series coverage cannot represent the result faithfully, use the supported clear presentation and explain the missing coverage instead of inventing continuity.

Use tables for precise comparisons

A table is useful when the reader needs exact values, several named targets, or a condition-based list. It can show campaign results, a selected event comparison, or a hierarchy of relevant assets. Choose columns that answer the question rather than reproduce every available provider field.

Put readable labels first. Campaign and group names establish context. The requested metrics follow. IDs and resource paths normally belong behind the scenes. A client-facing row should not require technical knowledge to identify the asset being discussed.

Keep units explicit and formatting consistent. Two money columns should use the relevant currency context. A ratio and a percentage should not share a misleading symbol. Precision should be enough to support the decision without six-decimal clutter.

Sort by the requested measure. A table described as the worst campaigns should not arrive in arbitrary provider order. If the ranking needs a valid denominator or a population filter, establish that before rendering rather than sort an incomplete or invalid sample.

Keep totals separate from examples. A short list can illustrate the leading results, while the account total needs its own evidence. The assistant should not sum capped rows and call the result the full account's performance unless those rows actually cover the intended population.

For a comparison, identify the baseline. The reader should know whether a change is against the previous period or the prior-year period. A difference column without a clear baseline is difficult to interpret and can imply a result the user did not request.

Do not add technical provenance as a prominent client-facing column when it does not help the decision. Provider details and retrieval internals can remain available where needed, while the ordinary output focuses on the selected business measures and material coverage notes.

Choose a manageable selection when a table becomes too large for conversation. Narrow by campaign, condition, or ranking, or use a feature-specific supported export where available. Do not promise a universal file generator for every reporting dataset merely because another research tool offers downloadable output.

Compare Ads and Analytics deliberately

A cross-source comparison should begin with the quantities the user wants to compare. Ads attributed primary conversion value and Analytics purchase revenue are related monetary measures with different scope and attribution. Showing them together can be useful without claiming they should always match.

Do not prohibit a useful comparison merely because the sources use different attribution. Use distinct labels and retain the chosen traffic scope. The purpose may be to see the relationship or discrepancy, not to add the series into one supposedly reconciled revenue figure.

For leads, select the corresponding Analytics event. Event names differ between sites. The assistant can retrieve observed event names and suggest a likely candidate by name, but the user's selection or confirmation is needed before treating it as the intended counterpart.

A named Ads conversion can be compared with a specific user-selected Analytics event. The report should retain those names in the series labels. A generic total should not replace the requested individual action because it is easier to retrieve.

For an aggregate comparison, preserve the requested definitions. All primary Ads conversions can be compared with the intended aggregate of Analytics key events. That does not mean the event sets are semantically identical or that every difference indicates a tracking error.

Traffic scope matters for revenue and return. Total website revenue includes a broader population than revenue attributed to a linked advertising account. If the user requests the broad view divided by selected spend, label the result blended ROAS or MER rather than silently narrowing it to Google traffic.

Advertising cost from Analytics depends on its available linked or imported data context. Do not assume its total must equal the live Ads account cost without checking the selected scope and definitions. A comparison can show both, with the relevant limits stated.

Keep offline and call questions grounded in their available Ads data. The ability to list these actions does not require inventing an Analytics pair. If the user asks only for their Ads results, answer that question directly and reserve cross-source matching for an explicitly selected counterpart.

Distinguish missing data from measured results

Google's data-freshness guidance explains that reporting does not update instantly and can be adjusted later. A recent completed period can still receive later outcome data. State the requested dates and interpret the result with the relevant measurement maturity.

A successful report with no matching activity differs from a failed retrieval. The assistant should not say the account recorded zero because a provider request failed. It should identify the unavailable evidence and use the supported recovery or narrowing step.

An unsupported report combination is also different from a provider limitation. The tool can return a structured selection error that the assistant should use to revise the plan. Repeating the unchanged invalid request adds delay without producing new evidence.

Keep partial coverage visible. A report may have a population boundary, an unavailable field, or source-specific metadata that affects interpretation. The output should identify the material limitation without burying the client in every technical detail of the API response.

Do not turn gaps into confident conclusions. Missing daily values do not prove that a source only offers totals. A failed mapping does not prove that the metric does not exist. The assistant should inspect the available catalogue and relevant tool result before making a factual capability statement.

Use retrieved totals consistently with the visual. The written answer and chart should describe the same report plan. Recalculating a total from a displayed sample or making another unnecessary read can create a mismatch between the text and graph.

When an observation is unavailable, choose a faithful output. A table can expose gaps more clearly than a connected line. If the source combination needs a selected event or currency decision, ask that concrete question before producing a misleading chart.

A report can be useful while still identifying a next check. “The selected measure changed; the recent outcomes may still mature” is a bounded interpretation. “Tracking is broken” requires separate evidence. The assistant should keep reporting observations and diagnosis distinct.

Configure recurring delivery

Recurring Reporting supports daily, weekly, and monthly schedules. The owner chooses the report time and applicable weekday or month day in the configured time zone. The schedule controls delivery, while the selected range controls which activity the report covers.

Choose the source and target first. A Google Ads account or campaign review differs from an Analytics segment review. The saved configuration should make the selected context clear, and the user should check it before saving rather than assume the form inferred every detail correctly.

Select a concise set of metrics that serves the regular audience. A weekly owner review may need spend and selected outcomes. An operator's review may need another performance measure. More columns are not automatically more informative.

Select the range and comparison explicitly. A weekly delivery can still report a rolling thirty-day window if that is the chosen review. The delivery frequency does not define the reporting period. Keeping them separate prevents a schedule label from becoming a false description of the data.

Run Now is the supported immediate execution choice for the current feature. It does not replace the recurring schedule. The saved configuration can be used for an on-demand delivery when the user needs it, subject to its enabled state and supported controls.

Do not describe a Preview feature as current. The active workflow uses the saved configuration and Run Now behavior. A user should not be directed to an obsolete action or route simply because an older plan mentioned it.

Manage the configuration when the review changes. Pause a temporary delivery, resume it when appropriate, edit the selected metrics or period, and remove a report that is no longer needed. A reporting routine should remain aligned with the current account ownership and business calendar.

Saving the report does not authorize account changes. The delivery can prompt a conversation and an approved edit later, but the Reporting configuration itself does not pause a campaign, change a budget, or upload creative.

Three illustrative reporting workflows

A retailer asks for a recent trend

An invented retailer asks for spend and the intended Ads primary conversion value over the last seven complete days, shown daily in one bar chart. The assistant uses the connected account, resolves the dates, retrieves the two measures, and renders the requested series together with distinct readable labels.

The owner then asks for the campaign with the largest contribution to spend. That is a follow-up breakdown using the established period, not permission to change the account. The assistant retrieves the needed campaign evidence and keeps the metric definitions consistent.

If the owner requests a pause, the tool prepares a separate proposal for the resolved campaign. The graph remains evidence for the discussion. It does not become a hidden automation rule or authorization for a live write.

A service team compares a named outcome

An invented service business wants the Ads Contact Request conversion compared with a site-specific Analytics form event. The user names the event after reviewing the available candidates. The assistant keeps that selection and uses distinct labels for the two daily series.

The graph shows the requested relationship without pretending that attribution and event populations are identical. A discrepancy prompts investigation of the definitions and website context. The assistant does not claim an error solely because the two lines differ.

The team can ask for a table of exact daily values or change the period while retaining the selected outcome names. Presentation changes should reuse the available data where possible and should not silently switch to all leads or all key events.

An agency schedules a stable client review

An invented agency wants a weekly review in the client's connected channel. The owner configures the selected source, account scope, metrics, complete reporting range, comparison, and delivery time. The form is reviewed before saving.

The recurring output gives the team a stable starting point. A client question about one campaign becomes a focused conversational read rather than an automatic edit of the saved configuration. If the team wants future reports changed, it updates the explicit Reporting settings.

When the client's operating plan changes, the agency reviews the schedule and metrics. It does not keep posting an obsolete review simply because the original setup succeeded. The reporting routine remains useful by reflecting the current audience and business question.

Continue the Slack conversation

For an immediate report, ask naturally: “Show the selected campaign's primary conversions for the last thirty complete days.” Add the desired breakdown or visual when it helps. The assistant should use the established account context and ask only for choices that materially affect the result.

For a visual, say what you want to see: a line over time, a bar comparison, or a table of exact values. The tool can reuse returned report data for rendering rather than make another provider read solely because the format changed.

For a follow-up, preserve the meaning of “same.” “Use the same period” should retain the dates. “Use total paid activity” should retain the defined paid population. The assistant must update the plan when the user corrects it instead of repeat the same wrong interpretation.

For recurring setup, use /ppctor reporting to manage the current feature and /ppctor reporting create to begin a new configuration. Use /ppctor reporting help for the declared command options. Review the form's selected source, target, metrics, dates, and schedule.

Keep explanatory and creative requests conversational when no account fact is needed. The assistant can explain what a ratio means or suggest how to structure a review without fetching the whole account. It should retrieve live evidence when answering what actually happened.

A concise reply should still be precise. State the result, relevant period, and material definition. The requested visual can carry the detail. Avoid a long technical narrative that forces the client to search for the answer among internal field names.

Move from evidence to an approved action

A report can identify a target worth investigating, but the selected metric does not determine the correct edit by itself. The owner may decide to pause, adjust a supported setting, replace creative, or leave the account unchanged based on the business context.

When an edit is requested, resolve the exact target from the evidence and current configuration. A campaign action needs the campaign. A deeper asset needs its correct parents. Do not use a table row's position as the only target reference after the report has been reordered.

The proposal should describe the exact live change in readable steps. It is separate from the report output. The owner can inspect the intended treatment and click Confirm and Execute before the API mutation occurs.

Relevant settings are checked again before execution. Another operator may have changed the account during the discussion. A valid report from earlier in the thread is not permission to overwrite a new state without reconciliation.

The final receipt verifies the applicable configuration result. Later reports evaluate performance under the new state. Do not equate a successful mutation with proven business improvement or claim a causal gain from a comparison affected by several simultaneous changes.

Record a no-change decision too when it matters. Expected promotional activity or immature outcomes can justify waiting. The report has helped the team make an informed decision even when no live edit follows.

Maintain a useful reporting routine

Review the regular audience and decision purpose periodically. A client owner, account operator, and finance team may need different views. Keep the recurring selection focused on what its readers use, while conversational tools handle the questions that arise between deliveries.

Document important metric definitions and conversion selections. A later analyst should understand whether a revenue figure represents all primary value, purchase-only value, or website-wide purchase revenue. This prevents a change in definition from masquerading as a change in performance.

Review the schedule after account transitions, campaign launches, and business-calendar changes. Time-zone and period settings matter. A report arriving reliably can still describe an outdated range or target if nobody maintains the configuration.

Keep a clear distinction between reports, alerts, audits, and live edits. Reports present evidence. Alerts test a chosen boundary. Audits review configuration. Approved edits change selected settings. The tools can support one workflow without being described as interchangeable.

Use material coverage notes and stable formatting. Readers should know when evidence is unavailable or definitions differ, while routine results remain easy to scan. Precision is useful when it supports interpretation; unnecessary technical clutter reduces the value of the conversation.

Evaluate the routine by the decisions it supports. If a recurring report never prompts a useful review, change its purpose or selection. If the same follow-up appears each week, consider whether that evidence belongs in the stable configuration. The aim is a reliable business conversation rather than a growing number of scheduled posts.

Common reporting questions

Do I need to create a schedule to ask for a chart?

No. Conversational tools can retrieve and render the requested evidence immediately. Use recurring Reporting when the same review should be delivered regularly. A temporary question does not require a saved schedule.

Can two related metrics appear in one chart?

Yes, when the plan and coverage support the requested comparison. The application supports up to three readable metrics or segments in one graph. Keep labels, populations, units, and source definitions explicit.

Does last thirty days mean last month?

No. A rolling period and the previous calendar month are distinct selections. The output should state the actual dates, and completed-day recurring ranges end at the relevant yesterday in the configured reporting time zone.

Can Ads leads be compared with a site-specific event?

The framework supports an explicitly selected Analytics event counterpart. The assistant can list and suggest observed names, but the user must select or confirm the intended event before it is treated as the corresponding measure.

Does running a report make an account change?

No. A report retrieves and presents evidence. A live edit uses a separate proposal and confirmation. Read the execution handoff guide for that workflow.

What if the report cannot retrieve the requested evidence?

The assistant should identify the actual unavailable read or invalid selection, preserve the requested scope, and use the appropriate correction. It should not invent values or declare a provider limitation merely because one tool plan failed.