Why are my products not showing? Check Merchant status, listing exclusions and delivery

Check the product's eligibility and campaign selection before blaming traffic

A product may be disapproved or pending in Merchant Center, excluded from the campaign's listing tree, or eligible without reported impressions in the selected period. Start with /ppctor products in a connected Slack channel, then ask: “Check this product's status for Shopping ads in my target country and its inclusion in the named campaign.”

Those are three different checks. Merchant status describes the product's reported eligibility in a context. Listing state describes which campaign groups include or exclude it. Performance describes observed activity over dates. A useful answer identifies which evidence establishes the current problem rather than using “not showing” as a single universal status.

The first response should name the product, intended country and destination, and relevant campaign context. If the product name is ambiguous, resolve the variant or item before diagnosing it. A broad catalogue count can show account health, but it cannot establish why one particular product did not receive impressions yesterday.

A clear next step follows the established evidence: inspect a reported Merchant issue, review an intentional listing exclusion or examine delivery for an eligible included product. The assistant should not automatically enable every excluded item or rewrite the feed because the owner expected to see one ad.

Live corrections remain separate from diagnosis. A status read or listing report makes no account change. If the owner requests a supported inclusion or exclusion edit, prepare the exact target selection and confirmation. If the actual issue belongs in the feed or website, identify that work rather than pretend a campaign mutation repairs it.

Identify the actual product and where it is intended to appear

A product title can match several variants, markets or data-source entries. Begin with the specific item the owner means, using the appropriate catalogue identity internally. A readable title and variant description can help the user choose. Do not attach a policy or listing decision from the first vaguely matching result to every similarly named product.

Country and marketing destination are part of the eligibility context. Shopping ads and free listings are different destinations, and a product can have different states across countries. A overall statement that the item is approved can be too broad for a question about Shopping ads in one market.

The Merchant account linked to the campaign also matters. An accessible catalogue is not necessarily the one the selected campaign uses. Resolve the relevant account relationship before comparing the feed with targeting. The assistant should not silently substitute another Merchant account because it contains a similarly named item.

Campaign and group context identify the intended advertising selection. Performance Max uses asset groups, while Standard Shopping uses ad groups. Within those groups, listing rules can select products through several attributes. A product-level diagnosis needs the actual group and full path rather than a campaign name alone.

A historical screenshot can describe an earlier selection or status. Establish the current item and setting before preparing a live operation. The campaign may have changed after the screenshot, and a product may have been replaced in the data source. Current identity and historical activity need to remain separate evidence.

Keep internal account and resource keys behind the scenes. The user usually needs product title, variant, country, campaign and group names to understand the diagnosis. A product's own item identifier may be useful when they explicitly ask for item-level listing detail, but unrelated technical IDs do not improve a ordinary explanation.

Merchant status identifies eligibility and the recorded issue

Google's product-visibility and status guidance distinguishes approval status from visibility and describes pending, limited and not-approved contexts. Its Needs attention workflow directs the advertiser to the relevant issue. Read the actual selected product's evidence before choosing which requirement needs work.

A reported disapproval is different from a deliberate campaign exclusion. The former concerns the product's eligibility in the selected Merchant context. The latter concerns advertising selection inside a campaign group. A product can have both conditions, and fixing one does not establish that the other is resolved.

Pending or processing states need their actual meaning retained. They should not be labelled a final disapproval merely because the owner expected immediate visibility. Conversely, a persistent issue should not be dismissed as ordinary delay without inspecting the current returned state and relevant provider guidance.

The Merchant API exposes processed product status and data-quality issues, as described in Google's product and issue guide. Use applicable destination and country details to establish the scope. A aggregated account status and a individual product issue are related but different reads.

A issue label starts the investigation without necessarily proving every technical cause. A destination-related issue can justify inspecting the saved product link and page behavior. A attribute issue can justify comparing processed data with the intended source. Do not expand a short label into a specific website fault until that evidence has been checked.

