Trace the product from Merchant eligibility to its actual advertising branch
Why are my products not showing? An agency guide to Merchant issues, Shopping targeting and Performance Max exclusions
Check the product's Merchant status for the intended country and destination, then inspect its campaign and listing-group membership. A disapproval, a manual exclusion and no reported impressions are different findings that need different responses.
Define where the product should appear
Start by establishing the intended surface. A product missing from Shopping ads in one country presents a different question from a product absent from free listings, a Performance Max asset group's product selection or a client's manual search. Ask which product, country, destination and campaign the client means. Then read the evidence for that scope. Merchant eligibility establishes whether Google reports an issue affecting the selected context. Ads targeting establishes whether the campaign's product partition includes the product. Performance establishes what exposure was reported during a period. None of these facts should be substituted for another merely because they all relate to visibility.
“Not showing” can describe several observations. The client might see a disapproved badge, notice no impressions in a report, find an excluded product in a listing tree or fail to see an ad when searching personally. These observations require different investigations. Record the actual symptom before ranking possible causes. A missing manual impression is not proof that a product never served, and an included product is not guaranteed to receive traffic. Likewise a product with historical impressions can be excluded now. The agency's first useful contribution is to translate the client's observation into a reproducible scope rather than opening every tool and presenting an unstructured collection of unrelated warnings.
Distinguish an eligibility repair from a targeting decision. Feed or policy problems can require source, website or Merchant review work. An intentional listing exclusion may simply need its commercial reason confirmed. A product with eligibility and inclusion but little exposure needs a performance investigation. The client should not be invited to approve an inclusion edit as though it removes a Merchant disapproval. The edit changes the advertising branch, while the Merchant issue remains its own evidence and task. A concise first answer names the verified blocking or limiting facts and identifies the next focused check.
Keep the business objective visible. A client might want all in-stock products eligible, prioritize a profitable category or keep discontinued items excluded. The agency needs that intention before proposing a broad inclusion change. A product may be deliberately omitted from one branch and included in another, with different creative or commercial purposes. The investigation should preserve that context. The eventual recommendation can be to repair an issue, retain an intentional exclusion, include a selected occurrence or review exposure. It should follow the evidence and the client's purpose rather than treating every absent impression as a technical failure.
Resolve the product and connected accounts
Confirm the connected Google Ads account and the relevant Merchant Center relationship. An agency can manage several accounts with similar store or campaign names, and the channel context must resolve the actual authorized client. A missing or expired Merchant authorization needs a clear connection or reauthorization response. It is not a verified empty catalogue. Similarly, a different Merchant account can explain why a familiar product cannot be found. Keep client-facing labels readable through the store and campaign names, while account identifiers remain inside the request. The investigation should not expose emails or internal job keys in a public report merely to prove that an account was resolved.
Resolve the specific product using the information the client supplied. A title fragment can match several offers, sizes or variants. Ask for the relevant product choice when that ambiguity affects the result. A product title is a convenient label, but the underlying offer identity establishes which inventory item belongs in the targeting path. Keep different variants distinct unless the client asks for an explicit grouping. Do not identify a product from the first partial title match and then propose a live edit against that guessed item. A readable candidate list can show the useful product names and commercial distinctions without overwhelming the client with every technical catalogue field.
Product IDs have a particular role in a listing-tree investigation. They can be necessary business identifiers for the exact item leaf the user wants to inspect, unlike an internal campaign or ad group resource number. Show the requested product identity and meaningful path when it is needed to answer the question, and avoid leaking unrelated account identifiers. If the client asks for the path to one item, the answer should name its owning campaign, asset group or ad group, and partition hierarchy. The identity should help the person recognize the selected inventory item. It should not become an indiscriminate dump of provider resource names.
Keep catalogue identity and historical reporting identity separate. A product may be represented through a broader partition today, while historical performance exists only for a particular explicit leaf path. The framework must preserve those relationships rather than joining unrelated rows by title alone. A title can change, an item can have several campaign memberships, and a listing leaf can be replaced while preserving its intended path. Use the relationship supported by the reporting surface. If history cannot be matched safely, show it as unavailable instead of borrowing a category's performance and assigning it to the individual product.
Read Merchant eligibility by context
Merchant product status is scoped by country and destination. A product can have different issues in different contexts, so an agency should read the intended Shopping ads or free-listing context rather than sum every returned number into an invented account-wide total. The current overview uses Google's aggregate product-status surface, avoiding an unnecessary download of the entire inventory simply to obtain provider counts. It returns active, pending and disapproved counts with issue details for each reported context. Preserve those labels in the result. An overview for one country should not be interpreted as a worldwide catalogue verdict.
Google's Merchant issue guidance distinguishes product-level issues from account-level issues and explains that country-specific warnings or disapprovals can differ. Warnings and disapprovals have different serving implications. The agency should read the actual issue and context before describing a product as universally blocked. Keep provider guidance brief and tied to the observed problem; the practical investigation then follows the product's specific status, source and intended destination. A general help article cannot establish that this client's product has a particular issue without a successful current read.
Pending status deserves its own explanation. A recently submitted or changed product may be under processing or review. The overview is not a promise of immediate refresh after every feed edit. Do not tell the client that a repair failed solely because the first subsequent snapshot still shows the earlier state. Establish when the source changed, inspect any current issue evidence and follow the provider's relevant review process. Conversely, pending is not proof that every required setup is correct. The agency should retain the unresolved status and identify the appropriate next check, avoiding both premature failure claims and a blanket assurance that waiting will solve everything.
An unavailable Merchant read must remain unavailable. Authorization errors, provider timeouts and partial coverage are operational facts, not product disapprovals. Explain the failed surface and preserve any independently successful Ads findings without pretending the Merchant side was verified. This lets the client distinguish an account access problem from a catalogue problem. Repeatedly rerunning a broad inventory scan is not a substitute for resolving access or choosing a focused supported read. The overview is useful because it obtains the provider's scoped aggregate directly; it should not be replaced with a local count that quietly loses context or hides a read failure.
Separate issue counts from product totals
One product can have several issues. A missing image, inconsistent price and destination problem can each contribute an issue count for that same product. Adding those reason counts does not produce a unique number of disapproved products. Keep the provider's context total separate from the issue breakdown. The client can then see both how many products are affected in that context and which problems require work. The current status module preserves severity as well as issue code, because the same code can have different serving impact in different destinations. A readable report should retain that distinction rather than flattening every warning into a disapproval.
Cross-context issue totals also represent overlapping occurrences. The same offer can have a reason in Shopping ads and free listings or in several countries. Those counts can help estimate the spread of an issue, but they should not be labeled unique products across the account. Neither taking the largest context count nor summing all contexts establishes a unique catalogue count when the product populations differ. State the measure that is actually available. This is especially important for agency clients who compare a Slack summary with Merchant Center: the comparison must use the same destination and country rather than two defensible numbers with different meanings.
Separate severity from business impact. A large issue count can concern low-priority inventory, while a smaller count can affect a core product category. The provider status identifies the issue and serving consequence; the client supplies commercial importance. Prioritize using verified context, inventory and supported performance information where available. Avoid multiplying a disapproved-product count by an average order value and calling the result lost revenue. That estimate would assume exposure, demand and conversion outcomes the report has not established. A useful agency handoff names the affected branch and evidence, then asks the appropriate owner to repair the specific issue.
Distinguish the listed examples from the complete issue population. The compact products response names a bounded number of reasons and indicates additional issues. An abbreviated list is not proof that no further problems exist. A fuller targeted investigation can inspect the relevant reason and matching products when supported. Keep its scope explicit, especially if the client wants a complete affected set. An empty result after a failed or incompatible filter must not be reported as a clean feed. The agency should verify that the successful read and selected context actually answer the question before interpreting absence as evidence of health.
Map the advertising campaign and group
Performance Max retail product targeting belongs to each asset group's listing tree. Standard Shopping product targeting belongs to each ad group's product-group tree. A campaign can contain several such groups, each with its own segmentation. Inspect all applicable enabled groups in the requested scope rather than assuming the first group's tree represents the whole campaign. The framework defaults to enabled groups in enabled campaigns, with explicit campaign-status scope when requested. Keep that population visible in the result. A count for current enabled groups should not be presented as all historical or paused targeting across the account.
The same product can be included in one group and excluded in another. That is not a contradiction in the read; it reflects separate targeting occurrences. The client may intentionally use different categories or creative branches, or an old exclusion may have survived a restructuring. Preserve campaign and group names with every occurrence. A question about one Performance Max campaign should not silently include another campaign that happens to contain the same product. A follow-up about one asset group should resolve that exact parent. These relationships are necessary both for an accurate count and for a safe later inclusion or exclusion proposal.
Google's listing-group API guidance describes the asset-group ownership in Performance Max and the analogous ad-group structure for other retail campaigns. Trees contain subdivisions and unit leaves, with complete partitioning through an Other branch. Performance Max listing filters express inclusion or exclusion rather than unit bidding. That model explains why a flat list of criterion rows is insufficient for the client's question. The agency must follow the relevant tree and preserve its parent relationships, not count every subdivision as though it were an individual product.
Current campaign and group state is configuration evidence. An enabled group does not prove that every eligible product received impressions, and a paused campaign's historical performance does not establish current exposure. If the client specifically requests paused campaign targeting, show that scope while retaining the enabled-group requirement of the current product-targeting dataset. Avoid quietly claiming coverage of paused groups that the dataset does not read. A clear boundary is more useful than a seemingly comprehensive count built from an inappropriate population. The agency can investigate another supported surface when the user's question requires a different state population.
Follow the complete listing-group path
A tree can begin at All Products, split into a product category, split again by brand and finally reach an individual item. The leaf's targeting state belongs to that complete path in its owning group. Show the hierarchy in an understandable order, naming the campaign and asset group or ad group first, then the product path. A label containing only a brand or item can hide which branch it belongs to. The client should be able to compare the result with the listing section they recognize in Google Ads without receiving an internal graph of resource numbers. Meaningful paths make deep segmentation inspectable.
A subdivision is a branch, not an included or excluded individual product. Its children determine the relevant unit leaves. Catch-all partitions also matter: an item not explicitly named can fall under the Other branch at a category or brand level. The framework evaluates the full ancestor and catch-all path rather than checking a single last dimension. This prevents an item from being assigned to the wrong leaf merely because it shares one brand value. The agency should distinguish explicit item leaves from products matched to broader rules, since they provide different kinds of evidence and may require different edits.
Broader excluded partitions can cover many products without listing their individual IDs as tree nodes. A count of explicit excluded item leaves alone can therefore understate the client's excluded inventory. The current product-targeting dataset expands broader leaves against the current campaign-scoped inventory and evaluates membership through the tree. It reports which products were explicitly identified and which were matched to a broader partition. This is a meaningful inventory count, with the dataset's completeness and scope limits retained. Do not confuse it with a count of exclusion rules. Both views can be useful, but they answer different questions and should be labeled accordingly.
Keep current inventory matching separate from historical performance. A product matched to an excluded brand partition today does not inherit all the brand partition's historical cost or return. It needs safely corresponding product history for an individual performance claim. If that history is absent, retain an unavailable measure. A current path can still establish targeting even when performance cannot be joined. The agency can answer “is this product excluded here?” without pretending to answer “how profitable was this specific product before exclusion?” The framework's relationship boundaries prevent one useful current-state fact from being stretched into an unsupported historical conclusion.
Count exclusions with the intended meaning
For the requested operational view, count excluded product occurrences per enabled group. If an item is excluded in two enabled asset groups, it contributes two occurrences. An account summary should name the number of matching products and the number of Performance Max campaigns and enabled asset groups, alongside Standard Shopping campaigns and enabled ad groups. This tells the client where the exclusions exist. It should not silently deduplicate the product across groups and replace an operational occurrence count with a unique catalogue count. A unique inventory question can be discussed separately, with an explicit identity and scope.
Consider a simple theoretical case: one campaign has two enabled asset groups with the same three products. The first excludes product two; the second excludes products two and three. The requested operational count is three excluded occurrences, even though only two distinct items are involved. The result should preserve both groups so the client can inspect and change the appropriate occurrences. Calling this “two exclusions” would hide one live targeting branch. Calling it “three unique products” would misdescribe the inventory. Clear wording can state the occurrence count and, when requested and supported, a separate distinct-item view.
Count only the campaigns and groups with matching findings in the stated selection. Do not include an enabled group merely because it exists in the account if none of its products match the requested exclusion condition. Conversely, preserve the same item in two matching groups. The dataset's summary uses campaign and group identity internally to support those counts, while the output uses meaningful names. Split the result between explicit item identities and inventory-matched broader rules when that distinction affects interpretation. A client can then understand why the count is larger than the number of individually named excluded leaf nodes visible in one tree.
Handle incompleteness honestly. A work or row limit should prompt a narrower campaign or group selection rather than a claimed account-wide exact count. Unknown performance under a condition should be reported as unassessed, not silently treated as zero or omitted without explanation. The full matching selection and the displayed preview are also separate. A top-ten list can illustrate a larger verified count, but it should not become the target population for “enable all” unless that is exactly what the user means. Safe counting establishes the selection before the action, keeping a compact Slack presentation from hiding the true scope.
Relate current targeting to historical performance
A client may ask how many products with return above a threshold are excluded. This combines current targeting with historical performance, so the answer must state both scopes. The product-targeting dataset establishes the current leaf state in enabled groups. Its related performance uses the requested reporting period and a safely matched group and full dimension path. The result should explain that these are products excluded now with the selected historical performance, rather than implying they were excluded throughout every date of that performance period. Current configuration cannot reconstruct historical status without the appropriate evidence.
Use the selected primary outcome definition for the supported related measures. The current listing relationship reports primary conversion count and value, with return calculated as value divided by cost. That primary value is not automatically purchase-only revenue, since the action population can include other valued primary outcomes. Label it accurately when interpreting a product's return. A value threshold based on all primary outcomes answers that selected question; it should not be described as a profit margin or a guaranteed purchase return. The agency should keep the account's commercial definition clear, especially when leads or other valued actions coexist with purchases.
Unavailable history and zero cost require careful handling. A product without safely matched history has no verified individual return. A zero-cost denominator also makes return undefined. Neither state means a return of zero. Preserve nulls and unknown-condition coverage so the client knows how many products could not be assessed. A broad brand or category leaf can have performance, but the framework does not distribute that aggregate across its individual inventory members. That boundary prevents a large excluded partition from producing fictitious high-return products merely because its parent historically performed well.
Reuse the group/path relationship for performance reads rather than making one API call for every product. The current implementation batches relevant group keys and only requests the measures needed for the selected fields or conditions. This is important for an agency account with many products under a few groups. Local capability and tree evaluation can reduce unnecessary reads, while bounded provider results protect completeness. Efficiency should not come from replacing unavailable product history with a convenient parent total. The accurate answer can include a verified matching count and an explicit unassessed count, giving the client a safe basis for a narrower follow-up.
Apply product and outcome conditions precisely
Use the generic condition framework to express the client's actual selection. A request can narrow by campaign, asset group or ad group, product title or item, current inclusion state and related performance. “Return above three” excludes equality, while “at least three” includes it. The current related return uses a multiple, so three means three times value relative to cost, not three percent. State that interpretation when it affects the result. Keep display rounding separate from the exact values used for comparison. A value shown as three can sit on either side of a strict boundary.
Logical combinations also matter. “Excluded products from Brand A with return above the threshold” selects the intersection. “Brand A or Brand B” selects a union under the stated parent scope. Do not drop an unsupported pushed-down OR merely to simplify the provider query; the complete condition must still be evaluated correctly by the shared executor. The framework can safely push supported parts of the scope and retain exact local evaluation where appropriate. The client-facing explanation should state the meaningful selection rather than exposing the internal expression tree. Reusable conditions make this work extendable without a new dedicated tool for every wording.
Keep unknown values distinct from false conditions. A product lacking the selected historical metric cannot be classified as below the threshold simply because the report has no number. State how many rows were assessable and how many remained unknown when that changes the answer. If a provider read fails, it is not a confirmed empty selection. A successful current-targeting read can still be reported separately while the performance branch remains unresolved. This helps the agency avoid making an inclusion decision based on an invented low-return label caused by missing data.
A follow-up should preserve the established selection. If the client asks “include those,” the proposal should resolve the exact verified products and owning partitions, not repeat an account-wide search and find a different set. If the preview is incomplete or the selection exceeds safe bounds, ask for a narrower request. If the user changes the condition, prepare the new selection explicitly. A reusable dataset and relationship framework can support these steps while maintaining target identity. The agency should never let a conversational shorthand authorize unseen products or a whole-tree replacement that the user did not request.
Investigate feed and website consistency
A Merchant issue can concern the product data, website or account setup. Read the actual reason and assign the task to the owner who controls that surface. A price mismatch may require checking the feed source and landing page; a missing image needs the image source; a destination problem needs website evidence. Do not claim that an Ads inclusion toggle repairs those facts. The provider overview identifies the reported problem and context, while a deeper feed or site review establishes what needs changing. The general product-visibility guide provides the underlying distinction, and an agency handoff should adapt it to the client's actual owner structure.
Verify the live commercial offer rather than copying data between systems blindly. The feed and landing page should describe the intended product, variant and availability. A temporary stock change can create a different task from a permanent discontinued item. The client may intentionally keep unavailable inventory out of advertising while fixing the source. The agency should confirm the desired commercial state before preparing inclusion. A product can be technically included in a listing tree while its site offer remains unusable. That is why targeting status and the website task must be documented separately.
A feed audit provides additional evidence when the issue points toward broader data quality. Use the supported tool and its actual findings rather than promising that one audit certifies every product and every website path. Product-level examples, aggregate status and historical earning-product views have different coverage. Preserve their limits and avoid treating a bounded example list as the complete affected inventory. Creative assistance can help improve a product title or draft an explanation from known context, but the draft is not automatically a live feed update. Separate suggested content from measured defects and from authorized publishing.
Review processing and provider decisions after the source repair. A changed feed can still need processing or review, and the first status snapshot may not reflect the new state. Use the appropriate provider workflow when review is required; do not advertise a universal automatic appeal service. A successful source update and a later approved Merchant state are separate evidence. Record both when available. If the product remains affected, return to the actual current issue rather than repeating the same Ads edit. This gives the client a clear explanation of what was repaired and which provider decision is still outstanding.
Follow an illustrative agency investigation
Consider an invented review by Ava Linden at Maple Media for the fictitious Willow Workshop Store. These people and events are illustrative, not a customer outcome. The client says several garden tools are not showing. Ava establishes that the concern is Shopping advertising in the intended country and identifies the relevant connected store and Ads campaign. The products overview reports scoped Merchant issues, while the targeting read inspects enabled Performance Max asset groups. The client receives those findings separately: some offers have a Merchant issue, and another item is excluded in a particular group. One label cannot accurately describe both cases.
The campaign has two enabled asset groups with different listing segmentation. One divides the inventory by category and brand, then names individual items; the other uses a broader brand partition. A product is excluded in both groups, while another is excluded only through the broad partition. Ava asks for the operational occurrence count and the complete paths. The framework preserves each group's membership and distinguishes explicit leaves from inventory-matched rules. The result explains why the count exceeds the number of individually named excluded item nodes. It does not describe every subdivision in the two trees as a product.
The client asks which excluded occurrences had return above the agreed threshold in the selected historical period. Some explicit leaves have safely matched history; broader inventory-derived memberships lack individual history. Ava reports the verified matches and the unassessed population separately. She does not assign the brand partition's value to every product. The client selects one intended item occurrence for inclusion, while the website owner repairs a price inconsistency affecting another offer. The proposal shows the campaign, asset group, selected item and exact targeting effect. It does not promise that inclusion will override the Merchant issue.
After confirmation, the app verifies the desired semantic product path and inclusion state where supported. Ava records the feed repair and later Merchant status separately. The follow-up report examines eligible exposure and selected outcomes without guaranteeing impressions or recovered sales. The case illustrates a reusable agency process: identify the symptom, read the correct contexts, follow the actual parent trees, preserve count meaning and approve a precise effect. The framework supports different products and segment paths without hardcoded brand rules or a dedicated tool for each client's campaign structure.
Choose focused Slack tools and conversation
Use /ppctor products for the connected Merchant product-status overview. It reports provider context counts and issue reasons, with a bounded compact listing. That overview is useful for asking whether Google reports a current catalogue problem. It is not the same as a product-targeting tree query. A conversational request such as “How many products are excluded in this Performance Max campaign's enabled asset groups?” uses the reporting dataset for that structure. The agency should choose the surface that answers the question rather than expecting one command to combine Merchant policy, current listing state and historical product performance automatically.
A focused follow-up can name the intended group: “Show the excluded products in Seasonal Tools, including their full product paths.” The assistant should reuse the established account and campaign context and resolve the actual enabled group. If the name is ambiguous, ask a narrow question. If the client asks for performance conditions, add the supported related history read with its selected dates. Avoid scanning unrelated Merchant inventory for a count that explicit listing leaves already answer. Broader partitions do require their relevant inventory matching, so efficiency comes from conditional work rather than pretending every product question can be solved without provider data.
Creative conversation remains useful around the measured result. The assistant can draft a client explanation, suggest a category organization or brainstorm product copy from the established offer. These requests do not automatically require keyword research or another catalogue scan. A request for actual targeting or current status does require the appropriate read. The distinction lets the agency work naturally in Slack without turning every sentence into an API operation. Keep proposed copy and organization ideas clearly separate from a live tree edit, which requires exact supported targets and owner confirmation.
Handle follow-ups through reusable data and relationships. Sorting a verified exclusion list, grouping it by campaign or drawing a supported visual from it should reuse that dataset when its scope remains valid. Changing dates, requesting a new Merchant context or preparing current edits can require focused additional reads. Read failures should identify the affected surface and leave successful independent facts intact. The agency account-question workflow describes the general conversation pattern. Here the product and listing relationships supply the exact hierarchy and count semantics needed for the client's specific question.
Present an understandable visibility result
Lead with the verified answer and scope. For Merchant issues, name the country and destination. For exclusions, name the operational product-occurrence count and the matching campaign/group totals. Then show a small readable table or list of the most important examples, with the parent hierarchy. A result can say that excluded occurrences span Performance Max campaigns and enabled asset groups, plus Standard Shopping campaigns and enabled ad groups. Avoid a wall of field names or a count of nodes mislabeled as products. The client needs to see what is affected and where the agency recommends the next action.
Show each meaningful condition once near the result. State the current-targeting population, historical performance dates and selected measure where applicable. Distinguish explicit item leaves from broader-rule inventory matches. If performance is unknown for part of the population, give the unassessed count rather than burying the limitation in a generic footnote. Display currency and ratios with readable precision, keeping comparison boundaries based on underlying values. A compact message can be accurate without becoming technical. Clear labels carry the scope that would otherwise be lost when the client reads only the top of the reply.
A requested chart should describe a real measured pattern. Merchant status snapshots are not automatically a historical daily series. A current exclusion count should not be drawn as a fabricated last-thirty-days trend. Historical product performance can support its available grain and relationship, while current targeting can support a grouped count. Use the verified dataset for the chosen visual and explain its measure. If the user asks for an unavailable history, state the specific boundary and offer a supported view. Do not create a plausible-looking chart from repeated current counts merely to satisfy the word graph.
Keep provider implementation details out of the normal client report unless they help the decision. The source matters through labels such as Merchant status or Ads targeting, not a raw provider version line or internal retrieval timestamp that dominates the result. Dates that define the measurement remain important and should be readable. A larger supported report can preserve the relevant scope and evidence without adding every available technical column. The agency can then summarize the actionable findings in Slack while retaining a usable fuller view for investigation, rather than making the client decode an API response.
Prepare exact inclusion and exclusion effects
The product-inclusion action uses the verified selection's group, listing leaf and selected item identities. It can include or exclude those specific products while preserving unrelated partition behavior. Current preparation rechecks the enabled owning group and appropriate campaign/group type, reads the tree and resolves the exact selected leaf. It rejects a missing leaf or one that has become a subdivision. These checks protect against a stale result after another person changed the listing structure. The agency should prepare from the verified selection rather than reconstructing targets from a displayed title or a cropped preview.
An explicit item leaf can require replacement to change its targeting state. A broader leaf can require a subdivision that names the selected items and retains a catch-all branch for the other inventory. An existing item catch-all can be extended with named siblings. These are implementation differences behind one understandable client effect: include or exclude the selected items in this owning group. The plan should preserve unrelated products and follow the provider's valid tree constraints. Do not use a whole-tree retargeting operation to fulfill a narrow product request when the dedicated partition action can express the exact effect safely.
For inventory-derived selections, preparation verifies the selected items against campaign-scoped inventory and the complete ancestor/catch-all path. A product missing from the expected scope or ambiguous within it should stop proposal preparation rather than receive a guessed target. Standard Shopping bid requirements and provider validation can also matter when included leaves are created. Respect the existing supported adapter and validation behavior; do not promise every arbitrary restructuring as a simple status toggle. The client-facing proposal should still describe the intended selected product effect clearly, without presenting internal temporary resource construction as something the client must understand.
A mixed Performance Max and Standard Shopping request can submit updates separately. One side may have applied when the other fails, so the result must retain per-effect status and avoid claiming atomic completion across both surfaces. Bound the selection to the supported safe size and ask for narrower work when necessary. This is a reason to display every logical effect distinctly under the confirmation. It is not a reason to silently execute only the first few products. The agency's plan should make the exact target set, dependency behavior and possible partial completion understandable before the owner approves it.
Approve and verify the targeting change
Show the campaign and owning asset group or ad group, then the selected product identity and requested inclusion or exclusion. Use one clear step or row per effect. Keep the meaningful product path visible when it disambiguates the leaf. Do not show an ad group as its own parent or add internal campaign numbers to a client-facing label. The client should see the actual target and scope before clicking Confirm and Execute. A Merchant feed task remains a separate line with its external owner, not an implied consequence of the targeting mutation.
Include the notice: “No changes have been made yet. This proposal expires in 15 minutes.” Preparing the request does not change the live account. The connected owner confirms the displayed effects, and the execution flow rechecks authorization and relevant current settings before supported validation and mutation. A revised selection or changed tree needs a revised proposal when it affects the intended request. The agency approval guide explains the common safeguards. The product workflow supplies the specific leaf relationships that those safeguards must protect.
Make execution progress visible promptly so the confirmed click does not appear ignored. The final result should distinguish sent changes, read-back verified effects and unresolved outcomes. The partition adapter verifies semantic full product paths and desired leaf state rather than relying on replacement resource numbers that can change during the mutation. That is the configuration evidence the client needs. A successful verification does not promise immediate impressions, policy approval or sales. Those are later eligibility and performance questions with their own evidence.
Do not blindly replay an uncertain mutation. If one write was sent and complete verification failed, inspect current state before deciding whether another change is needed. If mixed surfaces completed only partly, show which effects are verified and which require review. Keep the result's target labels consistent with the proposal so the agency can compare them easily. A clear successful-execution status is useful, but it must not cover an unverified external feed repair or an unsupported promise of future exposure. The client should know exactly what changed and what remains to be checked.
Review eligibility and exposure after the repair
Follow up on the mechanism that was repaired. For a Merchant issue, review the current provider context after the source work and relevant processing or review. For a listing edit, verify the desired path and current inclusion state. For an exposure question, read the appropriate performance period. These checks can occur at different times and should not be collapsed into one pass/fail label. The agency can report a verified targeting change while a Merchant issue remains pending, or a cleared Merchant issue while the client intentionally retains an exclusion.
Review outcomes with the same definitions used for the original decision. A product's later impressions do not automatically prove that a specific repair caused the change, and an included product with no immediate traffic is not proof that the edit failed. Examine the relevant campaign and group scope, commercial availability and selected outcome measures. Retain current-versus-historical distinctions in the follow-up. If the client changes the objective from all primary value to purchase-only outcomes, state the new definition instead of presenting the resulting series as directly continuous with the earlier measure.
Maintain a record of intentional exclusions and their commercial reason. A product might be unavailable, unsuitable for a region, reserved for another branch or temporarily excluded during source repair. Review those reasons when the offer changes. A later inclusion request should use the current exact selection and its own approval, rather than assuming an old proposal remains authorized. The agency can keep the record readable through product names and parent paths while retaining actual resource identities internally. This makes handovers more useful than a list of raw criterion numbers with no explanation of why each leaf exists.
The completed investigation should answer the client's actual visibility question: which Merchant context was read, which enabled targeting branches were inspected, what was included or excluded, which history was available and what changed after approval. Preserve unknowns and incomplete populations rather than manufacturing a universal account verdict. A reusable framework of datasets, conditions, trees and exact edit adapters makes that process work across different campaigns and inventory structures. The agency supplies the commercial interpretation and clear handoff. The client receives a specific path from observed symptom to verified configuration and an appropriate next performance review.