How to Use Negative Keywords (and Match Design) to Stop Broad Spend From Waste-Flowing

If you run Apple Search Ads, you’ve seen it: broad match brings installs… and then one day ROAS looks worse, even though clicks and installs still happen. The issue usually isn’t that broad match is “bad.” It’s that broad match is unconstrained, so a small set of irrelevant queries can keep siphoning budget. Negative keywords and match-type design are the tools to turn broad from a money pit into controlled discovery.

Below is a practical way to set this up and maintain it weekly.

Why negative keywords matter more with broad match

On Search Results keywords, you can use exact and broad. Broad keywords can match a wider set of searches than exact, increasing discovery but also pulling in traffic that isn’t actually buying.

Because Apple Search Ads is a CPT (cost per tap) auction, you’re paying for taps whether they convert or not. Your keyword set is your steering wheel. Negative keywords are how you remove known irrelevant traffic from ever getting taps.

Two important realities:

• Apple doesn’t give you per-keyword revenue directly. You’ll infer profitability via your install → purchase chain (e.g., with RevenueCat) and the attribution token.
• Attribution resolves within ~24h, but your reporting may lag (and subscription revenue will lag further). That means you want to clean keywords based on early engagement signals, then confirm with purchase outcomes later.

Build the foundation: separate “discovery” from “harvest”

Before adding negatives, make sure your campaigns are structured so you can learn.

A common indie-friendly pattern:

• One ad group (or campaign) for discovery using broad terms.
• One ad group (or campaign) for harvest using exact terms you already know are profitable.

This separation makes negative keywords safer. If you only have one blended keyword set, it’s harder to know whether a negative is blocking something useful.

Quick design checklist

• Your Search Results keywords should be primarily where you spend (unless you have a specific reason otherwise).
• Make sure your broad keywords are close to your actual user intent (don’t start with generic words that describe millions of apps).
• Keep bids reasonable for discovery so “mistakes” are contained.

Step-by-step: create negative keywords from search term evidence

Apple lets you review search terms that triggered your ads. That’s your raw material for negatives.

1) Export/inspect recent search terms

Pick a timeframe that’s long enough to see patterns but short enough to stay actionable (for example, “last 7–14 days,” depending on your volume).

For each search term, collect:

• Impressions
• Taps
• TTR (taps / impressions)
• Installs
• Install rate (installs / taps)
• CPA/CPI proxy (what you’re effectively paying per install)
• Your downstream conversion signal (purchase/subscription), if you can map it (RevenueCat + attribution token is typical)

2) Classify search terms into three buckets

You’re looking for terms that are clearly not aligned with your app.

• Bucket A: clearly irrelevant

  • High taps, low/no installs
  • Or installs exist but no meaningful conversion
  • Often: competitor names you can’t serve, unrelated feature searches, or “free”/“crack” style phrasing (if your app doesn’t match).

• Bucket B: ambiguous

  • Moderate installs but weak conversion quality
  • These may become profitable later, especially if your product page converts poorly right now.

• Bucket C: aligned

  • Good install rate and improving conversion
  • These are candidates to promote to exact.

Negative keywords should start aggressively with Bucket A.

3) Add negatives to block Bucket A from triggering

Workflow:

• For each Bucket A term (or close variant), add a negative keyword at the appropriate scope (keyword/campaign/ad group depending on your account setup).
• Start with the most obvious phrases first.

Why “obvious” matters: if you add a negative too broad, you risk blocking future intent that you haven’t validated yet.

How to choose the negative text (avoid accidental over-blocking)

The biggest indie pitfall is writing negative keywords that are so general they become a self-sabotage tool.

Use “specificity over coverage”

Instead of negatives like:

• music

Prefer terms like:

• competitor-specific strings (if you know those queries are irrelevant for your app)
• exact feature combinations you don’t support
• intent modifiers that don’t match (e.g., “offline wallpaper” if your app isn’t that)

Prefer negatives that match your observed failures

If a term shows:

• high taps and low install rate, it’s likely mismatch at the store.
• low taps but still poor installs, it may be too rare to matter—don’t over-optimize.

Remember: you’re not trying to predict; you’re trying to prevent the most costly mistakes.

Use match-type design to reduce the need for negatives

Negatives are a cleanup tool. Match-type structure is prevention.

Exact = confirmation, broad = exploration

Treat exact match as your “harvest” layer:

• Once you identify a search term that converts, move that idea to exact.
• This reduces dependence on broad for profitable intent.

Broad should be kept “wide but not stupid.” Broad learns, but it can only learn from what you allow.

Don’t rely on one broad keyword to cover everything

If you have one broad keyword that tries to describe your entire app category, it will match too many interpretations.

Better approach:

• Use several broad keywords that each represent a narrower intent cluster.
• Then use negatives to trim the worst off-target matches.

A weekly maintenance routine that actually sticks

Here’s a workflow you can run without living in the ASA UI.

Once per week (15–25 minutes)

1. Pull search terms from the last 7–14 days.
2. Identify Bucket A: high taps / poor install rate / poor conversion quality.
3. Add negatives in small batches (so you can measure impact).
4. Promote Bucket C terms to exact (optional, but it compounds learning).
5. Check if your overall TTR on Search Results is stable and if CPA/CPI improves.

After changes (wait for attribution + subscription lag)

• Attribution resolves within ~24h, but subscription revenue and purchase confirmation may take longer.
• Give changes at least several days to reflect in revenue/ROAS, especially if you’re optimizing subscriptions.

What “success” looks like after adding negatives

You should see one (or more) of these outcomes:

• Lower spend on the same campaign while maintaining taps or installs (meaning you removed waste)
• Improved taps-to-install conversion rate
• Improved CPA/CPI
• Later: improved ROAS after revenue attribution settles

Avoid expecting miracles instantly. Sometimes negatives mainly improve efficiency (less waste) rather than creating new demand.

Troubleshooting: when negatives don’t help

If you add negatives and performance doesn’t improve, check these common issues:

• Your store conversion is the real bottleneck: search terms may be fine, but the product page doesn’t convert. That shows up as weak install rate or weak post-install conversion.
• You blocked too little: the worst traffic might be coming from terms you haven’t identified yet. Repeat the process with a bigger data window.
• You blocked too much: your total impressions/taps drop sharply and install volume collapses. Roll back by removing the most suspect negatives.

Small note on how this fits into an advisory workflow

If you want an extra set of eyes, tools like AdsBuddy can ingest your Apple Search Ads + revenue signals and generate a short, prioritized list of what to change next (including negative keyword candidates). You still approve the changes yourself—nothing gets applied automatically by default.

Takeaway

Negative keywords aren’t a one-time setup—they’re part of maintaining control over broad match. The winning approach is simple: separate discovery from harvest, classify search terms using early efficiency signals, block the clearly irrelevant bucket first, and then validate with purchase outcomes once attribution settles.