A successful issue read can identify no reported problems within its scope. A failed read cannot. The application should retain provider availability and reauthorization context instead of reporting a clean catalogue from missing evidence. The owner needs to know which status was established before acting on the result.

Country and destination counts describe different populations

ppctor's Products command uses Google's aggregate product-status reporting. It receives active, pending and disapproved counts with issue evidence by reporting context and country. This avoids downloading every catalogue item merely to recount account health locally. It also preserves the provider's actual population boundaries.

The command deliberately avoids a invented universal unique-product total across contexts. One item can be represented in several countries or destinations. Adding all the disapproved context counts can count the same product more than once, while taking the largest count can understate different products affected in different markets.

Issue tallies can overlap as well. One product can have several issues, and the same issue can affect it in multiple destinations. A sum of issue counts measures occurrences within the stated reporting context, not necessarily distinct products needing independent fixes. Keep that distinction in the explanation.

A product can be usable for free listings but not the intended Shopping ads destination. A client asking about campaign delivery needs the relevant ads context rather than the most favorable catalogue status. The assistant should retain country and destination through follow-ups instead of returning a different population without disclosure.

If the owner needs a count of affected products in one market and destination, select that scope. If they need a full item list, request the appropriate filtered product evidence rather than infer titles from aggregate counts. Aggregate and detailed reads serve different questions and should be chosen accordingly.

The Products command guide explains this current account-health output. Use it to locate the relevant context, then narrow to the actual item and issue for a specific visibility diagnosis. A compact summary should not conceal the population needed to interpret its count.

Follow the complete listing path, not just explicit product leaves

Google's Performance Max listing-group guidance describes product selection within asset groups through product-data attributes. The structure can be subdivided several levels. An individual item can therefore be included or excluded through a broader rule rather than a visible explicit item-ID leaf.

A fictional path might be All products, then Outdoor Accessories, then a brand, then one item. Each level contributes context to the leaf. The assistant should reconstruct that complete path and parent group instead of printing a disconnected item ID with no indication of which branch controls it.

Subdivision nodes are rules, not product counts. A tree with nineteen exclusion entries can match far more than nineteen products, or some broad entries can match no current items. Counting the nodes cannot answer how many products are excluded. The appropriate product-targeting dataset resolves actual matching products within the relevant tree.

Current listing state also differs from historical activity. A product excluded today can have earlier impressions, clicks and outcomes. A product currently included can have none in the reviewed period. Neither performance condition establishes its current inclusion setting without a configuration read.

The generic framework distinguishes listing groups from product targeting. One view inspects nodes, branches and catch-all rules. Another describes matched products with paths and statuses. Choose the view that matches the user's question rather than building a separate one-off tool for every category or campaign.

A deliberate broad exclusion should not be treated as accidental by default. The owner may exclude a brand or product family for business reasons. The diagnosis should show which rule applies and ask whether that selection is intended before preparing a supported change that alters reach.

Inspect every relevant enabled asset group or ad group

A Performance Max campaign can contain several asset groups, each with its own listing tree. Standard Shopping uses ad groups with their corresponding product partitions. Reading one group and calling its result the entire campaign can undercount exclusions and misidentify which group still includes the product.

ppctor's product-targeting dataset works through enabled asset groups and enabled Shopping ad groups, with enabled campaigns as the default unless campaign status is explicitly selected. That scope must remain visible. A question about a paused group needs another deliberate selection or applicable inspection rather than a claim that the enabled-group result covers it.

Count product-group occurrences when that is the requested exclusion meaning. If the same product is excluded in two enabled groups, it contributes two occurrences. The number of distinct item identities is a different measure. A concise summary can report the occurrences and the contributing campaign and group counts clearly.

For example, one fictional campaign has two enabled asset groups. The first excludes product Two, and the second excludes products Two and Three. That is three exclusion occurrences across two groups, even though only two distinct products are involved. The assistant should preserve that requested counting rule rather than silently deduplicate.

A campaign-specific question should narrow the complete relevant group selection. A group-specific question should retain that actual group and parent campaign. This allows the owner to ask where one product is excluded without losing the full campaign context or receiving a count from only the first returned tree.

