Fix Google Ads negative keywords from Slack with evidence, scope, and explicit approval

Negative keywords are a decision about which searches the business does not want to pursue in a particular advertising context. They are not a universal list of words that every account should block. A term that is irrelevant to one campaign can be valuable to another, and a query with no recent conversion can still deserve investigation before exclusion.

Slack can make the evidence and decision easier to discuss. The assistant can retrieve relevant search and configuration data, help the user classify intent, and prepare supported live changes for approval. The business owner still supplies the offer boundaries and reviews the exact target and terms before execution.

This guide focuses on that handoff. The examples are invented and do not claim customer results. For the underlying account check, see the negative-keyword audit guide. The current dedicated ppctor addition actions use exact-match negatives; list creation and campaign attachment are separate operations. That distinction shapes both the proposal and its verification.

Define the unwanted intent

Start with the business's actual offer. A retailer may sell finished products but not spare parts. A service business may serve consumers but not employment seekers. An advertiser may pursue one product category in a campaign while another campaign handles a different category. These boundaries determine what “irrelevant” means.

Ask whether the unwanted intent applies to the whole campaign or only one group. A campaign can contain several product or service themes. A term that routes poorly to one group may still belong elsewhere in the account. The assistant should not turn a local relevance problem into a global exclusion without the user's decision.

Identify the desired alternative where one exists. If a query belongs to another offer, the task may be routing or structure rather than suppressing all demand. A negative can be part of that plan, but the business should understand which campaign or group is intended to handle the useful traffic.

Do not define unwanted intent solely as “no conversions.” The observation period, sample, conversion definition, and reporting maturity matter. A relevant query can have no observed outcome in a small sample. A query with a recorded outcome can still be commercially unsuitable. Business fit and performance evidence answer different questions.

State any known exceptions. A retailer that sometimes sells refurbished products should not casually approve a broad refurbished exclusion across every campaign. A service business that recruits through a separate campaign may need a narrower employment-related policy. The assistant should preserve those distinctions in the target scope.

Use ordinary language for the decision: “We do not offer repair services in this campaign” or “This group is only for the complete product.” The technical match type can then be chosen and reviewed explicitly. A clear business statement is easier to maintain than a collection of unexplained terms.

Keep the decision reversible at the appropriate level. Adding a term to one group and editing a shared list used by many campaigns have different consequences. The owner should understand that reach before approval. The convenience of a shared list is not a reason to broaden the policy.

Use search evidence carefully

When the user asks about actual account activity, retrieve the relevant search evidence for the named period and scope. A brainstormed list is not a search-term report. The assistant should distinguish observed queries from suggested exclusions based only on the offer description.

Keep the period explicit. Last month, the last thirty complete days, and a campaign's launch window can produce different findings. The result should state the dates used so the owner understands what the evidence covers. Do not silently substitute a convenient completed month for a rolling request.

Use metrics that match the business question. Spend, clicks, primary conversions, and the relevant primary conversion value can help evaluate observed traffic. A lead business may care about the specified primary lead outcomes rather than purchases. The assistant should not judge relevance from a mismatched revenue measure.

Apply requested conditions exactly. “Spend above the threshold and no primary conversions” is a joint condition. “Above or equal to” differs from strictly above. The retrieval and selection should preserve the user's logical meaning instead of translating a precise instruction into a loose recommendation.

Do not count unavailable data as zero. A failed provider read, an unsupported field, and a successful report with zero outcomes are different states. The assistant needs enough reliable evidence before presenting an exclusion as data-backed. If the read is unavailable, name that problem rather than claim the traffic performed badly.

Keep summary output separate from discovery coverage. The user may want a concise list of the most relevant candidates. That presentation limit should not become a silent cap on an account-wide count or a claim that every matching term was reviewed. Explain the actual population when coverage matters.

Retain the connection between each candidate and its source context. A term observed in one campaign does not automatically justify an exclusion in another. The user should be able to see why the assistant recommends that target and whether the same intent is useful elsewhere.

A short table can make the decision easier: query, campaign or group, relevant activity, and proposed reason. Keep money and ratios formatted clearly. Avoid raw internal field names and redundant identifiers that make a client-facing conversation resemble a technical export.

