Slack Google Ads Reporting command guide: set the scope, schedule and comparison clearly

Choose a recurring update for a repeatable business question

A recurring report works best when the owner knows what question should be answered at each delivery. It might be whether spending and tracked outcomes are moving together, how a selected campaign compares with its preceding interval, or how a relevant Analytics population performed during completed days. A saved configuration makes that question repeatable. The team can then discuss changes rather than reconstruct the source, target, and dates every time.

The report is an evidence delivery workflow. It does not automatically pause campaigns, diagnose every cause, or repair measurement. Its useful role is to bring a consistent set of observations into the connected channel. A follow-up conversation can request more detail or prepare a supported confirmed edit when the owner wants action. Keeping reporting and execution separate allows stakeholders to review performance without accidentally authorizing account changes.

Use an on-demand conversational request when the question is new, exploratory, or needs a custom population. Use a saved report when the team has an established recurring review. These approaches complement one another. A conversation can help refine a useful reporting routine, while the routine reduces repeated broad requests for familiar data. The point is to choose the workflow that fits the information need rather than make every request a new schedule.

Begin with a short specification: source, target, metrics, interval, comparison, audience, and delivery cadence. Those choices determine how to interpret the result. A report labelled only “weekly performance” leaves too much unspecified. Weekly delivery could show yesterday, the last seven completed days, or a rolling 30-day view. A dependable setup names those differences before the first result arrives.

The current app feature is called Reporting and uses /ppctor reporting. It is the registered workflow for saved performance updates. This guide describes that current implementation rather than a retired legacy Report command. Matching the actual command matters because a user should reach the correct setup and management surface instead of follow instructions for a feature that no longer owns the reporting flow.

Choose the source before choosing what the numbers mean

The configuration supports Google Ads or Analytics as its report source. A Google Ads report can target the account or one selected campaign. An Analytics report uses the connected property and its supported target or segment selections. These are distinct source definitions. A property-wide revenue result should not be described as a selected Ads campaign's attributed conversion value merely because both can be formatted as money.

The connected channel establishes the Google Ads account context. Analytics reporting additionally requires an available Analytics connection for that account. If the property is not connected, the report cannot invent an Analytics value from Google Ads. The setup should explain the missing prerequisite, and the owner can restore the connection before saving the intended Analytics report. This is a data-access question, not evidence that Analytics recorded zero activity.

For Google Ads campaign targets, the current setup validates an enabled campaign selection. Once selected, the campaign name gives the user readable context while the underlying identity remains part of the authorized configuration. If the owner later changes campaign structure, review whether the saved target still represents the intended question. A name that looks familiar is not enough to justify substituting another campaign silently.

Analytics segment choices depend on the available property data and metric compatibility. The setup checks that the selected target has applicable values and that the metrics can be reported together for it. A named event population is different from all Analytics data. Do not compare their totals without acknowledging that difference. The property, event or segment, and period should remain clear in the resulting discussion.

One saved report is not a universal cross-source comparison tool. If the owner asks for an Ads and Analytics chart together, use the conversational reporting framework to establish each series and its compatible business measure. The scheduled report's source choice should remain truthful and simple. Trying to reinterpret one source's displayed numbers as another source creates confusion that no amount of attractive formatting can correct.

Use a metric set that helps interpret the decision

A useful metric set pairs the business outcome with enough context to interpret it. Cost without an outcome can show activity but not return. Conversion value without cost can show tracked value but not advertising efficiency. A ratio without its underlying activity can hide small samples. The owner should choose a concise set that supports the intended review, not select every available metric simply because the form permits it.

The current saved configuration accepts between one and ten compatible metrics. That is a reporting-table selection limit, not the native conversational chart's series limit. The two outputs have different presentation constraints. A saved metric table can contain more rows than a readable multi-series chart. If a user later requests a chart, the assistant should apply that requested visual's actual limits rather than assume all ten table metrics fit one plot.

The Google Ads catalogue includes core performance measures and selected Search impression-share and invalid-click measures. Not every metric has equal relevance to every campaign type or review. A Search impression-share question needs its Search context. An invalid-click measure answers a different question from conversion value. The assistant should explain the chosen measure when ambiguity matters instead of imply every catalogue field represents a business outcome.

