Slack Merchant Center products command guide: read disapprovals without miscounting the catalogue

Choose a product-status overview when eligibility is the question

A product catalogue can contain valid stock, attractive offers, and strong historical sales while still having problems in Merchant Center. The product-status overview answers a specific operational question: what product eligibility and issue counts has Google reported for this connected merchant? It gives the team a place to start when products appear unavailable, a feed update needs checking, or an owner wants to know which issue categories deserve attention. It does not assess every aspect of merchandising quality.

That distinction matters because “products are not showing” can describe several different situations. An offer might be disapproved, excluded from an advertising product group, outside a chosen campaign scope, or simply receive no impressions during a period. Those are separate questions with different evidence. A status summary should establish provider eligibility first when that is the concern. It should not silently turn missing impressions into disapprovals or assume a manually excluded product has a broken feed.

The useful first answer is often a scoped overview rather than a long list of individual items. An operator can decide whether a problem is concentrated in one destination, one country, or one major reason before asking for product details. That saves attention as well as unnecessary retrieval. It also makes the next request more precise: investigate the image-related disapprovals, inspect the affected offer examples, or compare the relevant destination after a known source correction.

Use a feed audit when the question extends to broader data quality and configuration checks. Use performance reporting when the question concerns cost, conversion value, or recent activity. Use product-group evidence when the owner asks what an enabled advertising group deliberately includes or excludes. The Products command has a clear role alongside those workflows. Keeping their roles explicit prevents a status count from becoming an unsupported explanation for every shopping-performance change.

Read every figure with its country and destination

A merchant's catalogue is not one universal eligibility pool. The same offer can be considered in several places, including Shopping ads and free listings, and in more than one country. Each reported context describes one destination and country combination. A count attached to that combination is meaningful within it. Removing the labels to make the answer look simpler destroys information the operator needs to understand which part of the business is affected.

Imagine a retailer offering the same camping lantern in two markets. One context can be healthy while another has an issue requiring investigation. The owner needs to know which market and destination need attention, rather than hear that the lantern is globally “broken.” Similarly, an issue affecting free listings is relevant to organic product visibility even when the owner's immediate concern is paid shopping traffic. The destination distinction helps route the work and keeps performance discussions tied to the correct population.

The current tool reads the aggregate contexts reported for the linked Merchant Center. It does not infer the desired country from the language of a Slack message or treat the Google Ads account's campaign targeting as a replacement for Merchant context. The account link establishes which merchant is being checked. The returned context labels establish where its status counts apply. Those two stages should remain separate in any explanation of the result.

The official aggregate product-status resource defines statistics and item-level issues for a reporting context and country. It also distinguishes disapproved, demoted, and unaffected issue severities. These provider definitions support the scope of the summary; they do not make a current eligibility count into a revenue estimate or a catalogue-wide deduplicated total.

When comparing the result with Merchant Center, align the selected merchant, destination, and country first. A screenshot of one filtered interface view cannot be assumed to represent all the contexts returned by the command. If the numbers differ, record the selections before investigating arithmetic. That first step is often more useful than asking the assistant to combine everything into one large number that neither view actually supplies.

Avoid inventing a unique account-wide disapproval total

The command deliberately preserves context-specific counts rather than adding all disapproved counts together. Suppose an invented catalogue has 12 offers disapproved for Shopping ads in one country and 8 disapproved for free listings in that country. Those two lines do not tell the reader how many unique offers are involved. Some offers might appear in both groups. Summing the lines produces 20 destination-level occurrences, not a demonstrated total of 20 distinct products.

Taking the largest line does not solve that uncertainty. Twelve would be the unique total only under particular overlap assumptions. The eight free-listing offers might include some products not present in the Shopping ads problem set. Across different country catalogues, the largest count can conceal entirely different affected offers. Neither a sum nor a maximum can establish the unique union when membership data is absent. The honest summary keeps the original lines.