Understand the proposed match behavior

Google's negative-keyword guidance distinguishes negative match types from their positive counterparts. A negative exact match blocks the corresponding query without additional words, while broader negative forms have different coverage. Do not assume the behavior of a positive exact keyword describes a negative exact exclusion.

The dedicated ppctor addition actions currently prepare exact-match negatives. A proposal should say that clearly. If the user wants a wider phrase or broad exclusion, the assistant must use an applicable supported path or explain the boundary; it should not silently substitute a narrower exact addition and report the whole intent as completed.

For the reviewer, the key question is what the prepared term will exclude. An exact addition based on one observed query is a narrow decision. It should not be described as blocking every related topic or all variations of a business category.

Consider whether the observed query itself is the intended target. A user may say “exclude repair traffic” as a conceptual instruction. The assistant needs to turn that into explicit candidate terms and treatment for review. A concept alone is not a precise exact-negative list.

Google's guidance also explains that negative matching does not provide the same close-variant expansion as positive targeting. The business should therefore review the actual excluded terms rather than assume one addition covers every related expression. The tool's receipt should report what was added, not claim a complete semantic barrier.

Keep the proposed match type visible alongside the terms. Brackets or a clear exact-match label can communicate the treatment, but the output should remain understandable without requiring the user to know API enums. A sentence such as “Add these exact-match negative keywords to the campaign” provides a readable boundary.

Do not pretend that a larger exclusion is always better. Narrow additions can protect useful neighboring queries. Wider exclusions may be appropriate in a separately reviewed policy, but their effect needs to match the business's intent. The assistant should explain coverage rather than equate breadth with optimization.

For non-Search contexts, avoid reusing a Search explanation without checking the applicable behavior. Campaign types and exclusion mechanisms differ. The target and action need to be supported in that context before the assistant prepares a live request.

Choose the exclusion scope

A group-level negative applies a local decision. It can be useful when a query belongs elsewhere in the campaign or when one group's offer is narrower than its siblings. The proposal should name the group and parent campaign so the owner can see exactly where the exclusion is intended to act.

A campaign-level negative expresses a campaign-wide decision. Use it when the unwanted query does not belong anywhere in that campaign's offer. Do not choose it merely because the campaign name is easier to resolve than the actual group named by the user.

A shared list supports a reusable policy across selected campaigns. Editing that list can affect every campaign attached to it. The assistant should make that reach visible before adding terms, especially when the user discussed only one campaign in the conversation.

Google's shared-set documentation distinguishes creating a list container, adding its criteria, and associating it with a campaign. It also describes a separate account-level list type and attachment mechanism. A campaign shared list should not be described as automatically applying to the whole account.

The current dedicated list creator makes a campaign-oriented negative-keyword shared list. Creating it does not attach it to any campaign. Adding terms to an existing list also does not create a new campaign association. The proposed sequence must include the attachment when that is required and supported.

Do not assume every campaign type supports every list relationship. The Google API and application capability need to be valid for the selected target. For a PMax or other specialized request, use the applicable supported exclusion mechanism rather than invent an ad-group parent or promise a generic attachment works everywhere.

If the user requests one campaign, preserve that scope throughout discovery, proposal, and execution. A prior discussion about an account-wide policy does not automatically broaden the next live request. The assistant should use the current explicit instruction and established target context.

When the right scope is unclear, ask a concrete question. “Should these exclusions apply only to this campaign or to the campaigns using the shared list?” gives the owner a meaningful choice. A vague request for more information is less useful than identifying the actual policy decision.

Check existing negatives and list relationships

Read existing configuration before adding the requested terms. The dedicated addition builder compares the requested text and match type with the target's existing criteria and prepares missing additions. This helps avoid treating an already-present exclusion as a new live change.

The comparison is a configuration check, not a complete proof of every overlapping exclusion in the account. A term may also be covered through another level or list. If the user asks why traffic is excluded or whether a query is already blocked, investigate the applicable configuration rather than rely only on the one addition target.