The scheduled Google Ads catalogue labels its conversion-value measure Revenue. That label does not convert it into confirmed store revenue. It remains the configured provider conversion-value measure. If the owner needs purchase-only, named-action, or another explicitly defined outcome population, the appropriate focused reporting question should establish that measure. A familiar label should never override the actual source definition.

For Analytics, available monitoring metrics depend on the connected account type and target selection. A metric unavailable for the chosen segment should not be forced into the report. The setup checks compatibility rather than accept an arbitrary list. If the business question needs a different measure, review the target and source deliberately. A failed compatibility check is a useful boundary, not a reason to substitute an unrelated value without telling the user.

Review metric choice after measurement changes. If the business changes which outcomes are important, a previously useful recurring report can become misleading through continuity alone. Keep the reporting specification aligned with the intended outcome. The schedule can remain stable while the owner updates the measure, but colleagues should understand that a changed definition affects comparisons with earlier delivered reports.

Delivery frequency and data interval are independent choices

Daily, weekly, and monthly describe when the report is scheduled. They do not define how many days each result includes. The current range choices include yesterday, the last seven, fourteen, or thirty days, this month through yesterday, and last month. A daily report can therefore present a rolling month, while a weekly report can present a shorter interval. The form keeps these choices separate because they answer different operational questions.

Rolling ranges end with the previous completed reporting day. On October 2 in the relevant reporting time zone, the last 30 completed days end on October 1. They are not automatically the previous calendar month. Last month instead refers to its explicit calendar boundaries. This distinction matters near month changes, when two similar-looking selections can differ enough to change a performance interpretation.

This month through yesterday can be empty on the first reporting day of a month. The current renderer states that there are no completed days in this month yet rather than fall back silently to last month. That is a correct empty interval. It should not be mistaken for missing authorization or zero lifetime account activity. The owner can choose a rolling interval if a first-day report needs completed observations.

Reporting cadence uses the linked Ads account's time zone. Google Ads data periods use that account context, while Analytics data periods are resolved using the Analytics property's reporting time zone. Those calendars can differ. A report delivered at a familiar local hour does not guarantee both sources consider the same instant part of the same reporting day. Align actual date labels when discussing them together.

The selected delivery hour is a schedule setting, not a guarantee of immediate provider availability or a precise real-time arrival. Queue work, provider response, and delivery all occur after the due occurrence. Choose an operating cadence that fits the team's review rather than promise a second-by-second service. If the owner needs an intraday question, use the applicable conversational request with clear partial-day context.

Google's data-freshness guidance explains that performance metrics can arrive at different times and be adjusted later, including late conversions and invalid traffic. A completed calendar day is therefore not necessarily final immutable measurement. Keep that distinction visible when comparing an early report with a later provider view of the same dates.

Comparisons need both a named period and a valid baseline

The current comparison choices are none, previous period, and the same period last year. A previous-period comparison for a rolling interval uses the preceding interval of matching length. This-month-through-yesterday compares with the analogous elapsed portion of the prior month, clamped when that month is shorter. The message can identify the shorter calendar comparison so the reader does not assume equal day counts in every case.

Last-month previous-period behavior follows the shared completed-period engine's preceding equal-length interval. It is not a promise of a separate full previous calendar month for every selection. Read the actual date boundaries printed in the result. A period label is convenient, but the dates are the evidence for what was compared. If the owner needs a different calendar comparison, request it through an applicable custom analysis.

Year-over-year selections also need careful interpretation around calendar differences. The shared date engine maps the selected boundaries into the previous year and handles unavailable calendar days. The output retains the year when relevant to that comparison. A similar-looking interval still needs context about the business, promotions, and measurement definition before movement becomes a causal explanation.

A percentage change requires a valid nonzero previous value. If the previous value is zero, the report can show the observed values without fabricating a finite percentage increase. If a ratio lacks its required denominator, it remains unavailable. That is a mathematical boundary, not a formatting defect. Zero, no activity, and unavailable evidence should remain distinguishable so the owner can interpret the result correctly.