This is not a reason to avoid giving useful numerical answers. It is a reason to name what is being counted. “Twelve disapproved in Shopping ads for this country” is a precise answer. “Twenty disapproval occurrences across these two contexts” can be precise if explicitly requested and labelled. “Twenty unique disapproved products in the account” needs different evidence. A team should choose the count that fits its decision rather than demand one universal headline for convenience.

The same principle applies to percentages. A disapproval share calculated within one visible destination should use the corresponding population and an explicit denominator. It should not divide a cross-context sum by a single-country total. If a report uses a different definition of eligible offers, that definition needs its own label. The assistant should not present percentages as interchangeable just because all of them use a familiar percent sign.

The current multi-context Slack output shows each destination line with its own disapproved count and the displayed total formed from active, pending, and disapproved counts. That displayed total is not a count of every distinct product identity across the merchant. The underlying aggregate resource also contains an expiring statistic that is not separately displayed by this command. Do not add an unseen category to the short message or claim the message exposes every provider statistic.

Issue counts overlap within a context and across contexts

One offer can have more than one issue. A lantern missing required information and using an unsuitable image can appear under two reasons while remaining one disapproved offer in that destination. The issue breakdown answers how much reported exposure belongs to each reason. It is not a partition of the disapproved population into mutually exclusive groups. Adding the reason counts can therefore exceed the destination's disapproved count without indicating an arithmetic error.

Across destinations, the command merges matching issue codes with the same severity and sums their reported counts. That produces a readable list of major reasons across the returned contexts. A product appearing with the same issue in two destinations contributes twice to that merged occurrence count. The list is useful for identifying widespread issue exposure, but it cannot tell the team how many unique source records need editing. One source correction may affect several contexts.

The merged key includes severity. An issue code associated with disapproval in one context and demotion in another should not lose that difference merely to make the list shorter. The visible effect helps the user understand the nature of each line. Two similar reason labels can therefore appear with different impacts. Review the effect rather than combine them into a single inferred disapproval number.

The command sorts issue rows by their reported counts and shows up to ten reasons. Additional reasons are summarized as overflow. The overflow count is the sum of those issue occurrences, so it has the same overlap limitation as the individually listed rows. It is not an additional group of unique products that can be added to the headline. The presence of overflow tells the operator that the first ten examples are not the complete reason inventory.

A good work estimate separates reason exposure from repair effort. Thirty issue occurrences might trace to one shared image-generation rule, several independently entered product records, or a country-specific configuration problem. The initial summary cannot choose among those explanations. Ask for the detail that establishes the correction pattern, then estimate the task. Treating each counted occurrence as an independent manual edit would exaggerate work in some cases and understate complexity in others.

Disapproval, limited visibility, and warnings require different language

The command translates the returned severity into an ordinary impact label. Disapproved means the issue is classified as a disapproval. Demoted is described as limited visibility. An unaffected issue is described as a warning with serving unaffected by that issue. An unrecognized severity remains an unknown impact. That last case is important: an unfamiliar value should not be turned into a reassuring pass or a definite block without evidence.

A warning can still deserve attention even though its reported impact is different from a disapproval. The merchant might want to improve source consistency, prepare a seasonal launch, or prevent repeated operational confusion. Those are legitimate reasons to investigate. They do not justify describing the warning as the cause of all missing traffic. Keep the provider effect and the team's business priority as separate statements so the owner can understand both.

Likewise, a demotion should not be labelled a total inability to show. The useful next question concerns the returned issue and the business context. Does it affect an important offer family? Is the relevant market a current priority? Is recent performance actually changing? The status result establishes an eligibility-related condition, while a performance read supplies observations about a selected interval. The assistant should not replace one with a guess based on the other.

The initial count of disapproved products and the issue list can tell different stories because the issue list includes several severities. A merchant can have no disapproved products in a displayed context and still receive warnings. That is not contradictory. It means the overview should be read in two passes: first inspect the status counts, then inspect the reason effects. A headline alone is too narrow to describe the entire returned result.