The summary should distinguish Performance Max campaigns and enabled asset groups from Standard Shopping campaigns and enabled ad groups. Correct hierarchy is part of the evidence, not decorative wording. A confusing parent label can make an otherwise valid result unusable for the next confirmed edit.

Broader exclusions and catch-all branches require product matching

A excluded brand or category rule can affect many products without listing individual IDs at that node. The assistant needs the relevant product attributes and partition path to identify the matched items. A count of explicit excluded leaves alone will miss products covered by those broader rules.

Catch-all branches matter because they represent products not captured by the named subdivisions at that level. Their meaning depends on the surrounding tree. Treating a catch-all as a universal account-wide rule would lose that context. Reconstruct the sibling and parent structure before reporting the matched population.

The framework labels how each product was identified, distinguishing explicit item IDs from products matched to broader rules. A useful answer can state both counts. This explains why the product total can exceed the number of explicit IDs without inventing new leaf criteria.

Inspect the actual sibling structure when a product falls into a catch-all. If a group subdivides by two named brands, the remaining branch covers products that do not match those named values under that parent. A later subdivision can narrow the path further. The readable report should retain those successive conditions so the owner can see why this particular item matched, rather than describe the catch-all as an unexplained excluded product.

A product-attribute update can move an item between rules even when the listing tree itself has not changed. A revised brand, category or custom-label value can alter the current match. That makes the relevant catalogue evidence part of the targeting investigation. Do not automatically blame a campaign edit when the current path differs from an earlier screenshot; inspect the attribute and configuration contexts separately before deciding which change explains the new match.

Product attributes should come from the applicable catalogue evidence. Do not infer brand or category from a title when the partition uses a processed attribute. The selected product might belong to a different provider category than the owner informally expects, and that difference can explain the actual matching rule.

A supported inclusion change for selected items can expand a broader leaf appropriately while preserving unrelated partitions. That is different from replacing the entire listing tree. The proposal should retain the exact selected products and groups, and never use a whole-tree retargeting operation as a shortcut for a narrow item request.

If the matching selection is incomplete, narrow or establish it before action. A preview of a few products is not a complete current edit set. The owner should understand how many occurrences and groups will change, with missing coverage identified rather than silently omitted.

Eligibility and inclusion do not establish observed impressions

A product can be eligible in Merchant Center and included in a active group's listing selection without reported impressions in the chosen period. That is not automatically a contradiction. The configuration makes it a candidate for the intended context; the performance report establishes what activity was observed.

Inspect the relevant campaign and group states, period and available performance evidence. The campaign may have limited activity overall, or the product may have contributed differently from the owner's expectation. A current inclusion setting does not provide a guarantee of delivery for every item.

Do not infer a manual exclusion from zero impressions. Use the current listing tree to establish inclusion state. Conversely, do not infer approval from impressions in an earlier window. A later disapproval or exclusion can coexist with historical activity that remains visible in the report.

A individual search by the owner is not a complete delivery test. The relevant measured report is more useful for establishing whether the product received impressions in a defined population and period. The assistant should not diagnose a campaign problem solely because the owner did not personally see the ad once.

When broader campaign delivery needs investigation, read the actual applicable settings and outcome context. Budget, targeting and status can be relevant, but a product-level count alone does not identify which control caused low activity. Choose the next check from the established evidence rather than return every generic optimization suggestion.

The direct conclusion can be that the item is currently eligible and included but had no reported activity in the selected window, followed by the precise campaign-delivery check. That answers the verified question without pretending that approval, inclusion and impressions are one shared status.

A campaign can also deliver through other products while this item remains inactive. The account's overall impressions therefore cannot establish item-level visibility. Ask for the relevant product observations at the supported grain, with the actual campaign selection retained. Similarly, a product's activity in another campaign does not prove that the named campaign included it. Keeping the product, group and period together prevents a broad positive result from masking the user's specific concern.