A large percentage can still represent a small absolute change. The result should be read with its current and previous values. A ratio can move because its numerator, denominator, or both changed. Use the table to identify which follow-up is useful before assigning a diagnosis. The scheduled report establishes movement within its configured scope; it does not establish why the movement occurred.

Comparison failure should not erase a readable current period. The current renderer can retain current values and identify unavailable comparison evidence. That lets the owner use the information actually obtained while knowing which claim cannot be made. Do not treat a missing comparison as a zero baseline, and do not announce improvement when the previous-period evidence was never established.

Read the metric table with its daily-average context

The current scheduled output uses a native Slack table for selected metric rows. It shows the current period and seven-day and thirty-day daily-average context. With a comparison, it adds previous values and trend movement. This is the configured scheduled report presentation. It should not be advertised as an arbitrary daily line chart generated for every report, because a custom chart is a separate requested visual workflow.

For additive measures, a daily average describes a total divided over its defined day interval. For ratios, the appropriate context comes from aggregated inputs rather than averaging each day's ratio indiscriminately. The report's shared metric definitions decide the calculation. The owner should read the column as the stated context measure, not assume every cell is a raw total or every metric uses identical arithmetic.

The seven- and thirty-day context can extend beyond the chosen current report period. A report showing yesterday can still show recent daily-average references. Those are separate windows ending at the report's period end. Their purpose is to help interpret the current observation, not to expand yesterday's total. Keeping the column labels clear helps readers avoid adding context averages to the current values.

Distinct-user measures need special care because a user can appear on several days while remaining one user over the full interval. The current Analytics context path requests daily observations for relevant averages. A daily average is therefore not automatically a full-period distinct-user count divided by days. This is why the underlying metric definition matters even when two table cells both look like simple numbers.

The table displays unavailable context as a dash when the required additional evidence cannot be established. A failed context read should not manufacture a reference value or make a valid current result disappear. The comparison and averages add context, but each has its own evidence requirements. The owner can ask a focused follow-up if an unavailable context column is essential to the decision.

A native table is useful for scanning, but it does not replace explanation. A short conversational follow-up can identify a meaningful change, request a metric-specific chart, or clarify the measure. It should use the returned evidence and preserve source and period. The assistant should not add dramatic annotations about performance quality solely because a trend cell has an upward or downward indicator.

No activity, an empty period, and unavailable data are different

No activity recorded means the successful read did not establish activity for that selected population and interval. An empty period means the date selection contains no completed days. Unavailable data means the report could not establish the required evidence. These three states must not collapse into a visible zero. The distinction determines whether the next task is a business investigation, a date-choice adjustment, or restoration of data access.

A campaign-level report can have no activity while the account has activity elsewhere. An Analytics segment can be quiet while the property has traffic in other populations. The saved target explains that scope. If the owner expected activity, inspect whether the intended target and date interval were selected before treating the result as a tracking outage. A narrow empty population is not an account-wide diagnosis.

Ratio availability has its own conditions. A return measure cannot be computed without applicable cost; an average cost needs the appropriate count denominator. The shared metric catalogue expresses these requirements. If a denominator is absent or zero, the result stays unavailable rather than use a misleading default. The owner can still inspect underlying measures to decide whether the population simply had no relevant activity.

Authorization, property connection, compatible metrics, and provider availability can each affect evidence. A report failure is not the same thing as a live-account edit failure. The configured run should identify the operational stage through its diagnostics and recorded state. The user-facing conversation should explain the actual missing prerequisite or observation rather than say “performance is zero” because a request failed.

Use a targeted next step. Check scope when the returned population is unexpected. Restore the connection when authorization is unavailable. Review compatibility when a segment cannot support a measure. Check later when the relevant provider data is still processing. Running the identical configuration again without identifying the problem can repeat the same failure and add unnecessary work.

Three reporting routines illustrate deliberate configuration

A daily operations review uses a rolling baseline

An invented retailer named “Oak Supply” wants a morning view of cost, tracked conversion value, and ROAS for its account. The owner chooses daily delivery and a seven-day completed range with a previous-period comparison. The report supports a recurring operating question: has the recent account return changed while spending moved? It does not promise that every day's conversion evidence is final or that a decline automatically justifies pausing campaigns.