When forwarding a result, preserve these labels. Rewriting “limited visibility” as “all products rejected” changes the meaning and can trigger unnecessary emergency work. Rewriting “impact unknown” as “nothing important” hides uncertainty. A short internal note can remain readable while retaining the severity, destination scope, and next action. Clarity comes from selecting meaningful distinctions rather than flattening them into one dramatic status.

A new read does not remove Google's processing delay

The command requests current aggregate evidence, but the provider's aggregates need time to reflect inserted or updated products. A feed correction made moments ago may not yet change the result. Repeating the command immediately can return the same count without proving that the correction failed. The operator should establish when the source changed and which processing stage is being checked before interpreting repeated status evidence.

Google's product-statistics guidance says aggregate statuses can take more than 30 minutes to reflect an inserted or updated product. It also notes that issue descriptions may differ from Merchant Center interface wording. The current Slack footnote summarizes the delay as about 30 minutes; treat that as a caution about delayed evidence, not a guaranteed deadline for approval.

A source save, a submitted product update, a processed attribute, and a changed eligibility result are different observations. A team can verify that the source now contains the intended image while still waiting for Google to reflect it. It can also discover that the corrected source never reached the merchant's processed product. The status overview alone cannot establish the complete chain. Match each checkpoint to the evidence that actually demonstrates it.

Record the correction time and the relevant product scope in the task. That gives the next operator a sensible starting point and avoids duplicate changes. If the later result remains problematic, inspect whether the source update arrived and whether the reported reason is still the same. A different issue may now be visible. Do not assume a repeated headline means the identical technical defect survived unchanged.

Historical performance needs its own interval. A current product status does not explain what every offer was allowed to do throughout the preceding month. It may provide context for an investigation, but attributing a historical revenue decline requires more evidence. Keep the status check separate from a dated performance comparison and state which question each answers. This prevents a fresh operational snapshot from masquerading as a complete historical explanation.

Prioritize the unresolved business decision, not only the largest reason

The largest issue count is a useful starting point, but it is not automatically the highest-value repair. An issue affecting many low-priority offers may matter less to today's launch than a small number of essential products in the intended market. That priority needs business context. The assistant can organize the count evidence, but it should not invent margin, inventory importance, or expected recovered revenue from an aggregate reason list.

Begin by identifying the market and destination the owner actually needs. Then identify the reported impact and whether the affected products overlap with an active business priority. Ask for product examples when their identity changes the decision. If the owner wants a revenue-based priority, request a properly scoped performance measure and interval. Do not label the largest count “the biggest revenue loss” before performing that separate analysis.

Choose a correction pattern before assigning dozens of independent tasks. Image issues may share a template, attribute issues may share a source rule, and a small set of manually maintained records may need individual review. These are possible work patterns, not conclusions from the command. A focused sample can test which pattern fits. Once the source relationship is established, the team can plan a correction without downloading unrelated catalogue detail.

Separate immediate operational containment from durable source repair. If the owner decides to change a supported Google Ads target while the feed owner investigates, that is a separate approval-based edit with its own scope and consequences. It does not correct the source data or guarantee future product eligibility. The status task should retain its original repair owner so the temporary campaign decision does not cause the underlying work to disappear.

An effective task statement includes the affected destination and country, the reason and severity, the unresolved product detail, the source owner, and the next verification step. It need not contain every raw provider field. It should contain enough context for a colleague to act without guessing which merchant or market is involved. That is the practical value of turning a broad overview into a focused work queue.

Three illustrative situations show why the distinctions matter

A shared image problem reaches two destinations

Consider an invented outdoor shop named “Maple Trail.” Its result shows 16 disapproved offers in Shopping ads for Canada and 16 in free listings for Canada. The same image-related reason appears in both contexts. The operator must not report 32 unique broken products. The summary demonstrates 32 reason occurrences across those destinations. Product membership detail is needed to determine whether the two sets contain exactly the same offers.

The feed owner checks representative affected products and finds that a shared image rule produced the unwanted content. The team's task becomes correcting that rule and confirming the resulting processed products, followed by a later status check. It is not automatically 32 separate manual image edits. If the two destinations later improve at different times, keep both lines in the follow-up rather than declaring the entire merchant healthy after the first one clears.

