Turn an account exclusion count into an explicit inventory decision
Google Ads app-category-exclusion audits for in-house teams: agree the inventory policy before applying it
Understand the account-level coverage check, preserve intentional app activity and distinguish exclusion settings from placement performance. Prepare an exact, approved change and verify the categories that were added.
Define the inventory decision
An app-category-exclusion audit should help the team decide which app inventory fits its advertising policy. It starts with a setting question: which mobile app categories are excluded at the account level? That question is useful, but it differs from whether particular placements delivered valuable customers. Define the decision before interpreting the card. The in-house team may want a conservative account-wide inventory boundary, a review of an existing convention or evidence for a selective change. Each purpose needs a different level of investigation.
Bring the business context into the review. A company promoting a website service can have different inventory preferences from a company acquiring users for its own app. Brand suitability requirements can also matter independently of short-term conversion performance. The audit's recommendation should be considered alongside those objectives, rather than treated as a universal advertising rule. Write down the policy the owner intends to enforce and identify the campaigns whose goals need consideration. This makes approval a conscious decision about distribution, not a reflexive response to a red status.
Keep the first task proportionate. If the owner already decided that all available app categories should be excluded, the tool needs current account exclusions and the provider's available category set. It does not need to rank campaigns or fetch performance simply to implement that policy. If the owner has not made that decision, the conversation can clarify objectives before any edit is prepared. Efficient execution and careful judgement work together when the workflow distinguishes an agreed instruction from a recommendation that still needs business context.
Distinguish categories, apps and other exclusions
A mobile app category groups apps under a provider-defined classification. An individual app exclusion names a particular application. A website placement exclusion identifies another kind of inventory. A content-suitability control addresses a different classification again. These can all influence distribution, but they are not interchangeable resources. The current card checks mobile app categories at the account level. It does not add up every exclusion type or certify that the account's wider suitability policy has been implemented through all available controls.
The Google Ads API represents customer-level exclusions through customer negative criteria, with different fields for mobile app categories, individual mobile applications and placements. That resource distinction supports precise targeting of a requested edit. It does not mean that a category audit has already inspected all those fields. Use the correct resource type when interpreting a count or preparing an action. Google's customer-negative-criterion reference documents the provider types and their account-level context.
Translate these distinctions into ordinary language for colleagues. Exclude all app categories describes a broad category policy; exclude one named app describes a narrower placement decision. Neither instruction means disable mobile devices or remove the company's product from Shopping campaigns. Avoid ambiguous shorthand such as block mobile when the user means app inventory. A clear clarification at this point prevents the assistant from selecting a technically valid operation with a different business effect. The proposal should retain the same meaning the owner confirmed in the conversation.
Read the account-level coverage check
The current reader queries account-level customer negative criteria whose type is mobile app category. It compares the returned exclusions with the selected category universe. Only exclusions whose category is present in that universe contribute to the count. Structural headers and unrelated exclusion types do not increase it. The result contains an excluded count and a universe count. It supplies configuration coverage, not a category-by-category history of impressions, clicks, costs or conversions. Those metrics are absent from this particular check.
The card calculates how many categories remain unexcluded and passes when that number is zero. Otherwise it reports the number not excluded and offers the supported exclude-all action. A pass therefore means the selected universe is covered by this account-level comparison. It does not mean a placement report is empty, every historical app impression disappeared or all inventory policies are optimal. Keep the configuration statement narrow. The owner can use it as one verified part of a broader distribution review without overstating what was measured.
This check does not inspect campaigns to determine which ones use app inventory, and its result does not aggregate campaign-level or ad-group-level category controls. A category blocked through another scope may still appear unexcluded in the account card. That is consistent with the card's question. If colleagues ask for effective coverage across several levels, obtain evidence for those levels rather than reading the account count as the complete answer. The requested business scope should determine the evidence, while each returned setting remains labelled with its actual level.
Understand the category universe
The available category list is obtained from Google's mobile app category constants. The integration filters a defined set of structural container identifiers and retains the remaining finite category identifiers. This avoids counting expandable platform or grouping headers as ordinary leaf categories. The list is provider-derived rather than a permanently fixed total in the article. Its coverage still depends on the application's current filtering rules. A reader should understand that the universe is the set this implementation selects, not an independently reconstructed map of every app in the marketplace.
The audit fetch path caches that shared category list for thirty days. A successful cached read can therefore avoid repeating the constants query for every connected account audit. The account's own exclusions are queried separately. This separation is sensible because the category catalogue and customer settings have different meanings and change patterns. Do not confuse reuse of a catalogue with reuse of another customer's exclusion state. The former supplies stable classification knowledge; the latter must belong to the selected account and the relevant retrieval context.
Preparation of the supported live action retrieves the current available categories rather than blindly writing a historical fixed list. The resulting proposal can account for existing exclusions and add only what is missing. A changed provider catalogue can therefore alter the proposed number without changing the owner's broad instruction. Explain the number as available categories in the retrieved set. Avoid a timeless claim that all accounts always have exactly the same advertised count, especially when comparing an older screenshot with a newly prepared request.
Interpret the application's recommendation
The card's recommended state is exclude all. Its explanatory copy presents broad app exclusions as a conservative choice for accounts without App campaigns. This is the application's recommendation, not a measurement that every app category produced poor results. Keep the distinction explicit in the internal review. A missing exclusion tells the owner that the account differs from the recommended setting. It does not establish that the category served, that the clicks were accidental or that those visitors could not become valuable customers.
The current card does not enforce its App-campaign caveat by inspecting the campaign inventory before returning its status. The caveat remains information for the owner to consider. An in-house team should therefore check relevant business intent before approving the broad action. That does not require unnecessary campaign discovery during every already-agreed account-level edit. It requires recognising when a recommendation is being evaluated rather than merely executed. A user asking whether they should exclude app categories deserves consideration of their actual goals, not a repeated reading of the card's default.
Do not make a perfect audit status the advertising objective. An account may intentionally retain some inventory after a documented review. That decision can remain visible as an exception to the product recommendation. A justified exception should identify its owner and purpose, not hide the setting or pretend it matches the default. The team can then revisit it when objectives change. This approach keeps the audit useful as a transparent checklist while preserving the business judgement needed for account-specific distribution and acquisition decisions.
Recognise unavailable and empty evidence
A failed exclusion read is different from a successful read that returns no exclusions. The first leaves the setting unknown; the second supplies evidence that this account-level query found none. The audit's unavailable mapping associates this card with its data section, so a known section failure should not be represented as healthy coverage. Keep the retrieval status with the conclusion. When a tool cannot obtain the evidence, say which check could not be completed rather than inventing a count or returning the recommended state as if it were observed.
An empty category universe needs particular care. The fetch path can fall back to an empty list if catalogue retrieval remains unavailable. The finding now reports an unverified review with no automatic fix for an empty or invalid universe, rather than treating zero missing entries as complete coverage. Both live editing preparation and the audit action refuse an empty provider list. A meaningful nonempty catalogue remains necessary for the ordinary coverage conclusion; missing taxonomy evidence stays visible as an incomplete check.
For a real investigation, resolve the missing evidence before approving a proposal based on it. Refresh the relevant catalogue or account read through the supported workflow and confirm that a meaningful available set was obtained. Do not ask the user to choose an arbitrary number of categories to compensate for an unavailable list. The provider supplies the categories; the user supplies the intended policy. Keeping those responsibilities separate prevents the assistant from turning a temporary retrieval problem into an unsupported configuration decision or a misleading success report.
Protect intentional app activity
If the organisation promotes its own app, bring that goal into the discussion before applying an account-wide category policy. The card itself warns that App campaigns need app inventory and that broad exclusion can be counterproductive in that context. The relevant owner should explain whether app acquisition remains part of the account's strategy. A setting change motivated by website lead quality can have a wider account scope than the immediate problem. That wider scope must be clear to the person approving the proposal.
Do not equate app promotion with permission for every possible placement, either. The team may still have brand suitability requirements or specific inventory concerns. Those concerns should be evaluated with the appropriate supported controls and evidence. The useful question is which policy fits the account's goals and provider capabilities. A blanket rule based only on the presence or absence of an App campaign is too crude to resolve every case. The audit starts the conversation; the business and distribution owners supply the necessary context.
Record intentional exceptions so future colleagues do not reverse them during routine cleanup. State the relevant business activity, the owner and the reason for retaining or excluding the scope. This record can be concise. It should let a paid media specialist understand why the account differs from the default recommendation without searching old chat threads. Review the exception when the app programme ends, the account is reorganised or the inventory policy changes. Its purpose is continuity of judgement, not an indefinite exemption from examining current results.
Separate account scope from channel behaviour
An account-level exclusion identifies where the setting is stored. It does not supply a complete explanation of every campaign's eligible distribution. Provider rules differ across campaign types and inventory surfaces. Google's placement guidance distinguishes account, campaign and ad-group scopes, while its Performance Max guidance says that Performance Max respects account-level and manager-level placement exclusions. Those documented controls should inform the wider review without being treated as a promise that the category card checked every applicable surface. Google's placement-exclusion guidance explains the scope options.
Performance Max also has several distribution surfaces, so an app-category policy is only one part of its inventory management. It does not exclude specific products from a listing-group tree, change Search keywords or disable a mobile device category. Keep the requested operation separate from those controls. A user naming a Performance Max campaign may be asking for a campaign-specific effect, while the available broad category action writes at account level. The proposal must make that difference clear before the user can reasonably approve it.
Use the current provider documentation when reviewing channel applicability rather than copying a rule from an old article or assuming every exclusion behaves identically. Explain the supported scope of the actual operation and avoid guarantees about undocumented combinations. A team can verify that category criteria were stored at account level and separately investigate subsequent placement reporting. These are different evidence stages. Google's Performance Max suitability guidance documents the broader placement-control context.
Agree a policy with the right owners
The paid media owner should coordinate the inventory policy with the colleagues responsible for brand standards and business outcomes. A brand concern can justify avoiding certain environments even when immediate performance is inconclusive. A performance concern needs a defined outcome and a meaningful reporting scope. Write down which rationale governs the change. Mixing them makes evaluation difficult: a brand safety decision should not be called unsuccessful simply because short-term cost per lead rises, and a performance claim needs more than a suitability preference to support it.
Give the approver a concise description of the account-level effect. Broad app-category exclusion is a distribution policy, not a creative refresh. It can matter to several business units sharing the same advertising account. Identify the affected ownership boundary before preparing the change. That does not mean every colleague must approve every category. It means the person confirming the operation should have authority for the intended scope and understand that the action is broader than a single placement example mentioned in a conversation.
Retain the decision in a useful place. The policy can state the default treatment, deliberate exceptions and the circumstances that trigger review. The execution record can retain the specific approved change and verified result. Ordinary Slack requests can remain in their separate conversation record rather than appearing as executed edits. This separation gives the team both continuity and accountability. It also prevents a brainstorming discussion about exclusions from being mistaken for evidence that a live setting was already changed.
Request performance evidence separately
If the question is whether app inventory performs poorly, request reporting evidence capable of answering that question. The coverage card contains no placement costs or outcomes. A count of unexcluded categories cannot rank their value. Establish the campaigns, period and available placement reporting before interpreting results. Some reports expose different levels of detail or different measures. Preserve those limitations rather than attaching campaign-level revenue to a particular placement because both appear in the same account. Attribution at one scope does not automatically transfer to another.
Use a focused request. The owner may need to examine a named campaign's reported app placements over a recent period, or compare a defined set of reported rows against the current policy. Retrieve only the necessary fields and handle pagination where the report requires it. A short display should not silently become the complete underlying population. If a provider report offers impressions without the requested conversion value, explain that boundary. Do not calculate a placement ROAS from unrelated campaign totals merely to fill an expected column.
Keep performance evidence separate from current configuration. A placement can appear in a historical report even after a new exclusion is stored. The date range may include activity before the change. Conversely, the absence of a placement row in one report does not prove the exclusion prevented a specific number of visits. Establish the implementation time and reporting scope. The team can then evaluate subsequent results under a stable definition without confusing historical activity, present settings and a hypothetical counterfactual about what would otherwise have happened.
Define meaningful outcomes
A performance review needs the intended business outcome. For a lead-generating account, total primary conversions can include several kinds of primary actions. The owner should know whether the comparison uses all of them or a particular named action. Calls can contribute primary conversions and assigned value; imported offline conversions can also be visible in account reporting. Their presence does not prove that every placement report attributes them at the required detail. Keep the outcome definition and the report's available granularity explicit.
For a commerce account, distinguish total primary conversion value from purchase-only value and from GA4 purchase revenue. A campaign can have primary actions with assigned value outside purchase categories. If the owner wants a cross-source comparison, the metric definitions and scopes should match the intended question. A lead comparison requires an explicitly selected corresponding GA4 event rather than an inferred universal event name. These rules apply across the reporting framework; an app inventory investigation should not introduce a separate improvised definition of revenue or leads.
When the owner uses all-traffic revenue divided by advertising spend, label that measure blended ROAS or MER. It can help assess the broader business picture but does not establish the value of an individual app category. Ratios should use compatible numerator and denominator populations and be calculated from the relevant totals. Averages of unrelated row ratios can mislead. The audit's exclusion count remains a configuration measure. Connecting it to meaningful outcomes requires the separate reporting evidence and commercial definitions that the team agreed.
Avoid unsupported waste and savings claims
Do not call every app impression waste. A provider-defined category identifies an environment, not the intention or quality of each visitor. Accidental interaction can be a concern, but the coverage card does not observe intent. It also does not inspect fraud, validate individual leads or read customer conversations. The in-house team can adopt a conservative policy without claiming these unobserved facts. A clear rationale says that the owner prefers to avoid the inventory scope, or that a specific performance investigation supports a particular exclusion.
Historical cost is not automatically recoverable savings. Removing an inventory option can change where the campaign spends, how much it delivers and which outcomes it obtains. The card supplies no estimate of that counterfactual. A report should therefore avoid promising that the exact cost of previously reported app activity will return to the business after exclusion. The company can observe future distribution and outcomes, accounting for other relevant changes. That is an evaluation plan, not a guarantee of a fixed financial benefit from the setting.
Keep the decision and the measurement honest. If the reason is a brand policy, describe compliance with that policy as the immediate outcome. If the reason is performance, define the evaluation period and the data needed to assess it. A successful mutation confirms a stored setting; a later business review evaluates consequences. These two successes need not occur at the same moment. Separating them makes the final execution message precise and prevents a prominent verified status from being mistaken for a provider-certified improvement in advertising efficiency.
Choose broad or selective treatment deliberately
The supported exclude-all convenience action applies the available category set at account level. It is suited to a user who deliberately requests that broad policy. It should not be selected for a narrower instruction to avoid one named app or one category. Broad and selective treatments have different targets and require different operations. Resolve the intended scope before preparation. The tool's ability to perform a broad action efficiently is not a reason to expand the user's request into a more extensive change.
Selective treatment can be appropriate when the owner wants to retain some inventory and exclude an identified concern. That decision still needs a supported operation, an exact provider target and a clear level. Do not promise a particular selective convenience tool merely because the API has a resource type capable of representing it. The current workflow must support the requested edit and its verification. If it does not, give a precise implementation handoff or supported alternative for the owner to assess rather than hiding the capability gap behind an exclude-all proposal.
Account-wide policy can also conflict with a requested campaign-specific exception. Explain the hierarchy and the actual effect of the available operation before preparing it. The user should not have to infer that a request mentioning one campaign would alter every account-level category criterion. Scope is part of the proposed action, not a technical footnote. Once the owner confirms the broad intent, the workflow can proceed without unnecessary campaign searches. The clarification protects the business meaning while keeping an already-agreed account edit efficient.
Follow an invented in-house review
The following is an invented example. Rowan Ellis manages acquisition for Birch Kitchen Supplies. The account audit reports several app categories not excluded. Rowan initially asks whether those categories explain weaker leads. The analyst points out that the card supplies current exclusion coverage and contains no lead-quality evidence. They identify the relevant campaigns and agree on the primary lead action used in the performance review. The brand owner separately confirms that the company's current distribution policy prefers to avoid app inventory in this account.
The team checks that there is no intentional app-acquisition programme requiring a different policy. They decide to apply the broad account-level category instruction for the stated distribution reason. Rowan does not ask the assistant to rank every campaign before preparation because the policy target is already settled. The tool reads the current category universe and exclusions, then prepares only the missing criteria. The proposal names the account-level scope and retains existing exclusions. It does not promise better lead quality or quantify savings that the evidence cannot establish.
After confirmation, the workflow verifies that the intended category set is present. Rowan records the implementation time and the brand-policy decision. The analyst reviews later campaign outcomes using the same defined primary lead measure, while keeping other concurrent changes visible. This case illustrates a disciplined process rather than an expected improvement. Another company could retain app inventory after reviewing its goals. The useful pattern is to distinguish configuration, policy and performance, then approve and verify the action that matches the actual decision.
Use conversation and targeted account reads
A user can ask the assistant to explain app exclusions or draft an internal policy without calling Google Ads. These are conversational tasks. Current coverage, available categories and owned account settings require appropriate account evidence. Separate the tasks so the assistant does not run a full audit for a general explanation or invent a live count from a previous example. The same principle applies to creative work across the application: a suggestion or planning discussion need not become a provider-backed research request simply because it concerns advertising.
When the user requests a live account edit, identify the connected account and the exact action. Exclude all app categories has an account target; no campaign selection is required for the convenience operation. Reuse reliable context where it answers a follow-up, but refresh changeable settings as required before execution. A local action catalogue can identify the target type without an API request. The provider read supplies the current exclusions. Keeping those roles distinct avoids unnecessary discovery while preserving the evidence required for a safe, accurate proposal.
If the user first asks about a campaign and then asks to exclude all categories, clarify any conflict between campaign-specific wording and account-level effect. Do not silently translate one into the other. The assistant should retain the user's earlier context while recognising that the chosen operation has a broader target. The resulting reply can be concise: this action applies at account level, and approval will cover that scope. Once intent is established, avoid repeated questions that simply ask the user to restate an already confirmed policy.
Prepare the supported exclusion action
The current preparation function obtains the available leaf categories and reads existing account-level mobile app category exclusions. It refuses to prepare the action when the available set is empty. It then compares the sets and creates operations only for categories not already present. Existing exclusions remain in place. This difference-based preparation avoids treating the broad policy as a reason to recreate criteria that already satisfy it. The provider request is built from the exact missing set, not a pasted fixed number from an article.
The proposal includes a verification requirement that the account query contains the intended category set. This is the correct direction of comparison for an additive policy: all requested categories should be present, while unrelated existing exclusions need not disappear. Do not describe the operation as replacing the entire exclusion configuration. Its purpose is to add missing app-category criteria. Other exclusion resource types remain outside the requested change. This narrow behaviour should be clear in the user-facing step and in the execution record used for later review.
If no categories are missing, there is no live addition to execute. Report the current covered state rather than manufacturing a new operation so the user can click a button. The workflow should distinguish a verified no-op from a successful mutation. The owner still receives a useful answer: the requested account category coverage is already present. This saves provider work and avoids confusing the execution history with edits that made no change. It also makes later investigations easier because the log reflects actual actions rather than repeated checks.
Use the real dependency boundary
This action depends on the connected account, the available categories and the existing customer-level criteria. It does not depend on creating a campaign, selecting an ad group or reading an asset group's product tree. A general dependency framework should express that account-level boundary. It should not force every edit through campaign discovery simply because many advertising resources have campaign parents. The local catalogue identifies which target types and prerequisites are relevant; each operation then retrieves only the current facts that its own preparation requires.
The broad exclusion can be one logical action even though the provider payload creates many category criteria. Logical actions describe what the user asks to accomplish, not the number of technical operations required internally. If a request also pauses a campaign and changes another setting, show those as separate steps with their own targets. Resolve real dependencies among them rather than relying on the order of words in the message. Independent account exclusions should not be presented as the parent of unrelated campaign edits.
Check the complete intended change against the supported review safeguards. If the request needs smaller proposals, explain that requirement and ask the user to divide the work before execution. Do not execute an arbitrary subset and omit the rest. Within an accepted request, one confirmation should show every step clearly. The framework can group technical operations under the appropriate logical action while preserving exact targets, dependencies and verification requirements behind the readable proposal. This keeps the team's approval attached to meaningful effects rather than payload size.
Present one clear approval step
The proposal should state the action in ordinary language: exclude all available mobile app categories at account level, adding the currently missing exclusions. Name the connected account in a readable way without printing private identifiers. State the account-wide scope clearly so a user who began discussing one campaign understands the effect. Retaining existing exclusions is useful context. A long list of internal category resource names is unnecessary for this broad policy and makes the real action harder to recognise.
For a multi-action request, give each logical step a distinct visible section. The category action should not be buried inside a sentence that also changes a campaign status. Show the exact action and target for each step, with any meaningful current-to-proposed difference. Use one Confirm and Execute button for the complete accepted proposal. The message should say that no changes have been made yet and that the proposal expires in fifteen minutes. The live API call begins only after the authorised confirmation.
The user needs immediate acknowledgement when the button is pressed. Show a prominent change-in-progress state and prevent the same button from inviting a second simultaneous execution. That state should not include a user mention and should not claim completion. The final message can highlight executed and verified when the evidence supports it. If the request contains several logical actions, report their results separately so an owner can see whether the entire approved request completed. Readable status treatment matters because execution can take longer than a normal conversational reply.
Verify exact category coverage
The audit's direct apply action reads existing categories, submits only missing criteria and immediately reads the account criteria again. Its result compares the original intended universe against the returned set. The Slack preparation similarly declares a contains check for the requested category constants. Both preserve the central verification question: are the intended account-level categories now present? A mutation response alone is insufficient for that statement. Exact membership matters more than merely observing that an excluded count increased by some number.
Verify the correct account and criterion type. A campaign-level exclusion or an individual app placement does not satisfy an account-level category proposal just because its label looks related. The execution system must retain the exact approved resources behind the human-readable message. The ordinary result does not need to expose those identifiers, but the verification logic needs them. The owner should see a clear status and scope, while the system checks the provider fields necessary to support that conclusion.
Keep configuration verification separate from later distribution evidence. A successful membership read establishes the stored category criteria. It does not prove that historical reporting has no app rows, that every possible inventory surface is covered or that business performance improved. Those are different questions with different evidence. The final result should describe the action that was executed and verified, and a subsequent review can examine relevant delivery or outcomes. This separation makes a strong success message truthful rather than attaching unsupported business promises to a technical check.
Reconcile uncertain and partial results
If a request times out or verification cannot complete, inspect the exact account criteria before repeating the write. A failed connection can leave uncertainty about whether the provider accepted some operations. Because the action is prepared from missing categories, a new read can identify what remains. Do not blindly replay a stale payload. Reconciliation should preserve the approved policy while accounting for current state and any intervening changes. The owner needs a statement of what is verified and what still requires confirmation, not a guess that nothing happened.
A multi-action request can leave category coverage verified while a campaign edit remains unresolved. Report those outcomes separately. Conversely, a successful campaign pause does not justify marking the app exclusions successful if their check failed. The execution record should retain each logical step's intended targets and requirements. This makes the remaining work reviewable and avoids accidental omission. A concise normal reply can say which action completed and what remains uncertain without dumping the provider response or presenting a partial request as fully executed.
Use the smallest relevant follow-up read. Re-checking account category membership does not require rerunning the entire account audit, fetching keywords or generating a performance chart. That efficiency matters when many connected accounts interact concurrently. It also reduces ambiguity: the reconciliation question is whether the intended criteria are stored now. Once the system resolves that question, it can report the verified state or prepare a new specific corrective action. Additional performance research should follow only when the user asks for it or the business decision actually requires it.
Plan a specific correction rather than generic undo
An owner may later decide that the broad policy no longer fits. Treat that as a new request for a specific setting change, not a universal undo command. The original action retained pre-existing exclusions and added only missing categories. Removing every category afterwards could erase criteria the account intentionally had before the edit. The correction therefore needs the relevant current state and a clear definition of what the user wants restored. Historical execution evidence can inform that decision without replacing the current ownership and scope checks.
A supported removal should identify the actual account criteria to remove and verify their resulting absence. Do not infer a resource identifier from a category label or promise a removal tool that the current workflow cannot perform. If a selective correction requires another supported operation or a provider-interface handoff, explain it. The business decision remains useful even when the convenience exclude-all action is not the correct mechanism for reversal. Capability boundaries should be explicit so the owner does not believe that the new policy has already been applied.
Record the reason for changing direction. A new app programme, a revised distribution policy or evidence from a performance review can justify a different treatment. The record should distinguish this new decision from a failure of the original mutation. The prior action may have been executed correctly under an earlier policy. Clear chronology helps future colleagues understand why current settings differ from old audit screenshots. It also prevents repeated toggling driven only by the colour of the card, with no agreed commercial objective behind the changes.
Communicate the result in business language
A useful internal report identifies the policy, the account scope and the verified setting result. Explain that missing mobile app category exclusions were added and existing exclusions retained. If the owner intentionally keeps some categories available, describe that exception and its rationale. Do not mix the category coverage count with counts of individual apps, products or campaigns. A short, accurate summary helps business colleagues understand the action without becoming an API tutorial or a raw list of technical constants.
When performance research accompanies the policy review, show it as separate evidence with its period and available measures. State whether the result concerns campaign totals, reported placements or a narrower selection. Missing metrics should remain unavailable rather than being filled with zero or estimated from unrelated totals. If the data volume exceeds a readable Slack summary, provide an appropriate full report through the supported output workflow. The conversational summary should still explain the conclusion and selection boundary so the user can assess it without opening a technical export.
Keep success visible and specific. Executed and verified describes the stored category action, while the later outcome review remains a business evaluation. The user mention can appear before the feedback area in a normal final conversational reply, keeping feedback last. Progress should remain a clear status update without that mention. These presentation details support comprehension: the user sees that the approved account edit finished and can distinguish it from discussion, recommendation and future analysis. Readability should reinforce the evidence, not make an unsupported conclusion look more authoritative.
Keep the inventory policy current
Review the policy when the organisation's goals or distribution responsibilities change. A new app programme, a new business unit sharing the account or a revised brand standard can alter the right decision. The category universe can also evolve, so a previously complete set should be evaluated against current available categories when the owner requests renewed coverage. Routine review should remain proportionate. It does not require a full account investigation whenever someone asks whether the agreed account-level setting is still present.
Preserve a clear owner and an explanation for exceptions. A new paid specialist should be able to understand why categories are blocked or retained without reconstructing a long Slack conversation. The execution history should identify actual approved changes; the policy record should explain their purpose. Avoid recurring writes when the desired state is already verified. A useful monitoring process detects a meaningful difference and brings it to the right owner. It should not create operations merely to demonstrate activity or repeat a fixed recommendation without considering the current business context.
The in-house team gains a reliable workflow by keeping three questions distinct: what criteria are stored, what inventory policy it intends and what performance evidence supports further decisions. The current card answers the first within its category universe. Colleagues decide the second, and appropriate reporting investigates the third. Supported edits then follow exact targets, explicit confirmation and direct verification. This approach makes an exclusion audit useful beyond a one-time cleanup while avoiding a universal claim that app inventory is worthless or that a settings change guarantees improved returns.