When the owner wants to know which campaign contributed to a decline, the conversation requests campaign-level evidence for the same source and interval. The saved report remains the stable account view. A requested chart can use the applicable returned or newly required data. This is more useful than changing the saved target each time the operator asks a temporary investigative question.

A weekly campaign review preserves an explicit target

A fictional service business named “Maple Repairs” selects one enabled campaign and a weekly delivery cadence. Its metric set emphasizes spending, conversion activity, and a relevant efficiency measure. The owner chooses the data interval independently of the weekday. Colleagues can recognize that this is the campaign's recurring review rather than a complete picture of every campaign or every website event.

During a restructure, the owner reviews the saved target instead of assuming the familiar report name follows a newly created campaign. A paused report can preserve settings while the team decides the intended future target. Any live campaign edit remains a separate confirmed action. The reporting lifecycle should not itself pause or re-enable the actual campaign merely because the report is paused or resumed.

A property review needs Analytics context

A made-up publisher named “Cedar Guide” wants a recurring view of a supported Analytics population. The configuration uses the connected property and compatible metrics. The report's dates follow the property reporting calendar, while its delivery cadence uses the linked account schedule context. The owner keeps that distinction in the reporting specification so colleagues do not interpret a property-wide result as Google Ads-only activity.

If the owner later asks to compare a named Ads conversion with a particular site event, the assistant uses the applicable conversational measurement workflow. It does not assume the property report already selected that event. The owner can confirm the corresponding event when required. The saved routine continues answering its original question, while the exploratory comparison retains both source definitions.

Use the current command vocabulary, including its arguments

Run /ppctor reporting to open management for the connected account. Run /ppctor reporting create to open a new configuration, and /ppctor reporting help for current command guidance. Run /ppctor reporting list to see saved configurations and their short reporting references. The report reference identifies a saved schedule; it is not a campaign identifier.

The management commands for an individual saved report are /ppctor reporting edit #1, /ppctor reporting pause #1, /ppctor reporting resume #1, /ppctor reporting delete #1, and /ppctor reporting run #1. Replace the illustrative reference with the saved report shown by List. Missing references produce guidance rather than an inferred choice of the wrong configuration.

The account-wide management shortcut /ppctor reporting pause all pauses active report configurations for that account. It does not pause campaigns or turn off Analytics collection. That distinction is essential when an owner temporarily stops notifications during a handover. Report lifecycle actions affect the recurring delivery setup, while live-account changes use their own action flow.

The current management modal shows the selected source and target, metrics, interval, comparison, schedule, and enabled or paused state. Its row menu supports editing, pausing or resuming, and deletion. A Create action is available while the current account has room for another configuration. This gives users a visual management path alongside textual commands; neither requires inventing unsupported arguments appended to the base command.

At present, the account permits five saved reports, including paused reports. Pausing preserves the configuration and therefore does not free a saved-report slot. Delete an unwanted configuration if the owner needs another one. Choose the distinct business questions worth scheduling instead of creating duplicates with tiny metric differences that flood the channel without adding a useful review.

Create or edit the configuration through the reviewed form

The form selects source, target, frequency, reporting time, applicable weekday or month day, metrics, time frame, and comparison. The account context appears with its time zone, and the Analytics property appears when selected and connected. These settings form a reporting specification. Review them together before saving; a familiar metric set cannot compensate for a wrong account or interval.

Campaign selections are checked against enabled campaigns during setup. Analytics targets and metrics have their own connection and compatibility checks. Validation can reject a target that no longer fits the saved intent instead of silently substituting another one. If a configuration cannot be saved, correct the actual field or prerequisite. Do not treat a validation message as an instruction to choose arbitrary values merely to get a report delivered.

The form can offer Run Now after saving. Selecting it saves the configuration and queues a report; it is not an instant preview of unsaved settings. The confirmation indicates that the report was queued. Its delivery occurs through the run workflow. The schedule remains the chosen recurring schedule rather than being replaced by the manual occurrence.

Editing should preserve the purpose of the report unless the owner deliberately changes it. Review source and target before updating metrics or frequency. A change from account to campaign scope alters the population; a change in conversion definition alters the measure. If colleagues compare future reports with old screenshots, explain such changes so they do not infer performance movement from a configuration difference.