When the owner asks whether the item is excluded everywhere, examine the complete intended active-group population and report any coverage boundary. A single included occurrence disproves a claim of universal exclusion within that reviewed population, but it does not guarantee future delivery. The answer should state both facts plainly: where the product remains included and what the selected performance evidence shows.

Historical product performance needs the correct group and path

ppctor's related listing-performance dataset matches historical explicit item leaves through the group and complete dimension path, including replaced leaf identities where supported. It preserves unavailable history rather than assign a broader partition's cost or revenue to each individual product beneath it.

A brand-level row cannot establish per-item ROAS for every matched product. Dividing its value and cost evenly across the catalogue would invent measurements. If individual history is unavailable, retain that state and explain the actual supported population rather than display zero outcomes for all items.

The supported ROAS filter in this dataset uses primary conversion value divided by spend as a multiple. A request for greater than 3 means greater than 3×. Keep that definition and boundary when selecting excluded products for review, rather than switch to a percentage representation or another revenue population silently.

Unknown performance must not satisfy a numeric condition as if it were zero. The filter coverage can identify products that could not be assessed. Report how many matched and how many remain unassessed when that distinction affects the answer or potential edit selection.

Period performance and current targeting should remain separate columns. The user might ask how many historically strong products are excluded now. That combines a current relationship with a selected historical measure; it does not claim that the product generated outcomes while excluded throughout the entire period.

Listing and campaign impression totals can also have different counting context. Google's listing-group guidance explains that product-level impressions and campaign-level impressions need not reconcile as identical counts. Retain the selected grain and avoid calling a difference a defect without inspecting the provider definition.

Use the recorded issue to choose the feed or destination investigation

A Merchant issue can concern processed product attributes, destination behavior or another requirement. Inspect the actual returned topic and relevant product fields before choosing a correction. A product title resembling a restricted category is not a substitute for the provider's recorded issue.

Compare submitted or processed data with the intended product state where applicable. Price, availability and identifiers can be relevant, but the issue determines which evidence is needed. Do not rewrite every attribute or invent a missing GTIN because one status read says the item needs attention.

A destination issue needs the actual product link and a appropriate page check. A browser loading one URL does not establish every relevant provider condition. Keep the direct observation separate from the reported Merchant issue and verify the path the product actually uses.

The Feed Audit can inspect configured data and its findings, but it is not a universal live crawl or automatic repair service. Use its actual checks and coverage. A pass on one attribute does not prove the whole catalogue is approved, and a recommendation does not identify the complete cause of a specific disapproval.

Feed corrections may belong to the commerce platform or source process rather than a Ads edit. Assign the appropriate owner and establish what will be verified after the change. Updating a campaign's listing selection cannot repair a incorrect product attribute in Merchant Center.

The Feed Audit guide explains current structured checks. Combine it with a specific product-status read when needed, keeping data quality, provider eligibility and campaign selection separate so the owner knows where the actual correction belongs.

Three fictional product incidents require different actions

The item is disapproved for the intended ads destination

A fictional store sees its product listed in the catalogue but not in its campaign output. The status read shows a issue for Shopping ads in the intended country. The listing tree includes it. The assistant identifies the reported issue and relevant source or destination evidence rather than toggle an already included product.

The correction belongs to the verified Merchant or website condition. After the source owner completes it, the team reviews the processed product and current eligibility. A listing inclusion write alone would not close the original issue.

The item is excluded by a broad brand rule

A fictional Performance Max campaign has two enabled asset groups. The product is eligible in Merchant Center but matched to a excluded brand branch in one group and included in the other. The assistant reconstructs both paths and reports the exact occurrence rather than claim the product is excluded everywhere.

If the owner requests inclusion in the first group, the proposal selects the exact item and group relationship while preserving unrelated partitions. The operation is a targeting correction with its own confirmation and verification, not a feed approval request.

The item is eligible and included with no recent impressions