For a shared list, check which campaigns are attached when the effect on current traffic matters. The list's contents and its relationships answer different questions. A list can contain suitable terms and still have no serving effect on the campaign the user named.

Check that the chosen list is active and belongs to the permitted account context. A familiar name is not sufficient if several lists share similar labels or if the conversation refers to another connected account. The system retains technical references internally while presenting readable names to the user.

If a requested attachment already exists, report that state. If a requested detachment is already absent, do not invent a change. A no-op can be a useful factual result, but it should not be packaged as a newly completed mutation.

When creating a new list, check for an existing active list with the proposed name. The user may have intended to update an existing policy rather than duplicate it. Resolve that distinction before approval. Clear naming improves maintenance, but names do not replace the underlying target relationship.

Keep related changes visible. Creating a list, adding terms, and attaching it are separate logical actions with dependencies. The assistant should not report “negative list created” as if the requested campaign protection is active when the attachment was omitted.

For a larger request, preserve an explicit scope record: source campaign or group, selected destination for the negatives, relevant existing list, and requested attachment. This record supports the proposal and later verification without requiring the user to inspect raw API resources.

Select candidates with business context

A candidate needs a reason the business can assess. “The business does not offer repairs” is a clearer relevance reason than “this term looks bad.” “This query belongs to the wholesale campaign” describes routing. “The requested report shows spend without the specified outcomes” describes observed performance that still needs interpretation.

Keep those reasons distinct. An irrelevant-service query can be excluded based on a known offer boundary. A relevant query with weak recent performance may call for landing-page or creative review instead. The assistant should not disguise a performance judgment as an obvious semantic exclusion.

Use the user's current product context. If the conversation already established the product, the assistant can brainstorm likely irrelevant intents without a provider call. Label the result as suggestions. When the user asks for actual account evidence, retrieve the relevant data rather than present the same brainstorm as measured traffic.

Ask about ambiguous terms before preparing them. A word can describe both a useful product feature and an unwanted service. A generic exclusion can cut across that distinction. The assistant should identify the uncertainty in the candidate meaning and seek the business decision, not make a silent guess.

Review commercial exceptions. Promotional, refurbished, comparison, and informational traffic may have different roles in the business's acquisition strategy. The account owner should decide whether those intents are excluded in the chosen campaign. A generic industry list cannot answer that decision reliably.

Respect delayed outcomes. A lead or purchase may arrive after the click, and a short report window may not contain its complete result. If the user sets a precise performance condition, apply it faithfully and explain the observed period. Do not claim that every zero in an immature window is a permanently worthless query.

Group the approved candidates by intended target. A mixed list can contain terms for one group, another campaign, and a reusable list. Present those as clear action sections rather than send every term to one convenient destination. The user should see the policy structure before confirming.

Keep rejected candidates in the discussion only when they explain an important decision. The final proposal needs the approved terms and treatment. A long list of every idea considered can obscure the live action and make the confirmation harder to review.

Protect useful traffic from conflicts

Before approval, compare the proposed exclusions with the campaign's intended offer and relevant positive targeting. The goal is to avoid blocking demand the business deliberately wants. A negative keyword can be correctly created at the API level and still be a poor commercial decision.

Google's negative-keyword troubleshooting guidance recommends checking negative configuration and lists when useful keywords are prevented from serving. It also notes that a diagnostic test is not a comprehensive test of every possible query. Use such diagnostics as evidence with a defined scope, not as universal proof.

Pay attention to shared-list reach. A term suitable for a consumer campaign may be unsuitable for a trade campaign using the same list. The owner should review all relevant attached contexts before expanding the reusable policy. The assistant should not hide that effect behind the list name.

Do not assume a positive keyword overrides a negative exclusion. The operator needs to understand the applicable configuration and resolve the conflict. Adding more positive terms is not a substitute for examining an exclusion that prevents the desired traffic.

A routing plan needs a destination for the useful intent. If the team excludes a query from one group because another group should handle it, check that the intended receiving setup is coherent. Otherwise, the operation can remove traffic without establishing the promised alternative.

Keep brand and competitor policies explicit. Businesses can have different strategies for these queries. The assistant should not automatically classify every competitor name as irrelevant or every brand-related query as valuable. The campaign objective and owner-approved policy determine the treatment.