A new market introduces a different affected population

An invented homeware merchant named “Harbor Table” has seven disapproved offers in one country and eleven in another. The operator considers using eleven as an account-wide total because it is the larger line. That would hide the possibility that the first country has different affected offers. The right initial response retains both scopes and asks for membership detail only if the owner needs a unique cross-market list.

The business priority is a launch in the smaller affected market. Its seven offers are therefore the immediate task, even though the other line is larger. The operator records the intended market, reviews the exact reason, and assigns the corresponding source work. The other market remains a separate backlog item with its own owner. The aggregate counts support prioritization without dictating it or inventing which market contributes more profit.

A recent correction has not reached the aggregate result

A fictitious accessories seller named “Birch Carry” corrects an attribute and runs the command a few minutes later. The old disapproval count remains. The operator records that aggregate evidence is still pending and checks whether the corrected source reached the processed product. The unchanged summary is not sufficient evidence to repeat the source edit. Another immediate identical command also cannot force the provider's processing schedule forward.

At the later checkpoint, the team inspects the relevant destination and country again. If the reason clears, it records that outcome without claiming historical revenue recovery. If it persists, it checks the actual submitted value and current reason before selecting the next correction. This avoids oscillating between edits based only on an unchanged total and makes the final status claim traceable to the intended scope.

Assign feed, site, and advertising work to the correct owner

The source of product data determines where a durable correction belongs. A catalogue integration, merchant-managed feed, or site content process can each have a different owner. The Products command does not identify that entire ownership chain. The operator should establish it before promising that a conversational edit will repair the feed. A supported Google Ads mutation and a Merchant product-source correction are different operations.

A useful handover names the reported issue, the applicable market and destination, and a product example that the receiving owner can locate. It also states what is known about the source and what still needs checking. Avoid sending a screenshot with only a large count and a request to “fix products.” That leaves the colleague to rediscover scope and often produces an answer about a different interface selection.

Do not promise a universal automatic remedy. Some issues require correcting product attributes, others require site or business information, and some need the relevant provider process. The initial issue label is evidence for selecting that process, not authorization to make every possible change. If the owner asks the assistant to change a supported advertising setting, prepare the exact target and action separately and keep the feed investigation open.

For repeated source problems, the task should include prevention. The team might review the relevant generation rule, publishing validation, or responsibility for an upstream field after confirming the actual cause. That is original operational planning, not a claim that the command performs these checks. The point is to use a short status overview to start durable work rather than keep producing the same incident conversation after every catalogue update.

When a product correction and a campaign launch happen together, keep their outcomes separate. The source owner can confirm a corrected field, the advertising owner can confirm an approved account change, and a later provider read can confirm the applicable eligibility state. One completed task does not establish the other two. Clear ownership makes that separation manageable rather than burdensome, especially when several people work through one Slack thread.

Run the current Products command in the linked channel

The current syntax is /ppctor products. It uses the Google Ads account linked to the Slack channel and the Merchant Center connection associated with that account. The command does not define a country selector or arbitrary product-name flags appended to its text. A focused conversational follow-up is the appropriate place to request a narrower supported analysis after the broad overview.

Two prerequisites are checked separately. The channel needs its Google Ads account connection, and that account needs a linked Merchant Center in ppctor. If the first connection is missing, the command directs the user to Slack integration setup. If the merchant link is missing, it directs the user to Account connections. Those messages mean the tool cannot establish product status in the intended context. They are not evidence that the business has no products.

The authorized Merchant connection must also provide a usable access token. If authorization needs restoring, the result explains that product status could not be read. Do not interpret a failed read as zero disapprovals. The difference between an empty successful status response and unavailable evidence is essential. One describes what the provider returned; the other says the tool did not establish the answer.

The handler gives an immediate working receipt and performs the status read afterward. The completed result is posted to the channel through the command's response path. That behavior means the initial interaction and final result are separate stages. Avoid repeatedly submitting the same command because the final result has not appeared instantly. If delivery fails, inspect the command's recorded run and delivery diagnostics rather than assume that the Merchant read itself returned nothing.