A successful save confirms the configuration action, not the report's completed provider read. The queued run still needs authorization, readable data, and delivery. Keep that distinction visible when testing. First verify that the intended configuration was saved, then inspect the resulting report. If the run fails, use the actual run stage and scope to investigate rather than repeatedly recreating the same schedule.

Run, pause, resume and delete without confusing live settings

Run Now requires an enabled saved report. If the configuration is paused, the command asks the owner to resume it before running. The resulting reply says the report is queued. That word matters: submission to the run workflow is not completed provider evaluation or successful Slack delivery. The completed report is the separate observation the owner should inspect.

Pausing stops the report's active recurring workflow while preserving its settings. Resuming reactivates that report configuration. Neither changes campaign status, budget, bids, product eligibility, or tracking. A team should use these controls to manage notification routines. If the owner wants an advertising change, name that target explicitly and use the supported approval-based edit tools.

Deletion removes the saved reporting schedule and uses a confirmation surface. It is not a deletion of the underlying Ads account, campaign, Analytics property, or performance history. The user should still choose the intended report reference carefully. A concise confirmation names the configuration being removed so the owner can distinguish deleting a duplicate routine from stopping an important client update.

The run path checks the saved configuration's enabled state and revision before performing the occurrence. That helps avoid an older queued configuration being treated as the current reporting specification. A report already running and one completed earlier are also distinct operational states. The user should not infer from a lifecycle click that every earlier delivered message disappears or updates in place.

After a handover, inspect List and the management view to confirm which routines remain active. Check the source, target, interval, and destination channel. A tidy saved list is easier to operate than several overlapping schedules whose owners have left. Keep the recurring work aligned with an actual review meeting or decision rather than leave notifications active solely because they were once useful.

A report passes through evaluation and queued delivery

The current run loads and validates the saved occurrence, resolves its date bounds, claims the run, assembles the result, and queues account-message delivery with the report table. It records run state and advances the recurring schedule through the applicable path. These stages give the app a way to distinguish an evaluation problem from a delivery problem instead of treating every missing message as an empty provider result.

A successful queued state means the result entered the delivery workflow. It is not itself proof that every channel member has seen the message. Conversely, a provider read can succeed while a posting stage fails. When troubleshooting a missing report, identify the recorded occurrence and stage. Do not start by changing metrics or date ranges before knowing whether data retrieval was the failing part.

The message should retain the source, account or property context, chosen dates, and comparison labels. Those labels let readers interpret values without needing access to raw technical configuration. A native table makes the selected measures easier to compare, while the surrounding context preserves their meaning. Neither the readable formatting nor successful delivery changes what the provider measurements represent.

Repeated manual runs can create additional legitimate observations rather than a single final immutable report. If conversion evidence changes between them, their values can differ even for the same interval. Use the actual run timing and dates when discussing that difference. The team's routine should favor intentional review over repeatedly triggering the same report because a reader expects a value to match an earlier screenshot.

During a connection change, verify the intended account-channel relationship and the report's active state. An old client channel should not continue receiving a routine by accident. The saved reporting context and authorized delivery path are part of the review, not just the metric choices. This is particularly important for agencies working with several client workspaces and similar campaign names.

Provider cost depends on source, metrics and context reads

A report is not guaranteed to be one external request. For Google Ads, the evaluator selects core, Search-share, and invalid-click metric query groups only when the selected metrics need them. It can read current and comparison intervals and additional seven- and thirty-day context windows. Authorization and account resolution can add work. The concrete request pattern depends on the configuration and available cache evidence.

The Analytics path likewise reads current totals, a comparison when requested, and applicable daily observations and context totals. Those daily observations help avoid incorrect averaging of certain measures. Reusing cached evidence can reduce duplicate provider work, but it does not make every report free of external requests. A public guide should explain this dependency rather than claim a universal fixed quota cost.

Google's Ads API quota documentation counts Search and SearchStream queries as operations, with a streamed query counting once regardless of returned batches. Other limits still apply. Parallel independent reads reduce elapsed waiting; they do not eliminate their operation cost. The report's full workflow also includes local configuration and run-state work plus Slack delivery.