Do not treat one overlap check as complete account protection. The available read may cover a specific target and requested terms. If the user needs a wider conflict investigation, retrieve the relevant levels and relationships. The answer should identify the actual coverage.

When a conflict is discovered, correct the plan before confirmation. Do not proceed with a known bad candidate and leave the fix for later. The approval message should contain the final intended treatment, not a proposal the assistant already knows is inconsistent with the user's offer.

Create and attach lists deliberately

A new list starts as a container. Its name should describe a stable policy, such as a set of genuinely unrelated service queries, rather than an unexplained date or temporary analyst note. The user should understand what belongs in it before the first terms are added.

Add the approved terms with the explicitly supported match treatment. The current dedicated additions are exact match. A list name that suggests a broad subject does not change those criteria into a broader semantic exclusion. The contents and match type remain the operational facts.

Choose campaign attachments deliberately. The list should apply only where the policy is valid and the relationship is supported. Do not attach it everywhere merely because the account-wide audit highlighted missing negatives in several campaigns.

The dependency sequence is local and understandable: create the list if needed, add the approved terms, and attach it to the selected campaign. If the list already exists, creation is unnecessary. The tool should reuse the valid target and avoid extra provider work for a dependency that is already resolved.

Show each step in the proposal. The reviewer can see the difference between building the list and making it applicable to a campaign. One confirmation can approve the supported sequence, but the message must not collapse its distinct effects into a vague “fix negatives” sentence.

For detachment, identify the relationship being removed. The list can remain in the account and may remain attached elsewhere. Detaching it from one campaign is not the same as deleting the list or all its terms. The receipt should use language that reflects the actual operation.

If a list needs maintenance for only one campaign, consider whether editing the shared contents is too broad. A local campaign addition or a separately defined list may better match the business decision. The assistant can explain the choices before preparing the selected supported action.

Do not blindly repeat a chain after an uncertain result. The list may have been created and populated even if a later attachment read failed. Inspect the current state and reconcile the remaining step. Repeating creation can produce duplicates or collide with an existing name.

Review the exact proposal

The proposal should name the target in ordinary terms: campaign, group within campaign, or shared list. If a list is being changed, explain that its attached campaign relationships determine where the exclusions apply. Do not invent a campaign parent for a reusable account-owned list.

List the exact terms that will be added and the match type. A reviewer should not have to infer the text from an earlier brainstorm or technical payload. If the assistant refined a term during the discussion, the final proposal must show the final wording.

Use separate visible steps for list creation, term addition, and attachment. The message should show the relationship being established and any retained existing configuration. A readable sequence prevents the user from confusing an empty newly created list with active campaign exclusions.

Explain no-op findings plainly. If all requested criteria already exist, say that there are no new additions to prepare. If the list is already attached, report the relationship rather than manufacture an extra action. The system should not perform work solely to produce a success receipt.

Keep raw IDs and internal resources behind the scenes. The approver needs names, parents, terms, and effects. The execution tool retains the exact references internally. Human-readable output can remain precise without exposing implementation detail beside every asset.

The proposal should also state any material scope boundary. Exact additions do not exclude every related query. A campaign attachment does not apply to the whole account. An account read is not a complete website investigation. These boundaries belong where they help the user approve the intended action.

Before confirmation, reconcile exceptions and changes to the request. If the user removes a candidate or narrows the campaign scope, the proposal must reflect that current decision. Approval of an earlier broader list should not be reused for a different final plan.

Confirm and verify the edit

The prepared review explains that no changes have been made yet and that it expires in fifteen minutes. The connected approver clicks Confirm and Execute when the exact target and action are correct. An ordinary discussion of candidates should not bypass this live-edit handoff.

The execution flow checks authorization and relevant configuration again. The account may have changed while the user reviewed the proposal. If the prepared assumptions no longer hold, the system should reconcile the state rather than overwrite intervening work casually.

A visible progress state indicates that the operation is underway. Wait for the final result before preparing an overlapping request. Progress is not a verified success message, and repeated clicks should not be used as a way to accelerate the provider's response.