Use the command in the intended account channel and check the audience. Product issues can contain business-sensitive operating information even when they do not expose an email address or account ID. An agency should keep the client context and internal handover appropriate for that channel. The account connection establishes authorized data scope; it does not decide who ought to participate in every subsequent business discussion.

Read the posted message in layers

With multiple contexts, the message lists disapproved products by destination and country. It then lists product issue reasons with their counts and impact labels. A note clarifies that the reasons are counted across the destinations above. This order helps the reader establish where the problem is before interpreting why particular issue counts are large. It should not be collapsed into an unlabeled account-wide total.

The 20 on the first reason is not proof of 20 unique products. The warning count is not another disapproved population. The displayed destination totals do not make the two country lines additive. The example deliberately keeps these interpretations visible because a short message is otherwise easy to forward with a misleading headline. Reading the labels is part of using the output correctly.

With only one returned context, the current renderer uses a shorter line showing disapproved, active, and pending counts when pending exists. It does not explicitly display the context label in that condensed line. Therefore, if the country or destination matters to a handover, verify that scope rather than infer it from the channel name. A concise rendering does not justify inventing a missing market label.

If no contexts are returned successfully, the message says Google reports no product statuses for that Merchant Center yet. It does not claim that an account-wide catalogue is permanently empty or that a product can never be eligible. If no issues are returned in the available status result, it says no issues are reported. That is a status-summary observation, not a promise that the catalogue passes every possible quality or merchandising check.

The short output does not publish every issue detail, documentation link, product attribute, or affected identity. Those details belong to applicable follow-up evidence and the relevant provider surface. The initial message is useful precisely because it summarizes status rather than flooding the channel. The reader should understand its limits so an absent detail becomes a focused next question instead of an invented explanation.

The overview uses provider aggregates rather than a full product download

The current status path reads the provider's aggregate status resource and converts its returned counts into the app's summary. It does not fetch every product and recompute the account's broad status tally locally. That is a meaningful efficiency choice for large catalogues. The amount of detail retrieved is tied to context and issue summaries rather than automatically growing into a complete export of individual product records.

The official aggregate-status list method supports pagination and country or reporting-context filtering. Its documented access is for standalone merchants and subaccounts; an advanced-account parent is not a substitute for reading each intended subaccount. Provider filter support does not mean the current slash command exposes corresponding arguments. The command's existing path requests the linked merchant's overview.

Pagination means the overview is not guaranteed to require exactly one network request. The helper follows returned page tokens, bounds the read, and rejects incomplete results if paging cannot finish safely. It also has bounded retry behavior for certain temporary failures. Authorization and Slack delivery are separate operations. Describe aggregate retrieval as efficient without advertising a universal one-request total for the whole interaction.

A count question should not trigger a catalogue download merely to rediscover numbers the provider already supplies. A question about specific affected products may need product-level detail, which is a separate read. A question about a known label may need only an explanation of established evidence. Choosing among these needs is how the assistant remains useful at scale. Every follow-up should resolve an actual missing fact or decision.

Repeated broad checks can still consume time and provider allowance. Use them when a new status observation matters, such as after an appropriate processing interval or before a planned launch. If the user only asks what a known reason count means, explain the current result. Efficient use is not about avoiding necessary evidence. It is about avoiding redundant retrieval that cannot improve the answer, especially during a provider processing delay.

Ask for product detail only when it changes the next action

A natural follow-up is “Which products have this disapproval reason?” That moves from aggregate status to product-level evidence. The current reason-specific helper reads disapproved products through Merchant reporting and matches the reported disapproval codes to the requested reason. It preserves a completeness flag for bounded reads. This is different from treating the initial aggregate reason count as a ready-made list of identities.