A fictional Standard Shopping item is eligible for the chosen context and included in a enabled ad group. The selected completed period returns no observed activity for that item. The assistant reports those verified states and moves to the relevant campaign-delivery investigation. It does not manufacture a hidden product disapproval.

These invented cases show why “not showing” must be traced through several layers. A eligibility correction, a listing change and a delivery review are different tasks. The right next action follows the evidence rather than the most convenient mutation available.

Choose a correction that addresses the actual layer

A Merchant correction changes the relevant data or requirement. A product inclusion edit changes the selected listing relationship. A status edit changes the campaign or group. A budget edit changes an applicable spending control. Each can affect visibility in a different way, and none should be substituted for another without evidence.

If the product is deliberately excluded, ask whether the owner wants that business policy changed. They may have stock, margin or brand reasons outside the report. Do not automatically enable every historically strong item merely because a ROAS filter found it.

If the request selects several products, establish the complete current matched set and actual group occurrences. The same item in several groups can require several relationships to change. A unique catalogue count is not enough to describe that edit scope.

If the intended action requires a paused parent to be enabled, list that as a separate operation. Including the product does not enable the asset group, ad group or campaign. A successful leaf change should not be reported as complete campaign activation when the relevant parent remains paused.

If eligibility is unresolved, a supported targeting change can still be technically valid without making the product serve. State the actual purpose and remaining condition. The owner should not receive a execution message that equates a verified listing write with Merchant approval.

A concrete recommendation names the layer, target and desired state. “Include this selected item in the named asset group” is reviewable. “Make the products show” still requires diagnosis and a actual supported operation before it can become a live request.

Use the conversational framework to move from health to the exact product

The Products command gives current destination and country health. A follow-up can narrow to one item, issue or campaign. The assistant should retain the resolved Merchant relationship and intended context rather than ask the owner to start again with account details already established in the channel.

For targeting, request the registered product-targeting dataset with the relevant campaign or group scope. For tree structure, use listing groups. For historical evidence, request the supported related performance fields. These are reusable capabilities that let the assistant answer new conditions without dedicated patches for one product or campaign name.

Use precise conditions. “Count excluded products with ROAS greater than 3 in this campaign” needs current exclusions and the selected historical measure. “At least 3” includes the boundary, while “greater than 3” does not. Preserve the outcome definition and period across the follow-up.

Reuse available data for explanations and refresh only the state needed for a new decision. A question about which returned path excludes the item may use the established complete result. A live inclusion proposal needs current target checks. A daily chart requires actual new grain if the earlier read only returned period totals.

Creative discussion can remain conversational. The owner can ask for a clearer product description or ideas for a campaign message without another provider call. Generated suggestions should not be labelled measured demand or verified feed compliance. Data reads belong to actual account evidence requests.

The account-question guide explains this contextual flow. A useful response is the verified state, its actual scope and one concrete next action, with no silent edits and no repeated broad reads that add cost without resolving a new question.

Make the product path and count meaning readable

A table can show product, campaign, group, full listing path and included or excluded state. Use separate rows for distinct group occurrences. The owner should be able to locate the actual relationship without interpreting raw resource names or a paragraph that merges several parents into one confusing sentence.

When item IDs are explicitly requested for listing identification, show the relevant product identifiers with readable context. Ordinary summaries should avoid unrelated campaign, account and group IDs. The technical references stay internal for exact operations; the public message should explain the business hierarchy.

A count summary can report product-exclusion occurrences across the contributing Performance Max campaigns and enabled asset groups, plus Standard Shopping campaigns and enabled ad groups. It should separately identify explicit item matches and broader-rule matches when relevant. This communicates what was counted without pretending all rows are unique products.

A chart can show compatible performance series when actual data is available at the requested grain. A current listing tree is not a daily performance series. The assistant should not assign zero daily values or evenly distribute aggregate performance to make the requested visual appear.

Native combined charts are capped at three series, with readable grain chosen for long periods when daily detail is not explicit. Explicit daily data beyond the point capacity remains complete through explained consecutive charts. Currency and ratios use sensible precision, with unknown performance retained as unavailable rather than a measured zero.