For additions, verification checks the requested criteria. For a list creation, it checks the relevant created-list result. For attachment or detachment, it checks the campaign relationship. Each result should match the action it claims to verify.

A verified configuration edit does not prove the business achieved a particular cost reduction. It establishes the requested exclusion or relationship. Later performance and search evidence can evaluate the commercial effect. The receipt should not announce savings that were never measured.

If complete verification is unavailable after a sent edit, inspect the live state before another request. A provider write can succeed while a later read fails. Blindly repeating the operation can create confusing duplicates or repeat a larger chain unnecessarily.

For a multi-step outcome, distinguish completed and unresolved steps. The list may exist while the intended attachment remains unverified. A blanket failure statement can hide successful creation, while a blanket success statement can hide the missing relationship. The user needs the actual result.

Keep the final record concise: approved terms, target, match treatment, relationship changes, and verification outcome. This record is enough to support later maintenance without reproducing the full technical request in the conversation.

Evaluate later results without changing definitions

After the edit, choose a suitable observation window for the business outcome. An immediate report may contain little new activity and incomplete conversion results. The team should know when the exclusion took effect and which later data is mature enough to compare.

Keep the same metric definition across the comparison. If the first report used all primary conversions, do not switch the later report to purchase-only outcomes without saying so. If value was the decision metric, preserve the intended primary-value scope. A changed definition can masquerade as an exclusion effect.

Separate observed changes from causal claims. Spend can decline after an exclusion while demand, budget, bidding, promotion, or stock also changes. A factual report can show the movement and context without claiming that the negative keyword alone caused it.

Check whether the unwanted observed query remains in later evidence and consider the prepared match treatment. An exact exclusion is narrow. Seeing a different related query does not automatically mean the original criterion failed. Investigate the actual query and applicable configuration before adding more terms.

Monitor useful traffic too. A policy can remove unwanted intent while also revealing a conflict with a desired query or campaign. The owner should review both sides of the decision rather than celebrate a lower click count as an inherently better result.

For lead businesses, combine account outcomes with the business's known qualification context when available. Do not invent lead quality from an event name alone. The relevant primary lead actions and user-supplied commercial interpretation can guide the next review.

Keep shared-list maintenance deliberate. A later candidate should not automatically enter the reusable list merely because a similar term was previously approved. Check whether its meaning and cross-campaign applicability are genuinely the same.

If the policy no longer fits the offer, revisit it. The business may start selling a product it previously excluded or create a campaign for a formerly unwanted intent. Configuration should follow the current strategy rather than preserve old negatives as untouchable history.

Three illustrative exclusion decisions

A retailer excludes an unrelated repair query

An invented retailer sells complete grooming products but does not provide repairs. A Search report shows a specific repair-service query in a campaign intended for product purchases. The owner confirms that the query is outside the offer and approves a campaign-level exact negative for that observed term.

The proposal shows the campaign, exact text, and match treatment. After confirmation, verification checks the added criterion. The team does not claim that every repair-related query is now blocked. It reviews later evidence with the same purchase-value definition and period discipline.

The candidate was selected because of a clear business boundary, supported by observed context. The operator did not need to suppress every informational query or attach a global list to unrelated campaigns. The narrow scope makes the decision understandable and maintainable.

An agency builds a reusable irrelevant-intent list

An invented agency manages several campaigns with the same owner-approved offer boundary. The client wants a small reusable list of exact exclusions, attached only to the selected eligible campaigns. The agency first checks whether the intended list already exists and whether its contents and relationships match the request.

Where creation is needed, the plan exposes the container, additions, and attachment as separate steps. The owner confirms the supported sequence. The final result distinguishes list contents from campaign applicability, so an empty or unattached list cannot be mistaken for completed protection.

A later campaign with a different offer does not inherit the list by default. The agency reviews the policy for that campaign before attachment. Reuse saves maintenance effort only when the business meaning is genuinely shared.

A service business retains a relevant low-volume query

An invented service business asks whether a query with recent spend and no recorded leads should be excluded. The query describes a service the business does offer. The available period is short, and the owner explains that inquiries often arrive later in the customer journey.