Choose recurring frequency for the actual review need. A weekly meeting may not need several daily copies of an identical rolling-month table. A daily operations decision can justify a daily routine. Fewer purposeless occurrences reduce channel noise and repeated provider work together. This is a better optimization than removing the comparison or underlying evidence needed to answer the owner's intended question.

For a follow-up that only asks what a known value means, explanation can use established evidence. For a different target, period, metric, or segmentation, a new focused read may be necessary. The assistant should distinguish those needs. Repeating the entire saved report for every conversational clarification is neither faster nor more informative, especially when only presentation or wording changes.

Use focused follow-ups to move from report to investigation

The report identifies a movement; a follow-up identifies the next evidence needed. Ask which campaigns contributed to a cost change over the same interval, request a chart for a selected measure, or inspect a named conversion's definition. Preserve the current report context when it still applies. Change it only when the owner asks or a necessary clarification establishes a different intended population.

A request for a chart needs actual segmented rows. A table total cannot be expanded into invented daily points. The conversational framework can request the appropriate metric and date grain, then render the returned dataset. For native charts, keep the existing limits on series and points clear. A long interval can require coarser grouping unless the user explicitly asks to retain the daily detail.

Cross-source comparisons should retain separate source definitions. Ads conversion value and Analytics purchase revenue can be shown as distinctly labelled series when that is the requested business comparison. They should not be added into one revenue total. A named lead-event comparison needs the actual corresponding Analytics event. The assistant can suggest likely events from evidence, but the intended event selection must be established rather than guessed from a generic label.

If the owner asks why a metric moved, start with the scoped evidence and a concrete next check. A smaller conversion count can reflect several different measured populations and timing considerations, so the assistant needs the relevant data rather than a canned diagnosis. It should obtain that evidence when available and keep the result concise. The goal is a verified explanation, not a list of speculative causes attached to every report.

When the owner decides to act, the read conversation becomes a supported action proposal with an exact target and intended change. It does not execute merely because the table looks unfavorable. See the Slack approval guide for the confirmation boundary. Reporting makes the decision easier to assess; it does not replace that decision or the account-state check before execution.

Keep the routine understandable for the next operator

Record the saved report's purpose in ordinary business language alongside its source, target, selected metrics, interval, comparison, and schedule. The next operator should know why the report exists and which meeting or decision uses it. A list of configuration values without that purpose makes duplicate schedules more likely. A vague purpose without the values makes changes hard to assess.

Review definitions before comparing old and new delivered messages. A changed target, outcome measure, property, or interval can make the new report answer a different question. Preserve that context in the handover. When the routine is no longer useful, pause or delete it deliberately rather than leave a channel full of unowned updates that readers stop trusting.

Keep report evidence separate from repair closure. A source correction can be verified before its business effects appear in the next performance interval. A campaign change can be executed and verified while a later conversion count remains immature. The final operational note should name what was done and what remains to be measured. That is more dependable than declaring success because a subsequent table has a favorable trend icon.

Use client-reporting practices when audience and stakeholder interpretation are the main concern, and conversational account questions when the next task needs exploratory evidence. This command guide covers the saved routine itself. Each workflow is useful when its scope stays clear.

Common Reporting command questions

Does weekly frequency mean a seven-day report?

No. Frequency controls delivery cadence. The Time Frame field independently chooses the interval the report measures.

Does Last 30 days mean last month?

No. It is a rolling completed-day interval ending yesterday in the relevant reporting calendar. Last month has separate calendar boundaries.

Does Run Now show a preview before saving?

No. It queues an enabled saved report. The form's Run Now option queues a report after the configuration is saved.

Will pausing Reporting pause a campaign?

No. It pauses the saved reporting routine. Live-account settings require their separate supported action flow.

Why is a comparison percentage unavailable?

A missing or zero previous value cannot support a normal percentage change. Inspect the actual values and evidence state.

Can a current result survive a comparison failure?

Yes. The renderer can show readable current values while identifying that comparison evidence is unavailable.

Does every report include a line chart?

No. The current scheduled presentation uses a native metric table. Request a specific conversational chart when segmented visual analysis is needed.

How many report configurations can be saved?

The current account limit is five, including paused reports. Delete an unwanted saved routine to free a configuration slot.