The conclusion should identify the verified state and its scope. A compact clear report is more useful than a wall of provider labels. Current Merchant status, current listing configuration and historical performance can all appear, but their headings and wording must keep their meanings distinct.

Confirm the selected inclusion change before the live write

The supported product inclusion action uses exact selections from the registered targeting dataset. It retains the group, listing resource and selected item set internally. The proposal should display the product and actual parent group and campaign, describing inclusion or exclusion in ordinary language.

The edit preserves unrelated partitions and expands a broader leaf only for the selected products where required. That behavior is materially different from rebuilding the entire tree. A narrow owner request should remain narrow, with a complete current selection rather than a arbitrary preview.

The confirmation message states that no changes have been made yet and that the proposal expires in 15 minutes. A click starts current checks, the supported write and readback verification. A visible progress state should precede the final execution result so the owner knows the action is underway.

Validation establishes that the operation and selection are applicable. Verification establishes the resulting listing state. Neither guarantees Merchant approval or future impressions. A successful execution report should name the actual verified targeting change and retain any separate eligibility condition.

If execution was sent but full verification failed, inspect the current listing state before another edit. Do not blindly replay a partition operation, especially after the owner or another collaborator could have changed the tree. The verified current state should determine any subsequent proposal.

The confirmation guide explains the broader process. It keeps the product investigation reviewable from exact target selection to actual saved result, with read evidence, proposed action and live execution clearly separated.

Verify the corrected layer and then review later delivery

After a targeting edit, confirm the actual item relationship and parent scope. After a feed correction, inspect the relevant processed data and provider state. After a campaign-status change, verify the parent configuration. Each task has its own closure evidence and should not be treated as proof that every other layer is resolved.

Later performance reporting can establish whether the item received activity under the resulting configuration. Use the selected completed window and correct group or product grain. A saved inclusion is immediate configuration evidence; subsequent impressions and outcomes are measured delivery evidence.

Do not promise instant delivery from a completed edit. Reporting and review can have their own timing, and inclusion does not force a campaign to show every product. State the current verified result and the next relevant review instead of guarantee an unobserved future outcome.

Record deliberate exclusions and their business reasons. This helps a later reviewer distinguish a intended listing policy from a error. The record should not become a automatic assumption that every similar item is unwanted; a new request still needs its current selection and purpose established.

Ongoing product-health monitoring can direct attention to reported Merchant issues, while performance and targeting reports answer narrower questions. Use aggregate health for broad checks and focused item reads for specific investigations. This limits unnecessary catalogue reads without sacrificing the evidence required for the actual task.

The practical routine is to identify the item, inspect its destination eligibility, follow every relevant group path, establish observed activity and choose the correction at the right layer. That gives the owner a direct answer to product visibility with a supported route to a verified result.

Frequently asked questions

Does approved in Merchant Center guarantee campaign impressions?

It establishes the relevant eligibility context, not a guarantee of delivery in every campaign. Inspect current listing inclusion, parent states and actual period performance. A product can be eligible and included without reported impressions in the chosen window.

Can the bot see manually excluded product IDs?

The listing framework can inspect explicit item leaves and the full path, as well as products matched through broader rules. It must review every relevant enabled group for a campaign-level answer. Counting only explicit leaves or one asset group can miss much of the excluded population.

Does one product excluded in two groups count twice?

In the requested product-group occurrence measure, yes. Distinct product identity is another measure. The summary should state its counting basis and contributing campaign and group counts so the user understands what the total represents.

Can I filter exclusions by historical ROAS?

The supported dataset can relate eligible explicit-item history to current targeting with the defined primary-value-to-spend measure. Missing history remains unavailable and is reported through coverage. Broader partition performance is not allocated to individual products to manufacture the filter result.

Does enabling a product repair a disapproval?

No. Inclusion changes the applicable campaign selection. Merchant eligibility and its recorded issue are separate conditions. The final execution response should report the verified targeting state without claiming that a feed, website or provider review problem was also resolved.