The provider query narrows that helper's population to disapproved issue severity. Matching a particular reason then happens against returned disapproval codes. The helper does not use demotion warnings as reasons that a product is disapproved. If the requested wording matches no observed code, it can expose available reasons instead of inventing product examples. A user can then select the intended reason with a clearer label.

Ask for the smallest useful result: a few representative affected products for identifying a shared source rule, a complete applicable list when an individual repair requires it, or a count with explicit scope when preparing an operational note. A visible preview is not a complete population. If a bounded read is incomplete, the assistant must state that limit rather than turn the preview length into the final count.

Product identity also needs care. A brand name or title can match several variants, markets, or source records. The assistant should use the authorized product identity internally and give the user readable context. It should not infer that similar titles are identical records. If the user asks for a product-level action, the intended record and supported operation must be resolved before preparing a proposal.

Another follow-up might ask whether affected products recently generated conversion value. That requires a dated performance population and an explicit measure. A current disapproval list and a historical product-performance table are not automatically the same dataset. The applicable framework should establish their relationship and label any missing evidence. Do not estimate historical revenue exposure by multiplying an aggregate issue count by an invented average product value.

For manually excluded products, use the listing-group relationship evidence rather than this Merchant status command. An offer can be eligible in Merchant Center and excluded from one enabled advertising group while included in another. The count in that question concerns advertising occurrences with parent context, not provider disapproval. Keeping those populations distinct helps the assistant answer the user's actual question instead of returning a familiar but irrelevant product-status total.

Close the task with evidence for the outcome you claim

A product issue task has several potential completion points. The source owner can confirm a corrected value. The merchant read can show the processed product. A later aggregate can show a changed status in the relevant context. A performance report can show subsequent activity. Each supports a different statement. The final update should name the demonstrated outcome, rather than announce “everything fixed” because one of those stages completed.

Use the same country and destination when checking whether the original count changed. If the next result uses a different scope, it cannot directly close the previous issue. If the catalogue population also changed, record that fact before attributing the entire count difference to repair. A drop from ten disapprovals to five may reflect correction, product removal, or a changed population; the total alone does not establish which mechanism occurred.

A repeated issue should retain its reason and source history. The next operator needs to know what was corrected, when, and where the evidence was checked. This can be a short task note rather than a technical dump. It reduces duplicate work and helps identify whether the same source rule regenerated the problem or a different offer now shares a similar visible label.

If the owner asks for a supported Google Ads edit as part of the response, use the normal approval flow. The proposal must identify the target, its correct parents, and the intended action. Execution and verification confirm that account change; they do not certify Merchant product approval or website correctness. Read the approval workflow guide for that separate action boundary.

For a wider operational review, pair the focused status result with the appropriate account audit or performance report. Each contributes its own evidence. Keep the closure concise: original scoped finding, confirmed correction, latest applicable status, and any remaining work. That gives the owner a usable answer without turning one summary tool into a promise to solve every shopping problem.

Common questions about the Products command

Does the command change products or campaigns?

No. It reads aggregate product status and posts the result. A requested supported advertising change follows a separate proposal and confirmation path.

Why are issue counts higher than disapproved product counts?

One product can have several reasons, and the merged issue list can include occurrences across destinations. The reasons are not mutually exclusive product groups.

Can I add all destination counts to get unique products?

No. The same product can appear in several contexts. A unique cross-context total needs identity-level evidence about overlap.

Does a warning mean a product is disapproved?

No. Read the severity label. Warnings and limited visibility are different from disapproval, and unfamiliar severity remains unknown.

Why does a recent fix still appear?

The aggregate can lag the source update. Check the submitted or processed correction and allow for provider processing before treating an unchanged total as a failed repair.

Can I select a country in the slash command?

The current Products command does not expose a country argument. It returns the linked merchant's contexts; use an applicable focused follow-up when a narrower question is needed.

Does it show every affected product identity?

No. The overview shows aggregate status and reasons. Product examples or complete applicable lists require separate product-level evidence.

Is an excluded advertising product a disapproved Merchant product?

No. Advertising inclusion and exclusion belong to the campaign's listing-group structure. Merchant eligibility is a different property.