The assistant reports the observed metrics and does not label the query irrelevant. The team chooses further investigation of the destination and message before a live exclusion. Leaving the configuration unchanged is a concrete decision supported by the current evidence and business context.

If the owner later approves an exclusion, the assistant can prepare the exact target and treatment. The current discussion remains a read and interpretation task. This protects the business from converting every early zero into an automatic negative.

Use a productive Slack conversation

A data-backed request can be specific: “Show search terms in the Services campaign with spend above my threshold and no primary leads during the last thirty complete days.” The assistant should retain the requested conjunction, metric scope, dates, and campaign boundary.

A creative request can be conversational: “Suggest irrelevant search intents for this product, based on the offer we discussed.” That does not require Keyword Planner or an account mutation. The response should identify suggestions as suggestions rather than pretend they were observed in the account.

Move from discussion to action explicitly: “Add these three observed queries as exact negatives to this campaign.” The tool prepares the proposal for that target. It should not broaden the action into a shared-list edit unless the user requested and reviewed that choice.

For a list workflow, name the intended policy and attachment: “Create a list for these approved exact terms and attach it to the selected campaign.” If the list already exists, the assistant can explain the existing state and prepare only the missing work.

For a follow-up, preserve established context while checking current facts. “Use the same campaign” can refer to the resolved conversation target. If several campaigns were discussed, clarify which one before proposal. Ordinary context handling should not require the user to copy internal account or asset identifiers.

After execution, ask for the exact verification that matters. The answer can confirm the criteria or campaign relationship and state any unresolved result. It should not replace a precise outcome with a generic promise that the account is now optimized.

Maintain a useful negative-keyword policy

Document the policy in business terms. Name the excluded intent, applicable campaigns, known exceptions, and owner. This is more useful than a list whose meaning exists only in the analyst's memory. The next operator can assess a proposed addition against the current offer.

Review list attachments during campaign launches and account handovers. A well-maintained list can still be applied to the wrong campaign or remain unattached where it was intended to act. Contents and relationships need their own review.

Revisit exclusions when the product catalogue, service offer, geography, or campaign strategy changes. An old negative can become inappropriate after the business starts serving the previously excluded intent. The assistant should use the current decision context rather than defend every historical term.

Keep explanations concise enough to remain useful. A short reason attached to an important policy is better than a lengthy report that nobody reads. Detailed evidence can be retained where needed, while the live proposal remains focused on the exact terms and scope.

Do not confuse presence with quality. A campaign containing negatives can still have an unsuitable policy. An audit that identifies missing coverage creates a review task, not proof that adding any terms will improve results. Candidate selection still needs business context and appropriate evidence.

Separate routine review from scheduled automation. A conversational approval authorizes the prepared edit; it does not create an ongoing rule that excludes future queries. Any recurring workflow needs its own explicit configuration and supported behavior. Read the automation workflow guide for that distinction.

Common negative-keyword questions

Does the assistant automatically exclude every query with no conversions?

No. A zero in a report is evidence for the selected period, not a universal relevance judgment. Review the business offer, sample, outcome definition, and requested conditions. Live additions require a concrete proposal and confirmation.

Which match type do the dedicated addition actions use?

They currently prepare exact-match negatives. The proposal should show that treatment. A request for a wider exclusion must not be silently reduced to exact match while the assistant reports the whole intention as complete.

Does creating a shared list apply it to a campaign?

No. Creation, adding criteria, and campaign attachment are separate operations. The supported plan should include the required relationship explicitly, and verification should distinguish the list's existence from its applicability.

Can editing a shared list affect more than one campaign?

Yes, the attached campaign relationships determine its reach. Review that scope before changing contents. A term discussed for one campaign should not silently become a reusable policy for every campaign using the list.

Does a verified addition prove savings?

No. It verifies configuration. Evaluate subsequent activity and business outcomes with a suitable period and stable metric definitions. Do not attribute every later change in spend or revenue solely to the exclusion.

What belongs in the confirmation message?

The readable target, correct parent where applicable, exact terms, match treatment, and list relationship changes. Each logical action should have its own visible section. The Confirm and Execute guide explains the approval, progress, and verification handoff.